Dev parti : 5 décisions avant de recruter un développeur

Un de mes clients a découvert un mardi matin que son application tournait sur le compte AWS personnel de son freelance. Le freelance avait livré six mois plus tôt. Facturé. Et il ne répondait plus.

Le code était là. L'app tournait. Mais les clés de la maison étaient dans la poche de quelqu'un d'autre. Voici le plan d'action que j'applique quand un dirigeant m'appelle dans cette situation — et ça arrive plus souvent qu'on ne le croit.

Décision 1 — Sécuriser tous les accès dans les 48 heures

Pas recruter un remplaçant. Pas "comprendre le code". Sécuriser les accès.

J'ai accompagné un fondateur qui dépendait de son freelance pour tout : serveur, base de données, nom de domaine, Stripe, service d'envoi d'emails. Le freelance avait créé chaque compte à son propre nom, avec son email perso. Quand il est parti, le fondateur n'avait littéralement aucun accès à sa propre entreprise numérique.

Le freelance ne faisait pas ça par malveillance. Il avait créé les comptes au fil du développement, avec son email, parce que c'était plus rapide. Personne n'avait pensé à transférer. Personne ne pense jamais à transférer.

Ce qu'il faut récupérer, dans l'ordre :

• Hébergement (AWS, OVH, Scaleway, Vercel…) : à quel nom est le compte ? Si c'est celui du prestataire, transfert immédiat.
• Nom de domaine : vérifier le propriétaire dans le registrar. Le domaine, c'est votre adresse. Sans lui, vous n'existez pas.
• Base de données : récupérer les identifiants. Faire une sauvegarde ce jour-là — pas demain.
• Services tiers : Stripe, SendGrid, Firebase, Google Analytics, Apple Developer, Google Play Console. Tout lister, tout vérifier.
• Repo Git : le code source est sur GitHub, GitLab, Bitbucket ? À quel nom ? Avez-vous un accès admin ?

Chaque jour sans ces accès est un jour où un email sans réponse peut bloquer votre business. Si le prestataire coopère, ça prend une demi-journée. S'il ne répond plus, chaque semaine de retard complique la récupération. J'ai vu des situations se résoudre en 48 heures — et d'autres traîner 2 mois parce que le fondateur avait attendu "pour voir".

Si vous voulez savoir quelles questions poser pour évaluer l'état de vos accès et de votre sécurité, j'ai écrit une checklist concrète pour dirigeants non-techniques.

Décision 2 — Vérifier que vous possédez votre code

L'anecdote la plus douloureuse de ma carrière sur ce sujet : une agence web avait livré un projet complet — design, code, déploiement. Le client avait payé 35 000 €. Six mois plus tard, l'agence a fermé. Le code source était sur le compte GitHub de l'agence. Le compte a disparu avec l'agence. Le client n'avait aucune copie.

Il a refait développer son application. Depuis zéro. 35 000 € de plus.

La question à poser maintenant : le contrat de prestation prévoit-il le transfert de propriété intellectuelle du code ? En droit français, par défaut, l'auteur du code conserve ses droits. Si votre contrat ne mentionne rien sur la cession de propriété intellectuelle, le code n'est juridiquement pas à vous — même si vous l'avez payé.

Même si le contrat est clair, vérifiez les faits :

• Le repo Git est-il sur votre compte ou celui du prestataire ?
• Les déploiements tournent-ils sur vos serveurs ou les siens ?
• Les clés d'API (Stripe, services cloud) sont-elles à votre nom ?

Si le prestataire est parti en bons termes, demandez un transfert de tout. Par écrit — un email suffit, mais il faut une trace. Si la relation est tendue, consultez un avocat spécialisé en propriété intellectuelle avant de tenter quoi que ce soit. Je ne suis pas juriste, mais j'ai vu assez de ces situations pour savoir que l'improvisation juridique finit mal.

Décision 3 — Faire auditer le code avant de recruter qui que ce soit

C'est l'erreur que je vois le plus : le dirigeant panique, lance un recrutement développeur dans la semaine, et met le nouveau sur le code existant. Le dev ouvre le projet, découvre un chaos sans documentation, et passe les 3 premiers mois à essayer de comprendre ce qui se passe.

Un de mes clients a vécu ça. Coût de la montée en compétence improductive : 15 000 € de salaire avant la première ligne de code utile. Le dev a fini par démissionner — pas par incompétence, mais parce que le code était un mur.

Un autre client pensait avoir un "produit fini". L'audit a révélé un prototype. Pas de tests. Pas de gestion d'erreurs. Des mots de passe utilisateurs stockés en clair dans la base. Le produit "fonctionnait" — comme une voiture sans freins roule. Jusqu'au premier virage.

Avant de recruter, faites auditer le code par un tiers indépendant. Un audit de code prend 2 à 5 jours et coûte entre 1 500 et 5 000 €. Ce qu'il vous dit :

• Le code est-il maintenable ? Un nouveau dev peut-il travailler dessus sans perdre 3 mois ?
• Y a-t-il des failles de sécurité ? Vos données utilisateurs sont-elles exposées ?
• Quelle est la dette technique ? Combien ça coûte à remettre en état ?
• Faut-il continuer sur cette base ou repartir ? C'est la question à 50 000 €.

