Odoo + Claude : créer un bot Slack interne qui interroge votre ERP
Le bot Slack Odoo‑Claude répond aux questions opérationnelles dans Slack en traduisant le langage naturel en requêtes search_read Odoo gouvernées, tout en respectant les règles d'accès aux enregistrements.
Ce guide décrit le processus manuel actuel, le flux de données Odoo→Claude→Odoo et fournit un scénario précis (entrées/sorties) que votre intégrateur pourra implémenter.
Nous nous concentrons sur le cas d'un chatbot IA pour ERP dans Slack avec Claude comme LLM. Des comparaisons à GPT‑4 peuvent apparaître, mais les exemples partent du principe que l'API Anthropic fournit des sorties structurées.
Chaque étape cite explicitement les modèles et champs Odoo pour que vos équipes chiffrent le travail sans jargon flou sur l'IA.
Une fois la boucle principale stable, des usages complémentaires comme les requêtes conversationnelles ERP s'ajoutent naturellement.
Dasolo déploie ces modèles avec Claude sur une couche middleware hébergée en UE, mais les noms de champs et déclencheurs Odoo restent valables quelle que soit la région d'hébergement.
Vous retrouverez la mention du bot Slack Odoo‑Claude dans les sections processus, flux et pratique pour garder cohérence SEO et clarté opérationnelle.
Considérez Claude comme un exécuteur structuré qui renvoie du JSON que votre middleware valide — pas comme une fenêtre de chat à surveiller pour chaque écriture de champ.
Sur cette page
Comment les équipes procèdent aujourd'hui
Aujourd'hui, les opérationnels demandent des états AR ou des clichés d'inventaire sur Slack ; la finance exporte depuis Odoo, prend des captures, et répond parfois 20 minutes plus tard.
L'accès SQL ad‑hoc ou des droits administrateurs larges n'est pas envisageable, donc les demandes simples restent souvent en file d'attente.
Les démos de chatbot IA ERP sur Slack échouent quand le bot invente des chiffres : sans appui sur des search_read live, l'IA hallucine.
Une base multi‑sociétés rend les erreurs coûteuses si les règles d'accès aux enregistrements sont contournées.
Le bot Odoo‑Claude doit transformer le langage naturel en requêtes Odoo contrôlées — pas en accès brut à la base.
Exemple : l'entrepôt demande le statut crédit d'un client sur Slack ; la finance renvoie un PDF d'AR car aucune requête self‑service sûre n'existe.
Les chefs de projet sollicitent les devs pour l'état des tâches ; ces derniers basculent sans cesse de Project à Slack pour répondre.
Des réponses erronées sur les niveaux de stock provoquent des surventes quand Shopify affiche des caches périmés.
La DSI refuse d'accorder un accès Odoo étendu à des utilisateurs Slack qui n'ont besoin que d'informations en lecture.
Limiter le débit par utilisateur Slack évite les requêtes coûteuses lancées par plaisanterie dans un canal.
Les décideurs veulent un ROI avant de financer le middleware. Mesurez les minutes économisées par type d'enregistrement pendant deux semaines à côté de la vue liste Odoo.
Les ops craignent que l'IA contourne les chaînes d'approbation. Cartographiez les champs en mode brouillon avant tout webhook de production.
Six mois après le lancement, des slides de formation décrivent encore l'ancien processus : mettez à jour la docs internes quand Claude devient la norme.
La sécurité veut savoir si des emails clients quittent l'UE. Présentez un schéma d'architecture montrant la configuration régionale d'Anthropic et les règles de masquage avant le pilote.
Flux de données : Odoo → Claude → Odoo
Déclencheur : mention de l'app Slack ou DM du bot avec portée autorisée sur certains canaux.
Lecture Odoo : le mapping slack.user → res.users définit company_ids et groupes. La couche outils expose des templates search_read pour stock, AR, PO et tâches projet.
Tâche Claude : analyser l'intention et retourner un JSON d'appel outil contenant modèle, domaine, champs, limite et instructions de formatage naturel.
Retour : le middleware exécute XML‑RPC/JSON‑RPC Odoo avec les crédos utilisateur, envoie les lignes à Claude pour formatage en blocs Slack, et retourne le message. Pas d'écriture en v1.
Revue humaine : pour les requêtes sensibles, ajouter un bouton de confirmation dans Slack avant d'afficher le détail AR au niveau partenaire.
L'architecture reflète le déploiement Dasolo : un compte service lecture séparé par workspace Slack.
L'utilisateur Slack est mappé à res.users via e‑mail ; les utilisateurs non mappés reçoivent un message d'accueil avec lien OAuth pour approuver la liaison de profil Odoo.
Le registre d'outils autorise des modèles précis : stock.quant, purchase.order.line, account.move.line open, project.task avec listes de champs autorisés.
Claude ne reçoit jamais du SQL brut ; le middleware construit des tableaux de domaine depuis le JSON d'intention seulement.
Les opérations d'écriture sont désactivées en v1 ; une v2 proposera des créations après confirmation via un compte service sudo avec élévation explicite.
Le formateur de réponse utilise des blocs Slack avec maxi 20 lignes ; en cas de débordement, proposer un lien vers la vue liste Odoo filtrée.
Proposer un bouton « expliquer le domaine » dans la réponse Slack pour que les power users voient le filtre Odoo appliqué.
Le middleware fonctionne avec workers en file et backoff exponentiel si Anthropic renvoie 529, pour ne jamais bloquer les webhooks Odoo lors d'enregistrements.
La validation de sortie structurée s'effectue avec pydantic ou jsonschema ; un JSON Claude invalide est envoyé sur un canal de développeurs pour inspection.
Les templates de prompt versionnés (v1, v2) sont en git ; la prod lit la version active via variable d'environnement pour déploiements contrôlés du bot Odoo‑Claude.
Le log d'audit Odoo enregistre l'uid de l'API user sur les écritures pour tracer qui a autorisé des changements initiés par l'IA lors des revues trimestrielles.
La préprod rejoue des payloads anonymisés chaque semaine pour tester les modifications de prompt avant promotion, sans toucher aux données clients.
Les feature flags par company_id dans les bases multi‑sociétés permettent de piloter sur une entité pendant que les autres restent manuelles.
Exemple concret : du besoin à la réponse
Scénario : le responsable entrepôt demande les lignes PO ouvertes pour un SKU
Exemple : « Que contient la commande pour le SKU WL‑4421 et quand arrive‑t‑elle ? » Le bot résout product_id, interroge purchase.order.line en état d'achat, et renvoie fournisseur, quantité et date_planned dans un tableau Slack.
Question de suivi : filtrer sur le fournisseur Acme. Claude réutilise le contexte, mais exécute une nouvelle requête avec domaine resserré pour éviter des chiffres d'inventaire périmés.
Le CFO demande le total AR ouvert pour les cinq principaux partenaires par solde : le bot rend un tableau avec nom du partenaire, amount_residual et lien vers la vue comptable filtrée.
Ops demande quelles OF sont en retard aujourd'hui : le bot interroge mrp.production en state≠done et date_planned_start antérieure à aujourd'hui selon TZ société.
Pour une question d'inventaire ambiguë, le bot clarifie l'emplacement d'entrepôt avant d'exécuter la seconde requête.
Documentez la latence attendue du déclencheur à l'ébauche de réponse. Les équipes visent généralement <90 s pour email/transcript et <5 min pour extraction PDF.
Exécutez deux semaines en mode shadow : Claude écrit dans des champs test pendant que les humains travaillent normalement, puis comparez la qualité avant bascule.
Cas limite : requête inter‑sociétés bloquée
Si un utilisateur demande l'AR d'une filiale à laquelle il n'a pas accès, le bot renvoie une explication de permission sans divulguer de totaux d'autres company_id.
Les règles d'enregistrement sur res.users company_ids appliquent la frontière avant que Claude ne formate toute réponse numérique.
Checklist UAT : déclencher sur un enregistrement test, vérifier le log JSON, confirmer champs brouillon, approuver écriture, contrôler l'entrée chatter, rollback des tests.
Critères de mise en production du bot Odoo‑Claude : 90 % de satisfaction agents/resp. sur les dix premières exécutions et <5 % d'échecs de validation JSON.
Bénéfices clés
- Gains de temps : les commerciaux et agents relisent des ébauches générées par l'IA au lieu de retaper les mêmes champs Odoo toutes les heures.
- Cohérence : le bot applique les mêmes règles de classification et de formatage sur tous les postes et sites.
- Vitesse : le délai intake→première action diminue car les déclencheurs opèrent à la création, pas en traitement de fin de journée.
- Montée en charge : on ajoute un nouveau workflow en clonant le schéma de prompt et le webhook, sans reconstruire l'infra.
- Traçabilité : chaque appel à Claude logge entrées, sorties et sur‑écritures humaines sur l'enregistrement métier.
- Gouvernance : validation humaine pour les écritures client/financières afin de rester conforme.
- Onboarding : les nouveaux suivent les ébauches IA comme modèles et apprennent plus vite que via des SOP PDF obsolètes.
- Intégration : le même middleware supporte les workflows futurs sans contrats supplémentaires au‑delà de l'usage API Anthropic.
Points d'implémentation à prévoir
Qualité des données : noms partenaires erronés, références produits manquantes et descriptions helpdesk vides produisent de mauvais résultats. Nettoyez vos données maîtresses d'abord.
Revue humaine : commencez par des écritures en mode brouillon pendant quatre semaines. Mesurez le taux d'override avant d'autoriser l'application automatique sur les champs à faible risque.
API et coût : batchez les jobs nocturnes pour scoring et reporting. Réservez les appels Claude temps réel aux déclencheurs à forte valeur. Mettez en cache des extraits du catalogue produit lorsqu'ils reviennent souvent dans les prompts.
Sécurité : stockez les clés Anthropic dans les secrets du middleware, pas dans le JavaScript Odoo. Scoperez les utilisateurs Odoo par workflow avec le principe du moindre privilège.
Gestion du changement : montrez à vos équipes le temps gagné sur un workflow bot Odoo‑Claude avant d'annoncer dix autres déploiements.
Faites tourner la clé de signature Slack et les clés API Odoo chaque trimestre avec un runbook documenté.
Loggez chaque requête avec user_id et domain JSON pour audit, sans consigner les lignes complètes contenant des PII.
Pourquoi Dasolo est votre partenaire IA
Dasolo conçoit des agents IA et intègre Claude à Odoo pour les opérateurs Benelux et UE, en respectant rules d'enregistrement, journalisation GDPR et formation en français/néerlandais.
Nous livrons le bot Odoo‑Claude avec chemins de rollback, versioning des prompts et observabilité que votre DSI peut auditer sans explorer des notebooks data science.
Notre équipe relie Helpdesk, Ventes, Achats et Documents aux mêmes patterns middleware pour éviter de maintenir onze scripts distincts.
Nous documentons versions de prompt, fixtures de test et étapes de rollback dans votre repo pour que la DSI ne dépende jamais d'un savoir tacite.
Que vous commenciez par le bot Slack Odoo‑Claude ou un autre workflow de notre catalogue, la feuille de route d'intégration est la même.
Réservez votre audit IA avec Dasolo
Réservez votre audit IA avec Dasolo pour prioriser quel workflow Odoo‑Claude Slack lancer en premier et quel nettoyage de données le débloquera.
Conclusion
Le bot Odoo‑Claude Slack fonctionne lorsque Claude s'inscrit dans une boucle Odoo gouvernée avec contrôles humains, pas comme simple fenêtre de chat.
Choisissez un déclencheur pour ce sprint, mesurez temps d'exécution et taux d'override pendant 30 jours, puis clonez le modèle pour le prochain cas d'usage chatbot IA ERP Slack.
Lancez un workflow, mesurez le taux d'override et le cycle time, puis étendez le bot Odoo‑Claude à des déclencheurs voisins sur le même modèle Odoo.
Votre intégrateur doit fournir un pack de fixtures JSON de test pour que les tests de régression s'exécutent à chaque modification de prompt ou de version de modèle.