C’est notre engagement le plus difficile à tenir, et c’est probablement celui qui nous différencie le plus dans le paysage. Quand on quitte une mission CTO externalisé, on laisse derrière nous tout ce qu’il faut pour que quelqu’un d’autre puisse reprendre, sans dépendance à notre cabinet. C’est dans le contrat, et c’est dans notre méthode. Voici comment on s’y prend concrètement.
Pourquoi on en fait un sujet à part entière
La plupart des cabinets de conseil tech facturent surtout pour ce qu’ils font pendant la mission. La sortie est un détail administratif. Conséquence : six mois après la fin du contrat, le client a oublié l’essentiel des décisions prises, les outils sont en place mais personne ne sait les opérer, et il faut rappeler le prestataire pour la moindre évolution.
C’est exactement le contraire de ce qu’on veut faire. Notre conviction : la valeur réelle d’une mission, c’est ce qui en reste utilisable une fois qu’on est parti. Sinon, on a juste loué notre temps.
Les quatre couches de documentation
On structure la documentation de sortie en quatre couches.
Couche 1 : les décisions
C’est le document le plus important, et c’est presque toujours celui qu’on néglige. À chaque décision structurante prise pendant la mission, on enregistre dans un journal : la situation au moment de la décision, les options envisagées, les critères d’arbitrage, l’option retenue, et l’argument principal pour le choix.
Pourquoi c’est crucial : six mois plus tard, quand quelqu’un viendra remettre en cause un choix qu’on a fait, le journal des décisions permet de comprendre pourquoi on a tranché comme ça. Sans ce journal, chaque évolution future risque de défaire ce qu’on a construit, sans le savoir.
Concrètement, c’est un document Markdown maintenu au fil de la mission, pas reconstruit à la fin. C’est plus court qu’on ne croit : sur une mission de douze mois, on parle de vingt à quarante décisions structurantes, soit cinquante à cent pages au total.
Couche 2 : l’opérationnel
Tous les runbooks pour les opérations courantes. Comment relancer le système quand il plante. Comment ajouter un utilisateur. Comment gérer une montée en charge. Comment basculer en mode dégradé en cas d’incident majeur. Comment restaurer une sauvegarde.
Ces runbooks doivent être testés par quelqu’un qui n’est pas l’auteur. Si la procédure est ambigüe ou incomplète, le testeur s’en aperçoit. C’est le seul moyen de garantir qu’elles sont vraiment utilisables.
Couche 3 : la technique
L’architecture, les choix de stack, les intégrations, les points de configuration importants. Plus orienté développeur que les couches précédentes, mais essentiel pour celui qui reprendra le sujet techniquement.
On évite les longues prose académique. On privilégie les schémas, les exemples concrets, et les pointeurs vers le code source quand c’est plus clair que de redocumenter. La règle : un développeur sénior qui n’a pas participé doit pouvoir comprendre l’essentiel en une journée de lecture.
Couche 4 : le contractuel
Les accès, les contrats avec les prestataires, les abonnements en cours, les responsables côté éditeurs. Tout ce qui peut bloquer une équipe si elle ne sait pas où chercher. Cette couche est plus administrative que les autres, mais elle est souvent celle qui pose le plus de problèmes à la sortie quand elle est manquante.
Le test final : la formation de transmission
Avant chaque fin de mission, on organise une journée ou deux de formation avec l’équipe qui reprendra. On déroule chaque couche de documentation, on répond aux questions, on corrige ce qui n’est pas clair, et on note les sujets qui méritent d’être complétés.
C’est le moment où on teste vraiment la qualité de notre documentation. Si l’équipe pose des questions qu’on n’a pas anticipées dans les docs, c’est qu’on a un trou à combler. On le comble avant de partir.
Ce qu’on n’écrit pas
On ne documente pas tout, et c’est volontaire. On laisse de côté les détails qui changeront vite (les versions précises de chaque outil par exemple), les conventions qui sont des standards de marché (pas besoin de redocumenter REST), et les opinions personnelles non actionnables.
L’objectif n’est pas de produire un encyclopédie qui rassure l’auteur, c’est de produire une documentation qui aide concrètement le suivant. Quand on hésite, on demande : est-ce que ce paragraphe aidera quelqu’un dans un an ? Si la réponse n’est pas évidente, on le coupe.
La conviction sous-jacente
Pour nous, une mission qui se termine avec une documentation pauvre est une mission qu’on a mal faite, même si techniquement on a livré tout ce qui était prévu. On a en quelque sorte oublié la moitié du travail. C’est pour ça qu’on intègre du temps de documentation dans tous nos forfaits, et qu’on refuse les missions où le client veut couper cette ligne pour réduire le budget.
C’est probablement notre garde-fou méthodologique le plus important.
Pour aller plus loin
Lire sortie de mission préparée : la discipline qu’on oublie souvent de vendre pour le contexte philosophique, notre grille de diagnostic technique en douze points pour comprendre la phase amont, et forfait vs régie vs success fee pour le cadre contractuel. Et si vous voulez qu’on parle de votre cas, un échange court suffit.