De l’objectif à l’action contrôlée : boucles, vérification et permissions dans les agents d’intelligence artificielle
Découvrez comment les agents d’IA transforment un objectif en appels d’outils grâce à un cycle planer-agir-observer, et pourquoi la vérification, les niveaux d’autonomie et les couches de permission déterminent leur sécurité.
La plupart des gens ont découvert les modèles de langage comme des machines à répondre aux questions : on entre une demande, on obtient une réponse, et c’est terminé. Les systèmes d’agents brisent ce schéma. Face à un objectif, ils planifient, utilisent des outils, examinent les résultats et continuent jusqu’à ce que la tâche soit achevée. Cette présentation couvre le cycle de travail, les outils, la mémoire et les configurations multi-agents, avant de se concentrer sur ce qui est le plus important en environnement de production : vérifier le travail d’un agent et limiter ses pouvoirs.
Répondre versus travailler vers un objectif
Un chatbot classique effectue une seule action : une question est envoyée, le modèle produit une réponse, et rien d’autre ne se passe.
User
↓
Question
↓
AI
↓
Answer
Si vous lui demandez « Qu’est-ce que l’apprentissage automatique ? », vous obtenez une explication, rien de plus. Un agent est organisé autour d’un objectif, atteint grâce à une séquence d’actions accompagnées de retours d’information.
User
↓
Goal
↓
AI Agent
↓
Plan
↓
Use Tools
↓
Observe Results
↓
Take More Actions
↓
Complete Goal
Une demande telle que "analyser cet ensemble de données et produire un rapport" doit être divisée en étapes concrètes :
Read dataset
↓
Understand columns
↓
Clean data
↓
Analyze statistics
↓
Create graphs
↓
Find patterns
↓
Write report
En bref, un chatbot répond, tandis qu’un agent effectue le travail et l’adapte au fur et à mesure.
Qu’est-ce qui qualifie un système d’agent ?
Il n’existe pas de définition unique et universellement acceptée. Une définition pratique : un agent reçoit une tâche, prend des décisions, utilise les outils disponibles, examine les résultats et choisit des actions supplémentaires jusqu’à ce que l’objectif soit atteint. La caractéristique déterminante est le branchement en bas qui renvoie le contrôle vers le haut.
USER GOAL
↓
AI AGENT
↓
PLAN
↓
SELECT ACTION
↓
USE TOOL
↓
OBSERVE
↓
EVALUATE
↓
NEXT ACTION?
↙ ↘
YES NO
↓ ↓
Continue Finish
Sans cette boucle, on a un pipeline qui s’exécute une seule fois. Avec elle, le système peut se remettre de surprises, ce qui constitue à la fois sa force et la raison pour laquelle il a besoin de supervision.
Le cycle réfléchir, agir, observer
Le modèle mental le plus simple pour ce cycle est : penser, agir, observer. Imaginez qu’on demande à un agent de trouver le meilleur ordinateur portable dans votre budget et d’en comparer trois modèles. En interne, il procéderait probablement de la manière suivante :
Goal
↓
Understand requirements
↓
Search for products
↓
Read results
↓
Compare specifications
↓
Check prices
↓
Evaluate options
↓
Generate recommendation
L’agent ne s’appuie pas sur ses souvenirs d’entraînement pour parler des ordinateurs portables. Il consulte des sources réelles et base ses recommandations sur ce qu’il trouve, et c’est ce contact avec le monde extérieur qui le distingue de la simple génération de texte.
Trois composants : le modèle, les outils et l’état
Un agent de base peut être décrit en termes de trois éléments.
Le modèle en tant que décideur
Généralement, il s’agit d’un grand modèle de langage qui interprète les instructions et décide de la prochaine action à entreprendre.
Les outils en tant que capacités
Les outils représentent les capacités externes que l’agent peut utiliser, par exemple :
Search
Python
Calculator
Database
API
File system
Computer
Vision model
L’état en tant que registre en cours d’exécution
État correspond à ce que l’agent sait de la tâche pour le moment. Il répond à des questions telles que celles-ci :
What did I search?
What did I find?
What have I already done?
What remains?
Ensemble, ces trois composants influencent les actions que l’agent entreprend :
AI AGENT
│
┌──────────┼──────────┐
↓ ↓ ↓
Model Tools Memory
│ │ │
└──────────┼──────────┘
↓
Actions
Pour en savoir plus sur ces éléments de base, consultez notre guide sur les objectifs, outils, mémoire et le cycle de l’agent.
Pourquoi les outils ont une telle importance
Si l’on demande à un modèle de multiplier 938472 par 827391, il peut obtenir le bon résultat, mais il prédit les chiffres plutôt que de les calculer réellement ; par conséquent, une calculette ou Python est plus fiable. Un agent peut confier cette tâche à d’autres :
User
↓
LLM
↓
"I need exact arithmetic."
↓
Calculator
↓
Result
↓
LLM
↓
Answer
Le modèle n’a pas besoin de faire tout cela lui-même. Il délègue.
Choisir l’outil adapté à l’entrée
Comment l’agent choisit-il parmi ses outils ? Supposons qu’il puisse accéder à tous ceux-ci :
Python
SQL
Search
Calculator
Vision Model
File Reader
Email API
Calendar
Au vu de l’instruction « examinez ce tableau de bord des ventes et expliquez pourquoi les revenus ont chuté », le système déduit, à partir du type d’entrée, de la structure des données et de la tâche à effectuer, l’outil approprié :
Input = Spreadsheet
↓
Data = Tabular
↓
Task = Analysis
↓
Tool = Python/pandas
L’outil choisi s’occupe alors du travail principal et transmet ses résultats :
pandas
↓
Analyze sales
↓
Find patterns
↓
Return results
L’agent interprète ensuite ces résultats. En pratique, le choix de l’outil dépend fortement de noms et de descriptions clairs, car c’est tout ce que le modèle voit.
Enchaîner plusieurs outils dans un même flux de travail
Prenons l’exemple « analysez nos données de ventes, créez un graphique et envoyez le rapport par e-mail à mon manager », qui englobe l’analyse, la visualisation, la rédaction et la livraison :
Sales Dataset
↓
Python / pandas
↓
Statistical Analysis
↓
Matplotlib
↓
Create Charts
↓
LLM
↓
Write Report
↓
Email Tool
↓
Send Report
Le système coordonne désormais un flux de travail, où chaque sortie alimente l’étape suivante, de sorte qu’une erreur précoce se propage jusqu’à l’envoi par e-mail.
Planification grâce à la décomposition des tâches
« Créer un site web pour mon projet » est une tâche trop vaste pour être accomplie d’un seul coup. Un agent compétent la divise en étapes ordonnées :
Goal
↓
Understand requirements
↓
Create project structure
↓
Build frontend
↓
Build backend
↓
Connect database
↓
Run application
↓
Test
↓
Fix errors
↓
Deploy
C’est la décomposition de tâches : l’objectif se transforme en une série d’actions plus petites qui peuvent chacune être exécutées et vérifiées.
Réagir aux échecs plutôt que de les signaler
Le cycle s’avère utile lorsque quelque chose ne fonctionne pas. Supposons que l’agent exécute du code :
Write code
↓
Run code
↓
ERROR
Un chatbot ne peut que signaler l’erreur. Un agent peut la lire, corriger le code et essayer à nouveau :
Write code
↓
Run code
↓
ERROR
↓
Read error
↓
Identify problem
↓
Modify code
↓
Run again
↓
SUCCESS
De manière généralisée, il s’agit du cycle agentique, où l’évaluation alimente un nouveau plan :
┌──────────────┐
│ PLAN │
└──────┬───────┘
↓
┌──────────────┐
│ ACT │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVE │
└──────┬───────┘
↓
┌──────────────┐
│ EVALUATE │
└──────┬───────┘
│
└──────→ PLAN AGAIN
Un cycle capable de réessayer peut aussi le faire indéfiniment, c’est pourquoi les systèmes réels limitent le nombre d’itérations.
Mémoire et continuité entre les étapes
Sans mémoire, chaque tâche commence à zéro :
Task 1
↓
Forget
↓
Task 2
↓
Forget
Avec la persistance de l’état, chaque étape s’appuie sur la précédente :
Task 1
↓
Save result
↓
Task 2
↓
Use previous result
↓
Task 3
La mémoire existe à plusieurs niveaux :
- L’état à court terme conserve les informations relatives à la tâche en cours.
- La mémoire à long terme persiste entre les interactions, dans la mesure où le système le permet.
- La mémoire externe se trouve en dehors du modèle, dans des bases de données, des documents, des entrepôts vectoriels ou des fichiers.
Un agent peut consulter des documents de projet ainsi que des résultats antérieurs avant d’effectuer l’étape actuelle :
Agent
↓
Memory
↓
Project documents
↓
Previous results
↓
Current task
Combinaison de la récupération d’informations et de l’exécution d’actions
La génération améliorée par la récupération d’informations (RAG) s’accorde naturellement avec les agents. Afin de répondre à partir de documents internes de l’entreprise, un agent les recherche, lit les passages pertinents et y réfléchit :
Question
↓
Search company documents
↓
Retrieve relevant information
↓
Read context
↓
Reason about it
↓
Answer
En ajoutant des outils, l’agent peut également agir sur ce qu’il a trouvé :
AI AGENT
│
┌───────────┼───────────┐
↓ ↓ ↓
RAG Python APIs
↓ ↓ ↓
Documents Analysis Actions
Division du travail entre plusieurs agents
Lorsqu’un agent seul ne suffit pas, plusieurs agents spécialisés peuvent travailler sous la coordination d’un coordinateur :
MAIN AGENT
│
┌────────────┼────────────┐
↓ ↓ ↓
Research Agent Coding Agent Data Agent
│ │ │
Search Code Analysis
Les agents chargés de la recherche, du codage et des données s’occupent chacun de leur domaine spécialisé, tandis que l’agent principal répartit les tâches entre eux. Il s’agit d’un système multi-agents.
L’analogie avec une équipe et ses limites
La structure ressemble à une entreprise de logiciels avec des rôles distincts :
Manager
↓
Developer
↓
Tester
↓
Designer
↓
Deployment
Un système d’IA peut reproduire cette division du travail :
Coordinator Agent
↓
Research Agent
↓
Coding Agent
↓
Testing Agent
↓
Deployment Agent
La comparaison est approximative, mais elle indique une direction : coordonner des modèles et outils spécialisés plutôt que de compter sur un seul modèle. Chaque agent supplémentaire augmente également les coûts et la latence, il est donc nécessaire que la spécialisation soit réelle.
Comment les agents échouent
L’autonomie ne garantit pas la fiabilité. Un agent peut :
- choisir le mauvais outil
- mal interpréter l’objectif
- produire du code défectueux
- récupérer des informations irrelevantes
Les erreurs s’accumulent à chaque étape suivante :
User Goal
↓
Wrong interpretation
↓
Wrong tool
↓
Wrong result
↓
Wrong action
Plus un agent dispose de liberté, plus son travail doit être vérifié.
Intégrer la vérification dans le cycle
L’anti-modèle consiste en un agent qui agit sans autre vérification que l’hypothèse que son action a fonctionné :
Act → Assume success
Le bon modèle prévoit une vérification explicite avant de passer à l’étape suivante :
Act
↓
Observe
↓
Verify
↓
Continue
Pour le code, cette vérification se fait par un exécution de test avec une branche claire en fonction du résultat :
Write Code
↓
Run Tests
↓
Tests Pass?
├── NO → Fix
└── YES → Continue
Pour les données, il s’agit d’une vérification de cohérence du résultat avant que quiconque ne s’y fie :
Database Query
↓
Check Result
↓
Is result reasonable?
├── NO → Investigate
└── YES → Continue
Vérifier plutôt que de supposer est ce qui distingue fortement un agent adaptatif d’un simple script. Préférez des vérifications déterministes, telles que des tests ou une validation de schéma, plutôt que de demander au modèle d’évaluer lui-même son travail.
L’autonomie est un régulateur, pas un interrupteur
Les agents n’ont pas besoin d’une liberté totale. Imaginez une échelle commençant par un système qui ne répond qu’aux questions suivantes :
Level 1
AI only answers
Les niveaux supérieurs ajoutent des actions suggérées, puis des appels d’outils, ensuite une planification en plusieurs étapes, et enfin des workflows exécutés avec une supervision limitée :
Level 2
AI suggests actionsLevel 3
AI calls toolsLevel 4
AI plans multiple actionsLevel 5
AI executes workflows with limited supervision
Chaque étape supplémentaire sur l’échelle augmente les exigences envers l’agent :
Permissions
Safety
Monitoring
Verification
Human oversight
Le niveau le plus bas qui permet de résoudre le problème est généralement le choix le plus sûr.
Définir ce qu’un agent peut manipuler
Imaginez un agent connecté à tout ce qui suit :
Email
Banking
Files
Database
Cloud infrastructure
Production servers
Un accès non restreint serait imprudent. Une conception plus sûre fait passer les actions par une couche de permissions :
AI Agent
↓
Permission Layer
↓
Allowed Tools
↓
Action
Les permissions sont ensuite définies pour chaque action : lire un fichier peut être autorisé, tandis que supprimer, envoyer par e-mail, déployer ou accéder à une base de données dépendent du contexte :
Read file ✓
Delete file ?
Send email ?
Deploy software ?
Access database ?
Le principe est celui du moindre privilège.
Règles de contrôle et approbation humaine
Les agents en production ont également besoin de limites strictes quant à leur fonctionnement :
Allowed tools
Maximum actions
Time limits
Budget limits
File permissions
Network permissions
Human approval
Pour les actions à fort impact, l’agent prépare l’action et attend une approbation humaine :
Agent
↓
Prepare Action
↓
Human Approval
↓
Execute
C’est une conception avec un intervenant humain dans le processus. Les boucles limitées sont abordées dans notre article sur les boucles agentielles limitées en TypeScript.
Où les agents sont utilisés
Cette même logique se retrouve dans de nombreux domaines.
Développement logiciel
Requirement
↓
Coding Agent
↓
Code
↓
Testing
↓
Bug Fixing
Analyse de données
Dataset
↓
Data Agent
↓
Cleaning
↓
Analysis
↓
Visualization
↓
Report
Suivi client
Prêtez attention à l’étape de « action autorisée » : les agents de support travaillent dans un ensemble restreint d’opérations préapprouvées.
Customer Question
↓
Retrieve Account Information
↓
Understand Problem
↓
Take Permitted Action
↓
Respond
Recherche
Research Question
↓
Search
↓
Read Papers
↓
Extract Information
↓
Compare Findings
↓
Generate Report
Goal
↓
Calendar
↓
Email
↓
Documents
↓
Tasks
↓
Summary
Un type d’interface différent
Goal
↓
Calendar
↓
Email
↓
Documents
↓
Tasks
↓
Summary
Le logiciel conventionnel associe un contrôle à une fonction pour obtenir un résultat :
Button
↓
Function
↓
Result
Un agent associe un objectif défini à un plan, ainsi qu’à des appels d’outils et des actions :
Goal
↓
Planning
↓
Tools
↓
Actions
↓
Result
Plutôt que d’apprendre quels boutons appuyer, l’utilisateur décrit le résultat souhaité. Cela modifie l’interaction homme-machine et fait de la visibilité des actions de l’agent une exigence de conception.
Une remarque sur le mot « pensée »
Lorsque nous disons qu’un agent « pense », nous faisons généralement référence à des étapes computationnelles : interpréter les entrées, planifier, choisir des actions, évaluer les sorties et mettre à jour l’état. Cela ne prouve pas l’existence d’une conscience. Plus précisément, les agents exécutent des cycles itératifs de raisonnement et de sélection d’actions en direction d’un objectif ; le terme « agent » décrit le comportement et l’architecture, non pas l’expérience.
L’ensemble en un seul cycle
Assemblés, ces éléments forment cette architecture : planifier, agir à l’aide d’un outil, observer, vérifier, puis continuer ou s’arrêter.
USER
│
▼
┌─────────┐
│ GOAL │
└────┬────┘
↓
┌─────────────┐
│ AI / LLM │
└──────┬──────┘
↓
PLAN
↓
SELECT ACTION
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Search Python SQL
↓ ↓ ↓
└─────────────┼─────────────┘
↓
RESULT
↓
OBSERVE
↓
VERIFY
↓
Continue or Finish
Ce cycle se trouve au cœur de la plupart des systèmes agents.
Où cela mène
Imaginez demander à votre ordinateur votre rapport de recherche hebdomadaire, avec un agent qui gère toute la chaîne :
Open research sources
↓
Collect information
↓
Read documents
↓
Analyze data
↓
Create charts
↓
Write report
↓
Check errors
↓
Prepare final document
L’ordinateur coordonne alors les applications plutôt que de se contenter de les héberger. Sur une plus longue période, l’évolution se présente ainsi :
Rule-Based Software
↓
Machine Learning
↓
Chatbots
↓
LLMs
↓
Tool-Using LLMs
↓
AI Agents
↓
Multi-Agent Systems
Le changement ne concerne pas seulement des modèles plus gros, mais aussi des modèles qui interagissent de plus en plus avec des systèmes externes.
Points clés
Find the dataset
↓
Load it
↓
Analyze it
↓
Create visualizations
↓
Detect problems
↓
Write a report
↓
Ask for approval
↓
Deliver the result
La progression va de la réponse, à la planification, à l’action, à l’observation et à la vérification. Quelques points à garder à l’esprit pour tout agent que vous concevez :
- C’est le boucle, et non le modèle, qui fait d’un système un agent ; encadrez-la avec des limites d’itération, de temps et de budget.
- Déléguez des tâches précises telles que les calculs arithmétiques, les requêtes et l’exécution de code à des outils, et décrivez clairement ces outils.
- Vérifiez chaque étape suivante à l’aide de contrôles qui ne dépendent pas de l’évaluation effectuée par le modèle lui-même.
Les agents ne sont pas tant des machines qui pensent comme des humains que des systèmes qui transforment un objectif en actions concrètes. La question clé n’est pas la capacité du modèle, mais ce que vous êtes prêts à lui permettre de faire.
Lectures complémentaires
- Agentic AI Explained: From Language Models to Autonomous Agents — Une présentation structurée montrant comment les modèles de langage évoluent vers des systèmes agents grâce à des outils, une mémoire, de la planification, des architectures multi-agents et l’intégration MCP.
- Vérifier ce que font les agents IA : permissions, portes d’approbation et niveaux de risque — Découvrez pourquoi les agents autonomes ont besoin d’une mentalité de vérification, et comment le principe du moindre privilège, l’approbation humaine et l’autonomie basée sur le risque permettent de limiter leurs erreurs.
- Watères-marques textuelles statistiques contre credenciaux C2PA dans le output de Claude — Apprenez comment fonctionnent les watères-marques textuelles basées sur SynthID de Claude ainsi que les credenciaux de fichiers C2PA, ce que les détecteurs peuvent prouver, et comment évaluer tout outil prétendant les supprimer.
- Construire des agents IA sur vos services et APIs .NET existants — Comment les équipes C# peuvent transformer des services et APIs existants en outils d’agents gérés, avec les règles de contexte, de sécurité et d’observabilité qui assurent leur sécurité.
- Leçons du portage Zig vers Rust piloté par l’IA de Bun : la vérification est le véritable travail — Ce que le passage de Zig à Rust assisté par des agents chez Bun nous apprend sur les suites de tests en tant que contrats, les guides de portage, le code non sécurisé, et pourquoi la vérification limite aujourd’hui l’écriture de code par l’IA.