Démo

Le go-live

Le go-live est le moment où une solution quitte l'environnement de projet pour devenir l'outil de travail réel : les utilisateurs saisissent de vraies données, l'ancien système cesse de faire foi, et le retour arrière a une heure limite.

7 min de lecture Déploiement Adoption

Définition en bref

Le go-live désigne le passage en production d'une solution informatique : le moment où elle devient le système de travail réel des utilisateurs et où l'outil précédent cesse de faire foi.

  • C'est une décision, pas une date : elle se prend sur des critères de préparation vérifiables.
  • Le cutover est l'opération technique qui la réalise ; l'hypercare est la période de soutien qui la suit.
  • Sa réussite se mesure à l'usage réel dans les semaines suivantes, pas à l'absence d'incident le jour J.

Qu'est-ce qu'un go-live ?

Le go-live est le passage en production d'une solution : l'instant où elle devient le système de référence pour l'activité. Microsoft, dans son guide d'implémentation, le décrit comme un jalon critique du déploiement d'une solution métier en production — le moment où l'on vérifie que tout fonctionne comme prévu, non pas chaque brique isolément, mais l'ensemble (Microsoft Learn).

Le terme s'est imposé en français tel quel. On rencontre aussi « mise en production », « mise en service », « démarrage » ou « bascule », ce dernier désignant plus précisément le cutover.

Concrètement, au go-live :

  • l'ancien système passe en lecture seule, ou est coupé ;
  • les données reprises deviennent les données de référence ;
  • les processus métier s'exécutent dans le nouvel outil, sans double saisie ;
  • le support passe du mode projet au mode exploitation ;
  • les utilisateurs découvrent l'écart entre ce qu'ils ont appris et ce qu'ils doivent faire.

Qui décide du go-live, et sur quels critères ?

Le go-live n'est pas la fin du projet : c'est une décision de gestion du risque. Elle se prend en comité, souvent appelé go/no-go, et elle engage la direction métier autant que la DSI.

Les critères qui tiennent devant un comité sont peu nombreux et vérifiables :

  1. La recette utilisateur est prononcée, avec la liste des anomalies restantes et leur criticité assumée par le métier.
  2. La reprise de données est réconciliée : les soldes, les stocks ou les effectifs du nouveau système correspondent à ceux de l'ancien, à un écart près, défini avant la bascule et documenté.
  3. Le plan de retour arrière est écrit et testé, avec l'heure limite au-delà de laquelle il n'est plus praticable.
  4. Le dispositif d’hypercare est dimensionné, budgété, et les personnes sont nommées.
  5. Les utilisateurs savent quoi faire lundi matin : qui appeler, où trouver l'aide, quelle procédure a changé.

Sur ses déploiements Finance & Operations, Microsoft formalise ce jalon : la revue de préparation au go-live doit être demandée au plus tard quatre semaines avant la date visée. C'est un bon ordre de grandeur pour figer les décisions plutôt que de les arbitrer dans l'urgence.

4 semaines

au plus tard avant la date visée : c'est le délai que Microsoft demande pour la revue de préparation au go-live sur ses déploiements Dynamics 365 Finance & Operations.

Microsoft Learn

66 heures

la fenêtre de conversion que Swarovski a réservée pour son go-live du 20 avril 2026, après deux ans de préparation.

SAP News Center, juillet 2026

15 mois

de projet pour le go-live « big bang » de Kemira sur S/4HANA, sur un périmètre de 400 divisions SAP et 58 sociétés dans 37 pays.

SAP News Center, septembre 2023

Big bang ou déploiement progressif ?

Deux stratégies coexistent, et le choix pèse plus sur l'accompagnement que sur la technique.

Le big bang bascule tout le périmètre en une fois. Kemira a ainsi démarré 400 usines dans 37 pays d'un seul coup, au terme d'un projet de quinze mois (SAP News Center). L'avantage : pas de période d'interfaçage entre ancien et nouveau monde. Le risque : tout le monde apprend en même temps, et le support absorbe le pic d'un seul bloc.

Le déploiement progressif — par pays, par entité, par module — étale le risque et permet d'apprendre du premier groupe. Il coûte en revanche des interfaces temporaires, une double maintenance et une fatigue de projet qui se prolonge sur des mois.

Le critère décisif est rarement technique : c'est la capacité de l'organisation à absorber le changement. Une conduite du changement solide rend le big bang envisageable ; son absence rend même le déploiement progressif douloureux.

Ce que le go-live change pour les utilisateurs

