Votre dev clé part : que faire ?

Votre développeur clé annonce son départ. Il connaît la codebase, les accès, les scripts de déploiement et les zones qu'il ne faut surtout pas toucher. Sur le papier, le produit continue de tourner. En pratique, vous venez peut-être de découvrir que votre startup dépendait d'une seule personne.

La mauvaise réaction consiste à chercher un remplaçant dès la première heure. Vous recrutez dans le brouillard, sans savoir si vous avez besoin d'un builder, d'un profil infra, d'un senior produit ou d'une personne capable de reprendre une dette critique.

Il faudra recruter ou réorganiser. Mais avant ça, il faut comprendre ce qui peut casser, ce qui doit être récupéré, et ce que vous devez sécuriser tant que la personne est encore disponible.

Un départ clé n'est pas seulement un sujet RH. C'est un audit technique en accéléré.

Les 72 premières heures

Les trois premiers jours servent à réduire l'incertitude. Pas à tout résoudre.

Quand un développeur clé part, le risque principal n'est pas toujours le code. C'est la connaissance implicite : où sont les secrets, comment on déploie, quelles parties sont fragiles, quels comportements historiques n'ont jamais été documentés.

Votre objectif est simple : transformer cette mémoire orale en informations exploitables.

Commencez par poser un cadre calme. Si le départ se passe correctement, vous avez encore une fenêtre pour récupérer du contexte. Si le départ est tendu, sécurisez les accès plus vite, mais sans chasse aux sorcières. Le but est de garder le produit pilotable.

Dans une reprise, je commence par obtenir quatre choses :

• une cartographie des accès critiques ;
• une liste des zones techniques sensibles ;
• une procédure de déploiement reproductible ;
• un point clair sur les chantiers en cours.

Une page bien structurée vaut mieux qu'un document parfait jamais terminé.

Le piège, c'est de passer ces trois jours à parler contrat, préavis ou recrutement. Ces sujets comptent, mais ils ne remplacent pas le travail de reprise.

Ce qu'il faut récupérer avant le départ

La première liste à construire concerne les actifs techniques.

Qui possède le compte GitHub, GitLab ou Bitbucket ? Qui paie l'hébergement ? Où sont les domaines ? Qui a accès au DNS ? Où sont les clés API ? Qui peut déployer ? Qui peut restaurer une base ?

Ces questions semblent basiques. Pourtant, je les vois revenir très souvent dans les startups post-MVP. Tant que la personne clé est là, tout fonctionne. Le jour où elle part, chaque action simple devient une enquête.

J'ai vécu une version très concrète de ce risque avec un DevOps qui détenait le seul accès à un VPS. Ce serveur faisait tourner le pipeline de données d'un produit. La mission était terminée, mais il a quand même accepté de nous aider à récupérer l'accès après son départ.

On s'en est sorti parce que la personne a été correcte, pas parce que le système était sain. Ce n'est pas un plan de continuité.

Il faut donc récupérer les accès et leur logique.

Un export de mots de passe ne suffit pas. Vous devez comprendre quels accès appartiennent à l'entreprise, lesquels doivent être transférés, lesquels doivent être révoqués après le départ.

La checklist minimale :

• dépôt de code et droits d'administration ;
• hébergement, cloud, Vercel, serveurs, containers ou jobs planifiés ;
• base de données, sauvegardes et outils de restauration ;
• DNS, noms de domaine, certificats, emails transactionnels ;
• outils de monitoring, logs, alerting et analytics ;
• services externes : paiement, CRM, IA, stockage, webhooks ;
• comptes Apple, Google, Stripe, SendGrid, Resend ou équivalents ;
• documentation existante, même incomplète.

Le sujet sensible, ce sont les comptes personnels utilisés pour des actifs de l'entreprise. Un SaaS ne devrait pas dépendre du compte privé d'un développeur. Si c'est le cas, transférez ce qui peut l'être et documentez le reste.

Ce travail rejoint ce que je regarde dans un audit technique startup : les risques qui peuvent bloquer l'entreprise, pas seulement les défauts de code.

Les accès à sécuriser

