Le harnais d’un agent IA : un cadre pour ce qu’un agent peut voir, faire et prouver

L’essentiel d’un agent IA n’est pas le modèle. Le modèle propose l’étape suivante. Tout ce qui l’entoure décide de ce que l’agent peut voir, des outils qu’il peut appeler, de ce qu’il peut modifier, du moment où il doit s’arrêter, de ce qui est enregistré et de qui accepte le résultat. Ce système qui l’entoure, c’est le harnais de l’agent (en anglais, agent harness).

Deux équipes peuvent utiliser le même modèle et obtenir des agents très différents. L’une peut lire une file de support et rédiger des réponses qu’une personne relit. L’autre peut envoyer des e-mails et modifier des fiches clients seule. La différence ne tient pas à l’intelligence. Elle tient au harnais.

Ce cadre décrit les neuf couches d’un harnais, le contrôle minimal dont chacune a besoin et la défaillance qu’elle évite. Il rassemble ce que nous avons publié séparément sur les habilitations, la sécurité, les validations, le contexte de production et l’évaluation, et montre où chaque élément se place dans l’ensemble. Quand l’une des quatre automatisations qu’IZZY exploite pour ses clients illustre une couche, nous l’utilisons. Quand aucune ne le fait, nous le disons.

La réponse en 60 secondes

• Le harnais d’un agent, c’est tout ce qui entoure le modèle : contrat de tâche, contexte, outils, autorité, boucle d’exécution, état, transmissions, vérification et observation.
• Concevez-le couche par couche. Chaque couche répond à une question et exige au moins un contrôle que l’agent ne peut pas désactiver.
• L’autorité est accordée, jamais déduite d’un objectif, d’un document ou du message d’un autre agent.
• Gardez hors du modèle le journal de ce qui a été proposé, tenté et confirmé.
• L’agent peut vérifier son propre travail. Il ne peut pas l’accepter : l’acceptation repose sur des critères fixés avant le travail et sur des contrôles qu’il ne peut pas affaiblir.
• Dimensionnez le harnais selon la conséquence. Un brouillon à relire exige bien moins qu’une action qui déplace de l’argent.
• Revérifiez le harnais quand le modèle, un outil, une source de données ou la nature du travail change.

Dans cet article

1. Le modèle n’est pas l’agent
2. Les couches qui décident de ce que l’agent peut faire
3. Les couches qui gardent l’exécution sous contrôle
4. Les couches qui prouvent le travail
5. Dix règles valables dans chaque couche
6. Dimensionner le harnais selon le travail

1. Le modèle n’est pas l’agent

Un agent est un logiciel qui choisit des étapes et utilise des outils pour accomplir une tâche. Le modèle fournit les choix. Le harnais fournit tout ce qui permet d’agir sur ces choix en sécurité.

1  contrat de tâche     quel résultat, pour qui, jugé comment
2  contexte             ce que l’agent peut voir
3  outils               ce qu’il peut appeler, et où la limite est appliquée
4  autorité             ce qu’il peut modifier, et avec quelle validation
          ┌──────────────────────┐
          │        modèle        │   propose l’étape suivante
          └──────────────────────┘
5  boucle d’exécution   budgets, conditions d’arrêt, interruption
6  état et journal      ce qui a été proposé, tenté et confirmé
7  transmissions        ce qui passe d’une étape ou d’un agent à l’autre
8  vérification         qui accepte le résultat, et selon quoi
9  observation          ce qu’on apprend, et ce qui change

L’orchestration est une autre question. Elle décide comment les étapes et les agents s’enchaînent : chaîne fixe, routage, contrôles en parallèle. Le harnais décide de ce qui entoure chacun d’eux.

Les mêmes couches s’appliquent à un workflow fixe comportant des étapes de modèle. Retirer l’autonomie supprime certains risques ; cela ne supprime pas le besoin d’autorité, d’état et de contrôles. Aucune des quatre automatisations qu’IZZY exploite en production n’est un agent livré à lui-même. Ce sont des workflows dans lesquels des modèles lisent, extraient, comparent et rédigent. Elles montrent pourtant chaque couche à l’œuvre, et c’est pourquoi nous les utilisons ci-dessous.

2. Les couches qui décident de ce que l’agent peut faire

Couche 1 : le contrat de tâche

