Situation réelle

“Je pars dans 3 mois. Mon successeur arrive dans 1 mois. Comment lui transmettre 3 ans de contexte et de décisions sans le noyer ni disparaître brutalement ?” Cette question, tout CTO qui part proprement se la pose.

Ce que j’ai observé : une bonne succession se prépare des mois à l’avance et continue quelques semaines après le départ. Une mauvaise succession crée du chaos pour des mois.

Le faux problème

Le faux problème serait de croire qu’on peut tout documenter et que ça suffira. En réalité, beaucoup de contexte est tacite et se transmet par l’expérience, pas par la documentation.

Un autre faux problème : penser qu’on doit “tout réussir” avant de partir. En réalité, laisser quelques problèmes non résolus permet au successeur d’avoir de l’impact rapidement.

Le vrai enjeu CTO

Le vrai enjeu est de préparer une succession qui permet au successeur de réussir sans qu’on disparaisse brutalement :

Les erreurs de succession :

  • Partir sans rien préparer (contexte perdu, chaos)
  • Sur-documenter et paralyser (des centaines de pages illisibles)
  • Rester trop impliqué (le successeur ne peut pas prendre sa place)
  • Partir trop vite (pas le temps de transmettre l’essentiel)

Ce qui doit être transmis :

  • Décisions structurantes et leur contexte (pourquoi cette archi, cette stack)
  • Relations clés (qui décide quoi, qui consulter, qui éviter)
  • Dossiers chauds (projets critiques, problèmes en cours)
  • Angles morts et signaux faibles (ce qui inquiète, ce qu’il faut surveiller)
  • Culture et valeurs (ce qu’on protège, ce qu’on refuse)

Le timing optimal :

  • J-90 : décision de partir, début documentation
  • J-60 : annonce, recrutement successeur lancé
  • J-30 : successeur arrive, onboarding intensif
  • J0 : départ officiel
  • J+30 : disponibilité limitée pour questions

Le piège de la perfection : Vouloir tout régler avant de partir. En réalité, laisser quelques chantiers ouverts permet au successeur d’avoir des victoires rapides et de prendre sa place.

Cadre de décision

Voici comment je prépare une succession :

1. Phase documentation (J-90 à J-30)

  • ADRs des décisions structurantes (architecture, stack, process)
  • Cartographie relations (org chart réel vs officiel)
  • Liste des dossiers chauds (projets, problèmes, risques)
  • Contexte culture (ce qu’on protège, nos non-négociables)

2. Phase onboarding successeur (J-30 à J0) Semaine 1 : contexte général, meet the team Semaine 2 : décisions techniques, architecture Semaine 3 : relations stakeholders, board Semaine 4 : shadowing réunions, passation progressive

3. Phase transition (J0 à J+30)

  • Disponibilité 2-3h/semaine pour questions
  • Pas de participation aux décisions (sauf demandé explicitement)
  • Réponses dans les 24-48h
  • Encourager l’autonomie

4. Ce qu’il faut transmettre en priorité Règle 80/20 : 20% de contexte qui explique 80% des décisions. Pas tout documenter, documenter l’essentiel.

5. Ce qu’il ne faut PAS faire

  • Critiquer les premières décisions du successeur
  • Rester impliqué dans l’équipe
  • Comparer publiquement
  • Donner des conseils non sollicités

Retour terrain

Ce que j’ai observé dans différentes successions :

La succession brutale : CTO part en 2 semaines, pas de successeur identifié, documentation minimale. Résultat : 6 mois de chaos, décisions bloquées, équipe désorientée.

La sur-documentation paralysante : CTO documente 200 pages de contexte technique. Résultat : le successeur ne lit pas, information inutilisable.

La succession propre : CTO prépare 3 mois, successeur arrive 1 mois avant le départ, onboarding structuré, disponibilité 1 mois post-départ. Résultat : transition fluide, successeur opérationnel rapidement.

L’ingérence post-départ : CTO reste très impliqué post-départ, continue à conseiller l’équipe. Résultat : le successeur ne peut pas prendre sa place, double command, confusion.

Erreurs fréquentes

Partir sans préparer Démission avec préavis minimum, pas de documentation, pas de transition. Résultat : chaos, contexte perdu, successeur en difficulté.

Sur-documenter Vouloir tout documenter parfaitement. Résultat : burn-out pendant la transition, documentation illisible, contexte non transmis.

Rester trop impliqué Continuer à conseiller, à participer aux décisions, à être présent. Résultat : le successeur ne peut pas prendre sa place, confusion de responsabilité.

Critiquer le successeur Commenter ses décisions, comparer avec “comment je faisais”. Résultat : perte de crédibilité du successeur, toxicité.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Documenter progressivement, pas à la fin Tenir des ADRs au fil de l’eau plutôt que tout documenter avant de partir. Cette pratique facilite la transmission.

Négocier un overlap de 4-6 semaines Le successeur arrive pendant que je suis encore là. Cette période permet une transmission vivante, pas juste documentaire.

Lâcher prise après J+30 Arrêter d’être disponible après 1 mois post-départ. Cette coupure permet au successeur de vraiment prendre sa place.

Célébrer les premières décisions différentes Encourager publiquement quand le successeur fait différemment de moi. Cette posture légitime son autonomie.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore différentes successions avec leurs réussites et leurs échecs.

Pour approfondir, tu peux aussi consulter l’article “Comment passer le relais sans abandonner l’équipe” ou les autres contenus du pilier “Le rôle du CTO”.