Un dirigeant signe son abonnement Odoo Enterprise, et six mois plus tard une facture ne se génère plus comme elle devrait. Il ouvre un ticket, reçoit une réponse polie qui lui dit que sa demande relève du paramétrage, donc de son intégrateur, et se demande à quoi sert le support qu'il paie. La question est légitime. La réponse se trouve dans un document que presque personne ne relit après la signature : le contrat d'abonnement Odoo Enterprise, publié en clair dans la documentation. Je l'ai relu en entier, dans sa version 13 datée du 24 septembre 2026, pour séparer ce qu'Odoo s'engage à faire de ce qu'on croit acheter.
Cet article porte sur le contrat de l'édition Enterprise (Online, Odoo.sh et sur site sont des modes d'hébergement de cette même édition). Il ne reprend ni la grille tarifaire, déjà traitée dans Nouveaux tarifs Odoo : ce que l'utilisateur léger change pour une PME, ni le calendrier de migration vers la 20.0. Je cite le texte anglais du contrat en le traduisant ; seul le texte original fait foi.
Le support : bugs et usage du standard, rien d'autre
L'article 4.5 définit le périmètre. Le client peut ouvrir un nombre illimité de tickets, sans frais, mais « exclusivement » pour deux types de questions : les bugs, et l'aide à l'utilisation des fonctions standard du logiciel. Les autres demandes, par exemple sur le développement ou les personnalisations, peuvent être couvertes par un contrat de service distinct. Et lorsqu'il n'est pas clair qu'une demande entre dans le périmètre, le contrat précise que la décision revient à Odoo SA.
Revenons au dirigeant de l'introduction. Si sa facture ne se génère pas comme attendu à cause d'un réglage de ses journaux, le contrat ne promet rien d'autre qu'une aide sur l'usage du standard. Faire évoluer ce réglage, l'adapter à son métier ou le documenter pour ses équipes ne fait pas partie de l'abonnement. C'est le travail d'un intégrateur, et c'est précisément ce que l'article 4.6 organise : le client peut choisir un partenaire Odoo comme interlocuteur principal, qui peut solliciter Odoo SA pour une assistance de second niveau sur le standard, ou traiter directement avec Odoo SA.
Ce que le contrat appelle un bug
La définition compte, parce que c'est elle qui ouvre droit à la correction. Un bug est une défaillance du logiciel qui provoque un arrêt complet, un message d'erreur technique (traceback) ou une faille de sécurité, et qui n'est pas directement causée par une installation ou une configuration défectueuse. Une fonction qui ne produit pas le résultat attendu peut aussi être traitée comme un bug, mais « à la discrétion » d'Odoo SA. Le contrat cite en exemple le cas où une fonction propre à un pays ne répond plus aux exigences légales de la comptabilité.
Ce dernier point intéresse directement une PME française. Il signifie qu'une anomalie de conformité comptable peut être qualifiée de bug, mais que la qualification n'est pas automatique. Pour le traitement, l'engagement porte sur « tous les efforts raisonnables » et sur le démarrage de la prise en charge sous deux jours ouvrés. Il ne porte pas sur un délai de correction. Un bug corrigé dans une version couverte l'est aussi dans les versions couvertes plus récentes. Et si votre base tourne sur une version qui n'est plus couverte, la correction peut consister à vous demander de monter de version.
Mises à jour de sécurité et montée de version
Pour les bases hébergées chez soi, Odoo s'engage à envoyer un avis de sécurité aux clients au moins deux semaines avant sa publication, sauf si la faille a déjà été rendue publique par un tiers. Pour la plateforme cloud d'Odoo, les correctifs de sécurité sont appliqués sans action du client dès qu'ils sont disponibles. Ces engagements visent le logiciel d'Odoo, pas les modules additionnels : l'avis de sécurité exclut expressément les modules supplémentaires.
Le service de montée de version est plus limité qu'on ne le croit. Il couvre la conversion technique de la base vers la version cible, la correction des bugs directement causés par l'opération, et la conversion des modules supplémentaires couverts. En revanche, le contrat met à la charge du client la vérification de la base migrée, l'analyse de l'impact des nouveautés et l'adaptation de toute extension tierce non couverte. Autrement dit, la migration d'une base est un projet à budgéter, et pas seulement une demande à soumettre sur une plateforme.
Modules spécifiques : couverts, donc facturés
Le contrat distingue les modules supplémentaires « couverts » des autres. Un module est couvert s'il fonctionne sur Odoo Online, ou si le client choisit de payer une redevance de maintenance. Cette redevance est calculée au nombre de lignes de code : un montant mensuel par tranche de 100 lignes, mesuré avec la commande cloc du logiciel, qui inclut le Python, le JavaScript et le XML mais exclut les lignes vides et les commentaires. Les personnalisations en Python créées dans une base, par exemple avec Studio, entrent aussi dans la définition d'un module supplémentaire. Si un module n'a pas été couvert pendant les douze derniers mois, Odoo SA peut facturer des frais ponctuels pour chaque mois manquant au moment d'une montée de version.
Le contrat précise aussi qui assure ce service. Avec un partenaire, c'est lui qui devient le point de contact pour les modules couverts. Si le client traite directement avec Odoo SA, ces services ne sont fournis que s'il est hébergé sur la plateforme cloud d'Odoo. Un client sur site qui traiterait en direct avec l'éditeur ne peut donc pas faire couvrir ses modules supplémentaires par Odoo. Il lui faut un partenaire.
L'hébergement : un engagement, et une page qui nuance
L'article 4.4 liste ce qu'Odoo s'engage à fournir sur sa plateforme cloud, au minimum : le choix entre au moins trois régions (Europe, Amérique, Asie-Pacifique), des centres de données de niveau Tier III ou équivalent avec 99,9 % de disponibilité réseau, un chiffrement HTTPS, des sauvegardes automatisées et vérifiées répliquées dans plusieurs régions, et un plan de reprise d'activité testé régulièrement. Le détail est renvoyé à la page « Service Level Agreement » d'Odoo.
Cette page, que j'ai lue le 14 octobre 2026, donne des chiffres utiles : 14 sauvegardes complètes conservées au moins trois mois (une par jour pendant 7 jours, une par semaine pendant 4 semaines, une par mois ensuite), répliquées sur au moins trois machines de centres de données différents en Europe et au Canada, avec une quatrième copie figée en stockage froid. Le client ne peut ni choisir ni restreindre les régions où ces sauvegardes sont répliquées. Pour la perte d'un serveur, les objectifs sont de 24 heures au plus de données perdues (proche de zéro pour le SaaS) et de 6 heures pour la remise en service ; pour la perte d'un centre de données complet, 24 heures dans les deux cas.
Une note de bas de page de cette même page précise que ces objectifs de disponibilité et de reprise reposent sur la conception de l'infrastructure, que l'éditeur les atteint ou les dépasse en pratique, mais qu'ils ne constituent pas des garanties juridiquement contraignantes. Cette nuance pèse dans le choix d'un hébergement : le contrat parle d'engagements, la page de SLA d'objectifs. Si votre activité dépend d'une disponibilité contractuelle chiffrée, avec pénalités, ne la déduisez pas de ces textes. Notre comparatif Odoo.sh vs Online vs on-premise parle de « disponibilité garantie à 99,9 % » : cette formulation mérite d'être nuancée à la lumière de cette note.
Ce que je retiens pour une PME
Mon avis est que le contrat est plus honnête que sa réputation : il dit clairement que le support Odoo couvre les bugs et le standard, et qu'il ne remplace ni un intégrateur ni un projet de migration. Le vrai risque ne se trouve pas dans les clauses, mais dans l'écart entre l'attente d'un dirigeant (« j'ai un support, donc quelqu'un règle mon problème ») et ce que le texte promet. Avant de signer ou de renouveler, je recommande trois vérifications : qui est votre interlocuteur de premier niveau, avec quel contrat de service pour ce qui sort du standard ; si vos développements spécifiques sont couverts, et ce que cela coûte à la ligne de code ; et ce que vous attendez réellement de la disponibilité de la base, en sachant que les chiffres publiés sont des objectifs.
Sources
- Odoo Enterprise Subscription Agreement, version 13 du 24/09/2026 (consulté le 14/10/2026) : Lire le contrat
- Odoo Cloud Hosting Service Level Agreement (consulté le 14/10/2026) : Lire la page