Fixez le résultat attendu, le responsable, les actions autorisées et la façon de reconnaître un résultat acceptable, avant que le travail commence. Le niveau de détail dépend de la tâche : une ligne pour une synthèse interne, un contrat complet pour une action qui touche des clients.

Contrôle minimal : les critères d’acceptation existent avant l’exécution. Une personne habilitée peut les réviser explicitement au fil de la tâche ; personne ne les ajuste en silence pour qu’ils collent au résultat.

Défaillance évitée : un résultat assuré qui répond à une autre question, jugé selon des critères reconstruits à partir de ce même résultat.

En pratique : dans le reporting Search Console hebdomadaire qu’IZZY exploite après la migration du site d’un client, le brief de reporting fixe les règles et la structure attendue avant qu’un modèle rédige une seule ligne.

Pour aller plus loin : choisir son premier projet IA et le contrat de résultat dans construire une application ChatGPT qui résiste à une vraie action client.

Couche 2 : le contexte

Décidez de ce que l’agent voit, et de la nature de chaque entrée.

Les instructions arrivent par un canal de contrôle autorisé. Tout le reste - documents, e-mails, pages web, réponses d’outils, message d’un autre agent - est de la matière traitée. Cette matière peut déterminer laquelle des actions déjà autorisées s’applique. Elle ne peut pas créer une nouvelle habilitation. Une note ajoutée à la mémoire ne modifie pas les instructions permanentes et n’élargit pas les accès.

Le contexte est aussi une décision de divulgation. Envoyer les données d’un dossier à un fournisseur de modèle les divulgue à ce fournisseur : l’accès aux données et leur transmission relèvent donc de la décision d’autorité. Une information issue d’un dossier ou d’un client n’est pas réutilisée pour un autre simplement parce qu’elle est disponible.

Contrôle minimal : contenu non fiable séparé des instructions, cloisonnement entre dossiers et entre clients, et décision explicite sur ce qui peut partir vers chaque service de modèle.

Défaillance évitée : instructions injectées, fuite d’un client à l’autre et fenêtre de contexte remplie de preuves que l’agent n’aurait jamais dû voir.

En pratique : dans le workflow de préscreening de startups d’IZZY, collecter n’est pas vérifier. Le workflow conserve la source, la date et le contexte de chaque élément au lieu de réduire tout ce qu’il a rassemblé à une conclusion.

Pour aller plus loin : le contexte de production pour les agents de code, le RAG sécurisé et les habilitations et les voies d’attaque décrites dans la sécurité des agents IA.

Couche 3 : les outils et la frontière d’application

Définissez la surface de capacités : quels outils existent, ce que chacun peut lire ou modifier, et où sa limite est appliquée.

Le droit de lire n’implique pas le droit d’écrire. Le droit de rédiger n’implique pas le droit d’envoyer. Séparez les outils de lecture des outils d’écriture, donnez à chacun une finalité étroite et des identifiants stables, et renvoyez des états d’erreur explicites plutôt que de laisser le modèle improviser autour d’un échec.

La question décisive est l’endroit où se trouve la frontière. Une règle dans un prompt ou une skill est une demande que le modèle peut mal interpréter. Un contrôle d’habilitation dans le serveur, un proxy ou le système cible est un contrôle. Là où dépasser une limite peut causer un dommage réel, placez le contrôle là où le modèle ne peut pas l’ignorer.

Contrôle minimal : chaque limite à conséquences appliquée hors du modèle.

Défaillance évitée : un agent « en lecture seule » qui peut écrire, parce que seul le prompt disait le contraire.

Pour aller plus loin : MCP, skills ou CLI : placer la limite de sécurité là où le modèle ne peut pas l’ignorer et le registre des contrats d’outils dans construire une application ChatGPT.

Couche 4 : l’autorité

Décidez de ce que l’agent peut modifier, dans quel mode et avec quelle validation.

L’autorité est accordée, pas déduite. Un objectif utile, une demande dans un document ou le message d’un autre agent n’accordent rien. L’agent ne peut ni élargir ses propres habilitations ni modifier les contrôles qui jugent son travail.

Ces modes décrivent une politique. Ce n’est pas une échelle que chaque action devrait gravir, et certaines actions ne devraient jamais quitter les premières lignes.

La validation porte sur une action identifiable et ses paramètres : le destinataire, le montant, la fiche, le texte. Si l’un d’eux change, la validation est réexaminée. Exécuter une action déjà validée n’équivaut pas non plus à accepter son résultat ; c’est la couche 8.

