Support Odoo : qui répond vraiment quand votre ERP s'arrête

Lundi, 9 h 04. La personne qui édite les factures clients ouvre Odoo et tombe sur une trace d'erreur au moment de valider le lot du mois. Rien ne part. Le cycle de facturation est arrêté, et avec lui les relances, les encaissements et la trésorerie prévue en fin de semaine. La question qui se pose dans les dix minutes qui suivent n'est pas technique. Elle est très simple : à qui on téléphone.

Dans la plupart des PME que nous croisons, cette question n'a pas de réponse écrite. Il y a un abonnement Odoo Enterprise, un intégrateur qui est intervenu au déploiement, parfois un prestataire d'hébergement, et un salarié débrouillard qui a appris le paramétrage sur le tas. Chacun renvoie vers l'autre. Pendant ce temps, la facturation reste bloquée. Le coût de l'incident n'est pas le coût du correctif : c'est le nombre d'heures pendant lesquelles personne ne s'estime responsable.

Cet article démonte ce qui se cache derrière l'expression « support Odoo », qui recouvre trois réalités très différentes que les clients confondent régulièrement. Il détaille ce que l'éditeur couvre contractuellement, ce qu'il ne couvre pas, les trois modèles de tierce maintenance applicative pratiqués sur le marché français avec leurs pièges respectifs, et ce qu'un engagement de service sérieux doit contenir. Il dit aussi dans quels cas externaliser le support n'est pas rentable, parce que ce cas existe.

Trois choses différentes s'appellent « support Odoo »

Quand un dirigeant tape « support Odoo » dans un moteur de recherche, il cherche l'une de trois choses, et Google lui sert les trois en vrac. C'est la première source de confusion, et elle a des conséquences concrètes : des entreprises paient deux fois pour la même chose, ou croient être couvertes sur un périmètre qui ne l'est pas.

Le premier sens est le support de l'éditeur, la société belge Odoo SA, inclus dans l'abonnement Odoo Enterprise. C'est un service de correction de bugs et de réponse aux questions d'usage sur les fonctions standard. Il est illimité en nombre de tickets. Il est aussi étroitement délimité, on y revient.

Le deuxième sens est l'application Assistance d'Odoo, parfois appelée Helpdesk. C'est un module logiciel qui sert à gérer le support que vous rendez à vos clients : tickets, canaux d'entrée, engagements de service, base de connaissances, mesure de satisfaction. Ça n'a rien à voir avec le fait d'être dépanné soi-même. Si c'est ce que vous cherchez, la page dédiée à l'application Assistance et au helpdesk multicanal traite le sujet en détail.

Le troisième sens est la tierce maintenance applicative, ou TMA, assurée par un intégrateur. C'est un contrat de service avec un prestataire qui connaît votre instance, votre paramétrage et vos spécifiques, et qui intervient quand quelque chose casse ou doit évoluer. C'est le seul des trois qui répond à la question du lundi matin.

Ce que vous cherchez	Le bon interlocuteur	Ce que ça couvre	Ce que ça ne couvre pas
Un bug dans le code standard d'Odoo	Support éditeur Odoo SA	Correction du défaut dans les versions couvertes	Votre paramétrage, vos développements non souscrits
Gérer le support de vos propres clients	Application Assistance Odoo	Tickets, engagements de service, base de connaissances	Le dépannage de votre propre instance
Quelqu'un qui décroche quand votre ERP s'arrête	Contrat de TMA avec un intégrateur	Incidents, paramétrage, spécifiques, évolutions	Ce qui dépend de l'éditeur seul (correctifs du cœur)

Ces trois briques ne sont pas exclusives. Une PME sous Odoo Enterprise avec des développements sur mesure a besoin des deux premières couches et souscrit souvent la troisième. Le point à clarifier, c'est qui porte quoi, et surtout qui est le point d'entrée unique quand personne ne sait encore d'où vient le problème.

Que couvre réellement le support de l'éditeur ?

Il couvre les bugs du code standard et les questions d'usage sur les fonctions standard, dans les limites d'une définition contractuelle étroite. Le contrat d'abonnement Odoo Enterprise est public et lisible, plus précis et plus restrictif que ce que beaucoup de clients imaginent. Trois clauses méritent d'être lues avant de signer quoi que ce soit.

