Apres avoir implemente Odoo pour plus de 50 entreprises, nous avons remarque un schema qui nous derangeait. Nous passions des mois a configurer un systeme, migrer les donnees, former les utilisateurs et tout deployer. Six mois plus tard, le PDG - la personne qui avait approuve le projet - demandait encore a son assistant de tirer des chiffres d'Odoo. Il ne se connectait jamais lui-meme. Non pas parce que le systeme etait mauvais, mais parce qu'ouvrir un navigateur, naviguer jusqu'au bon menu, configurer des filtres et lire un tableau de bord represente trop de friction quand on veut simplement connaitre le chiffre d'affaires du mois dernier.
Ce n'est pas un probleme specifique a Odoo. Cela arrive avec SAP, avec Microsoft Dynamics, avec chaque ERP. Les personnes qui ont le plus besoin de donnees - les dirigeants, les fondateurs, les managers en deplacement - sont celles qui sont le moins susceptibles de s'asseoir devant une application de bureau et de cliquer dans des menus. Ils veulent des reponses, pas des interfaces.
Nous avons commence avec un prototype simple fin 2025. Un bot Telegram qui pouvait se connecter a une instance Odoo et repondre a des questions en langage naturel. La premiere version utilisait une correspondance basique par mots-cles - si vous tapiez 'chiffre d'affaires', il tirait le total d'account.move. C'etait rudimentaire mais la reaction de nos clients a ete immediate. Le PDG d'une entreprise manufacturiere nous a dit qu'il avait consulte ses chiffres plus souvent la premiere semaine avec le bot que pendant tout le trimestre precedent avec le tableau de bord Odoo.
La veritable percee est venue quand nous avons integre Claude comme colonne vertebrale IA. Au lieu d'une correspondance rigide par mots-cles, les utilisateurs pouvaient poser des questions naturellement : 'Combien d'unites de SKU-4521 avons-nous expediees la semaine derniere ?' ou 'Quel commercial a eu la meilleure marge au Q1 ?' L'IA analyse l'intention, la traduit en requetes de modeles Odoo, recupere les donnees via XML-RPC et formate une reponse lisible. Elle gere les questions de suivi avec contexte, donc vous pouvez demander 'Et au Q2 ?' et elle sait que vous parlez toujours des marges des commerciaux.
Le choix de Telegram comme interface etait delibere. Nous avons envisage de creer une application mobile personnalisee, un tableau de bord web, une integration Slack. Mais nos clients sont principalement au Moyen-Orient et dans la region CEI, ou Telegram est l'outil de communication professionnelle par defaut. Les gens l'ont deja ouvert toute la journee. Zero installation d'application, zero friction d'integration. Vous ajoutez le bot, vous vous authentifiez une fois et vous commencez a poser des questions.
L'architecture technique a traverse trois iterations. La version un etait un monolithe - bot, IA et integration Odoo dans un seul processus Node.js. Ca fonctionnait pour les demos mais c'etait impossible a mettre a l'echelle. La version deux a ete separee en microservices mais a introduit trop de complexite pour notre petite equipe. La version trois - ce que nous executons en production - est un monorepo pragmatique avec Grammy.js pour le bot Telegram, Fastify pour la couche API et Prisma pour notre propre base de donnees. Pas des microservices, pas un monolithe, juste une separation sensee au sein d'une unite deployable.
Ce qui nous a surpris, c'est la quantite de travail necessaire pour la detection de schema. Chaque instance Odoo est differente. Les clients ajoutent des champs personnalises, installent differents modules, utilisent differentes conventions de nommage. Notre bot doit comprendre que le client A appelle son champ produit 'x_brand' tandis que le client B l'appelle 'product_brand_id'. Nous avons construit un systeme automatique de profilage de schema qui lit les metadonnees Odoo du client lors de la premiere connexion et fait correspondre ses noms de champs specifiques a nos modeles de requetes standard.
La tarification a été une autre leçon. Nous avions initialement prévu un modèle simple par utilisateur, mais les clients entreprise voulaient des coûts prévisibles tandis que les petites entreprises voulaient des points d'entrée bas. Nous avons finalement opté pour quatre niveaux : un essai Gratuit de 14 jours pour tester (1 utilisateur, 20 requêtes, tous les rapports de base), Starter à 39$/mois pour les petites équipes (3 utilisateurs, 150 requêtes par mois, les 43 rapports, 4 rapports programmés), Pro à 149$/mois pour les entreprises en croissance (10 utilisateurs, 500 requêtes par mois, tous les rapports plus MRP, 15 rapports programmés, mémoire de conversation, support prioritaire), et Enterprise avec tarification personnalisée pour les grandes organisations (utilisateurs illimités, outils entreprise, déploiement sur site ou VPN, outils personnalisés définis en YAML, SLA de 99,9%, gestionnaire de compte dédié). L'enseignement clé était que le volume de requêtes, et non le nombre d'utilisateurs, est le bon axe de tarification pour un produit IA où chaque requête a un coût de calcul réel.
Le probleme d'ingenierie le plus difficile n'etait ni l'IA ni l'integration Odoo - c'etait la gestion correcte des droits d'acces d'Odoo. Quand un utilisateur demande 'Montre-moi tous les salaires des employes', le bot doit respecter les memes droits d'acces qu'Odoo appliquerait si cet utilisateur se connectait directement. Nous resolvons cela en executant les requetes via un compte de service avec des permissions soigneusement delimitees, mais cela signifie que certaines requetes retournent 'Vous n'avez pas acces a ces donnees' - ce qui est le comportement correct, pas un bug.
Nous avons aussi appris que l'hallucination de l'IA est un risque reel quand on traite des donnees d'entreprise. Si le bot affirme avec assurance que le CA du Q1 etait de 2,3 M$ alors qu'il etait en realite de 2,1 M$, c'est pire que pas de reponse du tout. Nous attenuons ce risque en ne laissant jamais l'IA generer des chiffres - elle ne fait que formater et expliquer des donnees qui proviennent directement des requetes Odoo. L'IA redige le narratif, mais chaque chiffre dans la reponse remonte a un enregistrement reel de la base de donnees.
Six mois apres le lancement, nous avons des clients dans la fabrication, l'education, le commerce de detail et les services professionnels qui utilisent le bot quotidiennement. Le client moyen envoie 15 a 20 requetes par jour, principalement depuis le mobile en dehors des heures de bureau - exactement le cas d'usage pour lequel nous avons concu le produit. Les requetes les plus populaires sont les syntheses financieres, les niveaux de stock et l'etat du pipeline commercial.
Quelle est la suite : nous construisons un systeme d'alertes proactives. Au lieu d'attendre que les utilisateurs posent des questions, le bot surveillera les metriques cles et les notifiera quand quelque chose necessite leur attention - stock en dessous du seuil, factures en retard depassant un certain montant, objectifs de vente en danger. L'objectif n'est pas seulement de repondre aux questions mais de s'assurer que les bonnes questions sont posees en premier lieu.