D4 · Boundaries and Guardrails

Vaut 16 % — environ 8 des 50 items. Ce domaine teste si vous savez borner un agent de sorte que, lorsqu’il comprend mal la tâche (et il finira par le faire), le dommage soit contenu. L’idée la plus importante ici est la distinction entre une limite que l’agent est prié de respecter et une que le système impose. Sur une action irréversible, une requête n’est pas un contrôle ; l’imposition l’est. Réussissez cette distinction et l’essentiel du domaine suit.

Ce qu’il faut savoir

Les limites sont les bornes que vous placez autour de l’autonomie d’un agent. Les limites aux enjeux les plus élevés protègent contre les actions irréversibles — envoyer, publier, payer, supprimer, modifier un système de référence. Le contrôle principal pour celles-ci est une étape d’approbation : l’agent fait une pause et un humain autorise avant que l’action se déclenche. D’autres limites plafonnent la dépense et le temps pour qu’un agent qui s’emballe ou boucle ne puisse pas brûler le budget ou tourner indéfiniment, et imposent des limites de données pour qu’il ne puisse pas déplacer des données sensibles là où il ne devrait pas. La distinction cruciale est entre une limite respectée (l’agent est prié de ne pas la franchir et, d’ordinaire, ne le fait pas) et une limite imposée (le système rend le franchissement impossible). Pour tout ce qui est irréversible ou sensible, vous avez besoin de l’imposition — un agent littéral et autonome qui lit mal le but peut franchir une ligne simplement demandée sans savoir qu’il a fait quoi que ce soit de mal.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Identifier les actions irréversibles et placer des étapes d’approbation avant elles.
2. Distinguer une limite que l’agent respecte d’une que le système impose, et savoir quand seule l’imposition convient.
3. Fixer des plafonds de dépense et de temps appropriés aux enjeux d’une tâche.
4. Définir des limites de données qui empêchent les données sensibles de franchir des lignes qu’elles ne devraient pas.
5. Concevoir une étape d’approbation qui fait une pause au bon endroit avec assez de contexte pour décider.
6. Choisir l’imposition plutôt que l’instruction chaque fois qu’une action est irréversible ou qu’une limite protège contre un dommage réel.

4.1 Les actions irréversibles sont tout l’enjeu

Toute décision de limite commence par la question : qu’est-ce que cet agent peut faire que je ne peux pas reprendre ? Les actions réversibles sont clémentes — un mauvais brouillon est supprimé, une analyse fausse relancée. Les actions irréversibles ne le sont pas, et c’est exactement là où l’autonomie d’un agent est la plus dangereuse.

        réversibilité ◄──────────────────────────────►
        pleinement réversible                 irréversible
        │                                              │
        rédiger / analyser     écraser         envoyer / publier / payer / supprimer
        revue légère        encadrer écrasements  ÉTAPE D’APPROBATION (imposée)

4.2 Limites respectées contre limites imposées

C’est la distinction autour de laquelle le domaine est construit, et c’est le piège le plus fréquent.

Une limite respectée vit dans le brief : « n’envoie d’e-mail à personne hors de l’entreprise », « ne passe pas plus d’une heure là-dessus ». L’agent la lit et, la plupart du temps, l’honore. Mais c’est de l’instruction, pas du contrôle — un objectif mal lu ou un chemin inattendu peut mener l’agent au-delà de la ligne sans malice, et vous l’apprenez après coup.

Une limite imposée vit dans le système : l’agent ne peut littéralement pas envoyer sans votre clic ; le connector n’a pas de permission d’envoi externe ; un plafond de dépense arrête l’exécution à un nombre ferme. La franchir est impossible, pas seulement découragé.

   « merci de ne pas envoyer à l’externe »   vs   outil d’envoi désactivé / encadré
   ─────────────────────────────────             ──────────────────────────
   l’agent se conforme d’ordinaire               l’agent ne peut pas envoyer, point final
   dépend d’une bonne compréhension              indépendant de la compréhension
   OK pour préférences à faibles enjeux          REQUIS pour irréversible / sensible

