Go-Live ERP : de la décision au premier jour de production Diffusion Votre préparation go-live est bouclée, le plan de bascule est prêt — et maintenant, c’est le moment de vérité. Dans la méthode PRISM, le Go-Live est la phase qui suit immédiatement la Préparation go-live : on passe de la préparation à l’exécution. Dans cet article, découvrez comment structurer cette étape critique pour basculer en confiance, gérer les premières semaines et poser les bases d’une stabilisation réussie. 🎯 L’essentielLa décision go/no-go est une étape formelle incontournable : avant d’appuyer sur le bouton, les sponsors et la direction doivent valider en connaissance de cause tous les risques connus et les sujets non résolus.Le Go-Live ne s’improvise pas le jour J : on exécute le cutover plan préparé en amont — migration, configuration finale, bascule des interfaces, activation du support.Les premières semaines sont décisives : un pilotage actif des incidents, du volume d’activité et de l’adoption utilisateur permet de détecter les vrais problèmes avant qu’ils ne s’installent. La décision go/no-go : formaliser pour avancer en confianceAvant toute chose, le Go-Live commence par une décision. Pas une date qu’on subit, mais un choix éclairé.Cette séance réunit les décideurs du projet — sponsors, direction, parfois le COMEX — et elle a un seul objectif : poser clairement la question « est-on prêt ? »Ce qu’on passe en revue :Ce qui est opérationnel : les flux validés, les données migrées avec succès, les utilisateurs formés, le support en place.Ce qui ne l’est pas encore, avec le niveau de risque associé. Chaque sujet dépriorisé au cours du projet (parce que ça pouvait attendre, parce que ça arrive une fois par an) doit être remis sur la table.Les décisions à confirmer : on ne suppose pas que les arbitrages pris en cours de route sont toujours valides — on les reconfirme avec les décisionnaires du moment. Exemple La clôture comptable n’a jamais été testée jusqu’au bout ? La valorisation de stock n’est pas configurée ? Ce n’est pas forcément un no-go — mais la direction doit l’entendre, l’assumer, et signer. Les vrais critères de no-go :Des flux standards ou critiques non validés en testUne migration de données incomplète ou non réconciliéeDes utilisateurs clés pas encore prêtsL’absence de plan de support opérationnel Attention : Un go-live peut tout à fait démarrer avec des sujets en suspens — à condition que ce soit un choix assumé, documenté, et non un oubli. La différence entre un risque géré et un risque subi, c’est souvent juste une signature. Retrouvez la matrice go/no-go détaillée et les critères par domaine (technique, données, formation, support) dans notre contenu dédié. L’exécution du cutover planDécision prise : on y va. Et maintenant, on exécute. Le cutover plan préparé en amont devient le seul document de référence.Les grandes étapes :Arrêt des flux dans l’ancien système et extraction finale des données transactionnelles (stocks, commandes ouvertes, soldes comptables)Migration finale dans l’environnement de production à partir du Golden — l’environnement de référence propre et verrouilléBascule des interfaces avec les systèmes périphériques (WMS, banque, EDI…)Activation des batchs et traitements automatiques dans l’ordre prévuOuverture des accès utilisateurs et tests de fumée pour vérifier que tout fonctionneN’oubliez pas : Le plan de retour arrière doit être prêt. À quel moment dit-on « stop » ? Qui prend la décision ? Que fait-on concrètement ? Ce n’t pas une option théorique : c’est une procédure écrite, disponible, assignée. Technique Le « Golden » n’est pas l’environnement de test rebaptisé. C’est un environnement dédié, sans données transactionnelles parasites, qui contient uniquement le paramétrage validé — et c’est lui qui passe en production. Template de cutover plan PRISM avec checklist d'exécution heure par heure. Les premières semaines : piloter la stabilisationLe go-live est passé. Le vrai travail commence maintenant.Qualifier les incidents, pas juste les compterTous les incidents ne se valent pas. Pour ne pas s’épuiser sur le mauvais problème, il faut une matrice simple dès le départ : Critère Urgent À traiter À planifier Blocage total des opérations ✅ Blocage partiel avec contournement ✅ Connu, solution de contournement documentée ✅ Deux niveaux de priorité suffisent amplement pour une ETI. Inutile de complexifier.Surveiller les volumes d’activité, pas juste les bugsC’est l’indicateur qu’on oublie le plus souvent : est-ce que les équipes travaillent vraiment dans le nouvel outil ?Si vous faisiez habituellement 1 000 commandes par mois et qu’après 6 semaines vous en avez 200, il y a un problème d’adoption — pas un bug.Si vous avez 10 incidents mais une seule commande saisie, le go-live se passe peut-être moins bien qu’il n’y paraît. Mémo Cohérence incidents + volumes = le vrai baromètre du go-live. Un faible volume d’incidents ne dit rien si le volume d’activité réel est inexplicablement bas. Les points de synchronisation réguliersPlanifiez des sessions collectives bihebdomadaires par population (supply chain ensemble, comptabilité ensemble). C’est bien plus efficace qu’une succession de tickets individuels sur le même problème. Attention : : Entre 25 % et 75 % des organisations subissent une baisse de performance opérationnelle au moment du go-live — ce qu’on appelle le « Grand V ». La productivité peut chuter temporairement à 60-80 % du niveau habituel avant de remonter progressivement. C’est normal, c’est prévisible, et ça se pilote. Modèle de matrice de qualification des incidents et tableau de bord stabilisation post-go-live. Les revues post-go-live : tirer les enseignementsAprès quelques semaines de stabilisation, une revue s’impose. Pas pour chercher des coupables — pour apprendre.Les bonnes questions à se poser :Sur quels sujets a-t-on passé beaucoup de temps en atelier… pour finalement n’utiliser que 2 % des cas ?À l’inverse, y a-t-il des cas « rares » qui s’avèrent mobiliser 4 jours de travail à chaque occurrence et qu’on n’avait pas anticipés ?L’adoption est-elle là ? Les indicateurs de volume le confirment-ils ?Le plan de support tient-il ? Les super-users sont-ils débordés ou dans leur rôle ?Ces enseignements ne servent pas seulement à améliorer le projet en cours. Ils alimentent les projets futurs, les évolutions du système, et parfois la façon de faire tout autrement la prochaine fois. Exemple Une société avait prévu un traitement comptable annuel exceptionnel. En recette, ça avait été testé « une fois pour voir ». En go-live, ce traitement s’avérait nécessaire tous les mois sur certains contrats — et chaque occurrence mobilisait une équipe pendant une demi-journée. Rien d’insurmontable, mais rien d’anticipé non plus. Et ensuite ? Le Go-Live marque le passage de la préparation à l’action. Pour maîtriser chaque étape de cette transition critique, découvrez nos articles détaillés :📋 Préparer et conduire la décision go/no-go Structurer la réunion de décision, valider les critères par domaine, et documenter les risques acceptés.⚙️ Exécuter le cutover plan sans accroc Le guide opérationnel heure par heure : de l’arrêt de l’ancien système à l’ouverture des accès utilisateurs.🔥 Gérer les incidents post go-live Qualifier, prioriser et résoudre efficacement sans se noyer sous les tickets.📊 Piloter la stabilisation Les indicateurs à suivre dès J+1 et les points de synchronisation pour détecter les vrais problèmes.🔍 Conduire les revues post go-live Tirer les enseignements des premières semaines pour transformer l’expérience en amélioration continue.Le Go-Live marque la fin de la phase Implement de PRISM. Une fois la stabilisation acquise, le projet entre en phase de Run : optimisation continue et exploitation durable du système. Téléchargez le kit Go-Live PRISM complet avec tous les outils opérationnels. ArticlesPrendre la décision go/no-go Exécuter le cutover plan Piloter la stabilisation Réaliser la revue post go-live (REX)