Un projet se prépare pendant des mois avec une équipe qui connaît l'outil par cœur. Le jour du go-live, l'outil est remis à des milliers de personnes qui l'ont vu deux heures en salle, six semaines plus tôt.

L'écart le plus coûteux du déploiement se creuse à ce moment. La formation a été donnée trop tôt pour être retenue, la documentation est ailleurs que dans l'écran, et la personne qui bloque à 9 h 15 sur un champ obligatoire n'ouvrira pas un PDF de quatre-vingts pages : elle appellera un collègue, ou contournera.

Une plateforme d'adoption digitale intervient exactement à ce moment : l'aide est dans l'interface, au bon écran, à la seconde où l'utilisateur en a besoin. C'est aussi ce qui permet de mesurer l'usage réel plutôt que le nombre de connexions — et donc de savoir si le go-live a réussi.

Cas réel · Swarovski, conversion vers SAP Cloud ERP

Le projet

Swarovski a mené la bascule de son système de gestion vers SAP Cloud ERP. L'entreprise a raconté le déroulé du projet dans une publication du SAP News Center parue en juillet 2026.

La préparation

  • deux ans de travaux préparatoires ;
  • plus de 600 participants impliqués ;
  • environ 25 000 tests exécutés.

La bascule

Une fenêtre de conversion de 66 heures a été réservée pour le go-live du 20 avril 2026. Ce cas n'est pas transposable tel quel, mais il donne un ordre de grandeur : sur un périmètre de cette taille, une bascule de cette durée a demandé deux ans de préparation (SAP News Center, juillet 2026).

Cinq erreurs qui transforment un go-live en crise

  1. Décider le go-live sur une date, pas sur des critères. Une date annoncée au comité de direction devient difficile à déplacer, même quand les signaux disent de le faire.
  2. Former trop tôt. Une session donnée six semaines avant la bascule est largement oubliée le jour J. L'accompagnement doit être disponible au moment de l'usage.
  3. Confondre tests techniques et recette utilisateur. Un système conforme aux spécifications peut être inutilisable dans le travail réel.
  4. Sous-dimensionner l'hypercare. Le pic de sollicitations arrive dans les premiers jours ; un support calibré sur le régime courant sature immédiatement.
  5. Ne pas prévoir le retour arrière. Un plan de repli non testé n'est pas un plan de repli. Et son heure limite doit être connue avant la bascule, pas décidée pendant.
L'expertise Knowmore

Comment Knowmore sécurise un go-live.

Knowmore intervient sur le point le plus fragile du go-live : l'écart entre ce que les utilisateurs ont appris et ce qu'ils doivent faire le jour J. Les guides contextuels K-NOW se déclenchent dans l'écran, au bon moment, dans l'outil réel.

K-STUDIO permet de produire ces guides avant la bascule, à partir des processus cibles, et K-VALUE montre dès les premiers jours quelles fonctions sont réellement utilisées — et lesquelles sont contournées.

Conclusion

Le go-live concentre l'attention de tout le projet sur quelques heures. C'est légitime : c'est le moment où le risque est maximal et où le retour arrière devient coûteux.

Mais un go-live techniquement réussi peut produire un échec fonctionnel si les utilisateurs ne savent pas travailler dans le nouvel outil. La bascule se joue en heures ; l'adoption se joue dans les semaines qui suivent.

Questions fréquentes

Quelle est la différence entre go-live et cutover ?

Le go-live est la décision et le résultat : la solution est en production. Le cutover est l'opération qui y conduit — gel des données, reprise, contrôles, ouverture aux utilisateurs. Un cutover se planifie à l'heure près ; un go-live se décide sur des critères.

Combien de temps avant le go-live faut-il figer le périmètre ?

Il n'existe pas de règle universelle, mais les éditeurs formalisent un délai de revue. Microsoft demande que la revue de préparation au go-live soit lancée au plus tard quatre semaines avant la date visée sur ses déploiements Finance & Operations. Ce délai sert surtout à ce que les arbitrages se fassent à froid.

Comment savoir si un go-live a réussi ?

Pas à l'absence d'incident le jour J. Les signaux utiles arrivent après : part des transactions traitées dans le nouvel outil, volume et nature des tickets, fonctions jamais utilisées, contournements observés. Un système stable que personne n'utilise correctement est un go-live raté.

Passons à la pratique

Un go-live réussi ne suffit pas.

Knowmore réduit le pic de support des premières semaines après votre bascule.