# L’autonomie a besoin de limites, d’un contrôle et d’une issue.

Combiner règles fermes, outils autorisés, confirmation, reprise et traces d’évaluation pour étendre l’autonomie avec des preuves.

Version 1.0 · 2026-07-29 · 10 min

## Réponse courte

Les garde-fous sont des contrôles du produit autour du modèle, pas de simples rappels dans son prompt. Commencez par des règles fermes sur l’accès aux données, les outils autorisés, les limites financières ou opérationnelles et les actions qui exigent toujours une personne. Le modèle ne reçoit que les choix compatibles avec l’état actuel. Les changements importants sont prévisualisés, confirmés dans le produit puis revérifiés au moment de l’exécution. Prévoyez les doublons, l’annulation et la reprise. Tracez les appels et l’état obtenu, puis n’élargissez l’autonomie que lorsque les évaluations et l’exploitation le justifient.

## À retenir

- Les limites fermes vivent dans le code, les droits et la liste des outils, pas dans une formulation persuasive.
- La confirmation n’a de valeur que si la personne voit l’effet proposé et peut encore l’annuler.
- L’évaluation examine les actions et l’état final, pas seulement le dernier message.

## L’autonomie utile est un choix produit, pas un réglage du modèle

Le même modèle peut répondre sur une procédure, préparer un ordre de travail ou envoyer une modification. Ces opérations n’ont pas les mêmes conséquences. Un seul bouton d’autonomie masque les différences importantes : périmètre des données, réversibilité, impact financier ou opérationnel et capacité à détecter l’échec.

Une conception fiable attribue l’autorité action par action. Le modèle peut évoluer librement dans un espace étroit et observable, tandis que le produit garde les limites, les identifiants et le chemin de reprise. Ajouter une capacité devient alors une extension contrôlée du produit, pas un prompt plus permissif.

## Un contrat d’autonomie en plusieurs couches

Chaque couche doit encore protéger le système lorsqu’une autre se trompe ou devient incertaine.

### 1. Classer le résultat

Séparer lecture, brouillon, proposition, exécution et effet irréversible. Indiquer qui porte la décision et quelles preuves sont nécessaires.

### 2. Fixer la limite ferme

Appliquer l’identité, le périmètre des données, les budgets, les invariants et les opérations interdites dans du code déterministe avec des droits limités.

### 3. Réduire les outils autorisés

Ne présenter que les opérations compatibles avec le rôle, le parcours et l’état actuel. Une recherche d’outils peut réduire cet ensemble, jamais l’élargir.

### 4. Placer de vrais points de contrôle

Montrer la cible, les valeurs, les preuves et l’effet attendu avant une opération importante. Demander l’accord tant que la personne peut encore corriger ou annuler.

### 5. Exécuter avec une reprise

Revérifier juste avant l’effet. Prévoir la protection contre les doublons, les délais, les échecs partiels et un chemin clair pour relancer, compenser ou transmettre.

### 6. Évaluer les traces et le résultat

Tester les refus, les injections, les états anciens, les pannes d’outils et les chemins alternatifs. Examiner les transitions, les appels et l’état final avec la qualité de la réponse.

## Exemples

### Support client

L’assistant lit les informations autorisées et prépare une réponse. Un remboursement ou un changement de compte reste une proposition typée jusqu’au contrôle de la règle et de la personne habilitée.

### Opérations industrielles

L’assistant retrouve une procédure et prépare une note d’intervention. Il ne contourne ni les verrous de l’équipement, ni les règles de sécurité, ni l’opérateur responsable.

### Boucle expérimentale étroite

Le dépôt autoresearch de Karpathy illustre un cadre précis : un seul fichier modifiable et une évaluation fixe. C’est un exemple de terrain pour limiter une expérience, pas la preuve que ce modèle convient à tous les usages en production.

## Pièges fréquents

- Demander au modèle d’être prudent tout en lui donnant des droits et des outils trop larges.
- Laisser un classement sémantique agrandir une limite de droits déterministe.
- Placer la confirmation après l’effet ou cacher le changement exact.
- Accorder de l’autonomie sans annulation, protection contre les doublons ni état d’échec partiel.
- Évaluer des conversations convaincantes sans regarder les appels ni l’état laissé dans le système.

## Checklist

1. Chaque opération possède une classe de conséquence et de réversibilité.
2. Les règles fermes sont appliquées hors du modèle.
3. Les identifiants et les outils autorisés suivent le principe du moindre privilège.
4. Les propositions importantes sont visibles et modifiables avant l’accord.
5. L’exécution revérifie l’identité, l’état et les invariants.
6. La reprise, l’annulation, la compensation et la transmission sont prévues si nécessaire.
7. Les traces relient décisions, appels, résultats et état final sans exposer de secrets.
8. L’autonomie grandit seulement après des évaluations réalistes et une revue d’exploitation.

## Limites

- Les garde-fous réduisent le risque. Ils ne rendent pas un agent ouvert sûr dans tous les environnements.
- Un contrôle humain devient mécanique si les propositions sont confuses ou trop fréquentes.
- Les exemples de terrain et conseils d’éditeurs doivent être confrontés aux outils, menaces et responsabilités de l’organisation.

## Sources

1. [Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — NIST, 2023; nature: standard.
2. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; nature: research.
3. [autoresearch](https://github.com/karpathy/autoresearch) — Andrej Karpathy, 2026; nature: field-practice.
4. [AI Elements documentation](https://elements.ai-sdk.dev/docs) — Vercel, 2026; nature: official-documentation.
5. [Trustworthy agents in practice](https://www.anthropic.com/research/trustworthy-agents) — Anthropic, 2026; nature: field-practice.
6. [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — Anthropic, 2026; nature: field-practice.

## Questions fréquentes

### Chaque appel d’outil doit-il être validé ?

Non. Une lecture limitée et une opération sans conséquence peuvent être automatiques. Le niveau d’accord dépend de l’impact, de la réversibilité et des preuves.

### Un prompt système est-il un garde-fou ?

Il guide le comportement, mais ne forme pas une limite ferme. Les accès, les outils, la validation et l’exécution restent dans l’application.

### Que doit vérifier une évaluation de l’autonomie ?

Le résultat de la tâche, la légalité du chemin, le passage par les contrôles requis, le refus des actions interdites et la possibilité de reprendre après un échec.

---

Canonical: https://scoperail.fokalabs.io/fr/guides/garde-fous-autonomie-agents
Author: Ramzi Laieb, FokaLabs