Sans cet audit, vous recrutez à l'aveugle. Vous ne savez pas si vous avez besoin d'un dev junior en maintenance ou d'une équipe senior pour une refonte. Si l'audit révèle une dette technique lourde, j'ai détaillé la marche à suivre dans reprendre un code existant sans tout casser.

Décision 4 — Documenter ce qui ne l'a jamais été

Si votre prestataire n'a pas documenté le projet — et dans mon expérience, 4 projets sur 5 n'ont aucune documentation exploitable — chaque jour qui passe rend la connaissance plus difficile à reconstruire.

Un fondateur m'a appelé 8 mois après le départ de son freelance. Entre-temps, il avait recruté un dev. Le dev avait passé 3 mois à comprendre le code, puis avait démissionné — frustré de travailler à l'aveugle. Le fondateur cherchait un deuxième dev. Je lui ai dit : "Avant de recruter, documentez. Sinon votre prochain dev partira pour les mêmes raisons."

Ce qu'il faut documenter en priorité :

1. L'architecture : comment l'application est structurée, quels services communiquent entre eux, où sont stockées les données
2. Le processus de déploiement : comment mettre le code en production — c'est souvent un enchaînement de commandes que seul l'ancien dev connaissait par cœur
3. Les dépendances externes : quels services tiers sont utilisés, pourquoi, et comment ils sont configurés
4. Les accès : la liste complète des comptes, serveurs, API (normalement fait à la Décision 1, mais formalisé ici dans un document de référence)

Qui peut le faire ? Pas vous — vous n'êtes pas technique et c'est normal. Un dev senior en mission courte de 2-3 jours. Ou un CTO externalisé qui prend le temps de comprendre le projet et produit un document de référence. Investissement : 1 000 à 3 000 €. Économie : des mois de flottement à chaque recrutement ou changement de prestataire.

Décision 5 — Choisir la suite : recruter, externaliser, ou attendre

Vous avez sécurisé les accès. Vous savez ce que vous possédez. Le code a été audité. La documentation existe. Maintenant — et pas avant — vous pouvez prendre une décision éclairée.

Recruter un développeur en interne si votre produit est au cœur de votre activité et évolue en permanence. Comptez 45 000 à 65 000 € brut chargé annuels pour un profil junior/intermédiaire, plus 2-3 mois de montée en compétence. Le recrutement lui-même prend 2 à 4 mois. C'est un engagement long, mais c'est le seul qui construit de la connaissance en interne.

Reprendre un freelance ou une agence si vos besoins sont ponctuels — moins de 2-3 jours par semaine. Le piège : retomber dans la même dépendance. Pour l'éviter cette fois : propriété du code dans le contrat, repo Git à votre nom, documentation obligatoire, accès partagés dès le jour 1. Tout ce que vous n'aviez pas avant.

Faire appel à un CTO externalisé si vous ne savez pas encore de quoi vous avez besoin. C'est la situation la plus fréquente. Vous sortez d'une mauvaise expérience, vous n'avez pas les compétences pour évaluer un dev ou cadrer un recrutement, et vous ne voulez pas refaire la même erreur. Un CTO externe cadre le recrutement, supervise les prestataires, prend les décisions d'architecture. Il vous évite les erreurs de casting qui coûtent 6 à 12 mois de salaire perdu.

Le piège à éviter : recruter dans l'urgence, parce que "le produit ne peut pas attendre". Quatre semaines de préparation vous font gagner six mois de productivité. Chaque client qui a sauté les étapes 1 à 4 l'a regretté.

Checklist : les 48 premières heures et la suite

Jour 1 :

• Lister tous les services et comptes liés au projet
• Vérifier à quel nom est chaque compte
• Contacter le prestataire pour demander le transfert des accès (par écrit)
• Faire une sauvegarde complète : code source, base de données, fichiers

Jour 2-3 :

• Relire le contrat : clause de propriété intellectuelle ?
• Vérifier que le repo Git est accessible et complet
• Changer les mots de passe des comptes récupérés
• Lister les questions sans réponse (déploiement, sauvegardes, services critiques)

Semaine 2 :

• Contacter un auditeur pour un audit de code indépendant
• Identifier les failles de sécurité prioritaires
• Commencer la documentation de l'existant

Semaine 3-4 :

• Analyser le rapport d'audit
• Décider : maintenance, évolution, ou refonte
• Lancer le recrutement développeur ou la recherche de prestataire — pas avant d'avoir fait tout le reste

Ce que ça coûte de ne rien faire

Le coût d'un prestataire qui part sans transfert d'accès, sans documentation, sans cadre contractuel ? Entre 10 000 et 50 000 € de surcoûts selon la taille du projet. J'ai vu les deux extrêmes. Le fondateur qui récupère la main en une semaine parce que tout était à son nom. Et celui qui a dû redévelopper une app complète parce que le code était perdu.

Le coût de la prévention — contrat clair, accès à votre nom, documentation continue — c'est quelques heures de rigueur au démarrage du projet.

Si vous êtes dans cette situation maintenant, les 5 décisions ci-dessus sont dans le bon ordre. Commencez par la première. Si vous avez besoin d'un regard technique pour cadrer la suite — audit, documentation, recrutement — c'est exactement ce que je fais en CTO externalisé.