Español
English
Català
Deutsch
Português
Italiano
Nederlands
Polski
Si vous avez une date de go-live vers Odoo 19 à l'horizon, la partie technique de la migration (mettre à jour le schéma, convertir les modules, déplacer les données) est en général bien couverte par celui qui réalise la migration. Ce qui reste souvent hors de la feuille de route, c'est tout ce qui entoure cette migration : des données sales dès l'origine, des modules tiers que personne n'a vraiment testés, aucun plan si quelque chose tourne mal, ou une équipe qui arrive le premier jour sans savoir où se trouve ce qu'elle utilisait chaque jour. Cet article rassemble, sous forme de checklist, les six blocs qui, d'après ce que nous avons vu, font la différence dans les migrations réelles.
Idée clé : un go-live échoue rarement à cause d'une seule grosse erreur technique : il échoue par l'accumulation de plusieurs petits points que personne n'a vérifiés à temps : une donnée de base en double qui fausse un rapport, un module tiers qui « devrait fonctionner » mais que personne n'a testé avec des données réelles, ou une équipe qui n'a pas su quoi faire dans la première heure parce que personne ne lui avait montré le flux réel. Cette checklist couvre les six blocs qui, d'après notre expérience de déploiement d'Odoo, font la différence entre un go-live serein et un go-live en mode pompier.
Pourquoi la plupart des migrations se compliquent au même endroit
Ce n'est généralement pas la migration technique elle-même (la mise à jour du schéma ou la conversion des modules) qui fait dérailler un go-live. C'est en général l'un des six blocs de cette checklist, tenu pour acquis parce que « on en avait déjà parlé », mais jamais vérifié avec des données réelles ni consigné par écrit. Les passer en revue avant de fixer la date n'allonge pas le projet : cela évite que la date retenue doive être repoussée à la dernière minute.
La checklist complète avant le go-live
Six blocs, un point de contrôle par bloc et pourquoi il est critique : sous forme de tableau pour que vous puissiez l'utiliser tel quel avec votre équipe.
Tableau récapitulatif : les 6 blocs à vérifier avant de valider le go-live
| Bloc | Point de contrôle | Pourquoi c'est critique |
|---|---|---|
| Données de base | Contacts, produits, tarifs, modèles de taxes et soldes vérifiés, sans doublons ni orphelins | Une donnée de base mal migrée n'échoue pas au moment de la migration : elle échoue des semaines plus tard, dans une facture ou un rapport, quand il est déjà difficile d'en retrouver l'origine |
| Modules tiers | Chaque module installé (OCA ou propriétaire) existe en version 19, a été installé en staging et testé sur un cas d'usage réel | Un module « indiqué comme compatible » sur sa fiche n'est pas la même chose qu'un module testé avec vos données et votre flux réel |
| Environnement de staging | Réplique de la production avec des données réelles (pas de démonstration), où au moins un cycle réel a été mené à bout : commande, facture, encaissement, stock, rapport | Les échecs avec des données de démo reproduisent presque jamais les échecs avec des données réelles : volume, formats, cas limites |
| Plan de rollback | Sauvegarde vérifiée et procédure documentée et répétée de retour au système précédent | Sans plan éprouvé, un problème imprévu dans les premières heures de production devient un arrêt d'activité sans issue claire |
| Fenêtre de maintenance | Plage horaire de faible trafic définie, communiquée à l'équipe et, le cas échéant, aux clients, avec une marge sur le temps estimé | Un go-live sans fenêtre claire mélange des utilisateurs qui travaillent dans le système pendant la migration, ce qui multiplie le risque d'incohérences |
| Formation de l'équipe | Chaque utilisateur a effectué, en staging, les tâches réelles de son poste : il ne s'est pas contenté de voir une démo | Le premier jour de production n'est pas le moment d'apprendre le système à partir de zéro |
Les six blocs en détail
1. Des données de base propres
Avant de fixer la date de go-live, quelqu'un de l'équipe (pas seulement celui qui migre) devrait avoir vérifié les contacts en double, les produits sans code ou avec des tarifs contradictoires, les modèles de taxes corrects par pays en cas d'activité internationale, et que les soldes comptables migrés concordent avec le système précédent. Migrer des données sales vers Odoo 19 ne les nettoie pas : cela ne fait que les transférer vers un nouveau système où elles sont plus difficiles à repérer.
2. Modules tiers portés et testés
Chaque module OCA ou propriétaire utilisé par l'entreprise doit exister en version 19 et avoir été installé et testé en staging sur un cas d'usage réel du métier, pas seulement avec une installation technique propre. Il est fréquent de découvrir en production qu'un module « compatible avec 19 » selon sa fiche échoue avec une combinaison précise de données que personne n'avait testée.
3. Environnement de staging validé avec des données réelles
Le staging ne sert pas de validation s'il n'est testé qu'avec des données de démonstration. Il faut une réplique de la production avec des données réelles (ou une copie représentative) où au moins un cycle complet a été mené : créer une commande, la facturer, l'encaisser, déplacer du stock, générer les rapports que l'équipe utilise chaque semaine. C'est la seule façon de trouver avant le go-live les défaillances qui n'apparaissent qu'avec un volume et des cas réels.
4. Plan de rollback
Une sauvegarde récente n'est pas un plan de rollback : le plan inclut la sauvegarde vérifiée (restaurée et contrôlée, pas seulement générée), et une procédure documentée pas à pas pour revenir au système précédent si le go-live échoue, avec les rôles de qui décide de l'activer et dans quel délai.
5. Fenêtre de maintenance
Le go-live nécessite une plage horaire de faible trafic, communiquée à l'avance à l'équipe et, le cas échéant, aux clients, avec une marge de temps sur l'estimation technique : les migrations prennent presque toujours plus de temps que prévu. Faire le basculement avec des utilisateurs qui travaillent dans l'ancien système pendant la migration est l'une des causes les plus fréquentes de données incohérentes.
6. Formation de l'équipe
La formation qui soutient un go-live n'est ni un manuel générique ni une démo passive : c'est que chaque personne ait exécuté, en staging, les tâches concrètes de son poste au quotidien, et sache à qui s'adresser si quelque chose ne correspond pas à ce qu'elle attendait le premier jour réel.
Liens utiles chez FlexigoTech
Si vous préférez que nous nous chargions de tout le processus (données de base, modules, staging, rollback et formation inclus), notre service de migration vers Odoo 19 couvre exactement ces six blocs avant de fixer la date de go-live. Et si vous devez en plus couvrir des processus que l'Odoo standard ne résout pas (logistique, conformité, marketplaces), vous pouvez consulter notre catalogue de modules avant de décider quoi migrer et quoi remplacer.
Questions fréquentes
Qu'est-ce que le go-live dans une migration vers Odoo 19 ?
Le go-live est le moment où la base de données migrée et testée en staging devient le système réel de production : le point où l'équipe commence à travailler sur Odoo 19 et où l'ancien système est déconnecté ou gelé. Ce n'est pas un événement technique isolé, c'est l'aboutissement d'un processus de validation (données, modules, environnement, plan de retour en arrière et équipe formée) qui aurait dû commencer des semaines plus tôt.
Combien de temps avant le go-live l'environnement de staging doit-il être prêt ?
Avec une marge suffisante pour mener au moins un cycle de tests complet avec des données réelles, et non de démonstration, avant de fixer la date : créer une commande, la facturer, l'encaisser, déplacer du stock et générer les rapports que l'équipe utilise chaque semaine. Si des incidents apparaissent pendant ce cycle, il faut du temps pour les corriger et refaire le test ; plus le staging est opérationnel tôt, moins la date finale est sous pression.
Que se passe-t-il si un module tiers n'a pas été porté vers Odoo 19 ?
Si le module n'existe pas en version 19, ou s'il existe mais que personne ne l'a testé avec des données réelles, il ne doit pas être coché comme fait dans la checklist, même si son éditeur l'annonce comme compatible. Les options : le tester vous-même en staging sur un cas réel avant le go-live, le remplacer par une alternative native ou un module équivalent, ou reporter cette fonctionnalité précise sans bloquer le reste de la migration.
Un plan de rollback est-il obligatoire si tout a bien été testé en staging ?
Oui. Le staging ne reproduit jamais 100 % des conditions de production (volume réel d'utilisateurs simultanés, intégrations externes en direct, pics d'utilisation) ; le plan de rollback (sauvegarde vérifiée et procédure documentée de retour au système précédent) est donc ce qui évite qu'un problème imprévu dans les premières heures ne devienne un arrêt d'activité sans issue claire.
Comment savoir si mon équipe est vraiment prête pour le changement ?
Lorsque chaque personne qui utilisera Odoo 19 le premier jour a effectué, en staging et avec des données réelles, les tâches concrètes de son poste (pas un manuel générique ni une démo passive) et sait à qui s'adresser si quelque chose ne correspond pas à ce qu'elle attendait. Une séance théorique sans pratique sur l'environnement réel suffit presque jamais à soutenir le premier jour de production.
Ce que nous faisons à ce sujet
Vous voulez que nous passions en revue votre checklist de migration avant le go-live ?
Nous vous aidons à passer en revue les six blocs avec votre cas réel (données, modules, staging, rollback, fenêtre et équipe) avant de fixer la date. Écrivez-nous à comercial@flexigobe.com ou appelez le +34 616 809 504.