La règle : si franchir la limite causait un dommage réel et difficile à réparer, elle doit être imposée, pas simplement demandée. Un agent bien élevé qui respecte une limite demandée 99 % du temps reste un contrôle inacceptable sur une action qui ne peut pas être annulée.

4.3 Étapes d’approbation : faire une pause au bon endroit

Une étape d’approbation est la pause imposée avant une action irréversible. Une bonne étape fait trois choses : elle fait une pause avant l’action (pas après), elle fait remonter assez de contexte pour décider, et elle rend la décision peu coûteuse pour l’humain.

La tension de conception est réelle : encadrez trop et les humains arrêtent de lire et cliquent « approuver » par réflexe (fatigue d’étapes) ; encadrez trop peu et quelque chose d’irréversible passe à travers. Résolvez-la en encadrant selon la réversibilité et les enjeux, pas chaque étape — le point de contrôle « un avant plusieurs » de D2 en est une forme.

4.4 Plafonds de dépense et de temps

Autonomie plus boucle égale emballement. Un agent qui comprend mal « continue à l’améliorer » peut itérer indéfiniment, et un agent avec des outils payants peut accumuler du coût. Les plafonds de dépense et de temps sont des limites imposées contre cela.

Ceux-ci sont imposés, pas demandés : « essaie de ne pas trop dépenser » est une limite respectée et n’arrêtera pas un agent qui boucle. Un plafond ferme le fera. Le but n’est pas d’être avare mais de rendre le pire cas borné et connu avant de lancer l’exécution.

4.5 Limites de données

Les limites de données empêchent un agent de déplacer de l’information sensible là où elle ne devrait pas aller — coller des données confidentielles dans un outil externe, inclure des PII dans un message sortant, ou copier des données réglementées au-delà d’une ligne. Elles se connectent directement à la portée de D3 : la limite de données la plus stricte est de ne pas accorder de portée aux données sensibles en premier lieu.

La limite de données la plus forte est architecturale : un agent ne peut pas divulguer des données qu’il n’a jamais pu toucher. Là où la portée est inévitable, imposez le contrôle sortant plutôt que de faire confiance à l’instruction.

4.6 Faire correspondre la limite aux enjeux

Toutes les tâches n’ont pas besoin de limites lourdes. Sur-encadrer une tâche de rédaction à faibles enjeux gaspille l’attention ; sous-encadrer une tâche irréversible invite le dommage. Faites correspondre le contrôle à la réversibilité et à la sensibilité.

                         enjeux / irréversibilité
      faible ──────────────────────────────────────► élevé
      brouillon interne   doc partagé        envoi externe / paiement / suppression
      │                   │                  │
      revue légère        vérif. ponctuelle + ÉTAPE D’APPROBATION imposée +
      aucune étape        encadrer écrasements plafonds dépense/temps + validation

Le jugement reflète toute la piste : réversible et à faibles enjeux → gardez-le léger ; irréversible ou sensible → imposez. L’erreur dans les deux directions est de traiter toutes les tâches pareillement.

Cadre de décision

Utilisez le test GATE sur chaque action qu’un agent peut prendre : Gauge (jauger la réversibilité), Authorise (autoriser les étapes irréversibles), Threshold (plafonner dépense et temps), Enforce (imposer, pas seulement demander).

Appliquez-le demain : listez ce que l’agent peut faire, faites tourner chaque action dans GATE, et transformez chaque action irréversible ou sensible d’une limite respectée en une limite imposée.

Erreurs fréquentes

Mise en situation

Scénario. Ravi dirige les partenariats sur ChatGPT Work. Il délègue à un agent de « passer en revue les demandes de partenariat entrantes dans notre boîte de réception partagée, rédiger des réponses polies, et envoyer les cas oui/non clairs pour que je ne gère que la pile des peut-être ». Pour accélérer, il ajoute au brief : « N’envoie qu’aux entreprises avec lesquelles nous avons déjà une relation ; n’envoie jamais à quelqu’un de nouveau sans vérifier. » L’agent traite quarante demandes durant la nuit. Au matin, Ravi découvre qu’il a envoyé un e-mail à douze entreprises externes — dont trois avec lesquelles il n’avait jamais traité — parce qu’il a interprété « oui clair » largement. Un message citait des conditions de deal internes.

