Votre CTO part : 5 décisions à prendre en 30 jours

Votre CTO vous annonce qu'il part. Vous avez 30 jours de préavis. Voici ce que vous devez faire, dans l'ordre — et la première chose, ce n'est pas de lancer un recrutement.

J'interviens régulièrement comme CTO externe dans des boîtes qui viennent de perdre leur direction technique. Le schéma est toujours le même : la panique pousse à recruter en urgence, alors que les vrais risques sont ailleurs. Le recrutement vient en dernier. Ce qui suit, c'est le protocole que j'applique à chaque mission de transition.

Ce que vous perdez vraiment quand votre CTO s'en va

Un CTO, ce n'est pas "un développeur senior". C'est la personne qui prend des dizaines de micro-décisions techniques chaque semaine. Quelle librairie utiliser. Faut-il corriger ce bug maintenant ou après la release. Combien de temps ça va prendre. Quel candidat est bon, lequel bluffe. Est-ce qu'on a un problème de sécurité ou pas.

Ces décisions ne sont documentées nulle part. Elles sont dans sa tête.

J'ai vu une startup SaaS perdre 3 développeurs sur 4 en deux mois après le départ de leur CTO. Le fondateur pensait que l'équipe continuerait à tourner. Sauf que sans personne pour arbitrer, prioriser et protéger les devs des demandes contradictoires du business, l'équipe s'est retrouvée paralysée. Plus personne ne savait qui décidait quoi. Les meilleurs sont partis les premiers — ce sont toujours eux qui partent en premier.

Concrètement, un départ de CTO vous expose sur quatre fronts :

• Les accès techniques. Mots de passe, serveurs, comptes cloud — souvent sur ses identifiants personnels.
• Le savoir non écrit. L'architecture dans sa tête, les choix passés, la dette qu'il connaissait mais n'avait pas le temps de corriger.
• La cohésion d'équipe. Le CTO est souvent le liant entre les devs et le business. Sans lui, les devs se sentent abandonnés.
• La capacité à avancer. Sans direction technique, l'équipe ralentit, puis s'arrête.

La bonne nouvelle : 30 jours suffisent pour traiter les quatre, si vous agissez dans le bon ordre.

Décision #1 — Sécurisez tous les accès (Jour 1 à 3)

C'est la priorité absolue. Pas demain. Pas la semaine prochaine. Le jour où vous apprenez le départ.

Un fondateur m'a appelé un dimanche soir. Son serveur AWS était tombé. Son ex-CTO, parti deux semaines plus tôt, avait le compte root sur son adresse mail personnelle. Le fondateur n'avait aucun accès. 48 heures pour récupérer la main — 48 heures de service indisponible pour ses clients.

Ce n'était même pas de la malveillance. Le CTO avait créé les comptes au lancement du projet, avec ses propres identifiants, comme 90% des CTO en startup early-stage. Personne n'avait pensé à transférer.

Voici les actions, dans l'ordre de priorité :

1. Listez tout : hébergement cloud (AWS, GCP, OVH), dépôt de code (GitHub, GitLab), bases de données, nom de domaine, DNS, monitoring, outils SaaS techniques, comptes de déploiement
2. Vérifiez qui a les accès admin — si c'est uniquement le CTO, faites le transfert avant son départ effectif
3. Activez la double authentification partout où ce n'est pas déjà fait
4. Changez les mots de passe partagés et les tokens d'API
5. Révoquez ses accès personnels le jour du départ effectif — pas avant, pas après

Ne soyez pas gêné de faire ça pendant le préavis. C'est de la gouvernance, pas de la méfiance. Un bon CTO comprendra parfaitement. Et s'il ne comprend pas, c'est une raison de plus de le faire vite.

Décision #2 — Auditez ce que vous avez (Jour 4 à 10)

Une fois les accès sécurisés, vous devez savoir dans quel état est votre patrimoine technique. Pas "globalement". Précisément.

Lors d'une mission de CTO externe, j'ai découvert que le CTO précédent avait accumulé 18 mois de dette technique sans jamais en parler au fondateur. Le code fonctionnait en surface. En dessous, c'était un château de cartes. Chaque fonctionnalité ajoutée augmentait le risque d'effondrement. Le fondateur l'a appris par mon audit — pas par son CTO.

Je ne dis pas que votre CTO vous a menti. Peut-être qu'il a simplement arrêté de remonter les alertes parce qu'il savait que ça ne changerait rien. C'est un schéma que je vois souvent, et c'est rarement de la mauvaise volonté.

Ce que vous devez évaluer :

• Documentation : existe-t-elle ? Est-elle à jour ? Quelqu'un peut-il comprendre l'architecture sans le CTO ?
• Qualité du code : y a-t-il des tests automatisés ? Le code est-il maintenable ?
• Dette technique : quels sont les vrais problèmes cachés ?
• Dépendances : quels services tiers, quels contrats, quelles limites ?

Si vous n'avez pas les compétences pour faire cet audit vous-même — et c'est normal, ce n'est pas votre métier — faites appel à quelqu'un d'externe. Un audit de code prend quelques jours et vous donne une cartographie claire de votre situation.

Le pire serait de reprendre un code existant sans savoir ce qu'il contient. J'ai vu des fondateurs investir 6 mois de développement sur du code qui aurait dû être stabilisé dès le départ. Six mois perdus, parce qu'ils n'avaient pas pris 5 jours pour faire un état des lieux.

Décision #3 — Stabilisez l'équipe (Jour 5 à 15)

