Chaque nouvelle version d'Odoo apporte de réelles améliorations — de meilleures performances, des interfaces plus claires, des fonctionnalités que vos équipes réclamaient. Pourtant, dans de nombreuses entreprises, l'annonce de la version annuelle est accueillie avec une appréhension silencieuse plutôt qu'avec enthousiasme. Quelque part dans le système se trouve du code personnalisé que plus personne ne comprend vraiment, et chacun soupçonne qu'une mise à niveau le cassera.
Cette crainte est rarement irrationnelle. C'est la facture prévisible de décisions prises des années plus tôt, généralement sous la pression des délais : une modification rapide dans le cœur d'Odoo, un correctif appliqué directement sur le serveur, une fonctionnalité greffée sans tests ni gestion de versions. La personnalisation fonctionnait le premier jour. La dette arrive à échéance au moment de la mise à niveau.
Nous construisons nos personnalisations avec une hypothèse non négociable : ce système sera mis à niveau, de façon répétée, aussi longtemps qu'il existera. Cette seule hypothèse change presque tout dans la manière dont le travail est réalisé.
Pourquoi modifier le cœur revient à vivre en sursis
Odoo est conçu pour être étendu, pas modifié. Lorsqu'un intégrateur modifie directement les fichiers du cœur, la personnalisation et le framework fusionnent en un bloc indissociable. La version suivante remplace ces fichiers du cœur — et avec eux, silencieusement, tout ce qui y avait été patché. À ce stade, l'entreprise fait face à un choix douloureux : reconstruire les modifications par archéologie, payer quelqu'un pour comparer des années de modifications non documentées, ou tout simplement cesser de mettre à niveau.
Geler la version est le choix le plus courant, et le plus coûteux. Un Odoo figé signifie aucun correctif de sécurité, aucune nouvelle fonctionnalité, des frictions croissantes avec les connecteurs et les bibliothèques, et un vivier de plus en plus réduit de personnes prêtes à le maintenir. Une modification du cœur ne fait pas gagner de temps. Elle convertit quelques heures économisées aujourd'hui en un passif structurel qui s'aggrave à chaque cycle de version.
Ce que signifie réellement une personnalisation de qualité modulaire
L'alternative n'est pas moins de personnalisation — c'est une personnalisation menée comme de l'ingénierie plutôt que comme de l'improvisation. Chaque modification que nous livrons vit dans son propre module, qui étend Odoo via les mécanismes d'héritage officiels du framework. Le cœur reste intact. Le module déclare ses dépendances, embarque ses propres données, vues et tests, et peut être installé, mis à niveau ou supprimé comme une unité.
Avant d'écrire une seule ligne de code personnalisé, nous vérifions si la communauté a déjà résolu le problème. Nous travaillons selon une approche Community-first et nous nous appuyons sur l'OCA — l'Odoo Community Association — dont les modules publiés et les conventions de codage constituent ce qui se rapproche le plus d'un standard d'ingénierie partagé dans l'écosystème. Suivre ces conventions n'est pas de la bureaucratie ; c'est ce qui permet à tout développeur Odoo compétent, des années plus tard, d'ouvrir le code et de le comprendre.
La discipline autour du code compte autant que le code lui-même. Chaque module que nous livrons est versionné dans Git avec un historique lisible, passe par une revue de code avant sa fusion, et est accompagné de tests automatisés qui fixent le comportement qu'il est censé garantir. Lorsque la version suivante d'Odoo arrive, ces tests font la différence entre vérifier une migration et simplement l'espérer.
Tester les mises à niveau, et ce qu'il faut exiger de tout intégrateur
Un module n'est pas terminé lorsqu'il fonctionne sur la version actuelle. Notre routine inclut le test des modules personnalisés sur la version suivante d'Odoo — exécution de la suite de tests, mise à l'épreuve des flux de travail réels, et correction des incompatibilités tant qu'elles sont encore mineures. Lorsqu'une migration réelle a lieu, elle suit la même discipline : des répétitions à blanc sur une copie des données, un rapport de réconciliation qui prouve ce qui a été transféré, et un plan de retour arrière au cas où quelque chose ne le serait pas. Des sauvegardes testées en restauration soutiennent l'ensemble.
Si vous évaluez un intégrateur — nous y compris — voici les engagements qui méritent d'être exigés par écrit :
- Aucune modification du cœur, jamais. Toute personnalisation vit dans des modules dédiés qui étendent Odoo via les mécanismes pris en charge.
- Un sourcing Community-first. Un module OCA maintenu vaut mieux qu'une réécriture sur mesure de la même fonctionnalité.
- Une gestion de versions visible. Un historique Git complet, le client ayant accès à son propre code.
- Revue de code et tests automatisés sur chaque module, pas seulement les plus gros.
- Un scénario de mise à niveau écrit. Des répétitions à blanc, un rapport de réconciliation et un plan de retour arrière pour toute migration.
- Un prix vérifiable. Des devis à prix fixe après un cadrage rigoureux, afin que la discipline soit intégrée au budget plutôt que facturée à l'heure d'intervention d'urgence.
- Un support avec de vrais engagements. Des SLA à plusieurs niveaux avec des délais de réponse définis, et des formations par rôle pour que le système soit réellement utilisé comme il a été conçu.
Le code personnalisé n'est pas l'ennemi des mises à niveau — c'est le code personnalisé indiscipliné qui l'est. Construites au niveau module, revues, testées et versionnées, vos personnalisations deviennent des actifs qui vous accompagnent de version en version, au lieu d'ancres qui vous retiennent à une seule. Et si un saut de version se profile déjà à votre horizon avec des modules personnalisés en jeu, notre approche de migration — rapports de réconciliation, répétitions à blanc et plans de retour arrière inclus — est détaillée sur notre page services.