« Prenez la dernière version » est un conseil qui paraît évident et qui, en Odoo Community, est souvent faux. La raison n'est pas la qualité du cœur d'Odoo : c'est l'écosystème des modules communautaires qui l'entoure.
Un module porté par la communauté est adapté à une nouvelle version majeure quand quelqu'un s'en charge. Pour certains dépôts, c'est rapide. Pour d'autres, cela prend des mois — et vous en dépendez.
L'essentiel
- Le cœur d'Odoo suit un rythme de version majeure annuel ; les modules communautaires suivent à leur propre rythme.
- Le coût d'une montée n'est pas la migration des données, c'est la recette de chaque module installé.
- La règle utile : choisir la version pour laquelle les modules dont vous dépendez sont disponibles et éprouvés.
- Atalios déploie Odoo 18 Community, et c'est sur cette branche que nos 1 725 fiches de modules sont établies.
- Le vrai risque n'est pas d'être en retard d'une version : c'est de l'être de quatre.
Pourquoi la dernière version n'est pas toujours la bonne
Quand une version majeure d'Odoo paraît, le cœur est disponible immédiatement. Les modules communautaires, non — et c'est logique : ce sont des contributions bénévoles ou financées par des intégrateurs, portées dépôt par dépôt.
Conséquence concrète : une entreprise qui passe à la toute dernière version peut découvrir que le module dont dépend son métier n'est pas encore porté. Elle a alors trois options, toutes mauvaises : attendre, financer le portage, ou se passer de la fonction.
| Situation | Risque | Décision raisonnable |
|---|---|---|
| Dernière version, modules non portés | Élevé | Attendre, sauf besoin impératif |
| Version N-1, modules éprouvés | Faible | Le choix par défaut |
| Version N-2 | Faible | Acceptable, à condition de planifier la suite |
| Version N-4 ou plus | Élevé | Migration lourde : les sauts s'additionnent |
La dernière ligne est celle qui coûte vraiment. Une entreprise restée sur une version très ancienne ne fait pas une montée de version : elle fait un projet de migration, parce que les écarts cumulés changent de nature.
Ce que coûte une montée de version, poste par poste
La migration des données est la partie la plus visible, et rarement la plus coûteuse.
- La recette des modules communautaires installés. C'est le poste principal. Chaque module doit être vérifié dans son usage réel, pas seulement installé sans erreur.
- La recette de vos personnalisations. Chaque écart au standard se repaie ici. C'est la raison principale de ne personnaliser que ce qui porte un avantage concurrentiel.
- La migration des données, généralement maîtrisée et outillée.
- La formation aux changements d'interface, souvent négligée et toujours nécessaire : une équipe qui ne retrouve pas un bouton perd confiance.
Le deuxième poste est celui sur lequel vous avez le plus de prise, et il se décide des années avant la montée de version : au moment où l'on choisit de personnaliser. Voir personnaliser ou rester sur le standard.
Quand monter, concrètement
Trois déclencheurs légitimes, et un mauvais.
- Une fonction dont vous avez besoin existe dans une version plus récente, et pas de contournement raisonnable dans la vôtre.
- Un module essentiel n'est plus maintenu sur votre version : vous perdez les correctifs, y compris de sécurité.
- Une obligation réglementaire l'exige — c'est exactement ce que la réforme de la facturation électronique a produit chez beaucoup d'entreprises restées sur d'anciennes versions.
Le mauvais déclencheur : « parce qu'il y a une nouvelle version ». Monter sans besoin, c'est payer une recette complète pour un bénéfice que personne n'a formulé.
Une montée de version se justifie par un besoin nommé, pas par un numéro. Et elle se planifie quand l'activité est calme — jamais en période de clôture ni de haute saison.
La règle qui évite de se retrouver bloqué
Une seule discipline suffit, et elle ne coûte rien : tenir la liste des modules communautaires dont vous dépendez vraiment, avec leur dépôt d'origine.
Cette liste répond en cinq minutes à la question « peut-on monter ? » : il suffit de vérifier la disponibilité de ces dépôts sur la version cible. Sans elle, la même question demande un audit.
C'est précisément pourquoi nous documentons nos 1 725 modules, dépôt par dépôt, sur la branche 18.0 : la liste existe, elle est à jour, et elle rend la décision mécanique au lieu d'être une enquête. Voir comment choisir un module communautaire.
Deuxième discipline, aussi simple : ne pas dépasser deux versions de retard. Au-delà, les écarts se composent et la montée devient un projet.
Comment nous procédons
- Une instance de recette est créée depuis une copie de votre base — jamais de montée sur l'instance de production.
- Chaque module installé est repris dans son usage réel : on émet une facture, on fait une réception, on sort un état.
- Les écarts sont listés et arbitrés avec vous : ce qui est corrigé, ce qui est abandonné, ce qui attend.
- La bascule est datée, en période calme, avec un retour arrière préparé.
La maintenance de l'instance est incluse dans nos offres ; la montée vers une version majeure est une option explicite, et nous préférons qu'elle soit visible dans un devis plutôt que découverte en cours de route. Voir nos offres.
Questions fréquentes
Quelle version d'Odoo déployez-vous ?
Odoo 18 Community. C'est également la branche sur laquelle nos 1 725 fiches de modules communautaires sont établies, ce qui nous permet de répondre précisément à « ce module existe-t-il, et que fait-il » sans enquête.
Faut-il monter de version chaque année ?
Non. Monter sans besoin nommé revient à payer une recette complète pour un bénéfice que personne n'a formulé. La discipline utile est de ne pas dépasser deux versions de retard : au-delà, les écarts se composent et la montée devient un projet de migration.
Combien de temps dure une montée de version ?
Cela dépend presque entièrement du nombre de modules communautaires et de personnalisations à reprendre, pas du volume de données. Une instance proche du standard se monte en quelques jours ; une instance très personnalisée demande plusieurs semaines de recette.
Que se passe-t-il si un module dont je dépends n'est pas porté ?
Trois options : attendre que la communauté le porte, financer le portage, ou renoncer à la fonction. C'est pour éviter ce choix qu'il faut tenir la liste de ses modules essentiels et vérifier leur disponibilité avant de décider de monter.
Peut-on tester avant de basculer ?
Oui, et c'est la seule méthode acceptable : une instance de recette créée depuis une copie de votre base, sur laquelle on rejoue vos usages réels — émettre une facture, faire une réception, sortir un état. Une montée testée uniquement par l'absence d'erreur à l'installation n'est pas testée.
Pour aller plus loin
- Personnaliser ou rester sur le standard
- Comment choisir un module communautaire
- Où héberger Odoo : qui porte quoi
En résumé
La bonne version n'est pas la dernière : c'est celle pour laquelle les modules dont vous dépendez sont disponibles et éprouvés. Le coût d'une montée est la recette, pas la migration des données. Tenez la liste de vos modules essentiels, ne dépassez pas deux versions de retard, et montez pour un besoin nommé. Parlons de votre instance.
