Une migration d’ERP (enterprise resource planning, progiciel de gestion intégré) est rarement un projet anodin. C’est un système qui touche les opérations, la facturation, la comptabilité, et parfois la production. Quand elle se passe mal, l’entreprise s’arrête. Quand elle se passe bien, personne ne le remarque, ce qui est exactement le résultat visé.
Cet article liste douze points opérationnels qu’on vérifie systématiquement sur les missions CTO externalisé qui incluent une migration d’ERP. Pas une méthode théorique. Des cases concrètes à cocher.
Avant la décision
1. Pourquoi migrer maintenant ?
Le déclencheur doit être clair et partagé. Trois raisons légitimes : fin de support de l’éditeur, besoin métier qui ne tient pas dans la version actuelle, intégration impossible avec un nouvel outil indispensable. Si le déclencheur n’est qu’un agacement diffus de la direction, on attend.
2. Qui porte le projet en interne ?
Une migration ne peut pas être pilotée uniquement par un prestataire. Il faut un référent métier en interne, identifié, dégagé d’autres responsabilités pendant la durée du projet. Si la direction ne peut pas désigner cette personne, on ne démarre pas.
3. Quel est le périmètre exact ?
On documente précisément : quels processus métier sont concernés, quels intervenants utilisent l’ERP, quelles intégrations avec d’autres systèmes, quelles données migrent et quelles données restent à l’ancien. Un périmètre flou produit une migration qui dérape.
Pendant le cadrage
4. Quelle version cible et chez qui ?
Le choix de la version cible (nouvelle version de l’ERP actuel, autre éditeur, refonte sur-mesure) doit être documenté avec hypothèses, risques, et alternatives. Le choix de l’hébergement (cloud éditeur, cloud tiers, on-premise) idem. Ces décisions sont rarement réversibles à coût raisonnable.
5. Stratégie de migration des données
Trois approches possibles : migration intégrale (toutes les données historiques basculent), migration sélective (seulement les données vivantes), reprise par paliers (les données arrivent par flux après la mise en service). Le choix dépend du volume, de la criticité, et du temps d’arrêt acceptable. On documente l’approche choisie et ses implications.
6. Plan de rollback
Avant de démarrer la construction, on rédige le plan de rollback. Si la mise en service tourne mal, comment revient-on à l’ancien système ? Combien de temps prend la bascule arrière ? Quelles données seront perdues ? Ce plan est documenté noir sur blanc, et il est validé par la direction.
Pendant la construction
7. Tests sur données réelles anonymisées
On ne teste pas la migration sur des données fictives. On la teste sur un échantillon anonymisé des vraies données. C’est la seule manière de voir les cas de bord qui apparaîtront en production.
8. Implication des opérationnels par phase
Les opérationnels doivent valider à chaque jalon, pas seulement à la fin. Sinon, le système livré ne correspond pas à leur façon de travailler, et il faut tout reprendre. La méthode prévoit des points de validation tous les 15 jours avec les utilisateurs cible.
9. Documentation produite en parallèle
La documentation utilisateur et technique est produite pendant la construction, pas après. Sinon, elle est bâclée. On documente au fil de l’eau, avec les bonnes captures d’écran de la version qui va vraiment être livrée.
Pour la mise en service
10. Fenêtre de bascule étudiée
La fenêtre de bascule est choisie en fonction du métier : un samedi en début de mois pour une PME de service, le mois d’août pour une activité saisonnière à l’envers, jamais en fin d’exercice comptable. Et on planifie une fenêtre où l’équipe technique du prestataire est disponible 48 heures à la suite.
11. Présence des bons interlocuteurs en J+1
Le jour de la mise en service et la semaine qui suit, on a sur place ou en astreinte : un opérationnel métier, un référent technique, et notre équipe. Pas un seul. Les imprévus arrivent dans des combinaisons qui demandent toutes les compétences en même temps.
12. Surveillance des indicateurs critiques pendant 30 jours
On surveille pendant un mois les indicateurs critiques : nombre de transactions par jour, taux d’erreur, temps de réponse, retours utilisateurs. Si quelque chose dérive, on le voit en quelques heures, pas en quelques semaines.
Ce qu’on ne fait pas
Trois pièges classiques que notre méthode écarte.
Une mise en service précipitée pour tenir une date qui ne signifie rien. Si la date était arbitraire au démarrage, elle peut bouger sans casse en cours de projet. Mieux vaut un décalage de quinze jours qu’un système instable.
Une formation après la mise en service. Les utilisateurs doivent être formés avant. Sinon, on connaît la suite : ils abandonnent l’outil et reviennent à l’ancien, et la migration est ratée.
Une dépendance créée par défaut. À la fin du projet, l’équipe interne doit savoir opérer le nouvel ERP sans nous. Documentation, accès, formation. Notre méthode de sortie de mission s’applique.
Quand on refuse une mission de migration
Trois situations où nous disons franchement non.
- Pas de référent interne. Sans personne dédiée côté client, on ne fait pas. C’est non négociable.
- Calendrier intenable. Si le délai demandé empêche les tests et la formation, on dit non. Et on propose un calendrier qui marche.
- Périmètre fluctuant. Si le périmètre change tous les quinze jours pendant le cadrage, c’est que les commanditaires ne sont pas alignés. On le dit, on les laisse régler ça en interne, on revient quand c’est stabilisé.
Plusieurs de ces douze points, le périmètre, la validation par les opérationnels, la recette, relèvent du travail d’une assistance à maîtrise d’ouvrage plutôt que de l’intégrateur qui migre.
Pour aller plus loin
- CTO externalisé : la mission type qui pilote ce genre de migration
- Moderniser ses outils legacy en 2026 : le contexte plus large d’une modernisation
- Sortie de mission préparée : la discipline qui évite la dépendance après livraison
- Reprise de données : le poste qui fait déraper les migrations : les sept anomalies qu’on retrouve partout
- Outil métier sur mesure ou ERP : avant de migrer, vérifier que c’est bien un ERP qu’il faut
- Contrats informatiques et reconduction tacite : la fenêtre de sortie, à repérer avant de s’engager ailleurs