La définition contractuelle d'un bug est étroite

Le contrat définit un bug comme une défaillance du logiciel qui provoque un arrêt complet, une trace d'erreur ou une faille de sécurité, et qui n'est pas directement causée par une installation ou une configuration défectueuse (Odoo Enterprise Subscription Agreement, section 2). Relisez la fin de la phrase. Un dysfonctionnement causé par votre paramétrage n'est pas un bug au sens du contrat. Il sort donc du service inclus.

C'est la source d'un malentendu très fréquent. Dans le déploiement d'un ERP (progiciel de gestion intégré, le logiciel unique qui porte ventes, achats, stocks et comptabilité) en PME, la grande majorité des incidents des six premiers mois viennent du paramétrage, des règles fiscales, des routes logistiques, des droits d'accès ou des données reprises, pas du code d'Odoo. Le contrat prévoit d'ailleurs une zone grise : la non-conformité aux spécifications peut être considérée comme un bug, mais à la discrétion d'Odoo SA. Autrement dit, c'est l'éditeur qui arbitre.

Le délai de deux jours ouvrés n'est pas un délai de résolution

Le même contrat engage Odoo SA à faire tous les efforts raisonnables pour corriger un bug, et à commencer à traiter les demandes sous deux jours ouvrés. Deux nuances comptent ici, et elles sont juridiques autant que pratiques.

La première : « tous les efforts raisonnables » est une obligation de moyens, pas de résultat. La seconde : le délai porte sur le démarrage du traitement, pas sur la remise en service. Un bug complexe peut être pris en charge le mardi et corrigé dans une version publiée trois semaines plus tard. C'est cohérent pour un éditeur qui maintient une base de code mondiale. Ce n'est pas dimensionné pour une facturation bloquée un lundi matin.

Vos développements spécifiques ne sont pas couverts par défaut

C'est le point que nous voyons le plus souvent découvert trop tard. Dans le vocabulaire du contrat, tout module ajouté à votre base est un « Extra Module », y compris les personnalisations créées avec Odoo Studio. Un Extra Module ne devient couvert par le support, les corrections et les migrations que si le client choisit de payer une redevance de maintenance dédiée.

Et le mode de calcul de cette redevance surprend : elle est facturée mensuellement par tranche de cent lignes de code, arrondie à la centaine supérieure, les lignes étant comptées avec l'outil cloc hors lignes vides et commentaires. Plus votre spécifique est volumineux, plus il coûte à maintenir chez l'éditeur. C'est logique, et c'est rarement anticipé au budget.

Enfin, le support d'usage est cadré par la même logique : le contrat autorise un nombre illimité de tickets gratuits, mais exclusivement pour des questions portant sur des bugs ou sur l'utilisation des fonctions standard. Les demandes liées à du développement ou à de la personnalisation relèvent d'un accord de service séparé. Et la disponibilité s'entend selon les horaires d'ouverture locaux, pas en continu.

Ce que le support éditeur ne traitera jamais pour vous

Au-delà des clauses, il y a une réalité de terrain. L'éditeur ne connaît pas votre entreprise. Il ne sait pas que votre société applique une remise de fin d'année sur trois familles de produits, que votre entrepôt fonctionne en double emplacement, ni que votre comptable attend un export dans un format précis pour son cabinet. Ces sujets ne sont pas des bugs. Ce sont des sujets métier.

• Le paramétrage. Une taxe mal positionnée, une position fiscale absente, une règle de réapprovisionnement qui déclenche des commandes en boucle. Rien de tout cela n'est un défaut du logiciel.
• Les données. Un fichier articles importé avec des unités de mesure incohérentes produira des valorisations de stock fausses jusqu'à ce que quelqu'un reprenne le fichier.
• La formation. Quand un utilisateur ne sait pas qu'il doit valider un transfert avant de facturer, le problème n'est pas dans Odoo.
• Les modules tiers. Un module installé depuis l'Odoo App Store ou depuis un dépôt communautaire n'est pas maintenu par l'éditeur, sauf souscription explicite.
• Les intégrations. Un flux qui casse entre Odoo et votre boutique en ligne ou votre transporteur relève de celui qui a construit le connecteur.

