Le départ d’un CTO, d’un lead developer ou de plusieurs développeurs ne crée pas seulement un poste vacant. Il peut interrompre les mises en production, laisser des décisions techniques sans responsable et rendre une partie du produit incompréhensible. La priorité n’est donc pas de recruter dans la précipitation, mais d’assurer la continuité de l’activité.
Voici un plan d’urgence destiné aux fondateurs et dirigeants qui doivent reprendre le contrôle sans aggraver la situation.
Pendant les premières heures : protéger l’entreprise
Commencez par identifier ce qui dépend directement des personnes sur le départ. La production peut-elle fonctionner sans elles ? Qui sait traiter un incident ? Qui possède les comptes et les moyens d’authentification ?
Les accès essentiels doivent être recensés immédiatement :
- dépôts de code et outils de livraison ;
- cloud, serveurs, bases de données et sauvegardes ;
- noms de domaine, DNS et certificats ;
- outils de monitoring et de support ;
- comptes Apple et Google pour les applications mobiles ;
- services externes, facturation et clés d’API ;
- gestion de projet et documentation.
L’entreprise doit disposer de comptes administrateurs qui ne reposent pas sur une adresse personnelle. Il faut également prévoir la révocation des accès à la date convenue, sans interrompre les automatisations utilisées en production.
Organiser une transmission utile
Une documentation exhaustive rédigée en quelques jours sera rarement fiable. Demandez plutôt une transmission fondée sur des opérations réelles :
- construire l’application depuis un poste neuf ;
- déployer en préproduction puis en production ;
- diagnostiquer un incident récent ;
- restaurer une sauvegarde ;
- présenter l’architecture et les zones fragiles ;
- expliquer les décisions encore ouvertes.
Ces sessions peuvent être enregistrées et transformées ensuite en procédures courtes. La liste des sujets non maîtrisés est aussi importante que les documents disponibles : elle évite de confondre absence d’information et absence de risque.
Désigner un responsable technique temporaire
Après le départ du CTO, plusieurs personnes peuvent prendre de bonnes initiatives tout en créant des directions contradictoires. Un responsable temporaire doit pouvoir arbitrer la roadmap, les incidents, la dette technique et les demandes commerciales.
Trois solutions sont généralement possibles :
- faire monter temporairement un profil interne suffisamment expérimenté ;
- recruter un CTO permanent, avec le délai que cela implique ;
- confier la transition à un CTO externalisé capable de piloter et d’intervenir dans l’existant.
Le bon choix dépend de la maturité de l’équipe, du niveau d’urgence et du besoin futur. Une startup n’a pas toujours besoin de remplacer immédiatement un poste à l’identique.
La première semaine : distinguer urgence et agitation
Créez un backlog unique avec quatre catégories : incidents de production, risques de sécurité, engagements clients et évolutions. Chaque sujet doit avoir un responsable et un critère de résolution.
Pendant cette période, évitez les grands changements d’architecture. L’équipe doit d’abord savoir construire, tester, déployer et restaurer le produit. Les nouvelles fonctionnalités non indispensables peuvent attendre quelques jours ; les utilisateurs et les données, non.
Un point quotidien court suffit pour partager les blocages. La direction doit recevoir un état factuel : services disponibles, incidents ouverts, accès manquants, prochaine livraison et décisions attendues.
Les 30 premiers jours : reconstruire une capacité de livraison
Une fois la continuité assurée, la startup peut lancer un audit technique, clarifier l’architecture et choisir une trajectoire. Le plan doit couvrir :
- les risques à corriger immédiatement ;
- la roadmap réellement engagée auprès des clients ;
- les recrutements ou partenaires nécessaires ;
- la remise en état des tests et de la CI/CD ;
- la documentation minimale à maintenir ;
- le budget de stabilisation et d’évolution.
Notre guide pour faire reprendre le développement d’une application existante détaille cette phase technique.
Le retour d’expérience MyTwiga
Farrago a repris l’ensemble du socle technique de MyTwiga après le départ de plusieurs développeurs. La mission associait applications mobiles, API, infrastructure, DevOps et organisation produit. La centralisation du backlog, des priorités explicites et des cycles de livraison courts ont permis de terminer les refontes engagées et de rétablir une exploitation structurée.
Cette réalisation MyTwiga montre pourquoi une transition réussie associe direction technique et travail opérationnel. Un plan stratégique sans capacité à intervenir dans le code ou l’infrastructure laisse les risques intacts.
Préparer le prochain départ avant qu’il arrive
La meilleure succession se prépare pendant que l’équipe est stable. Les comptes doivent appartenir à l’entreprise, deux personnes doivent savoir déployer, les décisions importantes doivent être écrites et les sauvegardes testées. Les revues de code et les démonstrations régulières distribuent également la connaissance.
Le départ d’un CTO ou d’un développeur reste un événement humain normal. Il devient une crise seulement lorsque le fonctionnement du produit dépend d’une personne unique.