Pourquoi les bascules ERP progressives valent mieux que les mises en service big-bang

Chaque étude de cas d'échec d'ERP que vous lisez commence de la même façon : un plan de projet confiant, une date de mise en service unique, et une équipe financière qui a passé le trimestre suivant à répondre à des questions d'audit au lieu de clôturer les comptes. Le plan ne dit jamais « big-bang ». Il dit « mise en service ». Mais la structure — une date, un basculement, tous les modules — revient au même.

Nous ne procédons pas ainsi. La première clôture mensuelle sur un nouvel ERP est censée être ennuyeuse. Et la façon de la rendre ennuyeuse, c'est de ne pas tout déplacer d'un coup.

Ce que « progressif » signifie réellement

Une bascule progressive migre un domaine fonctionnel à la fois — généralement les achats d'abord, puis les stocks, puis la finance, puis les ventes/CRM — pendant que le système hérité continue d'opérer les modules que vous n'avez pas encore migrés. Chaque domaine que vous déplacez fonctionne en parallèle de l'ancien système pendant au moins un cycle de clôture complet avant que vous ne désactiviez le système hérité.

L'objectif n'est pas la rapidité. L'objectif est que, si la réconciliation des achats se casse, vous le découvriez avant que l'entrepôt et la finance ne dépendent eux aussi du nouveau système pour fonctionner.

Ce que vous abandonnez

Vous abandonnez la simplicité d'une date unique dans le plan de projet. Le directeur financier qui voulait « tout le monde sur le nouveau système d'ici juillet » se retrouve avec une bascule échelonnée sur quatre mois. C'est un coût réel. Aucun client ne nous a jamais dit, après coup, qu'il aurait préféré que le plan de quatre mois soit recompressé en un seul week-end.

Vous abandonnez aussi une certaine élégance d'intégration pendant la fenêtre de fonctionnement en parallèle. Deux systèmes détenant des données qui se chevauchent, cela signifie des scripts de réconciliation, des comparaisons quotidiennes d'instantanés, et quelques semaines où quelqu'un dans l'équipe est payé pour repérer les écarts. Nous construisons généralement l'outillage de réconciliation dès la deuxième semaine de la mission — ce n'est pas glamour, mais c'est ce qui permet aux quatre phases suivantes de se dérouler sans drame.

Une séquence réelle

La version canonique en a été une mission industrielle : six systèmes hérités, douze semaines, quatre phases.

1. Semaines 1–4 — Cadrage, cartographie des processus et construction du dispositif de réconciliation. Pas encore de bascule en production.
2. Semaines 5–7 — Les achats migrent. Les nouveaux bons de commande sont créés dans le nouvel ERP ; le système hérité reste en lecture seule pour référence historique. La réconciliation tourne chaque nuit.
3. Semaines 8–9 — Les stocks suivent. La passation entre les achats (nouveau) et l'entrepôt (nouveau) est la première fois où les deux moitiés d'une paire de domaines vivent sur la nouvelle stack.
4. Semaines 10–11 — La finance migre. C'est celle que la plupart des équipes veulent faire en premier parce que c'est la plus visible. C'est la bonne à faire en dernier, car le temps d'y arriver, les données qui y affluent ont déjà été validées pendant deux mois.
5. Semaine 12 — Les ventes/CRM basculent. À ce stade, l'équipe l'a déjà fait quatre fois. Personne ne panique.

La raison pour laquelle cela fonctionne, c'est qu'aucune phase ne porte le risque à elle seule. Si la réconciliation des achats présente un écart de 0,4 %, vous le détectez en semaine 6, face à un système hérité fonctionnel, avec trois phases encore entre vous et le moindre auditeur externe.

Quand le big-bang a réellement du sens

C'est rare, mais cela existe. Les déploiements greenfield, où il n'y a aucun système hérité à faire tourner en parallèle, peuvent être en big-bang par nécessité — il n'y a rien contre quoi phaser. Les très petites entreprises (moins d'environ 30 utilisateurs, entité unique) s'en sortent parfois bien avec une bascule sur un seul week-end, car la surface est assez réduite pour être testée exhaustivement à l'avance. Et il arrive qu'une échéance réglementaire impose une date unique et rende le compromis inévitable.

Pour tous les autres : le jour où vous comprimez chaque module en une seule bascule est le jour où vous misez la clôture de fin d'année sur un système que personne dans votre équipe n'a encore utilisé en production. Nous préférons prendre les quatre mois.