C'est exactement le périmètre qu'un intégrateur couvre, et c'est pour cette raison que le contrat d'abonnement prévoit explicitement le cas du partenaire : quand le client choisit de travailler avec un partenaire Odoo, l'éditeur lui sous-traite les services liés aux modules spécifiques et le partenaire devient le point de contact principal, avec la possibilité de solliciter Odoo SA en second niveau sur le standard. Le contrat précise aussi qu'en travaillant en direct avec Odoo SA, les services relatifs aux modules spécifiques ne sont rendus que si la base est hébergée sur la plateforme cloud de l'éditeur.

Qu'est-ce que la TMA en informatique ?

La tierce maintenance applicative désigne un contrat par lequel une entreprise confie à un prestataire externe l'entretien et l'évolution d'une application déjà en production. Le terme vient des grands comptes et des projets sur mesure. Appliqué à Odoo, il recouvre trois natures d'intervention qu'il vaut mieux distinguer dans le contrat, car elles n'ont ni la même urgence ni le même coût.

La maintenance corrective répare ce qui ne marche plus : un flux bloqué, un état comptable faux, une erreur à la validation. C'est le cœur de l'urgence. La maintenance évolutive fait avancer l'outil : un nouveau champ, un rapport, une règle d'automatisation, un changement de processus. Ce n'est presque jamais urgent, mais c'est ce qui empêche l'ERP de se figer. La maintenance préventive regarde ce qui n'a pas encore cassé : montées de version, surveillance des sauvegardes, contrôle des performances, revue des droits.

Un contrat qui ne parle que de corrective produit un effet pervers connu : l'entreprise n'ose plus faire évoluer son ERP, chaque demande devenant un devis. Deux ans plus tard, les équipes ont recréé des tableurs à côté du système. On retombe sur les signes qui trahissent une PME arrivée au bout d'Excel, sauf qu'elle a désormais aussi un ERP.

Les trois modèles de TMA du marché et leurs pièges

Sur le marché français de l'intégration Odoo, trois modèles de contractualisation dominent. Aucun n'est meilleur dans l'absolu. Chacun crée une incitation économique différente, et c'est cette incitation qu'il faut regarder, pas le prix affiché.

Modèle	Principe	Ce qui marche bien	Le piège réel	Pour qui
Forfait mensuel	Un montant fixe couvre un périmètre et un niveau d'engagement définis	Budget prévisible, le prestataire a intérêt à ce que ça ne casse pas	Périmètre flou : tout ce qui n'est pas listé devient hors forfait et se redevise au cas par cas	Instances avec du spécifique, flux critiques, plusieurs sociétés ou entrepôts
Carnet d'heures	Achat d'un volume d'heures consommé au fil des demandes	Souplesse, l'entreprise arbitre elle-même ses priorités	Aucun engagement de délai adossé, et heures qui expirent en fin de période sans report	Besoins irréguliers, équipe interne capable de qualifier les demandes
Ticket à l'acte	Chaque intervention est devisée puis facturée	On ne paie que ce qu'on consomme, zéro engagement	Le prestataire n'a aucune obligation de disponibilité : vous passez après ses clients sous contrat	Périmètre standard, usage stable, tolérance à l'arrêt élevée

Sur le forfait mensuel, vérifiez d'abord la définition du périmètre inclus et la règle de bascule vers le hors forfait. Le montant vient après. Demandez un exemple écrit de trois demandes classées incluses et de trois demandes classées hors forfait. Si le prestataire ne sait pas répondre en dix minutes, la frontière n'existe pas, et elle sera tranchée au moment de la facture.

Sur le carnet d'heures, le piège est double. La péremption des heures d'abord : un carnet consommable sur douze mois sans report transforme une réserve de sécurité en dépense sèche. L'absence d'engagement de délai ensuite : acheter des heures ne garantit pas qu'un consultant soit disponible mardi matin. Vérifiez que les deux sujets sont traités séparément dans le contrat.

