Agents

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, read
Périmètre : modèle mail.activity
Opérations : query, read, create
Périmètre : modèle sale.order
Opérations : query, read, write
Condition : amount_total < 5000

Un 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.

GroupeCouvre
crmPistes et opportunités
ventesDevis et commandes
facturationFactures, avoirs, paiements
achatsCommandes fournisseur
stockMouvements, transferts, inventaire
supportTickets
rhEmployés, congés, notes de frais
communicationMessages, 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érationCe qu'elle autorise
queryChercher des enregistrements
readLire des enregistrements connus
reportCalculer des agrégats
printGénérer un PDF
createCréer
writeModifier
workflowDéclencher une action métier Odoo
executeAppeler 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.

ConditionEffet
amount_total < 5000L'agent ne touche pas aux grosses affaires
state != postedIl 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