Préparation au go-live Odoo — le compte à rebours 30 jours
Le go-live est le moment dont tout le monde se souvient — pour les bonnes ou mauvaises raisons. Nous en avons fait beaucoup. Les go-live calmes partagent tous un compte à rebours 30 jours qui vérifie ce qui pourrait mal tourner avant que cela n'arrive.
Un go-live Odoo n'est pas un déploiement. C'est un événement business. Les gens vont utiliser le nouveau système lundi matin. S'il ne marche pas, les ventes s'arrêtent, la facturation s'arrête, les entrepôts s'arrêtent. Le compte à rebours existe pour rendre ce lundi matin ennuyeux.
Nous traitons les 30 jours avant go-live comme leur propre phase de projet, avec stand-ups quotidiens, registre de risques explicite et liste de critères no-go claire. La phase est courte, à enjeux élevés, rentable.
Voici le compte à rebours 30 jours que nous menons avec les clients, les catégories de vérifications, et les critères no-go qui nous ont sauvés de mauvais week-ends.
T-30 à T-21 — données, intégrations et répétition générale
À trois semaines, focus sur données et intégrations. Charger les données complètes du legacy vers un clone de production. Réconcilier comptes et soldes. Tester chaque intégration end-to-end avec volumes réalistes. Faire la répétition générale du basculement avec toute l'équipe.
- Chargement complet des données dans le clone de prod — réconcilié
- Chaque intégration testée end-to-end avec volumes réalistes
- Répétition générale du script de basculement avec toute l'équipe
- Test de performance sous charge réaliste
- Backup et restore testés au moins une fois
T-20 à T-11 — gel UAT, formation, communication
À deux semaines, l'UAT doit être gelée. Les nouveaux problèmes à partir de là sont des bloquants go-live, pas des sujets de formation. Les utilisateurs finaux terminent la formation et signent la présence. Les comms internes atteignent toute l'entreprise — qu'est-ce qui change lundi, que faire si quelque chose casse.
- UAT gelée — les nouveaux soucis sont bloquants, pas formation
- Formation utilisateurs terminée et présence signée
- Comms internes envoyées à toute l'entreprise
- Comms clients / fournisseurs envoyées si visible change
- Équipe hypercare et rota d'astreinte confirmées
T-10 à T-3 — vérifications finales et revue de readiness
À une semaine, mener la revue finale de readiness avec le comité de pilotage. Parcourir les critères no-go un par un. Confirmer le plan de rollback. Imprimer le runbook de basculement. Briefer l'équipe support sur la première semaine. Dormir tôt la veille.
- Revue finale de readiness avec le comité de pilotage
- Critères no-go parcourus un par un — tous verts
- Plan de rollback testé et documenté
- Runbook de basculement imprimé et distribué
- Équipe support briefée sur les schémas première semaine
T-2 à T-0 — week-end de basculement
Le week-end de basculement est l'exécution. Verrouiller le legacy. Charger le delta final. Smoke tests dans le nouveau système. Validation de chaque owner business. Ouvrir les portes lundi matin avec toute l'équipe hypercare sur site ou en astreinte.
- Système legacy verrouillé à l'heure convenue
- Chargement delta terminé et réconcilié
- Smoke tests menés en production
- Owners business signent l'acceptation du basculement
- Équipe hypercare en place lundi matin
T+1 à T+30 — hypercare, pas maintenance
Les 30 premiers jours post go-live sont hypercare. Stand-ups quotidiens, priorisation explicite des issues, traitement rapide des fixes, dashboard quotidien pour le comité de pilotage. L'hypercare se termine quand le business le dit — pas à une date fixe.
- Stand-ups hypercare quotidiens pendant au moins deux semaines
- Triage des issues avec priorité et SLA explicites
- Traitement rapide des fixes — la prod n'est pas en régime
- Dashboard quotidien pour le comité de pilotage
- Sortie formelle d'hypercare quand le business confirme