Sur le ticket à l'acte, la question est celle de la file d'attente. Un intégrateur alloue ses ressources en priorité aux clients qui portent un engagement contractuel. C'est rationnel de sa part et vous devez le savoir. Ce modèle convient quand votre tolérance à l'interruption est réelle, pas quand votre facturation ou vos expéditions en dépendent.

Que doit contenir un engagement de service sérieux ?

Quatre éléments : un délai de prise en charge distinct du délai de résolution, une grille de criticité définie par les effets métier, des plages horaires calées sur votre activité réelle, et un chemin d'escalade nommé. Beaucoup de contrats affichent un engagement de service, souvent appelé SLA, qui tient en une ligne, « intervention sous 4 heures », et cette ligne seule ne veut rien dire.

Le délai de prise en charge doit être distinct du délai de résolution

Ce sont deux engagements différents et ils doivent apparaître comme tels. La prise en charge, c'est le moment où un humain identifié vous répond, qualifie l'incident et vous dit ce qu'il fait. La résolution, c'est le retour au fonctionnement. Un contrat qui ne mentionne qu'un seul délai ne vous protège pas : c'est presque toujours la prise en charge qui est engagée, comme dans le contrat de l'éditeur.

Dans les faits, un engagement de résolution ferme est rarement tenable sur un incident dont on ignore la cause. Ce qui est tenable, et ce que vous devez exiger, c'est un engagement de prise en charge ferme assorti d'un point d'avancement à fréquence définie tant que l'incident est ouvert. Un intégrateur qui vous promet une résolution garantie sous quatre heures sur tout type d'incident vous vend une ligne qu'il ne pourra pas honorer.

La criticité doit être définie par ses effets, pas par ressenti

La grille de criticité est le document qui évite les disputes. Elle doit qualifier les incidents par leur effet métier, pas par l'émotion de celui qui appelle. Voici une trame de travail que vous pouvez reprendre et adapter à vos flux réels.

Niveau	Définition par l'effet métier	Exemple concret	Ce qui doit être engagé
Bloquant	Un processus qui génère du chiffre d'affaires ou une obligation légale est arrêté	Impossible de valider les factures clients ou d'expédier une commande	Prise en charge dans l'heure ouvrée, point d'avancement toutes les heures, contournement recherché en priorité
Majeur	Le processus fonctionne mais de façon dégradée, avec une charge manuelle anormale	Un rapport de stock est faux, les équipes recomptent à la main	Prise en charge dans la demi-journée ouvrée, correctif planifié
Mineur	Gêne d'usage sans effet sur le résultat métier	Un libellé erroné, un champ mal placé dans une vue	Traitement dans le cycle d'évolutions courant
Évolution	Demande de changement, pas de dysfonctionnement	Ajouter une règle de remise automatique	Chiffrage et planification, hors circuit d'incident

Les plages horaires doivent correspondre à votre activité réelle

Un contrat en heures ouvrées classiques ne protège pas une entreprise qui expédie le samedi ou qui clôture ses commandes en ligne le dimanche soir. Inversement, payer une astreinte de nuit quand votre activité s'arrête à 18 h est une dépense sans contrepartie. La bonne plage est celle qui couvre vos créneaux critiques, pas la plus large.

