Gouvernance d’un agent IA : ce qui compte plus que le prompt

Un agent IA tient dans une entreprise grâce à ce qui l’entoure : des règles écrites, des actions confirmées avant de partir, des outils limités à la tâche et une personne qui entretient l’ensemble. La consigne de départ compte, mais elle ne rend pas à elle seule le comportement prévisible d’une semaine à l’autre.

Le marché suit ce mouvement. Sur sa plateforme, Malt constate que les demandes de projets portant sur des agents IA ont été multipliées par 60 entre 2024 et 2025 (Malt Tech Trends 2026). Un article de Malt du 1er septembre 2026 décrit le passage du « prompt engineering » à une ingénierie de la gouvernance. Ces chiffres décrivent l’activité d’une plateforme, pas tout le marché français.

Qu’est-ce que la gouvernance d’un agent IA ?

La gouvernance d’un agent IA désigne les règles, les contrôles et les responsabilités qui encadrent ce qu’il peut lire, ce qu’il peut faire et ce qu’il doit demander. Elle tient en quatre pièces : des règles écrites qui priment sur les consignes du moment, des actions confirmées avant exécution, des outils limités à ce que la tâche demande, et un entretien régulier de la mémoire et de la machine.

Un contrôle se place hors du modèle

Une règle écrite dans le prompt reste une demande que le modèle interprète. Un contrôle placé dans le logiciel qui exécute l’action s’applique quelle que soit la réponse du modèle. C’est la différence entre écrire « ne jamais envoyer sans validation » et ne pas donner l’outil d’envoi.

Exemple fictif. Un agent prépare des relances de devis. Dans une première version, la consigne demande de ne rien envoyer : une formulation ambiguë d’une demande ultérieure peut suffire à la contourner. Dans une seconde version, l’agent n’a accès qu’à la lecture des messages et à la rédaction de brouillons. Il peut se tromper de ton ; il ne peut pas envoyer.

Dans TARS, les actions externes qui engagent demandent une confirmation avant exécution. C’est le fonctionnement par défaut de Hermes Agent, le logiciel open source de Nous Research sur lequel TARS est construit, et il vaut pour toutes les formules.

Comment TARS sépare la règle de la consigne

Dans TARS, chaque cas d’usage se règle en deux parties. La partie générique (sources choisies, heure de passage, plafonds) est validée par le moteur. La consigne libre, écrite par la personne, est recopiée après les règles, comme une citation : elle oriente le choix, l’ordre et le ton du résultat, mais elle ne lève aucun plafond et ne change pas le lieu de livraison.

Ce découpage protège aussi contre une erreur courante : une consigne qui « déborde » et finit par réécrire le fonctionnement prévu. Un champ laissé vide sur l’écran de réglage n’efface pas non plus ce que la personne avait déjà écrit dans ses fichiers.

Des outils bornés plutôt qu’un accès général

Les outils de recherche de l’agent TARS sont en lecture seule. Ils cherchent dans des sources déjà préparées, renvoient au plus 20 résultats par recherche et ne peuvent pas écrire dans la mémoire. Une boîte mail branchée par le protocole standard IMAP s’ouvre de la même façon : l’agent peut lister les dossiers, chercher et lire les messages ; l’envoi, la suppression et le déplacement de messages ne lui sont pas proposés.

Ce choix réduit ce qu’un agent peut faire de travers. Il ne remplace pas la vérification du résultat : un brouillon peut rester faux même quand il n’est jamais parti.

Une correction se range dans les règles

Exemple fictif. Un dirigeant corrige un brouillon : « nos devis mentionnent toujours le délai de livraison ». Si la correction reste dans la conversation, elle disparaît avec elle. Si elle est enregistrée dans les règles, avec sa date, elle s’applique au devis suivant et peut être relue.

La même logique vaut pour une information devenue fausse. L’article sur la correction d’une information périmée détaille comment la retrouver et la remplacer.

Qui entretient le dispositif

Une gouvernance qui n’est pas entretenue se dégrade : un processus change, un accès expire, une mise à jour du modèle modifie un comportement. Dans l’abonnement TARS, l’entretien de la mémoire de l’agent est réalisé par l’exploitant : liens entre les notes, contrôle de ce qui s’y écrit, accompagnement des mises à jour. La surveillance de la machine en fait partie : je suis prévenu quand un composant s’arrête et je remets le service en route.

Une limite à connaître : la relecture des messages que l’agent rédige pour vos clients n’est pas comprise. Ce qui part sous votre signature reste votre décision ; l’exploitation porte sur la machine, pas sur les sorties.

Par où commencer

1. Lister les actions qu’un premier usage demande, puis les classer : lecture, préparation, action externe.
2. Retirer de l’agent tout outil qu’aucune de ces actions n’utilise.
3. Écrire les règles et au moins un cas où l’agent doit s’arrêter.
4. Tester sur cinq dossiers, dont un qui doit être refusé.

Le guide pour choisir une première tâche aide à délimiter ce premier usage. Pour l’appliquer à votre activité, écrivez-moi avec la tâche visée et les outils concernés : je vous dirai si TARS couvre ce périmètre et quels contrôles il demande.