Erreurs de go-live que nous avons vécues
Cinq schémas récurrents qui blessent les go-live de sauvetage.
- Sauter la répétition générale parce que tout le monde était fatigué.
- Ne pas geler l'UAT — nouveaux besoins qui arrivent en dernière semaine.
- Sous-estimer le temps de réconciliation des données le week-end.
- Pas de plan de rollback — et puis en avoir besoin.
- Traiter l'hypercare comme une formalité d'une semaine au lieu de la phase la plus importante.
Comment mesurer que le go-live s'est bien passé
Cinq chiffres et signaux à suivre les 30 premiers jours.
- Incidents critiques en semaine 1 — cible zéro.
- Ventes / factures traitées jour 1 vs cible — dans les 90%.
- Tickets support utilisateurs par jour en tendance baissière.
- Écarts de réconciliation fermés dans les 24h.
- Score satisfaction sponsor et utilisateurs en semaine 4.
Comment Flydoo mène la readiness go-live
Nous traitons le compte à rebours 30 jours comme un sous-projet avec son backlog, ses stand-ups quotidiens et une liste de critères no-go sur laquelle le sponsor peut opposer un veto. Nous préférons retarder d'une semaine que pousser un go-live pas prêt.
Notre équipe hypercare est sur site ou sur un canal dédié les deux premières semaines. Nous mesurons quotidiennement et adaptons vite. Le comité de pilotage reçoit un statut une page chaque matin jusqu'à ce que le business confirme le régime.
- Compte à rebours 30 jours comme sous-projet à part
- Stand-ups quotidiens avec liste de critères no-go explicites
- Veto sponsor sur le go-live si critères non remplis
- Hypercare sur site ou canal dédié deux semaines
- Statut quotidien une page au comité de pilotage
Checklist maîtresse readiness go-live
Parcourir hebdomadairement durant le compte à rebours 30 jours.
- Chargement complet des données dans le clone de prod réconcilié
- Chaque intégration testée end-to-end
- Répétition générale du basculement effectuée
- UAT gelée et formation signée
- Plan de rollback testé et documenté
- Comms envoyées à toute l'entreprise et aux clients si besoin
- Équipe hypercare et rota d'astreinte en place
Les go-live ennuyeux sont les meilleurs
La meilleure histoire de go-live est celle où il ne se passe rien. Les ventes vendent, l'entrepôt expédie, la finance facture, la paie tourne. Tout le monde rentre à l'heure.
Les go-live ennuyeux résultent de comptes à rebours disciplinés, répétitions générales, UAT gelées, plans de rollback testés et hypercare correct. La discipline est le cadeau que vous faites à votre futur lundi matin.
Si vous êtes à 30 jours d'un go-live et voulez une deuxième paire d'yeux sur votre compte à rebours, nous parcourons volontiers les critères no-go avec vous.
Questions fréquentes
Combien de temps doit durer l'hypercare ?
Deux semaines minimum, souvent quatre. L'hypercare se termine quand le business le dit — généralement quand le volume quotidien d'issues retombe à un régime gérable. Fixer une date de fin à l'avance est une recette pour un retrait précoce du support, que les clients ressentent toujours.
A-t-on vraiment besoin d'une répétition générale ?
Oui. Chaque go-live mené sans répétition complète a eu des surprises le week-end. Chacun avec répétition a été ennuyeux. La répétition coûte un week-end de l'équipe et sauve le vrai week-end de basculement d'être une war room.
C'est quoi exactement le plan de rollback ?
Une procédure documentée pour revenir au legacy si le go-live ne peut pas se faire en sécurité. Inclut qui décide, jusqu'à quand, comment les données capturées dans le nouveau système en route se réconcilient, et comment les comms atteignent les utilisateurs. Rarement nécessaire — mais l'avoir change le calcul de risque le week-end.
On bascule un lundi ou un week-end ?
Le basculement se fait le week-end pour que les utilisateurs ouvrent lundi sur le nouveau système. Certains clients préfèrent un long week-end (basculement vendredi, ouverture mardi) pour le buffer ; d'autres un week-end normal. Plus le delta de données est gros, plus on veut de buffer.
Quel est le rôle du sponsor le week-end de basculement ?
Disponible, décisif, présent physiquement ou virtuellement aux moments de signature. Le sponsor ne fait pas le travail technique mais signe les portes d'acceptation business : données réconciliées, smoke tests passés, prêt à ouvrir. Sans présence sponsor, les décisions de basculement bloquent aux mauvais moments.
Envie d'en discuter pour votre propre projet Odoo ? Parlons-en.