L'inventaire dit ce que l'entreprise possède. La sécurisation dit ce qu'elle doit reprendre en main.

L'erreur fréquente consiste à tout couper trop vite. Ça rassure, mais ça peut vous bloquer si personne d'autre ne sait encore opérer le produit. L'autre erreur consiste à ne rien changer pendant des mois, parce que "tout s'est bien passé".

La bonne approche est progressive.

Créez ou vérifiez les comptes d'administration qui appartiennent à l'entreprise. Ajoutez une deuxième personne de confiance sur les outils critiques. Préparez la révocation des accès personnels pour la date de départ effective.

Sur les secrets techniques, soyez plus strict. Clés API, tokens, clés SSH, accès base de données, webhooks de paiement : tout ce qui permet de lire des données, modifier la production ou déclencher des actions sensibles doit être revu.

Changer tous les secrets d'un coup peut casser le produit si vous ne savez pas où ils sont utilisés. Procédez par ordre de criticité :

• secrets liés aux données clients ;
• accès production et base de données ;
• moyens de paiement et webhooks ;
• déploiement et CI/CD ;
• outils moins sensibles.

Chaque rotation doit être testée. Une clé supprimée trop vite peut faire tomber une intégration discrète, comme un webhook Stripe ou un envoi d'email transactionnel.

Pour un fondateur non-tech, ce moment est inconfortable. Pourtant, c'est de la gouvernance : vous vérifiez que l'entreprise possède son produit.

Les zones techniques à auditer

Une fois l'urgence contenue, il faut regarder la codebase.

Pas pour tout refactorer. Pour savoir où se trouve le risque de reprise.

Le premier indicateur est le bus factor. Combien de personnes peuvent modifier, déployer et diagnostiquer le produit sans appeler la personne qui part ? Si la réponse est une seule, votre priorité n'est pas de livrer une nouvelle feature. Votre priorité est de rendre le produit transmissible.

Je regarde cinq zones en priorité.

La première, c'est le déploiement. Un nouveau développeur peut-il lancer le projet en local, déployer en staging et comprendre ce qui se passe si le build échoue ? S'il faut une demi-journée d'appels pour refaire tourner l'environnement, vous avez déjà un problème.

La deuxième, ce sont les flux métier critiques : inscription, paiement, permissions, onboarding, génération de documents, synchronisation avec des outils externes.

La troisième, ce sont les jobs invisibles : scripts de synchronisation, traitements asynchrones, imports, exports, relances emails. Quand personne ne sait qu'un job existe, personne ne sait quand il casse.

La quatrième, ce sont les données. Où sont les sauvegardes ? Ont-elles déjà été restaurées ? Quelles tables sont sensibles ? Quels scripts modifient beaucoup de lignes ? Un produit peut survivre à une interface imparfaite. Il survit beaucoup moins bien à une perte de données.

La cinquième, c'est la dette qui bloque la reprise. Une zone de code peut être laide sans être dangereuse. Une autre peut être courte, mais impossible à reprendre sans contexte historique.

Dans ce genre de situation, un CTO part-time peut aider à séparer l'urgence, la dette acceptable et les risques à traiter avant de recruter. Le but est de remettre de la décision technique là où il n'y a plus qu'une dépendance à une personne.

Comment communiquer avec l'équipe et les clients

Le départ d'un développeur clé crée souvent deux réactions opposées : l'équipe minimise, le fondateur voit tout devenir fragile. Communiquez sans dramatiser, mais sans maquiller le risque.

En interne, dites clairement qui reprend les sujets en cours, qui a le droit de déployer, quels chantiers sont gelés temporairement, quelles zones ne doivent pas être modifiées sans revue.

Avec les clients, tout dépend de l'impact réel. Inutile d'annoncer un départ interne si le service reste stable. Si une livraison importante prend du retard, dites-le simplement avant qu'il devienne visible.

Ne promettez pas que rien ne changera si vous n'en êtes pas sûr. Un départ clé peut être absorbé, à condition de ralentir certaines décisions pendant la reprise.

Le plan de reprise sur 30 jours

