CTO externe : les 14 premiers jours

Vous signez avec un CTO externe un lundi matin. Deux semaines plus tard, qu'est-ce qui doit avoir changé ? Pas toute l'architecture, ni toute la roadmap. En 14 jours, il doit surtout rendre votre situation technique lisible : les risques qui menacent le produit, les décisions qui attendent un responsable et l'ordre dans lequel agir. Sans ce résultat, vous avez acheté des réunions. Avec lui, vous pouvez décider où investir les trois prochains mois.

Je me souviens d'une mission de CTO part-time où l'on aurait facilement pu réduire le sujet à l'architecture. Le SaaS ne fonctionnait pas encore, une équipe offshore avançait sans cadre commun et l'infrastructure coûtait plus de 400 euros par mois. La priorité n'était pas de dessiner le système idéal. Il fallait remettre le produit en état de livrer, donner un cadre à l'équipe et réduire une facture qui est ensuite tombée à 100 euros par mois. Ce cas résume bien ce qu'on attend des premiers jours : trouver le bon ordre avant d'ajouter du travail.

Cette période donne le ton de la mission. Le CTO découvre le produit, mais vous découvrez sa manière de travailler. Vous voyez s'il comprend avant de prescrire et s'il relie la technique aux clients. Surtout, vous vérifiez que ses recommandations peuvent vivre sans lui.

Les 14 premiers jours doivent réduire l'incertitude

Un CTO externe arrive rarement dans une situation calme. Le MVP a trouvé ses premiers clients, l'équipe avance avec des habitudes prises dans l'urgence et la roadmap commence à engager des montants sérieux. Le fondateur sait que quelque chose doit être structuré, sans toujours savoir par où commencer.

On me demande parfois une nouvelle architecture dès la première semaine. Je préfère attendre. Un schéma propre ne dit rien sur la priorité commerciale, la capacité de l'équipe ou les contraintes laissées par les clients actuels.

Dans une mission de CTO part-time, je commence par chercher les décisions qui coûtent déjà du temps. Un recrutement est-il bloqué parce que le rôle reste flou ? Une agence attend-elle une validation sur l'architecture ? Une dette ralentit-elle vraiment les ventes, ou gêne-t-elle surtout les développeurs ? Le même problème technique ne mérite pas la même réponse selon son impact.

Les 14 premiers jours servent à passer d'un sentiment diffus à une situation nommée. « La plateforme devient fragile » doit devenir « le paiement peut être traité deux fois », « personne ne sait restaurer une sauvegarde » ou « chaque nouvelle entreprise cliente exige une modification manuelle ».

Ce niveau de précision change la discussion. Le fondateur peut arbitrer un budget. L'équipe comprend ce qui sera traité et ce qui peut attendre. Le CTO, lui, prend la responsabilité de proposer un ordre plutôt qu'une liste anxiogène de défauts.

Au terme de ces deux semaines, vous devez pouvoir répondre à quatre questions : où le produit risque-t-il de casser, quelles décisions sont en retard, qui doit les prendre et quel chantier commence lundi prochain ?

Jours 1 à 7 : comprendre avant de prescrire

La première semaine commence par les accès, mais elle ne s'arrête pas au dépôt GitHub. Pour comprendre un produit, il faut relier le code à ce que l'entreprise vend.

Je demande d'abord au fondateur de raconter le produit sans ouvrir la roadmap. Qui paie ? Quel parcours déclenche la valeur ? Quelle promesse figure dans les contrats ? Quel incident ferait perdre le client le plus important ? Ces réponses donnent une hiérarchie que le code ne contient pas.

Viennent ensuite les échanges avec les personnes qui construisent et exploitent le produit. Un développeur connaît souvent la zone qu'il évite de modifier. Le support sait quelle erreur revient chaque semaine. Le commercial connaît la fonctionnalité promise au prochain grand compte. En réunissant ces informations, on distingue une dette agaçante d'un risque capable de bloquer une vente.

La revue cherche d'abord ce qui empêcherait l'entreprise de continuer si une personne ou un prestataire disparaissait demain. Si le fondateur ne peut plus accéder au produit, à son domaine ou aux comptes qui le font fonctionner, il ne possède pas vraiment son outil. Une collaboration qui s'arrête peut alors arrêter l'activité.

Elle regarde ensuite ce qui peut abîmer la relation client. Un paiement compté deux fois touche directement le chiffre d'affaires. Un utilisateur qui voit les données d'une autre entreprise détruit la confiance. Des informations perdues sans que l'équipe puisse les récupérer peuvent transformer un incident discret en rupture de contrat.

Enfin, il faut comprendre pourquoi les engagements glissent. Une roadmap trop large ne demande pas la même réponse qu'un produit devenu impossible à modifier ou qu'une équipe dépendante d'une seule personne. Dans les trois cas, le fondateur voit du retard. Le CTO doit distinguer ce qui relève du périmètre, de l'organisation ou du produit avant de proposer un chantier.

Cette revue n'est pas un audit exhaustif de chaque fichier. En sept jours, chercher l'exhaustivité produit surtout un rapport long et peu utile. La priorité est d'identifier les points qui peuvent affecter le chiffre d'affaires, la confiance d'un client ou la continuité de l'équipe.

Le fondateur peut accélérer cette phase en préparant les accès, les contrats prestataires, la roadmap actuelle et les incidents récents. Masquer un problème pour « laisser une bonne impression » fait perdre du temps à tout le monde. Une première mission réussie part de la situation réelle, pas de la version présentable en comité.

