Article basé sur le livre “Être ou ne pas être CTO”.

Situation réelle

Premier jour comme CTO. L’équipe vous observe. Le CEO attend des résultats. Vous avez une vision de ce qui devrait changer, mais vous ne connaissez pas encore le contexte réel des décisions passées. La tentation est grande de montrer votre valeur en agissant rapidement.

Ce que j’ai observé : les premiers 90 jours déterminent rarement le succès à long terme, mais ils façonnent la perception que l’équipe et l’organisation auront de vous. Cette période est moins une course contre la montre qu’un exercice d’écoute et de compréhension.

Le faux problème

Le faux problème serait de croire qu’il existe un playbook universel, une checklist à suivre jour par jour qui garantirait une prise de poste réussie. Cette approche ignore la singularité de chaque contexte : taille d’équipe, maturité technique, culture existante, contraintes business.

J’ai vu des CTOs arriver avec leur méthodologie éprouvée ailleurs, l’appliquer mécaniquement, et créer plus de résistance que de valeur. Le vrai défi n’est pas de suivre un plan, mais de comprendre ce qui fait sens ici et maintenant.

Le vrai enjeu CTO

Le vrai enjeu des premiers 90 jours est triple :

Établir la crédibilité sans imposer : L’équipe technique a besoin de voir que vous comprenez leur réalité avant de proposer des changements. Cette crédibilité se construit par l’écoute, pas par l’autorité du titre.

Comprendre le contexte des décisions passées : Chaque choix technique a été fait dans un contexte précis. Critiquer sans comprendre ce contexte, c’est manquer de respect pour ceux qui ont construit avant vous.

Poser les bases d’une vision partagée : Les 90 premiers jours ne sont pas le moment de tout transformer, mais celui de comprendre où vous allez ensemble et comment vous y allez.

Cadre de décision

Voici les principes qui m’ont aidé à naviguer cette période :

1. Écouter avant de proposer
Les premiers 30 jours sont dédiés à la compréhension. Rencontrer chaque membre de l’équipe technique, comprendre leurs frustrations réelles, identifier ce qui fonctionne déjà bien. Cette écoute permet de distinguer les vrais problèmes des symptômes.

2. Identifier 1 à 2 quick wins significatifs
Entre le jour 30 et 60, choisir une amélioration visible qui résout un vrai problème identifié par l’équipe. Ce n’est pas pour montrer votre valeur, mais pour prouver que vous comprenez leurs besoins. Un quick win mal choisi peut créer plus de scepticisme que de confiance.

3. Construire la vision avec l’équipe, pas pour elle
La vision technique ne s’impose pas. Elle se construit à partir de la compréhension du contexte actuel et des besoins futurs. Présenter un draft, recueillir les retours, itérer. Une vision non partagée est une vision qui ne sera pas exécutée.

4. Rester dans votre rôle
Les premiers mois, la tentation est forte de revenir au code pour prouver votre valeur technique. Mais votre rôle est stratégique : comprendre, décider, aligner. Coder 10 à 20% du temps maximum, pour le prototypage ou les urgences. Le reste du temps, vous devez être disponible pour les décisions qui bloquent l’équipe.

5. Ne pas promettre ce que vous ne comprenez pas encore
Face à la pression du CEO ou des stakeholders, il est tentant de promettre des résultats rapides. Mais promettre sans comprendre le contexte réel, c’est créer des attentes impossibles à tenir. Mieux vaut dire “je dois comprendre X avant de m’engager sur Y” que de s’engager et échouer.

Retour terrain

Ce que j’ai observé dans différentes prises de poste :

Ce qui fonctionne : Prendre le temps de rencontrer chaque développeur individuellement, sans agenda caché. Poser des questions ouvertes : “Qu’est-ce qui marche bien ici ?”, “Qu’est-ce qui te frustre ?”, “Si tu étais CTO, que changerais-tu ?”. Ces conversations révèlent souvent plus que les métriques ou les diagrammes d’architecture.

Ce qui bloque : Arriver avec des solutions toutes faites. “Dans ma boîte précédente, on faisait X” est une phrase qui crée immédiatement de la résistance. Mieux vaut présenter des options : “J’ai vu X fonctionner ailleurs dans un contexte similaire. Qu’en pensez-vous ?”

Le timing des quick wins : Un quick win trop précoce (semaine 1-2) peut être perçu comme de l’agitation. Un quick win trop tardif (après 60 jours) laisse l’impression que rien ne bouge. La fenêtre idéale se situe entre le jour 30 et 45, une fois que vous avez compris le contexte mais avant que l’impatience ne s’installe.

Erreurs fréquentes

Tout changer trop vite
Arriver et annoncer une refonte complète dans les premières semaines. L’équipe se sent dévalorisée, le business voit ses priorités remises en question. Résultat : résistance généralisée et perte de crédibilité.

Rester dans le code
Passer 60% de son temps à coder pour prouver sa valeur technique. Les décisions stratégiques s’accumulent, l’équipe attend vos arbitrages, vous devenez un bottleneck. Votre rôle a changé : vous devez multiplier l’impact de l’équipe, pas ajouter votre propre production de code.

Ignorer la culture existante
Imposer des processus ou des outils sans comprendre pourquoi les choses sont faites ainsi aujourd’hui. Chaque organisation a ses raisons historiques. Les ignorer, c’est créer de la friction inutile.

Promettre sans comprendre
S’engager sur des résultats ou des délais avant d’avoir compris la complexité réelle. Les attentes créées sont impossibles à tenir, la déception est garantie.

Si c’était à refaire

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

Prendre encore plus de temps pour écouter
Les 30 premiers jours, je consacrerais 80% de mon temps à des conversations individuelles et à comprendre le contexte. Pas de pression pour produire des deliverables immédiats. La compréhension précède l’action.

Identifier les quick wins avec l’équipe
Plutôt que de choisir seul un quick win, je proposerais à l’équipe d’identifier ensemble les 2-3 améliorations qui auraient le plus d’impact. Le quick win devient alors un projet collectif, pas une démonstration individuelle.

Partager la vision en construction
Présenter la vision technique comme un work in progress dès le jour 45, pas comme un document finalisé. Inviter explicitement aux retours, montrer que vous intégrez les feedbacks. Une vision construite ensemble a plus de chances d’être exécutée.

Rester humble sur ce que je ne sais pas encore
Admettre ouvertement les zones d’ombre plutôt que de faire semblant de tout comprendre. Cette humilité crée de la confiance et invite l’équipe à partager son expertise.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore en profondeur les enjeux de la prise de poste, avec des témoignages de CTOs sur leurs premiers 90 jours et les leçons qu’ils en ont tirées.

Pour approfondir, tu peux aussi consulter les pages piliers du site ou les guides mis à disposition.