Mon CTO est parti : reprendre les clés avant de chercher un successeur

Une scène classique après un départ : quelqu’un cherche le mot de passe du registrar. Il était dans la tête du CTO, ou sur son téléphone, ou sur son adresse personnelle parce qu’un soir c’était plus rapide comme ça. Il n’a rien caché ; il a simplement été, pendant des années, l’endroit où tout convergeait. C’est ce que révèle un départ : pas un vide dans l’organigramme, la liste de tout ce qu’une seule personne savait.

Le CTO qui part n’est pas le problème. Le problème, c’est ce qu’il était seul à savoir, et les trente premiers jours servent à le récupérer pour définir le besoin durable. Reprendre sa fiche de poste sans cet inventaire, c’est recruter sans savoir quel travail reste à couvrir. Ce qui ne peut pas attendre, en revanche, c’est de nommer dès le premier jour qui tranche les urgences.

Ce plan vaut pour un départ préparé comme pour un départ brutal, avec une différence qui change tout : tant que la personne est encore là, pendant un préavis, la moitié du travail se fait avec elle.

La première semaine ne sert qu’à une chose : s’assurer qu’au moins deux personnes de l’entreprise peuvent agir sur chaque système critique. Pas une. Deux. Vous venez de vivre ce que coûte le chiffre un. La liste commence par ce qui donne la main sur tout le reste :

• le registrar des noms de domaine et la gestion DNS
• le compte principal de l’hébergeur cloud et sa facturation
• l’hébergement du code source et les droits de propriétaire de l’organisation
• le gestionnaire de mots de passe et les secrets de déploiement
• la messagerie et l’annuaire des comptes
• les comptes de paiement, les magasins d’applications et les outils de monitoring

Un compte ouvert avec l’adresse personnelle du CTO, ou une double authentification liée à son téléphone, bloque une reprise pendant des jours. Si le départ est préparé, ces transferts se font avec lui, avant son dernier jour. C’est la première chose à lui demander, avant la documentation.

Retirer un accès ne prouve pas qu’il a disparu. Les accès qui survivent aux outils montre comment vérifier un retrait, et la page sur la fiabilité et la sécurité replace ce travail dans la gestion des risques d’exploitation.

Les deux semaines suivantes servent à inventorier ce que l’entreprise utilise et paie. Trois sources, aucune complète seule : la facturation, les relevés bancaires et les intégrations présentes dans le code. On croise, et on découvre toujours un fournisseur que personne n’avait en tête. Le même inventaire vous sera demandé lors d’une due diligence technique avant une cession ; autant qu’il existe déjà.

Pour chaque fournisseur, qui paie, comment, à quelle échéance, sous quel compte. Pour chaque domaine, l’expiration, le renouvellement automatique et le titulaire. Pour chaque contrat, la durée, le préavis et le signataire. Pour chaque intégration, les données qu’elle reçoit et les accès qu’elle détient.

Un abonnement payé avec la carte du CTO peut être interrompu après son départ si le moyen de paiement n’a pas été repris. Un domaine que plus personne ne renouvelle expire, coupe le site ou la messagerie, puis se fait enregistrer par quelqu’un d’autre qui, comme l’explique l’article sur l’usurpation par email, peut s’en servir pour envoyer de faux courriels au nom de l’entreprise.

Une partie de ce que savait le CTO n’est écrite nulle part. Comment déployer. Comment restaurer une sauvegarde. Pourquoi ce choix d’architecture. Quel client a une intégration particulière. Tant qu’il est là, ses dernières semaines servent d’abord à ça, et la seule transmission qui vaille consiste à faire exécuter chaque geste par quelqu’un d’autre, devant lui. Une procédure écrite par celui qui part et jamais rejouée par celui qui reste est un document de plus.

Après le départ, le même savoir se retrouve presque toujours au même endroit : chez une ou deux personnes, souvent un lead dev, qui deviennent indispensables en une nuit. Elles n’ont rien demandé. Indispensable veut dire surchargé, puis courtisé, et leur départ devient le risque suivant. Repérez-les tout de suite, pour les décharger et répartir ce qu’elles savent avant que ça compte ; comment s’y prendre sans les braquer, c’est dans Faire grandir une équipe de développement.

Le radar de santé d’équipe sert à ouvrir cette conversation sans en faire une évaluation : il compare la lecture de la direction et celle de l’équipe, notamment sur le partage des connaissances, sans noter les personnes.

Un départ pousse à décider vite, parce que décider soulage. Résistez. Quatre décisions gagnent à attendre ce que le premier mois va vous apprendre :

• une réécriture, un changement de technologie ou d’hébergeur
• une réorganisation de l’équipe
• de nouveaux engagements de calendrier auprès des clients
• un recrutement lancé sur la seule base de la fiche de poste du CTO précédent

Chacune engage l’entreprise pour des mois. Prise la première semaine, elle repose sur ce que vous ne savez pas encore du système, des contrats et de l’équipe.

Une seule décision ne peut pas attendre, et c’est celle qu’on oublie : qui décide quoi pendant l’intérim. Une personne pour les incidents, une autre pour les priorités, une date pour la suite. L’équipe supporte un mois de flou sur la stratégie. Elle ne supporte pas trois jours de silence sur qui tranche.

L’intérim doit couvrir les décisions urgentes dès le départ. Pour définir le remplacement durable, l’inventaire permet ensuite de préciser les décisions que prenait le CTO et celles qui attendent un responsable. L’article Recruter un CTO détaille cette enquête. Le poste à pourvoir n’est presque jamais celui qui vient de se libérer : la personne qui l’occupait l’avait modelé à sa main.

Pour tenir l’intérim, deux formats sont confondus en permanence. Un CTO de transition remplace le CTO à plein temps, tous les jours, jusqu’à l’arrivée d’un successeur. Un CTO à temps partagé intervient quelques jours par mois ou par semaine, sur un périmètre convenu. Je travaille dans ce second format et je n’ai jamais exercé de mission de transition.

Le temps partagé suffit quand un lead dev peut conduire l’équipe au quotidien, que la production est stable et que les décisions se prennent au rythme de la semaine plutôt que de l’heure. Il sert alors à reprendre les arbitrages, préparer le recrutement et accompagner l’arrivée du successeur. Il ne suffit pas quand personne ne peut conduire l’équipe, que les incidents exigent une présence constante ou qu’un chantier critique demande des décisions chaque jour. Il faut alors un plein temps : promotion interne, recrutement ou mission de transition. Dire le contraire serait vous vendre quelque chose.

Au bout du mois, vous avez quatre choses que vous n’aviez pas le jour du départ : la liste des accès critiques avec deux administrateurs chacun, l’inventaire des fournisseurs et des domaines avec leurs échéances, la carte de qui sait quoi, et la liste des décisions en attente. Avec ça, vous pouvez choisir le remplacement.

Ce plan ne vous garantit pas un mois sans incident. Il ne vous dit pas non plus de recruter : il arrive qu’une personne interne porte déjà la moitié du rôle, ou que les décisions restantes dessinent un autre poste que celui qui vient de se vider. Je veux pouvoir décrire le travail à reprendre avant de chercher la personne qui le reprendra. Quand l’intérim peut se tenir à temps partiel, l’offre de CTO à temps partagé décrit comment ce type de mandat se cadre.