Vos développeurs savent que le CTO part. Ils se posent trois questions : est-ce que la boîte va bien ? Est-ce qu'on va me demander de faire le travail du CTO sans le titre ni le salaire ? Est-ce que je devrais partir aussi ?

Si vous ne répondez pas à ces questions rapidement, ils y répondront seuls. Et leur réponse ne sera probablement pas celle que vous espérez.

Parlez à chaque développeur individuellement. Pas en réunion d'équipe. En face à face. Demandez-leur comment ils vivent la situation. Ce qui les inquiète. Ce dont ils ont besoin pour continuer à avancer. Vous serez surpris — la plupart ne demandent pas grand-chose. Juste de la visibilité et un interlocuteur qui prend les décisions.

Deux erreurs à ne surtout pas commettre :

Ne promettez pas un remplacement rapide. Un recrutement CTO prend 3 à 6 mois minimum. Si vous annoncez un remplacement "dans les semaines qui viennent", vous perdrez toute crédibilité quand ça ne sera pas le cas. Dites la vérité : vous êtes en train de gérer la transition, étape par étape.

Ne nommez pas le dev le plus senior "CTO par défaut". Être un bon développeur et diriger une équipe technique, ce sont deux métiers différents. Imposer ce rôle à quelqu'un qui ne l'a pas demandé, c'est le meilleur moyen de le perdre lui aussi. En revanche, vous pouvez nommer un point de contact technique temporaire — pas un CTO, un interlocuteur qui centralise les décisions du quotidien pour débloquer l'équipe. Et soyez transparent sur le fait que c'est temporaire.

Décision #4 — Faites appel à un CTO externe (Jour 10 à 20)

C'est la décision la moins intuitive. Et je suis transparent : c'est aussi ce que je propose, donc prenez mon avis avec ce biais en tête. Mais je le recommande parce que j'ai vu l'alternative — et elle coûte beaucoup plus cher.

Un CTO externe, c'est un directeur technique expérimenté qui intervient à temps partiel sur une période définie. Pas un consultant qui produit des slides. Quelqu'un qui prend les décisions techniques, manage l'équipe dev et structure la transition.

Pourquoi c'est souvent la meilleure option à ce stade :

• Délai : opérationnel en 1 à 2 semaines, contre 3 à 6 mois pour un recrutement.
• Coût : 3 000 à 8 000€/mois en temps partiel, contre 100 000 à 130 000€/an pour un CTO salarié, plus l'equity.
• Objectivité : pas de politique interne, un regard neuf sur la situation technique.
• Préparation : il documente, structure les process, et surtout — il définit le bon profil pour le futur CTO permanent. Ce qui évite le recrutement raté.

J'ai fait cette transition pour une fintech de 12 personnes. Le CTO cofondateur partait après 4 ans. Trois mois de mission : audit du code, restructuration de l'organisation dev, mise en place des process qui manquaient. Quand le nouveau CTO est arrivé, il avait une base saine sur laquelle construire, pas un champ de ruines à déblayer.

Le piège serait de voir le CTO externe comme un pansement. Ce n'est pas un pansement — c'est un pont. Il vous fait traverser la rivière, mais il faut quand même construire la route de l'autre côté.

Décision #5 — Préparez le recrutement (Jour 20 à 30)

"Préparez", pas "recrutez". La différence est cruciale.

Un fondateur que j'accompagnais a publié une offre CTO 48 heures après l'annonce du départ. Premier candidat retenu en 3 semaines. Contrat signé en 5 semaines. Record de vitesse. Sauf que le nouveau CTO a voulu tout recoder — refonte à 80 000€ qui n'a jamais abouti. Douze mois plus tard : re-départ, re-recrutement. Coût total : un an de perdu et plus de 150 000€ entre salaire et refonte avortée.

Le recrutement précipité d'un CTO est l'erreur la plus coûteuse que je vois chez les fondateurs non-techniques. Un mauvais recrutement CTO coûte entre 6 et 12 mois de salaire si on additionne le recrutement, l'onboarding, les dégâts et le re-recrutement.

Ce que "préparer le recrutement" signifie concrètement :

• Définir le besoin réel. Votre prochain CTO n'est pas forcément une copie du précédent. Votre boîte a évolué, vos besoins aussi. Avez-vous besoin d'un manager d'équipe ? D'un architecte ? D'un profil hands-on qui code ? Les trois à la fois, c'est un fantasme — choisissez la priorité.
• Savoir évaluer un profil technique quand on ne code pas soi-même. C'est possible, mais ça demande une méthode.
• Structurer le process. Test technique évalué par un tiers (votre CTO externe, par exemple), mise en situation, références vérifiées auprès d'anciens employeurs — pas juste auprès de ceux que le candidat vous donne.

Prenez 3 mois. Six si nécessaire. Un bon CTO transforme une boîte. Un mauvais la met à genoux.

Checklist des 30 jours post-départ CTO

Le départ d'un CTO n'est pas une catastrophe

C'est un moment de vulnérabilité. Et comme tous les moments de vulnérabilité, il peut devenir une opportunité si vous le gérez dans l'ordre.

Les fondateurs qui s'en sortent le mieux ne sont pas ceux qui recrutent le plus vite. Ce sont ceux qui sécurisent d'abord, comprennent ensuite, et recrutent en dernier.

Si votre CTO vient de vous annoncer son départ et que vous lisez cet article un peu paniqué : respirez. Vous avez 30 jours. C'est suffisant pour reprendre le contrôle — à condition de commencer par les accès, pas par LinkedIn.

Et si vous avez besoin d'un CTO externe pour structurer la transition, c'est exactement le type de mission que je fais. On en parle quand vous voulez.