Choisissez le mode selon la conséquence : qui pourrait être touché, jusqu’où une erreur pourrait se répéter et si son effet est réversible. Une revue après coup ne peut pas annuler un effet irréversible : ces actions exigent un contrôle avant exécution ou restent entre les mains d’une personne. Le coût permet de choisir entre des garde-fous suffisants, pas de supprimer un garde-fou nécessaire. Si aucun contrôle suffisant n’est abordable, réduisez le périmètre ou ne déléguez pas l’action.

En pratique : le framework de publication de contenu d’IZZY fonctionne en deux modes. En mode proposition, l’utilisateur accepte ou corrige la façon dont le système a compris, structuré et enrichi l’article. En mode exécution, les transformations acceptées, le paquet final et la publication s’enchaînent automatiquement. L’unité de validation est la décision éditoriale, pas chaque redimensionnement d’image.

Pour aller plus loin : gérer les accès et autorisations des agents IA et quand l’IA doit répondre, rédiger, demander une validation ou exécuter.

3. Les couches qui gardent l’exécution sous contrôle

Couche 5 : la boucle d’exécution

Bornez l’exécution : étapes, relances, durée, coût et nombre d’enregistrements qu’elle peut toucher. Définissez les conditions d’arrêt avant la première exécution.

Quand une information ou un garde-fou nécessaire manque, l’agent ne devine pas. La politique dit s’il fait une pause, applique une solution de repli autorisée ou transmet le dossier à une personne.

Une interruption doit laisser un état connu : ce qui est terminé, ce qui est en attente et ce qui reste incertain. Si un arrêt brutal peut lui-même causer un dommage, définissez une transition sûre. Le moyen de restreindre ou de retirer l’autorité ne doit pas dépendre de l’accord de l’agent pour s’arrêter.

Contrôle minimal : des budgets et un arrêt placés hors de l’agent.

Défaillance évitée : boucles sans fin, coûts en cascade et agent qui « termine » une tâche en inventant ce qui lui manquait.

En pratique : quand un élément obligatoire manque dans un article, le framework de publication d’IZZY bloque la validation. Il ne comble pas le vide avec quelque chose de plausible.

Pour aller plus loin : les cascades et boucles incontrôlées dans la sécurité des agents IA.

Couche 6 : l’état et le journal

Gardez le dossier hors du modèle : entrées, constats, décisions, validations et effets.

Chaque action a trois états : proposée, tentée et confirmée. Un délai dépassé après une demande d’écriture n’est pas un échec. C’est un résultat inconnu. Vérifiez le système cible avant de relancer, utilisez une référence unique et sa protection contre les doublons, et arrêtez-vous pour revue si l’effet reste incertain.

Le récit que fait l’agent de ce qu’il a fait est enregistré comme une déclaration. Il ne peut pas réécrire les preuves qui servent à le juger. Son explication de la raison d’une action est une piste à vérifier, pas la preuve de sa cause : des travaux de recherche ont montré que les explications d’un modèle peuvent travestir les vraies raisons d’une réponse.

Enregistrez de quoi reconstituer les événements, et pas davantage. Réduisez au minimum les données sensibles, tenez les secrets à l’écart et définissez accès et durées de conservation selon l’usage.

Contrôle minimal : un journal protégé, tenu par le workflow et non par le modèle.

Défaillance évitée : actions en double après une relance, annonces de réussite sans effet confirmé et piste d’audit modifiée par l’agent.

En pratique : dans le funnel d’acquisition qu’IZZY a construit avec Notion et n8n, chaque action dépend d’un état exploitable unique. Notion fournit la vue opérationnelle, n8n déplace les événements et applique les règles, le paiement confirme l’état commercial, et une personne corrige cet état quand un remboursement l’exige.

Pour aller plus loin : transformer les notes de réunion en tâches avec n8n sans doublons et la matrice des cas difficiles dans construire une application ChatGPT.

Couche 7 : les transmissions

Encadrez ce qui passe d’une étape ou d’un agent à l’autre.

Les habilitations ne grandissent pas lors d’une transmission. L’émetteur doit être autorisé à déléguer le travail ; le destinataire agit dans les limites de sa propre autorité. Consignez la source et le statut de chaque transmission, appliquez les contrôles requis à chaque frontière et jugez le résultat d’ensemble. Accepter chaque étape ne prouve pas que la tâche entière a atteint son but.