À la fin du septième jour, le CTO ne devrait pas encore promettre une refonte. Il doit être capable de formuler les risques observés, de dire lesquels nécessitent une vérification supplémentaire et de signaler une urgence sans attendre le rapport final.

Jours 8 à 13 : transformer le diagnostic en décisions

La deuxième semaine est celle des arbitrages. Une liste de problèmes ne suffit pas : presque toutes les codebases en production contiennent de la dette, des dépendances vieillissantes et des zones peu documentées. Le travail consiste à choisir ce qui mérite du temps maintenant.

Chaque sujet doit être relié à une conséquence et à une décision. « Il manque des tests » devient « une modification de la facturation peut changer un montant sans alerte ; nous sécurisons ce parcours avant d'ajouter le prochain plan tarifaire ». La formulation permet au fondateur de comprendre pourquoi ce chantier passe devant une amélioration plus visible.

Je classe généralement les actions selon leur horizon, sans fabriquer une roadmap annuelle au bout de dix jours.

Ce dernier horizon compte autant que les autres. Une première mission de CTO externe ne doit pas transformer chaque imperfection en urgence. Décider qu'une dette peut attendre évite de détourner l'équipe d'un enjeu commercial plus important.

Le plan doit aussi respecter la capacité réelle. Recommander six chantiers à une équipe capable d'en mener deux ne crée pas de direction. Cela déplace seulement la confusion dans un document. Le CTO doit donc confronter ses priorités aux personnes qui vont les exécuter, puis ajuster le périmètre.

Entre les jours 8 et 13, les décisions commencent déjà à circuler. L'équipe n'attend pas la présentation finale pour corriger un accès critique ou clarifier la responsabilité d'un prestataire. Le livrable du jour 14 consolide le travail ; il ne le découvre pas.

Jour 14 : un livrable que l'entreprise peut reprendre

Le dernier jour ne devrait pas se résumer à une présentation de 60 diapositives. Quelques pages suffisent si chaque ligne aide réellement à décider.

Il contient une lecture courte de la situation, les risques classés par impact, les décisions déjà prises et un plan réaliste pour les prochaines semaines. Chaque chantier a un responsable, un résultat attendu et une raison d'être. Les sujets écartés apparaissent aussi, afin qu'ils ne reviennent pas à chaque réunion sous une nouvelle forme.

Le document doit rester utilisable si la mission s'arrête le lendemain. Un fondateur doit pouvoir le partager à son équipe, challenger un devis avec lui ou l'utiliser pour recruter. Si seul le CTO comprend ses propres recommandations, l'entreprise a créé une nouvelle dépendance au lieu de réduire les anciennes.

Le jour 14 permet aussi d'évaluer la collaboration avant de s'engager sur la durée. Le nombre de problèmes trouvés m'intéresse moins que la qualité des décisions obtenues.

Au bout de deux semaines, je vérifie quelque chose de très simple. L'équipe sait ce qui passe en premier, le fondateur comprend le risque couvert et chacun connaît son rôle. Les désaccords existent encore, mais ils portent sur des choix explicites plutôt que sur des impressions.

Un audit qui conclut qu'il faut tout réécrire, tout migrer ou recruter immédiatement mérite d'être challengé. Une recommandation technique peut être juste sur le papier et mauvaise pour l'entreprise. Le CTO externe doit assumer ce contexte dans ses décisions.

Vous pouvez alors choisir la suite : arrêter après le cadrage, confier l'exécution à l'équipe existante ou poursuivre avec un accompagnement régulier. Le coût d'un CTO part-time devient plus simple à juger lorsque les responsabilités et les résultats attendus sont visibles.

Ce qu'il faut retenir

• Les 14 premiers jours servent à rendre les risques et les décisions techniques lisibles pour le fondateur.
• La première semaine relie le produit, les clients, l'équipe et la réalité du code.
• La deuxième transforme le diagnostic en priorités compatibles avec la capacité disponible.
• Le livrable du jour 14 doit rester utile même si la mission s'arrête immédiatement.
• La qualité du démarrage se mesure aux décisions clarifiées, pas au nombre de pages produites.

Questions fréquentes

Quels accès préparer avant l'arrivée d'un CTO externe ?

Préparez l'accès au code, aux environnements, aux outils de suivi et aux services critiques. Ajoutez la roadmap, les contrats prestataires et les incidents récents. Le CTO demandera uniquement les droits nécessaires et pourra signaler les accès qui devraient rester séparés.

Un CTO externe peut-il vraiment auditer un produit en 14 jours ?

Il peut identifier les risques prioritaires et construire un plan de décision en 14 jours. Il ne peut pas vérifier chaque ligne de code ni corriger toute la dette dans ce délai. La valeur vient du ciblage : comprendre assez vite pour agir sur ce qui menace réellement le produit ou l'entreprise.

Faut-il poursuivre la mission après les deux premières semaines ?

Pas systématiquement. Un cadrage ponctuel peut suffire si l'équipe sait exécuter le plan et porter les décisions. Un accompagnement régulier devient utile lorsque les arbitrages continuent, qu'un prestataire doit être piloté ou que l'équipe se structure.

Conclusion

Pour cadrer ce que vos 14 premiers jours doivent produire, réservez un échange de 30 minutes. Nous identifierons les décisions à débloquer avant de parler de durée ou de forfait.