Je raconte cette mission parce qu’elle illustre bien ce qu’on appelle un CTO externalisé en mode opérationnel : pas juste du conseil, du pilotage concret jusqu’à la mise en prod. Le client préfère rester anonyme, mais le type d’organisation est représentatif : industriel français, cent personnes, deux sites, un ERP métier installé en 2010 et qui n’avait jamais été mis à jour sérieusement depuis.
Le contexte qu’on a trouvé
L’ERP en place, c’était un Sage adapté il y a quinze ans pour le métier précis du client. Adaptations en VBA, modifications de base données directement par les utilisateurs, plus de quatre cents scripts maison sans aucune documentation. L’éditeur ne supportait plus la version. Aucune sauvegarde testée depuis deux ans.
Le client avait essayé deux fois de moderniser. La première avec un intégrateur classique, qui avait laissé tomber après six mois. La deuxième avec un prestataire low-cost qui avait facturé sans rien livrer. À ce stade, la direction commençait à se demander si c’était possible.
Le diagnostic de cinq jours
On a commencé par un diagnostic court, rémunéré, sur cinq jours. L’objectif : comprendre où on allait, et chiffrer honnêtement le risque de la migration. Pas un cahier des charges en cinq cents pages, un livrable de quinze pages exploitable par la direction.
Les conclusions étaient sévères mais nettes. La migration vers une nouvelle version Sage était possible, mais nécessitait de récupérer la logique métier des quatre cents scripts, de la traduire dans le nouveau standard, et de refaire les exports vers les outils périphériques (paye, facturation, logistique). Estimation : quatre mois calendaires, avec une équipe dédiée des deux côtés.
La direction a validé le diagnostic et signé un forfait sur quatre mois pour la mission complète, avec engagement contractuel sur la non-perte de données et sur la tenue de la date de bascule.
Le déroulé mois par mois
Mois 1 : cartographier et stabiliser. On a passé les trois premières semaines à inventorier les scripts existants, comprendre la logique métier de chacun, et identifier ce qui était encore utile vs ce qui pouvait disparaître. Sur les quatre cents scripts initiaux, soixante-dix étaient utilisés en production, le reste était mort ou redondant. Premier soulagement.
En parallèle, on a stabilisé l’existant. Sauvegardes testées, accès documentés, anciens contributeurs sortis du système. On a aussi formé deux personnes en interne pour qu’elles puissent intervenir en cas de problème pendant la migration, plutôt que de tout faire reposer sur nous.
Mois 2 : reconstruire la logique métier. On a réécrit la logique des soixante-dix scripts utiles dans le nouveau standard de l’ERP cible. Pas du copier-coller, une vraie refonte qui simplifiait là où c’était possible. On a mis en place un environnement de test miroir de la production, sur lequel on a fait tourner les processus métier en parallèle pendant trois semaines pour vérifier la conformité des résultats.
C’est dans ce mois qu’on a failli planter une première fois. Sur un calcul de coût de revient, on a trouvé une divergence qu’on n’arrivait pas à expliquer entre l’ancien et le nouveau système. Pendant deux jours, on a cru qu’il faudrait tout revoir. Finalement, c’est une formule cachée dans Excel utilisée par le contrôleur de gestion qui modifiait les résultats. Le nouveau système était juste. L’ancien était faux depuis cinq ans. La direction a découvert ça à ce moment-là.
Mois 3 : intégrer les outils périphériques. Tout le reste de la chaîne (paye, facturation, logistique, BI) recevait des fichiers de l’ancien ERP, parfois à la main. On a documenté chaque flux, recodé les exports, testé les intégrations. Trois prestataires externes étaient impliqués sur les outils périphériques. On a coordonné le calendrier pour que tout le monde soit prêt en même temps.
Deuxième moment de tension : l’intégrateur de la paye avait disparu pendant les vacances d’été. On a dû reprendre nous-mêmes la spec d’export et la valider avec un autre prestataire en urgence. Glissement de deux semaines absorbé sur notre marge de sécurité initiale.
Mois 4 : bascule et stabilisation. La bascule en production s’est faite un samedi de septembre, sur trois jours. Vendredi soir, on arrête l’ancien système. Samedi, on bascule les données. Dimanche, on teste. Lundi matin, le nouveau système était en production.
La semaine suivante, on avait quatre personnes sur site en astreinte pour gérer tous les cas de bord qu’on n’avait pas anticipés. Quelques bugs mineurs, aucun bug critique. Au bout de quinze jours, le système tournait seul, et on avait formé l’équipe interne pour la suite.
Ce qui a fait la différence
Trois choses, à mon avis.
D’abord la qualité du diagnostic initial. Sans ces cinq jours bien faits, on serait partis sur des hypothèses fausses, et la mission aurait probablement échoué comme les deux précédentes. Le diagnostic, c’est la base de tout.
Ensuite l’engagement de la direction. Le dirigeant a libéré du temps pour les arbitrages, le DAF a accepté de revoir des hypothèses qu’il portait depuis dix ans, et l’équipe métier a accepté que ses workflows évoluent. Sans ce soutien, on aurait été bloqués.
Enfin l’humilité face aux imprévus. La divergence sur le calcul de coût de revient, la disparition de l’intégrateur paye, les cas de bord à la mise en production : tout ça arrive sur ce type de mission. Notre rôle, c’est d’absorber, pas de prétendre que ça n’arrivera pas.
Le résultat un an après
On est repassé voir le client six mois plus tard. Le système tournait depuis sans incident majeur. L’équipe interne avait pris la main complètement, les deux personnes formées étaient devenues les référents officiels. Notre nom n’apparaissait plus nulle part dans les procédures opérationnelles. C’est exactement la sortie de mission qu’on cherche.
Pour aller plus loin
Lire comment on cadre un diagnostic en cinq jours, moderniser ses outils legacy en 2026, et réussir la migration d’un ERP : douze points qu’on regarde pour le cadre méthodologique. Et si vous avez un cas équivalent à creuser, un échange direct vaut souvent mieux qu’un appel d’offres formel.