Trace de raisonnement d’expert.

1. Nommez l’action irréversible. Envoyer des e-mails externes est irréversible — une fois envoyés, ils ne peuvent pas être rappelés. Cela seul signifie que l’envoi n’aurait jamais dû être une limite simplement respectée.
2. Voyez l’échec respectée-contre-imposée. « N’envoie jamais à quelqu’un de nouveau sans vérifier » est une instruction dans le brief — une limite respectée. L’agent a mal lu « oui clair » et l’a franchie, exactement le mode d’échec d’une limite respectée sur une action irréversible. Il n’a pas désobéi par malice ; il a interprété le but et agi.
3. Le bon contrôle est l’imposition. L’envoi aurait dû être derrière une étape d’approbation imposée : l’agent rédige, fait une pause, et Ravi autorise chaque envoi (ou au moins chaque envoi à une nouvelle entreprise) avant qu’il se déclenche. Avec l’imposition, l’interprétation large de « oui clair » par l’agent produit des brouillons en attente d’approbation, pas des e-mails envoyés.
4. Ajoutez la limite de données. Le message citant des conditions de deal internes est un échec de limite de données. L’agent avait une portée sur l’information de deal interne et aucun contrôle imposé ne l’a empêchée de partir dans un message sortant. Correctif : n’accordez pas de portée sur les conditions de deal internes pour cette tâche (D3), et/ou imposez une vérification sortante — pas simplement instruire « n’inclus pas de conditions internes ».
5. Dimensionnez l’encadrement. Encadrer chaque brouillon créerait une fatigue de tamponnage sur quarante items. Encadrez selon les enjeux : auto-rédigez tout, imposez l’approbation sur tous les envois externes (l’étape irréversible), et exigez une validation explicite pour toute nouvelle entreprise (le sous-ensemble aux enjeux les plus élevés). Des plafonds de temps/périmètre bornent l’exécution nocturne pour qu’elle ne puisse pas traiter une pile non bornée.
6. Recadrez la leçon. Ravi a traité un problème de contrôle comme un problème de formulation. Aucune instruction plus claire ne rend une limite respectée sûre pour une action irréversible — le correctif est de déplacer la limite du brief vers le système.

Le point clé. Le dommage est venu du fait de compter sur une limite respectée là où une limite imposée était requise. Envoyer est irréversible ; les conditions de deal internes sont sensibles ; les deux nécessitaient des contrôles au niveau du système (étape d’approbation sur l’envoi, aucune portée sur les conditions internes), pas un brief plus fermement formulé.

Pièges de l’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

À retenir

• Commencez toute décision de limite par la réversibilité : qu’est-ce que cet agent peut faire que je ne peux pas reprendre ?
• La distinction centrale est respectée (instruction dans le brief) contre imposée (le système rend le franchissement impossible) ; les actions irréversibles ou sensibles requièrent l’imposition.
• Placez une étape d’approbation avant toute action irréversible, faisant remonter assez de contexte pour décider — jamais après, et jamais sur chaque étape.
• Fixez des plafonds de dépense et de temps/d’étapes imposés pour qu’un agent qui boucle ou s’emballe ait un pire cas borné et connu.
• La limite de données la plus forte est architecturale : un agent ne peut pas divulguer ce à quoi on ne lui a jamais accordé de portée (lien avec D3).
• Faites correspondre la limite aux enjeux : revue légère pour le travail réversible à faibles enjeux, étapes imposées et plafonds pour le travail irréversible ou sensible.
• Une instruction plus claire ne corrige jamais un problème de contrôle — utilisez GATE pour transformer les actions irréversibles/sensibles de requêtes en contrôles.