Connecter ChatGPT et Claude à Odoo : trois cas d'usage

Au Maroc, quand une entreprise de taille moyenne décrit son système d'information, la conversation arrive vite à Odoo. Ventes, achats, stocks, comptabilité, parfois production et paie : l'ERP concentre les données qui font tourner l'activité. Et c'est exactement ce qui manque à ChatGPT ou à Claude pour cesser d'être des assistants de rédaction et devenir des assistants d'entreprise. La question n'est donc pas de savoir s'il faut connecter l'IA à Odoo, mais comment le faire sans transformer votre ERP en passoire ni votre intégration en dette technique.

Pourquoi Odoo est-il le bon point de départ au Maroc ?

Trois raisons convergentes. D'abord la densité de données utiles : contrairement à un ERP éclaté en modules d'éditeurs différents, Odoo réunit dans un même modèle de données les clients, les produits, les prix, les stocks, les commandes et les factures. Un assistant qui y accède voit le cycle complet, pas un fragment.

Ensuite l'ouverture technique. Odoo expose ses objets métiers de manière homogène et documentée. Là où un ERP propriétaire exige des développements spécifiques coûteux pour chaque point d'accès, Odoo permet d'exposer proprement une action précise — « rechercher un client », « lire les stocks d'un article » — sans réécrire l'application.

Enfin la maturité du parc marocain. Beaucoup d'entreprises ont franchi l'étape de l'ERP il y a plusieurs années et disposent aujourd'hui d'un historique exploitable : des milliers de devis, des années de tickets, des mouvements de stock. C'est cette matière qui rend les cas d'usage suivants immédiatement rentables, sans projet de reprise de données préalable.

Cas d'usage 1 : les devis assistés

Dans la plupart des PME industrielles ou de distribution, produire un devis suppose de retrouver ce qu'on avait proposé au même client l'an dernier, de vérifier la remise habituellement consentie, de contrôler la disponibilité des articles et de reprendre les conditions commerciales d'usage. Un commercial expérimenté fait cela en vingt minutes. Un commercial récent y passe une heure, et se trompe plus souvent.

Un assistant connecté à Odoo change la mécanique. À partir d'une demande en langage naturel — « fais-moi un devis pour la société Alpha, cinquante unités de la référence X, conditions habituelles » —, il consulte l'historique du client, retrouve la grille de remises appliquée, vérifie le stock disponible et la date de réapprovisionnement, puis crée un devis à l'état brouillon dans Odoo. Le commercial le relit, l'ajuste, le confirme.

Deux points de conception rendent ce cas d'usage sûr. Le premier : l'assistant écrit un brouillon, jamais un document confirmé. Aucun engagement commercial n'est pris par une machine. Le second : il n'invente pas de prix. Les tarifs et les remises viennent des grilles Odoo, et si aucune règle ne s'applique, l'assistant le signale au lieu de combler le vide. C'est la différence entre un outil qui accélère un expert et un outil qui produit des erreurs à grande vitesse.

Le gain observé est moins spectaculaire qu'annoncé sur le temps de rédaction, mais très réel sur la cohérence commerciale : moins d'écarts de remise, moins de références indisponibles proposées, un rattrapage plus rapide des nouveaux entrants sur les pratiques de la maison.

Cas d'usage 2 : les réponses clients

Le service client d'une entreprise sous Odoo dispose d'une information que ses agents n'ont pas le temps de croiser : le client qui écrit a une commande en cours, une facture ouverte, un historique d'incidents et un contrat. La réponse pertinente à « où en est ma commande ? » se trouve dans l'ERP ; la trouver prend deux minutes, la formuler correctement en prend trois, et il y a cent messages par jour.

Un assistant branché sur Odoo prépare la réponse : il identifie le client à partir de son adresse, retrouve la commande concernée, lit son statut réel et sa date de livraison prévue, vérifie s'il existe un incident ouvert, puis rédige un projet de réponse dans le ton de l'entreprise, en français, en arabe ou en anglais selon la langue du message reçu — un point qui compte davantage au Maroc qu'ailleurs.

Ici encore, la règle de conception est ferme : l'agent propose, l'humain envoie, au moins pendant les premiers mois. Non par principe de précaution abstrait, mais parce que la mesure de l'écart entre la réponse proposée et la réponse envoyée est votre meilleur indicateur de qualité. Quand cet écart devient marginal sur une catégorie de demandes — les demandes de suivi de commande, typiquement —, vous pouvez envisager une autonomie ciblée sur cette catégorie, et sur elle seule.

Le piège classique consiste à vouloir traiter d'emblée les réclamations complexes et les litiges. Ce sont précisément les cas où le jugement, la relation et l'enjeu commercial priment. Laissez-les aux humains, à qui vous aurez rendu du temps en automatisant les demandes de statut, qui représentent souvent la moitié du volume.

Cas d'usage 3 : les analyses de stock

