Règles et permissions
Le moteur de règles qui borne chaque agent : groupes fonctionnels, opérations, conditions de valeurs, garde-fous automatiques et outils externes.
6 min de lectureMis à jour le 7 août 2026
Un agent travaille sans surveillance. Ce qui le borne n'est donc pas votre vigilance, mais un moteur de règles qui vérifie chaque appel avant qu'il ne parte vers Odoo.
La sécurité ne repose jamais sur le prompt
Les règles ne sont pas des consignes données à l'IA. Elles sont appliquées par le serveur, à chaque appel, indépendamment de ce que l'agent croit avoir le droit de faire. Une instruction malveillante cachée dans une donnée Odoo ne peut donc pas les contourner.
Comment une règle se compose
Une règle associe un périmètre à des opérations, avec des conditions facultatives.
Périmètre : groupe « facturation »
Opérations : query, readPérimètre : modèle mail.activity
Opérations : query, read, createPérimètre : modèle sale.order
Opérations : query, read, write
Condition : amount_total < 5000Un agent cumule plusieurs règles. Tout ce qui n'est couvert par aucune règle est refusé.
Les périmètres
Vous désignez soit un groupe fonctionnel, soit une liste de modèles explicite.
| Groupe | Couvre |
|---|---|
crm | Pistes et opportunités |
ventes | Devis et commandes |
facturation | Factures, avoirs, paiements |
achats | Commandes fournisseur |
stock | Mouvements, transferts, inventaire |
support | Tickets |
rh | Employés, congés, notes de frais |
communication | Messages, activités, canaux |
Chaque groupe embarque aussi les modèles en lecture seule dont il dépend : accorder l'écriture sur les commandes donne la lecture des clients et des produits, sans jamais permettre de les modifier.
Pour un agent au périmètre étroit, préférez une liste de modèles explicite : c'est plus long à régler, et nettement plus sûr.
Les opérations
| Opération | Ce qu'elle autorise |
|---|---|
query | Chercher des enregistrements |
read | Lire des enregistrements connus |
report | Calculer des agrégats |
print | Générer un PDF |
create | Créer |
write | Modifier |
workflow | Déclencher une action métier Odoo |
execute | Appeler une méthode Odoo |
La suppression n'existe pas
delete est absent de cette liste, et pas par oubli : aucun agent ne peut supprimer un enregistrement, quelle que soit sa configuration. Pour retirer un enregistrement de la circulation, un agent doit l'archiver via write.
Les conditions de valeurs
C'est le réglage qui transforme une permission large en permission sûre.
Une condition porte sur un champ et s'applique avant l'écriture. Aidoo relit l'enregistrement concerné et vérifie la condition sur son état réel, pas sur ce que l'agent affirme.
| Condition | Effet |
|---|---|
amount_total < 5000 | L'agent ne touche pas aux grosses affaires |
state != posted | Il ne modifie jamais une facture comptabilisée |
user_id = <un commercial> | Il reste sur le portefeuille d'une personne |
En cas de doute, l'appel est refusé
Si Aidoo ne parvient pas à vérifier une condition, faute d'avoir pu relire l'enregistrement par exemple, l'appel est bloqué. Le moteur échoue systématiquement du côté du refus.
Le mode workflows uniquement
Le réglage le plus restrictif : l'agent ne peut appeler aucun outil Odoo directement, seulement exécuter des workflows enregistrés que vous avez validés.
Il agit alors strictement dans le cadre de séquences que vous avez écrites et approuvées. Vous perdez en souplesse ce que vous gagnez en prévisibilité. C'est le bon réglage pour un agent qui touche à la comptabilité.
Les garde-fous automatiques
Ils ne se règlent pas au cas par cas : ils protègent tous les agents en permanence.
Contrôle Odoo avant tout appel au modèle d'IA. Si votre Odoo est injoignable, l'exécution s'arrête immédiatement, avant qu'un seul jeton ne soit consommé. Après plusieurs tentatives, l'agent se met en pause.
Pause automatique. Après N échecs consécutifs, ou au-delà d'un seuil d'écritures par exécution, l'agent se met en pause et vous notifie plutôt que d'insister.
Interrupteur général. Un bouton met en pause tous les agents de l'espace de travail d'un coup. Utile pendant une migration Odoo ou un incident.
Blocage souple des crédits. À épuisement du pool, les exécutions sont mises en file d'attente, pas perdues. Elles repartent au réapprovisionnement.
Journal infalsifiable. Chaque étape est écrite au fil de l'exécution et ne peut plus être modifiée. Les paramètres sensibles y sont masqués.
Les outils extérieurs à Odoo
Un agent peut aussi agir hors d'Odoo : publier dans Slack, envoyer un e-mail, écrire dans Notion. Deux sources, cinq applications par agent au maximum.
La banque d'applications. Plus de 1 000 services connectables en quelques clics depuis la page Intégrations, avec l'authentification gérée pour vous.
Vos propres serveurs MCP. Si vous exposez déjà des outils internes en MCP, déclarez-les avec leur authentification (en-tête statique ou OAuth). Les secrets sont chiffrés par espace de travail.
Le détail de la connexion, du catalogue et du réglage des permissions est dans Intégrations et outils externes.
Restreignez la liste des outils
Pour chaque application, n'activez que les deux ou trois outils réellement utiles. Sans cette restriction, tout le catalogue de l'application est chargé à chaque tour de conversation, ce qui gonfle la consommation de crédits sans rien apporter.
L'écriture vers un service externe est gouvernée par un interrupteur distinct : par défaut, un agent ne fait que lire. Et le contenu qui revient d'un service tiers est traité comme non fiable, exactement comme les données Odoo.
L'accès web
Deux outils facultatifs, réservés aux agents et jamais exposés à Claude ou ChatGPT : une recherche web et une lecture de page. Désactivés par défaut.
Utile pour un agent qui doit vérifier une information publique, par exemple l'existence d'une société avant de qualifier un lead. Les résultats sont tronqués pour ne pas faire exploser le budget de jetons, et les adresses internes sont bloquées.
Une méthode de réglage qui fonctionne
Commencez en lecture seule
Première semaine : uniquement query, read et report. L'agent produit ses analyses, vous constatez qu'il vise juste.
Ajoutez l'écriture la moins risquée
En général create sur mail.activity : l'agent planifie des relances sans rien modifier d'existant.
Ouvrez la modification, avec des conditions
write sur un modèle précis, borné par une condition de valeur. Jamais write sur un groupe entier sans condition.
Gardez le plafond d'écritures serré
Cinq écritures par exécution suffisent à la plupart des missions. Relevez-le seulement quand un cas légitime le dépasse.
Étape suivante
- Crédits et consommation : ce que coûte chaque exécution
- Bonnes pratiques et dépannage : diagnostiquer un agent bloqué