Je vais raconter une journée que j’aurais préféré ne pas avoir à vivre. Elle illustre pourtant assez bien ce qu’est une mission en mode CTO (chief technology officer, directeur technique) externalisé quand les choses ne se passent pas comme prévu. Et la leçon qu’on en a tirée est restée dans notre méthode depuis.
Le contexte
Mission CTO externalisé chez un client B2B, équipe technique interne de six développeurs, projet de bascule d’une plateforme métier critique. La nouvelle version était prête. Tests OK. Recette utilisateur OK. La bascule était calée pour la nuit du vendredi au samedi, fenêtre d’arrêt de service prévue de quatre heures.
J’étais arrivé sur site à dix-huit heures, accompagné de Clairmont. L’équipe interne était mobilisée. Le client avait fait préparer du café et des sandwichs. L’ambiance était bonne. La direction était sereine. Tout était sous contrôle.
La première alerte à vingt et une heures
On démarre la bascule à vingt heures. Première étape : extraction des données de production vers le nouveau système. Cette étape avait été testée trois fois sur les jeux de données récents, sans problème.
À vingt et une heures, l’extraction n’est toujours pas terminée. On regarde les logs : un de nos scripts d’export tourne lentement. Anormalement lentement. On le profile en direct, et on comprend qu’il y a une jointure sur une table que personne n’avait identifiée comme grosse, et qui contient en fait trois fois plus de lignes qu’estimé.
C’est gérable. On lance une optimisation rapide sur le script, on relance, et l’extraction se termine vers vingt-deux heures quinze. Quinze minutes de retard sur le calendrier, c’est dans la marge de sécurité. On continue.
Le vrai problème à vingt-deux heures quarante
On démarre l’import des données dans le nouveau système. Première vérification de cohérence à vingt-deux heures quarante. Les volumes correspondent. Les checksums correspondent. Mais quand on regarde un échantillon de données concrètes, on voit que les valeurs d’un champ critique ont été décalées d’une ligne. Pas toutes les lignes. Une sur quelques milliers, apparemment aléatoirement.
C’est le genre de bug que je déteste : pas reproductible facilement, ne ressort pas dans les volumes globaux, mais sur les cas individuels c’est une catastrophe métier. Si on met en production avec ce décalage, des clients de notre client vont recevoir les mauvaises informations dès lundi matin. Et on n’aura aucune trace claire pour réparer après coup.
On essaie de comprendre pendant quarante minutes. On change deux paramètres d’import, on relance, on revérifie. Le bug persiste. On commence à voir une faiblesse dans la structure de mapping des colonnes entre l’ancien et le nouveau système, mais on n’arrive pas à isoler précisément où.
La conversation difficile
À vingt-trois heures vingt, je vais voir le directeur des systèmes du client. Il avait dormi un peu sur un fauteuil. Je le réveille pour lui expliquer la situation, sans la maquiller.
« Je ne peux pas garantir que les données qu’on va remettre en production lundi matin seront cohérentes. J’ai un bug que je n’ai pas isolé. Je propose qu’on annule la bascule, qu’on remette l’ancien système en production avec les données de vendredi soir, et qu’on reprenne le sujet posément la semaine prochaine. »
Sa première réaction est d’essayer de pousser pour passer quand même. La fenêtre est cadrée, l’équipe est mobilisée, on a communiqué la bascule, et reculer maintenant veut dire qu’on perd du crédit. Je l’entends mais je tiens ma position : le risque de produire de mauvaises décisions business côté ses clients pendant deux semaines avant qu’on s’aperçoive du décalage est beaucoup plus grave que le coût d’une annulation.
Il prend cinq minutes pour appeler son dirigeant. À vingt-trois heures trente-deux, on annule la bascule.
Le redémarrage du week-end et la suite
On remet l’ancien système en production, on vérifie que tout est cohérent, et on termine vers une heure du matin. Tout le monde rentre dormir, sauf moi et Clairmont qui restons dormir sur place.
Samedi matin, café et reprise de l’analyse. En quatre heures, on isole le bug : un caractère spécial dans certains champs source provoquait un décalage de parsing dans un cas sur cinq mille environ. Bug trivial à corriger une fois identifié. Mais qu’on n’aurait jamais isolé en une nuit avec la fatigue et la pression.
On a refait la bascule deux semaines plus tard, sans incident. Le client était reconnaissant qu’on ait annulé la première fois, et nous a confié plusieurs autres missions depuis.
La leçon qu’on a tirée
On a ajouté un point dans notre checklist de mise en production : avant chaque bascule, un seuil de qualité concret est arrêté par écrit avec le client, du type « si l’échantillon de contrôle dépasse le niveau de divergence convenu, on annule ». Et un binôme indépendant de l’équipe de bascule a la mission d’observer ces seuils et de pouvoir crier stop.
Sans ce point formalisé, c’est la pression du moment qui décide. Et la pression du moment pousse presque toujours à passer outre. Avoir une règle écrite avant, c’est ce qui rend la décision soutenable.
C’est devenu un de mes garde-fous personnels en mission CTO externalisé : ne jamais arriver à une mise en production sans un protocole de rollback clair et des seuils écrits. C’est moins glamour qu’une démo de produit, mais c’est ce qui distingue une équipe qui livre proprement d’une équipe qui livre au hasard.
Pour aller plus loin
Lire réussir la migration d’un ERP : douze points qu’on regarde, refonte d’un ERP industriel : ce qu’on a vraiment fait en quatre mois, et moderniser ses outils legacy en 2026. Et si vous avez une bascule à risque qui approche, un échange en amont vaut largement le coût d’un mauvais incident.