Les données de stock d'Odoo sont exactes et pratiquement inexploitées. La raison est prosaïque : poser une question un peu fine — « quels articles ont une couverture inférieure à trois semaines compte tenu des ventes des deux derniers mois et des commandes fournisseurs en cours ? » — suppose de construire un état, donc de solliciter la DSI, donc d'attendre.

Un assistant connecté aux objets de stock, d'achats et de ventes répond à cette question en langage naturel, en interrogeant les données réelles et en montrant son calcul. Les usages qui remontent le plus vite du terrain : détecter les ruptures imminentes avant qu'elles n'atteignent le client, identifier les stocks dormants qui immobilisent de la trésorerie, comparer les délais réels de livraison des fournisseurs à leurs engagements contractuels.

Ce troisième cas est le plus simple à sécuriser — l'assistant travaille en lecture seule, il ne modifie rien — et c'est pour cette raison qu'il constitue souvent le meilleur premier projet. Il permet à l'organisation d'apprendre à travailler avec un assistant connecté à l'ERP, de mesurer la qualité de ses réponses et de construire les réflexes de vérification, sans exposer un seul processus d'écriture.

Une exigence, toutefois : l'assistant doit afficher les chiffres sur lesquels il s'appuie, pas seulement sa conclusion. Une analyse dont on ne peut pas retracer la source ne sera pas utilisée pour décider — et elle ne le mérite pas.

Pourquoi passer par MCP plutôt que par des connecteurs sur mesure ?

Rien n'empêche de développer une intégration spécifique entre un modèle et Odoo. C'est même la voie la plus rapide vers une démonstration réussie — et la plus sûre vers une dette technique.

Le Model Context Protocol propose une autre approche : vous exposez Odoo une fois, sous la forme d'un serveur MCP qui déclare un catalogue d'actions permises — rechercher un client, lire un stock, créer un devis en brouillon —, avec pour chacune ses paramètres, ses limites et ses contrôles. Tout modèle ou toute application compatible s'y connecte ensuite sans développement supplémentaire.

Les conséquences pratiques sont directes. Vous ne dépendez pas d'un fournisseur de modèle : le même serveur MCP sert ChatGPT Enterprise aujourd'hui, Claude demain, un modèle ouvert hébergé chez vous après-demain, sans retoucher l'intégration. La sécurité se centralise : les droits, les plafonds et la journalisation vivent dans le serveur MCP, chez vous, et non dispersés dans chaque application. La surface exposée reste explicite : ce qui n'est pas déclaré comme action n'existe pas pour le modèle — on ne donne pas un accès général à la base, on donne quinze actions nommées.

C'est cette dernière propriété qui devrait convaincre un directeur des systèmes d'information. La question « qu'est-ce que l'IA peut faire dans notre ERP ? » appelle une réponse qui tient sur une page, et cette page, c'est le catalogue de votre serveur MCP. Pour le cadre général, notre article le Model Context Protocol expliqué aux décideurs détaille le raisonnement.

Que faut-il prévoir avant de brancher quoi que ce soit ?

L'alignement des droits. L'assistant ne doit jamais voir plus que l'utilisateur qu'il assiste. Un serveur MCP qui se connecte à Odoo avec un compte administrateur, quel que soit l'utilisateur derrière, annule vos habilitations. Les droits Odoo existants doivent être hérités, pas contournés.

La qualité des données. Un assistant qui répond à partir de fiches clients en double, de références obsolètes ou de stocks théoriques faux produira des réponses fausses avec assurance. L'IA rend visible la qualité de vos données ; elle ne l'améliore pas.

Les traitements sensibles. Les données commerciales, tarifaires et clients de votre ERP sont parmi vos actifs les plus stratégiques. Lorsque leur envoi vers un service cloud n'est pas acceptable — pour des raisons contractuelles, sectorielles ou concurrentielles —, la même architecture MCP fonctionne avec un modèle ouvert hébergé sur vos infrastructures, dans le cadre d'un déploiement d'IA souveraine.

La conduite du changement. Les commerciaux qui découvrent des devis pré-remplis sans explication les ignorent. Ceux à qui l'on a montré comment l'assistant travaille, où il se trompe et comment le corriger l'adoptent en quelques semaines.

Par où commencer ?

Prenez le cas d'usage en lecture seule — l'analyse de stock —, exposez cinq à dix actions MCP, mesurez la qualité des réponses pendant un mois. Vous disposerez alors d'un serveur MCP réutilisable, d'utilisateurs formés et d'une base de confiance pour aborder les cas d'usage en écriture, à commencer par le devis en brouillon.

C'est le cœur de notre offre d'intégration IA : concevoir des serveurs MCP sécurisés au-dessus d'Odoo et de vos autres systèmes, puis y brancher les assistants et les agents IA qui portent vos processus. Les usages décrits ici correspondent à nos copilotes ventes, support client et achats. Pour le contexte local et nos références, voyez notre page IA au Maroc, et pour cadrer un premier périmètre sur votre instance Odoo, parlons-en.