Sur les cas multi-sites, cette question devient structurante. Une organisation comme IDC Pharma, dont dix-sept sites de vente sont unifiés dans un WMS multi-entrepôts (warehouse management system, le système qui pilote les mouvements d'entrepôt), n'a pas le même profil d'incident qu'une société mono-site : une anomalie de règle de stock s'y propage sur l'ensemble du réseau en quelques heures. Le dimensionnement des plages et de l'escalade doit suivre cette réalité.

L'escalade doit nommer un chemin, pas une boîte mail

L'escalade, c'est ce qui se passe quand le premier niveau ne suffit pas. Un dispositif utilisable comporte trois choses : un second niveau technique identifié, un délai au bout duquel l'incident remonte automatiquement sans que vous ayez à le demander, et un interlocuteur côté prestataire capable de décider d'engager des moyens supplémentaires. Si l'escalade se résume à « renvoyer un mail à la même adresse », il n'y a pas d'escalade.

Qui décroche vraiment à 9 h un lundi

C'est le seul test qui compte, et il ne se lit pas dans le contrat. Il se vérifie avant de signer, avec quelques questions très concrètes que peu de prospects posent.

• Qui est la personne qui répond, et connaît-elle mon instance ? Un support générique qui redécouvre votre paramétrage à chaque ticket vous fera payer le temps de redécouverte, en heures ou en délai. Côté éditeur, les canaux officiels sont centralisés sur la page d'aide d'Odoo.
• Combien de personnes chez vous savent intervenir sur mon dossier ? Une seule personne, c'est un risque de continuité, en congés comme en départ.
• Quel est le canal d'entrée et que se passe-t-il s'il tombe ? Un support joignable uniquement par formulaire web est inutilisable quand c'est le serveur web interne qui est en cause.
• Puis-je parler à deux clients sous contrat depuis plus d'un an ? La réponse à cette demande est déjà une information. Les retours d'expérience de clients ayant vécu un projet complet en disent plus qu'une plaquette.
• Où sont mes accès et mes sauvegardes ? Si vous n'avez pas vous-même un accès administrateur à votre hébergement et à vos sauvegardes, vous n'avez pas de plan B.

Ce dernier point rejoint directement la question de la réversibilité, que nous traitons dans l'article sur la façon de choisir son intégrateur Odoo. Un contrat de support est un contrat de dépendance. Il doit donc prévoir la sortie : restitution du code des développements spécifiques, documentation du paramétrage, transfert des accès, et un délai de réversibilité écrit. Un prestataire qui refuse d'écrire cette clause vous dit quelque chose d'important.

Montées de version : le coût que le contrat de support ne montre pas

La maintenance d'un ERP ne se résume pas aux incidents. Elle inclut le fait de rester sur une version supportée, et c'est là que la facture arrive par la porte de derrière.

Le contrat d'abonnement définit les versions couvertes comme les trois versions majeures les plus récentes, avec une nouvelle version majeure publiée une fois par an. Vous disposez donc d'une fenêtre de trois ans, ce qui est confortable, mais qui n'est pas infini. Le contrat prévoit qu'une fois par an, et pas avant six mois après la sortie d'une version majeure, un client dont la base tourne sur une version non couverte accepte de payer un supplément égal à 25 % du prix annualisé de son abonnement. Ce supplément facture le maintien d'un support sur une base ancienne, et il vaut mieux le lire comme tel. Pour les tarifs de licence en vigueur, référez-vous à la grille publiée sur odoo.com.

Le service de migration lui-même est délimité avec la même précision. La documentation officielle sur les mises à niveau et le contrat convergent : le service se limite à la conversion technique de la base vers la version cible et à la correction des anomalies directement causées par l'opération de migration. La validation de la base migrée reste à la charge du client, tout comme l'adaptation des extensions tierces installées avant la migration.

Traduction opérationnelle : plus votre instance porte de spécifiques, plus la montée de version coûte, et ce coût là n'est presque jamais dans le forfait de support. C'est un poste à budgéter séparément, tous les deux ou trois ans. Nous détaillons cette mécanique et les autres postes sous-estimés dans l'analyse du coût réel d'un projet Odoo. Pour situer un ordre de grandeur sur la partie développement, le développement d'un connecteur sur mesure se situe chez nous dans une fourchette indicative de 2 000 à 15 000 €, pour deux à huit semaines selon la complexité des flux. Ce développement, lui, se maintient ensuite à chaque montée de version.

Comment réduire son besoin de support ?

Trois investissements modestes font baisser le volume de tickets de façon mesurable : documenter votre paramétrage, former un référent interne et disposer d'un environnement de test. Le meilleur contrat de support reste celui qu'on utilise peu. Ces trois choix se décident au moment du déploiement d'Odoo, pas six mois après.

Documenter le paramétrage, pas le logiciel

Personne n'a besoin d'un manuel Odoo : la documentation de l'éditeur existe et elle est bonne. Ce qui manque toujours, c'est le document qui explique vos choix : pourquoi cette position fiscale, pourquoi ce type d'opération de stock, pourquoi cette séquence de numérotation. Une trentaine de pages suffisent. Elles évitent qu'un successeur défasse dans l'ignorance un réglage posé pour une bonne raison, et elles raccourcissent le diagnostic de moitié quand un incident survient.

Former un référent interne, et lui donner du temps

C'est l'investissement le plus rentable et le plus souvent bâclé. Un référent interne formé filtre une part importante des demandes avant qu'elles atteignent le prestataire, parce que la majorité des tickets sont des questions d'usage, pas des incidents. Encore faut-il que ce rôle soit reconnu dans sa charge de travail. Un référent qui n'a pas de temps dédié redevient un utilisateur comme les autres en trois mois. Cette question relève de la conduite du changement sur un projet ERP autant que de la technique.

Disposer d'un environnement de test séparé

Tester une modification directement en production est la première cause d'incidents évitables. Un environnement de test, alimenté par une copie récente de la base, permet de valider un changement de paramétrage, une mise à jour de module ou une migration avant qu'il touche vos utilisateurs. Sur les hébergements gérés par l'éditeur, cette capacité existe déjà. Sur les autres, elle se met en place, et elle se maintient.

Un dernier point, souvent oublié : vérifiez que vous savez restaurer une sauvegarde, pas seulement qu'elles existent. L'engagement de service cloud d'Odoo publie des objectifs précis, avec quatorze sauvegardes complètes conservées sur au moins trois mois et des objectifs de reprise de 24 h de données et de 6 h de remise en service en cas de sinistre serveur (Odoo Cloud Hosting Service Level Agreement). Ces objectifs ne valent que si quelqu'un chez vous a déjà fait l'exercice au moins une fois.

Quand externaliser le support n'est-il pas rentable ?

Dans trois cas : quand vous avez une équipe interne compétente et disponible, quand votre périmètre est standard et stable, et quand votre tolérance à l'arrêt est réelle. Souscrire une TMA revient alors à payer une assurance pour un risque que vous ne portez pas. Les voici en détail, sans détour.

Vous avez une équipe interne compétente et disponible. Une entreprise qui emploie un profil technique connaissant Python et le framework Odoo, avec du temps réellement alloué à l'ERP, n'a pas besoin d'un forfait mensuel. Elle a besoin d'un accès à une expertise ponctuelle, ce qui correspond au modèle du carnet d'heures ou du ticket à l'acte. Payer un forfait dans cette configuration finance surtout une disponibilité que vous avez déjà.

Votre périmètre est standard et stable. Une PME qui utilise Odoo en configuration proche du standard, sans développement spécifique, sans intégration externe, sur des processus qui n'ont pas bougé depuis dix-huit mois, génère très peu d'incidents structurels. Le support de l'éditeur couvre l'essentiel de ce qui peut casser, puisque ce qui tourne est précisément le code que l'éditeur maintient. Dans ce cas, le forfait mensuel est une dépense de confort, à assumer comme telle.

Votre tolérance à l'arrêt est réelle. Toutes les activités ne sont pas également sensibles. Une société de conseil dont Odoo porte la facturation mensuelle et le suivi de temps peut absorber deux jours d'indisponibilité sans conséquence commerciale. Un négoce qui expédie deux cents commandes par jour ne le peut pas. Le dimensionnement du support doit suivre cet écart, pas la moyenne du marché.

Et il faut dire l'inverse aussi, parce que c'est la partie que les prestataires taisent volontiers : aucun contrat de support ne répare certaines choses. Un paramétrage bâclé au démarrage ne se rattrape pas par des tickets. Il produit des incidents à répétition dont chacun sera traité, facturé, et suivi d'un autre, jusqu'à ce que quelqu'un reprenne le paramétrage à la racine. Des données sales, doublons de tiers, articles en double référence, historiques incohérents, continueront de produire des états faux quel que soit le niveau d'engagement souscrit. Et une équipe non formée génère un volume de tickets qui ne baissera pas, parce que le problème n'est pas dans l'outil.

Un cadrage initial sérieux et des données propres réduisent le volume d'incidents bien plus sûrement que n'importe quelle clause contractuelle. Ce travail se fait au démarrage du projet, et il ne se rachète pas ensuite au forfait mensuel.

Questions fréquentes

Quels sont les problèmes rencontrés avec Odoo ?

Les difficultés les plus fréquemment rapportées en PME ne portent pas sur des défauts du logiciel mais sur trois zones : un paramétrage initial insuffisamment cadré, des données reprises sans nettoyage, et des développements spécifiques accumulés qui compliquent chaque montée de version. S'y ajoute la dépendance à l'intégrateur lorsque la documentation et la réversibilité n'ont pas été prévues au contrat.

Quels sont les inconvénients d'Odoo ?

Le principal est le coût de possession dans la durée, souvent sous-estimé : maintenance des spécifiques, montées de version tous les deux à trois ans, et redevance de maintenance des modules additionnels facturée par tranche de cent lignes de code selon le contrat d'abonnement. Le second est la profondeur fonctionnelle inégale selon les modules, certains étant très matures et d'autres nettement moins.

Le support Odoo est-il inclus dans l'abonnement ?

Oui, avec un périmètre précis. Le contrat d'abonnement Enterprise autorise un nombre illimité de tickets gratuits, mais exclusivement pour des bugs au sens contractuel ou pour de l'aide à l'usage des fonctions standard. Les questions de développement ou de personnalisation relèvent d'un accord de service distinct.

Odoo est-il vraiment gratuit ?

La version Community est libre et sans redevance de licence, mais elle n'ouvre droit ni au support de l'éditeur, ni au service de migration, ni aux modules Enterprise. La distinction et ses conséquences pratiques sont détaillées dans notre comparaison entre Odoo Community et Odoo Enterprise.

Qui sont les meilleurs intégrateurs Odoo ?

La question utile n'est pas le classement mais l'adéquation : un intégrateur qui a déjà traité vos flux critiques, qui accepte d'écrire une clause de réversibilité et qui peut vous mettre en relation avec des clients sous contrat depuis plus d'un an. Les critères de sélection sont détaillés dans notre guide sur le choix d'un intégrateur, et nos cas clients donnent des exemples de périmètres réellement traités.

Quel langage de programmation utilise Odoo ?

Le cœur d'Odoo est écrit en Python, avec du JavaScript pour l'interface et du XML pour les vues et les données de configuration. C'est une information utile au moment de recruter ou d'évaluer un référent interne : les compétences nécessaires pour intervenir sur un spécifique sont celles d'un développeur Python, pas d'un administrateur fonctionnel.

Faut-il un contrat de TMA dès la mise en production ?

Les trois à six mois qui suivent une mise en production concentrent le plus gros volume d'incidents, essentiellement liés au paramétrage et à la prise en main. C'est la période où un engagement de service serré a le plus de valeur, quitte à réviser le dispositif à la baisse une fois l'usage stabilisé.

En résumé

Le support Odoo n'est pas une case à cocher, c'est une chaîne de responsabilités qu'il faut écrire avant d'en avoir besoin. L'éditeur couvre les bugs de son code et l'usage du standard, sous deux jours ouvrés de prise en charge, hors paramétrage et hors développements spécifiques non souscrits. Tout le reste, c'est-à-dire l'essentiel de ce qui bloque une PME un lundi matin, relève d'un contrat de TMA ou de vos propres équipes. Entre le forfait mensuel, le carnet d'heures et le ticket à l'acte, aucun modèle n'est supérieur : ils créent simplement des incitations différentes, et vous devez choisir celle qui correspond à votre tolérance à l'arrêt.

Avant de signer, exigez trois choses par écrit : un délai de prise en charge distinct du délai de résolution, une grille de criticité définie par les effets métier, et une clause de réversibilité qui prévoit la restitution du code et de la documentation. Puis travaillez à réduire votre besoin, avec un paramétrage documenté, un référent interne à qui on donne du temps, et un environnement de test. Reste à confronter votre situation à des cas comparables, notamment sur des flux e-commerce ou logistiques. Racontez-nous votre instance telle qu'elle fonctionne aujourd'hui et nous vous dirons quel modèle de contrat correspond à votre tolérance à l'arrêt.