Préparation go-live ERP : ce qu'il faut avoir fait avant d'appuyer sur le bouton Votre projet ERP avance bien, le Build touche à sa fin — et vous pensez commencer à préparer le go-live une fois tout terminé ? C’est justement là que beaucoup de projets décrochent. Dans la méthode PRISM, la phase Préparation go-live démarre pendant le Build : idéalement 2 à 3 sprints avant la fin, ou dès les 30 % restants du projet. Dans cet article, découvrez les 5 piliers qui vous permettront d’arriver au go-live en position de force, sans précipitation et sans mauvaise surprise. 🎯 L’essentielCommencer trop tard est l’erreur la plus fréquente : la préparation se conduit en parallèle de la fin du Build, pas après.Un go-live peut démarrer sans que tout soit parfait : ce qui compte, c’est de savoir ce qui fonctionne, ce qui ne fonctionne pas encore, et d’avoir des solutions de contournement documentées.5 piliers structurent cette phase : complétude du Build, rôles et accès, formation, cutover plan et plan de support — tous préparés avant le jour J, même si certains ne s’exécutent qu’après. Les 5 piliers de la préparation go-live1. S’assurer de la complétude du BuildLa préparation go-live commence par un état des lieux lucide : qu’est-ce qui est prêt, qu’est-ce qui ne l’est pas encore ? Aller en production avec des fonctionnalités partiellement opérationnelles est possible — à condition de le savoir, de le documenter et d’avoir des solutions de contournement. Ce qui n’est pas acceptable, c’est de ne pas le savoir.Quatre éléments sont à passer en revue :La configuration et les paramétrages. Toutes les configurations validées en atelier ont-elles été reportées dans l’environnement ? Les tests sont-ils concluants ? C’est ici qu’on s’appuie sur l’environnement Gold — l’environnement de référence, propre, qui ne contient que le paramétrage validé et qui sera promu en production. Il doit être peaufiné, testé, verrouillé.Les interfaces. Les connexions avec les autres systèmes (WMS, CRM, banque, EDI…) sont-elles prêtes à être activées ? Une interface qui fonctionne en test peut se comporter différemment sous charge réelle. C’est le moment de le vérifier.La migration de données. La stratégie a été définie et testée pendant le Build. Ce qu’on vérifie ici : la procédure est connue et documentée — quels objets, quelle transformation, quels scripts, dans quel ordre. On ne migre pas encore, on s’assure qu’on est prêt à le faire.Les batchs et traitements automatiques. Calcul des besoins (MRP), FNP comptables, validations automatiques, traitements WMS… Ces batchs doivent être listés, leur périodicité définie, leur activation planifiée dans le cutover plan. Attention : L’environnement Gold n’est pas « l’environnement de test rebaptisé prod ». C’est un environnement dédié, sans données transactionnelles parasites — c’est lui qui passe en production. Valider les rôles et profils d’accèsLes accès utilisateurs sont l’un des points les moins aboutis dans la plupart des projets — et c’est normal. Ni l’intégrateur ni vous ne savez d’avance précisément qui a besoin de quoi. La règle simple : partir restrictif plutôt que permissif.Un accès manquant, ça se signale et ça se corrige en quelques minutes. Des droits trop larges accordés par défaut, ça génère silencieusement des erreurs de saisie et des risques de sécurité. Attention : Côté utilisateur, un problème d’accès se traduit rarement par « il me manque un profil ». Il se traduit par « ça ne marche pas ». Assurez-vous que vos super-users savent distinguer un bug fonctionnel d’un problème de droits. Avant le go-live, vérifier que : tous les comptes sont créés et actifs, chaque utilisateur est rattaché au bon profil métier, les données sensibles (finance, paie, marges) sont protégées, et les accès ont été testés par les utilisateurs eux-mêmes en pré-production — pas seulement par l’IT.3. Former les utilisateurs finaux (par les super-users)La formation est le dernier rempart contre l’échec d’adoption. Et sa réussite repose sur qui la délivre.La règle d’or : la formation vient des key users, pas de l’intégrateur. Les key users ont été présents tout au long du projet — ils ont fait les tests, participé aux ateliers, validé les processus. Quand la formation vient d’un collègue qui connaît les réalités du terrain, l’adhésion est plus concrète, plus crédible, plus rassurante. L’équipe projet prépare les supports (slides, fiches, captures d’écran), les key users animent les sessions.Comment structurer les sessions :Commencer par le processus, pas par l’outil : expliquer ce qui change, pourquoi, ce que ça apporte.Passer ensuite à l’outil : montrer comment le nouveau processus se traduit dans l’ERP, sur des cas concrets de l’entreprise.Segmenter par population : supply chain et comptabilité n’ont pas les mêmes besoins — des sessions mixtes noient tout le monde. Mémo Si PRISM a bien été suivi, les key users ont déjà présenté les nouvelles procédures à leurs collègues durant le projet. La formation ne devrait pas être une surprise — c’est la mise en pratique de ce qui a déjà été communiqué. N’oubliez pas : Les super-users doivent avoir du temps dédié pour préparer et animer les formations. Ce n’est pas une tâche qu’on cale « en plus » de leur activité quotidienne. 4. Préparer le cutover planLe cutover plan, c’est la feuille de route du basculement : comment on passe, objet par objet, de l’ancien système au nouveau. Ici, on ne l’exécute pas — on le prépare, on le documente, on le valide.La logique du cutover par objet repose sur une distinction fondamentale : Type de données Exemples Approche Master data Clients, fournisseurs, articles, tarifs Migration possible en avance Données transactionnelles Stocks en cours, commandes ouvertes, soldes comptables Migration au dernier moment uniquement Sur le transactionnel, le choix structurant est : récupère-t-on tout l’historique ou seulement ce qui est en cours ? La réponse quasi-systématique : seulement ce qui est ouvert et non soldé. Migrer des années de transactions crée de la complexité et des risques sans valeur opérationnelle réelle. L’ancien système reste accessible en lecture pour consulter le passé. Exemple : Un utilisateur veut récupérer toutes les factures historiques, même soldées. Cela implique aussi de migrer tous les paiements associés — ce qui était un objet devient deux objets à transformer et tester. Multipliez ça par tous les modules : c’est pourquoi les intégrateurs déconseillent systématiquement l’historique complet. Ce que le cutover plan précise, objet par objet :Quand on arrête les flux dans l’ancien système.Quelle extraction on réalise (quoi, quel format, par qui).Quelle procédure de chargement dans le nouveau système.Quand les interfaces sont basculées ou activées.Quels batchs sont activés, dans quel ordre, avec quelle périodicité.Quelles périodes comptables ou de stock ouvrir dans le nouveau système.Le plan de retour arrière est indissociable du cutover plan : dans quel scénario doit-on annuler le basculement ? Qui prend la décision ? Que fait-on concrètement ? Ce plan doit être écrit, validé et accessible le jour J. Attention : Le cutover plan se prépare pendant la Préparation go-live. Il s’exécute pendant le go-live. La rigueur de la préparation détermine la sérénité de l’exécution. 5. Préparer le plan de support post-go-liveLe go-live, c’est le moment où tout le monde accède au système pour la première fois en conditions réelles. Si le support n’est pas organisé avant le démarrage, il sera improvisé sous pression — et l’improvisation sous pression ressemble à une messagerie Teams qui explose dans tous les sens.Les trois niveaux de support à définir :Niveau 1 — Super-users : premier filtre pour les questions et blocages courants. Attention : il faut leur prévoir du temps dédié — le go-live est l’un de leurs moments les plus importants, pas la fin de leur implication.Niveau 2 — Équipe projet ou intégrateur : incidents fonctionnels ou de paramétrage. C’est ici que joue le contrat de support ou la garantie de l’intégrateur.Niveau 3 — Configuration ou développement : interventions techniques en profondeur.Ticketing plutôt que Teams. Un canal Teams peut sembler pratique, mais dès que le volume monte, les priorités se noient et les demandes se perdent. Un outil de ticketing, même simple, permet de prioriser, tracer et résoudre les incidents de façon structurée.Séances collectives bihebdomadaires. En complément, planifier des sessions par population (supply chain ensemble, comptabilité ensemble…) pour traiter collectivement les problèmes les plus impactants et corriger en live. C’est bien plus efficace qu’une succession de tickets individuels sur le même sujet.N’oubliez pas : Niveaux de support, outil de ticketing, séances collectives — tout cela se prépare avant le go-live, pas le lundi matin quand les utilisateurs ont déjà commencé à rencontrer des problèmes. Et ensuite ? La Préparation go-live débouche directement sur le Go-live — l’exécution du cutover plan, l’ouverture du système à tous les utilisateurs, et la mise en œuvre du plan de support. Tout ce qui a été préparé ici sera activé là-bas.Mais chaque pilier évoqué dans cet article mérite d’être approfondi. C’est pourquoi nous avons préparé une série d’articles micro qui détaillent chacune de ces étapes :Valider la complétude du Build : comment vérifier que config, interfaces, données et environnement Gold sont réellement prêts.Gérer les rôles et accès utilisateurs : méthodologie pour arbitrer entre sécurité et fluidité opérationnelle.Structurer la formation par les super-users : comment préparer, animer et mesurer l’impact des sessions de formation.Rédiger un cutover plan robuste : guide objet par objet pour orchestrer le basculement et anticiper le retour arrière.Organiser le support post-go-live : outils, niveaux, rituels et dimensionnement des ressources. Accédez aux 5 guides détaillés Préparation go-live PRISM pour maîtriser chaque pilier en profondeur. (Contenu disponible sur inscription) ArticlesÉvaluer la complétude du Build Valider les rôles et accès utilisateurs Construire le cutover plan Organiser la formation des utilisateurs Mettre en place le plan de support Préparer le rollback plan
