CTO première année : les 90 jours qui définissent tout
CTO première année : les 90 jours qui définissent tout
J'ai accompagné un CTO recruté chez un client dans le secteur de la santé avec 18 mois d'expérience. Brillant, reconnu, enthousiaste. À J+15, il avait déjà annoncé une migration d'architecture. À J+60, la moitié de l'équipe résistait activement. À J+90, il repartait en négociant sa rupture conventionnelle. Il avait agi avant de comprendre. C'est l'erreur la plus fréquente, et la plus coûteuse.
Une étude Gartner montre que 40% des dirigeants recrutés de l'extérieur quittent ou sont écartés dans les 18 premiers mois. Pour les CTOs spécifiquement, la pression est double : prouver la compétence technique ET gagner la confiance d'une équipe qui a ses propres façons de travailler. J'ai occupé tous les rôles (développeur, tech lead, engineering manager, directeur technique) et j'ai vu ce pattern se répéter partout, de BNP Paribas à Canal+.
Les 90 premiers jours définissent la crédibilité, la confiance, et la trajectoire du CTO pour les 2 à 3 années suivantes. Voici la séquence qui fonctionne.
Phase 1 : Jours 1 à 30 : écouter, observer, cartographier
C'est la phase la plus difficile pour un CTO expérimenté. Vous avez des opinions. Des patterns reconnus. Des solutions éprouvées. Résistez.
Ce que je fais dans cette phase :
- 1-on-1 de 45 minutes avec chacun des développeurs seniors et tech leads
- Shadow de 2 sprints complets : j'observe sans intervenir
- Lecture de tous les ADRs disponibles, post-mortems, et architectures documentées
- 3 sessions avec le CEO et le CPO pour comprendre les priorités business et les tensions existantes
Les questions que je pose systématiquement en 1-on-1 :
- "Qu'est-ce qui fonctionne bien dans l'équipe que tu veux absolument préserver ?"
- "Quel est le problème le plus frustrant dans ton quotidien ?"
- "Si tu étais CTO pour un jour, quelle serait ta première décision ?"
- "Y a-t-il des décisions passées que tu ne comprends pas ?"
Ce que je cartographie :
- La carte des dépendances techniques (modules, services, intégrations)
- La carte des personnes clés et des dynamiques informelles
- La dette technique visible et ses estimations
- Les tensions business/technique non-résolues
Résultat attendu : un document de 3 à 5 pages décrivant l'état actuel sans jugement. Je le partage avec le CEO et les tech leads pour validation, pas pour impressionner, mais pour calibrer.
Phase 2 : Jours 31 à 60 : diagnostiquer et prioriser
Avec la carte établie, je peux faire un diagnostic structuré. Pas encore de décisions : des hypothèses documentées.
Le diagnostic technique que je mène :
- Évaluation de maturité engineering sur les 4 métriques DORA minimales
- Identification des 3 risques techniques les plus critiques (ce qui peut tomber en prod et coûter cher)
- Évaluation de la dette technique en termes d'absorption et de coût annuel
- Audit des pratiques : CI/CD, tests, architecture, sécurité
Le diagnostic organisationnel :
- Cartographie des compétences de l'équipe vs les besoins des 12 prochains mois
- Identification des personnes clés à risque de départ
- Évaluation du niveau de confiance et de psychological safety (échelle Amy Edmondson)
- Analyse des processus de delivery : lead time, prédictabilité, qualité
Dans ce client dans le secteur de la santé que j'évoquais, le diagnostic J+45 a révélé que le principal risque n'était pas la dette technique (surestimée par l'équipe) mais un bus factor de 1 sur le module de facturation. Un seul développeur comprenait ce code, et il cherchait activement un nouveau poste. Cette information, obtenue en 1-on-1 confidentiel, a changé radicalement les priorités des 30 jours suivants. Ce n'était jamais un problème de personnes. C'était un problème de système.
Résultat attendu : un diagnostic en deux parties (technique + organisationnel) avec les risques priorisés par impact et urgence.
Vous êtes nouveau CTO et vous voulez éviter les erreurs classiques des 90 premiers jours ?
Vouloir montrer sa valeur rapidement est l'instinct naturel, et le piège le plus courant. Vous avez peut-être déjà senti la pression de décider avant d'avoir vraiment compris le contexte. En 30 minutes, je vous aide à structurer votre plan d'écoute et de diagnostic adapté à votre situation, pour éviter les mois perdus à reconstruire une crédibilité abîmée par une décision trop rapide.
Phase 3 : Jours 61 à 90 : premières décisions ciblées
C'est le moment d'agir, mais sur des décisions préparées, ciblées, et expliquées. Pas sur des intuitions.
Mes critères pour les premières décisions :
- Visibilité haute (l'équipe les verra et les commentera)
- Risque limité (pas de changement architectural majeur)
- Impact rapide et mesurable (résultat visible en 2 à 4 semaines)
- Basées sur le diagnostic, jamais sur mes convictions pré-contexte
Exemples de bonnes premières décisions :
- Résoudre le risque organisationnel identifié (bus factor, personne clé en risque de départ)
- Implémenter les 4 métriques DORA si elles n'existent pas encore
- Fixer la Definition of Done avec l'équipe
- Résoudre le problème le plus frustrant cité par le plus grand nombre de développeurs en 1-on-1
Ce qu'il ne faut surtout pas faire avant J+90 :
- Restructurer l'organisation technique
- Décider de réécrire un composant existant avant d'avoir compris pourquoi il existe
- Annoncer un changement de stack ou d'architecture sans avoir construit le consensus
Le livrable de fin de 90 jours
À J+90, je présente au CEO, CPO et au board un document de 8 à 10 pages :
- État des lieux : maturité engineering, risques identifiés, points forts
- Diagnostic priorisé : les 3 à 5 enjeux critiques avec leur impact business
- Plan à 12 mois : initiatives prioritaires, ressources nécessaires, résultats attendus
- Métriques de succès : comment je vais mesurer le progrès
- Premières décisions : ce que j'ai déjà fait et l'impact observé
Ce document installe la crédibilité de façon durable. Il montre que vous avez compris le contexte, que vous avez écouté avant d'agir, et que votre plan est fondé sur des données, pas sur des intuitions importées d'ailleurs.
Le piège à éviter absolument
Quand un développeur vous dit "notre CI est cassée 40% du temps", la réponse correcte est "merci, je note." Pas "je vais régler ça demain."
Agir trop tôt sur des problèmes isolés, sans vue d'ensemble, crée des priorités contradictoires et signale que vous n'avez pas de méthode. Michael Watkins le décrit précisément dans The First 90 Days : les leaders qui réussissent leur prise de poste construisent d'abord leur compréhension, puis leur crédibilité, puis leur influence. Dans cet ordre.
En résumé
| Phase | Durée | Action principale | Livrable |
|---|---|---|---|
| Écoute | J1-J30 | 1-on-1, observation, cartographie | Document état des lieux |
| Diagnostic | J31-J60 | Évaluation technique + organisationnelle | Diagnostic priorisé |
| Action ciblée | J61-J90 | Premières décisions + quick wins | Résultats mesurables |
| Rapport | J90 | Présentation au leadership | Plan à 12 mois |
FAQ sur les 90 premiers jours d'un CTO
Que faire si la pression du CEO pour "montrer des résultats rapides" est forte dès J1 ?
Je négocie explicitement la définition de "résultats rapides". Pour un CEO, un résultat rapide peut signifier une décision visible dans les 2 premières semaines. Je propose un quick win de visibilité haute et risque limité, par exemple publier les métriques de santé technique qui n'existaient pas, ou résoudre un problème connu et frustrant pour l'équipe. Ce quick win prouve que j'agis, sans compromettre la qualité du diagnostic.
Faut-il s'abstenir de toute décision technique pendant les 90 premiers jours ?
Non. Les décisions urgentes (une faille de sécurité critique, un incident en cours) se prennent immédiatement. Ce qu'on évite pendant les 90 premiers jours : les décisions structurelles (réorganisation, changement d'architecture majeur, changement de stack) qui ont un impact irréversible et nécessitent une compréhension complète du contexte.
Comment gérer un Tech Lead qui résiste à l'arrivée du nouveau CTO ?
C'est l'un des cas les plus fréquents. La résistance vient souvent d'une inquiétude sur son rôle futur ou d'une protection de son territoire. Ma réponse : écoute active lors du 1-on-1, reconnaissance explicite de sa contribution passée, et transparence sur mes intentions. Je ne contourne jamais le Tech Lead, je l'implique dans le diagnostic et les premières décisions. La résistance qui persiste après 60 jours est un signal à adresser directement.
Le plan à 90 jours s'applique-t-il si on est CTO fondateur reprenant un rôle plus stratégique ?
La structure reste valide mais le contexte change : vous connaissez déjà le code et l'équipe. La phase d'écoute est plus courte (2 semaines) mais reste nécessaire, particulièrement pour comprendre les dynamiques organisationnelles que vous n'avez peut-être pas vues de votre ancien poste. Le diagnostic technique peut être réalisé plus vite, mais le diagnostic organisationnel (confiance, dynamiques, attentes) prend le même temps.
Comment mesurer concrètement la maturité engineering pendant la phase de diagnostic ?
Je m'appuie sur les 4 métriques DORA comme baseline : deployment frequency, lead time for changes, change failure rate, et MTTR. Croisez ces données avec le modèle des 5 niveaux de maturité engineering pour positionner l'équipe. Ces métriques se retrouvent dans les outils existants (GitHub, Jira, PagerDuty) sans infrastructure dédiée. Elles donnent une image objective de la maturité du système de delivery, indépendante des perceptions internes qui peuvent être fortement biaisées dans les deux sens.
Ressource gratuite : Engineering Maturity Self-Assessment
L'outil idéal pour vos 30 à 60 premiers jours de CTO : 30 questions sur 5 dimensions de maturité engineering, scoring automatique, et 3 priorités d'action pour les 90 prochains jours. Un outil de diagnostic structuré à partager avec le leadership pour installer votre crédibilité dès le départ.