Après l'urgence, il faut sortir du mode réaction.

Un bon plan de reprise sur 30 jours ne cherche pas à rendre la codebase parfaite. Il cherche à réduire la dépendance à la personne partie.

Semaine 1 : sécuriser les accès, secrets, sauvegardes, déploiement et chantiers en cours. À la fin de cette semaine, l'entreprise doit savoir qui peut opérer le produit.

Semaine 2 : documenter le minimum vital. Pas toute la codebase. Les flux critiques, les commandes utiles, les procédures de déploiement et les zones dangereuses.

Semaine 3 : réduire le risque de modification. Ajoutez ou renforcez les tests sur les parcours critiques. Pas besoin de viser une couverture théorique. Il faut surtout éviter de casser ce qui génère du revenu.

Semaine 4 : décider la suite. Recrutement, freelance senior, CTO part-time, refactor ciblé, documentation plus poussée. À ce stade, vous avez assez d'informations pour choisir au lieu de réagir.

Ce plan doit produire des livrables concrets :

• une matrice des accès ;
• une documentation de reprise courte ;
• une liste priorisée des risques techniques ;
• un plan de continuité pour les prochaines livraisons ;
• une décision claire sur le renfort nécessaire.

Le plus gros gain n'est pas technique. Il est mental. Vous passez de "on espère que ça tient" à "on sait ce qui tient et ce qu'on traite maintenant".

Ce qu'il faut retenir

• Le départ d'un développeur clé révèle souvent un problème de dépendance, pas seulement un problème de recrutement.
• Les 72 premières heures doivent servir à récupérer les accès, les procédures et la connaissance implicite.
• Les secrets, les sauvegardes, le déploiement et les flux métier critiques passent avant les refactors esthétiques.
• Un plan de reprise sur 30 jours doit réduire le bus factor et rendre le produit transmissible.
• Si personne ne peut expliquer comment le produit tourne sans appeler la personne qui part, le risque technique est déjà business.

Questions fréquentes

Que faire si le développeur clé part sans transition ?

Commencez par sécuriser les accès : dépôt de code, cloud, base de données, DNS, paiement et outils de déploiement. Ensuite, faites auditer les zones critiques pour comprendre ce qui peut casser vite. Le recrutement vient après cette phase, sinon vous risquez d'embaucher quelqu'un dans un brouillard complet.

Faut-il tout réécrire après le départ d'un développeur ?

Non. Un départ clé ne justifie pas automatiquement un rewrite. Il faut d'abord identifier les zones qui bloquent la reprise : déploiement, données, permissions, facturation, intégrations critiques. Si la douleur est localisée, un refactor ciblé sera souvent plus utile qu'une réécriture complète.

Comment éviter de dépendre d'une seule personne ?

Documentez les décisions importantes, partagez les accès d'administration avec au moins deux personnes, automatisez le déploiement, testez les flux critiques et organisez des revues régulières sur les zones sensibles. Le but n'est pas que tout le monde sache tout, mais qu'aucune partie vitale du produit ne soit connue d'une seule personne.

Un CTO part-time peut-il aider dans cette situation ?

Oui, surtout si vous devez reprendre vite sans recruter dans la précipitation. Un CTO part-time peut auditer la codebase, prioriser les risques, cadrer le plan de reprise, aider à sélectionner un profil senior et remettre de la gouvernance technique autour du produit.

Conclusion

Un développeur clé qui part met rarement une startup en danger du jour au lendemain. Ce qui met la startup en danger, c'est de découvrir trop tard que le produit, les accès et les décisions techniques vivaient dans une seule tête.

Il faut reprendre le contrôle dans l'ordre : sécuriser les accès, comprendre les zones sensibles, documenter le minimum vital, puis décider du renfort nécessaire. C'est moins spectaculaire qu'un recrutement express, mais c'est souvent ce qui sauve le plus de temps.

Si vous vivez un départ clé ou si vous sentez que votre SaaS dépend trop d'une seule personne, on peut identifier les premiers risques et cadrer le plan de reprise en 30 minutes. Réservez un échange ici.