Migration pour 150 collaborateurs : un playbook sans big bang

Une entreprise de 150 personnes éteint le vendredi soir l'ancien système et allume le nouveau. Le lundi, la moitié des commandes est bloquée, la comptabilité ne correspond plus au magasin, et personne ne sait si cela tient aux données ou à un mauvais paramètre. C'est le big bang, et il échoue rarement en silence. Les grands projets IT dépassent leur budget de 45 % en moyenne et livrent 56 % de valeur en moins que promis. Pour 17 % d'entre eux, les dégâts sont assez importants pour menacer la survie de l'entreprise (McKinsey et Oxford, 2012).

Une transition pour 150 collaborateurs ne doit pas être un pari. Vous la découpez en vagues, vous laissez l'ancien système tourner jusqu'à ce que chaque vague soit stable, et vous décidez après chaque étape si vous continuez. Voici l'ordre qui fonctionne, avec les endroits où les équipes se bloquent.

Mesurer d'abord, construire ensuite

La première erreur consiste à choisir un fournisseur avant de savoir ce que vous remplacez. Commencez par un audit de processus : fixez comment le travail se déroule réellement aujourd'hui, quelles étapes apportent de la valeur et lesquelles ne sont là que parce qu'elles y ont toujours été. Chez 150 personnes, des dizaines de processus s'entremêlent, et la plupart ne sont décrits nulle part. Ce que vous ne cartographiez pas migre avec le reste, y compris le double travail.

Posez en plus un audit FinOps sur vos licences et votre infrastructure. Les organisations gaspillent 20 à 30 % de leurs dépenses IT, et plus de la moitié des licences SaaS restent inutilisées (Flexera, 2024). C'est de l'argent que vous n'avez pas besoin d'emporter vers la nouvelle plateforme. Chaque licence que vous supprimez et chaque système que vous éteignez est un coût qui disparaît et une intégration de moins à construire.

Découpez la migration en vagues

Une vague est une portion de travail délimitée que vous menez de bout en bout de l'ancien vers le nouveau système : un module, un service ou un processus, avec les données et les utilisateurs qui vont avec. Vous ne construisez pas tout en même temps. Vous choisissez une première vague assez petite pour rester maîtrisable et assez importante pour prouver quelque chose.

1. Commencez par un processus au périmètre clair, où les données sont propres et les dépendances limitées. L'order-to-cash ou la gestion des stocks sont souvent de bonnes premières vagues.
2. Placez les processus qui dépendent les uns des autres dans des vagues successives, afin qu'une erreur dans l'un n'entraîne pas l'autre.
3. Gardez pour plus tard le processus qui compte le plus d'exceptions et les données les plus sales, quand l'équipe connaît la plateforme et que le rythme est installé.
4. Donnez à chaque vague le même schéma fixe : construire, tester avec des données réelles, faire tourner en parallèle, et ne basculer qu'ensuite.

Laissez le legacy tourner : le parallel run

Le big bang échoue parce qu'il n'y a pas de retour en arrière. Un parallel run, lui, en a un. Pendant chaque vague, l'ancien système continue de faire le travail de vérité, tandis que le nouveau exécute le même travail en parallèle sur les mêmes entrées. Vous comparez les résultats jour après jour : les mêmes factures, les mêmes soldes, les mêmes états de stock. Ce n'est que lorsque le nouveau système donne le même résultat plusieurs périodes de suite que vous déplacez la source de vérité. Cela coûte un temps de double travail, et cela vous achète le droit de revenir en arrière sans dégâts.

Ne comptez pas pour autant sur une IA qui ferait la migration à votre place. Gartner s'attend à ce que plus de 70 % des projets de sortie de mainframe lancés en 2026 n'atteignent pas leur objectif, précisément parce que les équipes surestiment ce que l'IA générative peut faire (Gartner, 2026). L'IA aide à lire de l'ancien code et à rédiger des cas de test. La réconciliation, elle ne la fait pas, et vos exceptions, elle ne les connaît pas. Traitez-la comme un outil, pas comme l'entrepreneur.

Migrer et réconcilier les données

La migration des données est l'endroit où le plus de temps disparaît et celui que les équipes planifient le moins. Les anciens systèmes sont pleins de champs que quelqu'un a un jour détournés pour autre chose, de clients qui existent trois fois, et de montants dans des devises que plus personne n'utilise. Vous en extrayez les données, vous les nettoyez, et vous les chargez avec une trace vers la source, afin de pouvoir remonter chaque enregistrement. La réconciliation est le cœur de chaque vague.

• Comptez les enregistrements des deux côtés et expliquez chaque écart, même un écart de un.
• Réconciliez au centime près les montants qui comptent : créances ouvertes, valeur de stock, soldes du grand livre.
• Testez avec une copie des vraies données de production, pas avec des exemples inventés, car les exceptions se trouvent dans le réel.
• Faites valider les chiffres par le propriétaire du processus, pas par l'équipe qui a mené la migration.

Emmenez 150 personnes avec vous

Une plateforme techniquement juste que personne n'utilise est une migration ratée. Chez 150 personnes, vous changez plus que le logiciel. Vous changez la façon dont les gens organisent leur journée. Impliquez tôt une poignée d'utilisateurs clés par vague, laissez-les participer à la manière dont leur processus se déroule dans le nouveau système, et faites-en les personnes qui formeront leurs collègues. Formez par vague et au plus près de la bascule, afin que ce que les gens apprennent soit encore frais lorsqu'ils en ont besoin. Une seule grande formation pour toute l'entreprise, des mois avant la première vague, est du temps perdu.

Bascule, module par module

La bascule elle-même est courte si le travail préparatoire est juste. Par vague, vous basculez un module, à un moment de faible trafic, avec l'ancien système encore en stand-by. Les utilisateurs de ce module passent, le reste de l'entreprise travaille comme hier. Si la première vague tourne quelques semaines de façon stable, la suivante démarre, avec ce que vous avez appris intégré dedans. Vous construisez ainsi la plateforme pendant que l'entreprise continue de tourner, jusqu'à ce que le dernier module soit passé et que l'ancien système puisse être éteint.

Le chemin vers une nouvelle plateforme n'est pas spectaculaire. C'est une suite de petites étapes réversibles, chacune avec une issue. C'est précisément pour cela qu'il aboutit.

À la fin se trouve une seule plateforme que vous possédez, avec le code dans votre propre dépôt et sans le verrou qui vous prendrait de nouveau en otage la prochaine fois. Qui aborde ainsi une transition échange un grand risque en une soirée contre une suite de petites décisions que vous gardez vous-même en main. C'est la seule version de cette migration que vous oseriez refaire une deuxième fois.