Le go-live

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é et les personnes sont nommées, pas seulement budgété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.

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.

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.

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