Commencez avec un seul agent. Ne découpez le travail que si certaines parties exigent des accès différents, ou si un même jeu d’instructions devient trop complexe pour être suivi de façon fiable. Un intitulé de poste différent n’est pas une raison d’ajouter un agent.

Contrôle minimal : chaque destinataire travaille avec ses propres habilitations, quoi que l’émetteur puisse faire.

Défaillance évitée : le blanchiment d’autorité, quand une étape peu habilitée demande à une étape très habilitée d’agir à sa place.

En pratique : dans le workflow de préscreening, des modèles différents prennent en charge la collecte par source, l’extraction des documents, la structuration et l’évaluation, et se transmettent un travail structuré d’une étape à l’autre. Ils ne votent pas. L’actif, c’est l’interface entre les étapes : ce que chacune reçoit, ce qu’elle doit renvoyer et quelles preuves doivent survivre.

4. Les couches qui prouvent le travail

Couche 8 : la vérification et l’acceptation

Décidez si le résultat peut être accepté. Posez quatre questions distinctes :

L’autocontrôle est permis et utile. L’acceptation est autre chose. Elle repose sur des contrôles que l’agent ne peut ni lever ni affaiblir, avec des preuves ou une méthode qui vont au-delà de sa propre assurance. Un test écrit par l’agent ne devient pas indépendant parce qu’il passe. Cherchez aussi les erreurs partagées, comme une spécification erronée utilisée à la fois par le producteur et par le relecteur.

Distinguez deux types de contrôles. Les contrôles avant exécution ou usage décident si une action ou une production peut continuer : autorité, format, limites, destinataires, sensibilité des données. Les contrôles du résultat établissent ce qui s’est passé et si cela a fonctionné : effets confirmés, comparaison aux sources, mesure, évaluation humaine. L’échantillonnage peut convenir au second type. Il ne remplace jamais un contrôle qui doit avoir lieu avant le dommage.

L’incertitude doit survivre au contrôle. Dans le workflow de préscreening, chaque question reçoit la réponse oui, non ou possible. « Possible » signifie que le dossier ne justifie pas encore une conclusion binaire, et oriente la question vers davantage de preuves ou vers une personne.

Contrôle minimal : critères et contrôles d’acceptation maîtrisés hors de l’agent qui produit.

Défaillance évitée : un travail accepté parce qu’il a l’air terminé et que l’agent l’a dit.

En pratique : les rapports Search Console d’IZZY sont produits automatiquement ; leur livraison ne l’est pas. Un spécialiste SEO lit, simplifie et valide chaque rapport avant qu’il parte chez le client, ce qui prend 15 à 25 minutes dans la plupart des cas.

Pour aller plus loin : tester fraîcheur, RAG, pannes et valeur métier d’une mémoire opérationnelle.

Couche 9 : l’observation et le changement

Transformez ce qui se passe en décisions.

Examinez les erreurs, exceptions, tentatives bloquées et résultats non résolus, pas seulement les réussites, à une fréquence proportionnée à la conséquence. Chaque incident se termine par une décision consignée : modifier un contrôle, réparer le travail, traiter une cause externe ou expliquer pourquoi la réponse existante suffisait. Un refus injustifié est aussi une défaillance. Jugez-le séparément d’un arrêt justifié, et ne jugez pas l’agent au nombre de tâches terminées ou à un taux d’erreur global.

Réévaluez le harnais quand un modèle, un outil, une instruction, une source de données ou la nature du travail change d’une manière qui pourrait modifier ce que fait l’agent. La réussite d’une action ne justifie pas d’accorder une autre habilitation.

Contrôle minimal : un responsable nommé qui examine les résultats et peut modifier les contrôles, le périmètre ou l’autonomie.

Défaillance évitée : un harnais juste au lancement et discrètement faux six mois plus tard.

En pratique : la première faiblesse relevée dans les rapports Search Console n’était pas un faux signal. Certaines versions en disaient trop, de façon trop dense. Ce retour a changé la question de qualité : les rapports devaient hiérarchiser et condenser, pas seulement détecter des variations.

Pour aller plus loin : la checklist pour passer du pilote IA à la production.

5. Dix règles valables dans chaque couche

Les couches disent où construire. Ces règles disent ce qui doit rester vrai dans chacune d’elles.

