Mettre Odoo à niveau : préparer les tests métier avant la bascule

Faire l’inventaire de ce qui peut changer

Listez modules, développements, connexions, rapports et documents. Identifiez leur responsable et leur compatibilité avec la version cible. La documentation Odoo indique notamment que les modules personnalisés doivent disposer d’une version adaptée pour accompagner la mise à niveau.

L’inventaire doit aussi couvrir les procédures informelles : export envoyé à un partenaire, modèle de document modifié ou tâche planifiée. Ce sont parfois ces éléments périphériques qui bloquent le travail alors que l’application principale fonctionne.

Pour approfondir : Upgrade — Odoo 19.0 documentation

Choisir des parcours représentatifs

Préparez des scénarios de vente, livraison, facturation et correction adaptés à votre activité. Pour chaque scénario, conservez les données de départ et le résultat attendu. Les cas difficiles méritent une place : annulation, remise, pièce manquante et changement de responsable.

Faites exécuter les tests par les utilisateurs concernés. Un développeur peut vérifier qu’une page s’affiche sans savoir si le document produit répond aux besoins métier. La validation technique et la validation opérationnelle sont complémentaires.

Travailler sur une copie maîtrisée

La documentation Odoo recommande de tester la base mise à niveau avant la production. Préparez un environnement isolé et empêchez les envois ou opérations externes non souhaités. Une copie de test ne doit pas relancer des messages clients ou déclencher des paiements.

Protégez les données présentes dans cet environnement. Conservez les différences de configuration avec la production afin de comprendre ce qui n’a pas été testé à l’identique. Le résultat doit être interprété avec ces limites, pas présenté comme une garantie absolue.

Pour approfondir : Upgrade — Odoo 19.0 documentation

Une anomalie discrète peut être bloquante

Imaginons qu’une facture s’ouvre correctement, mais que son modèle ait perdu une information utilisée par le client pour le rapprochement. Le test technique passe ; le processus client se dégrade. Un autre cas peut concerner un droit devenu trop large ou une intégration qui ne reçoit plus le champ attendu.

Classez les anomalies selon leur effet et définissez les critères de blocage. Tout défaut visuel n’empêche pas la bascule, mais une erreur de montant ou une perte de traçabilité exige un traitement. Cette classification doit être convenue avant la pression de la date de lancement.

Préparer le jour de bascule et les jours suivants

Définissez la fenêtre, la sauvegarde, la personne qui décide et les contrôles immédiatement après. Préparez une communication interne et un canal de remontée des incidents. Les premières journées doivent disposer de capacité d’assistance.

Le retour en arrière doit prendre en compte les opérations créées depuis la bascule. Restaurer une ancienne base peut les perdre. Décidez comment les conserver et les rapprocher, ou à partir de quand une correction en avant devient préférable. Cette limite ne doit pas être découverte au milieu d’un incident.

La preuve attendue avant le feu vert

Demandez un dossier de recette court : scénarios exécutés, résultats, anomalies ouvertes et responsabilités. La date de mise à niveau n’est pas à elle seule un critère de réussite. L’entreprise doit savoir quels risques elle accepte.

Pourriez-vous expliquer demain à l’équipe pourquoi la bascule a été autorisée ? Une réponse fondée sur des parcours et des contrôles est plus solide qu’un « tout semblait fonctionner ». C’est cette discipline qui permet de faire évoluer les outils sans remettre l’activité en chantier à chaque version.