1. Définir la délégation avant le travail : le résultat, le responsable, les actions autorisées et la façon de reconnaître la réussite. (Couche 1)
2. L’autorité est accordée, pas déduite. Aucun objectif, document ou message ne l’étend, et l’agent ne peut pas modifier ses propres contrôles. (Couches 2 à 4)
3. Proportionner la liberté à la conséquence : dommage, portée, réversibilité, incertitude et échelle, y compris le coût de ne pas agir. (Couche 4)
4. Traiter les limites explicitement. Faire une pause, se replier ou transmettre ; ne jamais inventer une habilitation ni deviner à la place d’une information manquante. (Couche 5)
5. Rendre les actions traçables comme proposées, tentées ou confirmées, avec qui a agi, sous quelle autorité et sur quoi. (Couche 6)
6. Protéger le journal contre l’agent qu’il sert à juger. (Couche 6)
7. Transformer les observations en décisions, y compris pour les refus injustifiés. (Couche 9)
8. Juger la finalité, les preuves et la couverture, pas l’apparence ni une déclaration d’achèvement. (Couche 8)
9. Séparer l’autocontrôle de l’acceptation. (Couche 8)
10. Préserver tout cela à travers les transmissions et les changements. (Couches 7 et 9)

Chaque règle est un principe. Un usage donné la traduit en politique et en mécanisme :

Une instruction écrite exprime une politique. Elle ne l’applique pas.

6. Dimensionner le harnais selon le travail

Tous les agents n’ont pas besoin de tous les contrôles à pleine puissance. Partez de la conséquence de l’action, pas de la sophistication du modèle.

Les couches se lisent différemment selon le domaine :

• Développement logiciel : quels changements sont autorisés, quels tests que l’agent n’a pas écrits établissent l’exactitude, et qui autorise les effets sur les utilisateurs ou les systèmes en production.
• Contenu : ce qui étaye chaque affirmation, ce qui rend le contenu utile et quelles habilitations encadrent la publication.
• Processus administratifs : comment les dossiers sont rapprochés, comment les exceptions sont traitées et qui autorise les engagements externes.

Les activités réglementées - juridiques, médicales ou agissant sur des systèmes physiques - exigent leur propre évaluation des obligations, des compétences et des limites de fonctionnement sûres. Ce cadre n’en établit aucune.

Enfin, le harnais le plus léger est souvent le bon. Si une automatisation déterministe peut faire le travail de façon fiable, elle est plus facile à tester, à expliquer et à maintenir qu’un agent. La choisir est aussi une décision de harnais.

Conclusion : construire le harnais, puis choisir le modèle

Les modèles vont continuer de changer. Les questions auxquelles répond le harnais ne changeront pas : ce que l’agent peut voir, ce qu’il peut faire, comment son exécution est bornée, ce qui est enregistré et qui accepte le résultat.

Concevez ces neuf couches délibérément, placez chaque limite à conséquences là où le modèle ne peut pas l’ignorer, et laissez les preuves, pas une démo, décider du moment où l’agent mérite plus d’autonomie.

Questions fréquentes

Sources et limites

• Les exemples IZZY proviennent des descriptions publiées de quatre automatisations qu’IZZY exploite pour ses clients : un funnel d’acquisition, un workflow de préscreening de startups, un framework de publication de contenu et un reporting Search Console post-migration. Ce sont des workflows avec des étapes de modèle, pas des agents autonomes, et aucune nouvelle mesure n’a été réalisée pour cet article.
• Saltzer et Schroeder, 1975 : moindre privilège, refus d’accès par défaut et médiation complète des accès.
• OpenAI, Practices for Governing Agentic AI Systems, 2023 : pratiques proposées pour limiter, observer et garder le contrôle des systèmes agentiques.
• Google, An Introduction to Google’s Approach for Secure AI Agents, 2025 : contrôleurs humains, pouvoirs limités, activité observable et défenses en couches.
• Turpin et al., 2023 : les explications pas à pas (chain-of-thought) peuvent travestir les raisons de la réponse d’un modèle.
• Microsoft, taxonomie des modes de défaillance des agents IA, 2025 : menaces propres aux agents et atténuations possibles.

Les neuf couches et les dix règles sont une synthèse d’IZZY. Ces sources appuient des points de départ précis, pas l’efficacité ni l’exhaustivité du cadre. Il ne revendique aucun taux d’erreur universel et n’établit ni autorisation légale, ni compétence professionnelle, ni certification de sécurité ; les obligations existantes doivent être vérifiées pour chaque déploiement. Sources vérifiées le 5 octobre 2026.