L'IA agentique expliquée : quand un système d'IA peut planifier, utiliser des outils et agir

L'IA agentique est un système d'IA dans lequel un modèle peut poursuivre un objectif sur plusieurs étapes en décidant quoi faire ensuite, en utilisant des outils ou d'autres capacités, en observant les résultats, en mettant à jour son état de travail et en continuant jusqu'à atteindre une condition d'arrêt. Le modèle seul n'est pas l'agent. Un agent utilisable a également besoin d'un environnement d'exécution ou d'un harnais qui gère le contexte, l'exécution des outils, l'état, les permissions, les approbations, les erreurs et la boucle entre les décisions et les observations.

Ce que signifie réellement l'IA agentique

Le changement important entre l'IA générative ordinaire et l'IA agentique réside dans le contrôle du processus. Un assistant normal peut répondre à une question en utilisant le contexte qu'il reçoit. Un agent peut décider que répondre nécessite des étapes supplémentaires : inspecter un fichier, rechercher dans un dépôt, interroger une API, demander une clarification, exécuter un test, mettre à jour un ticket, déléguer une sous-tâche ou réessayer après une action échouée.

Cela n'exige pas une autonomie illimitée. Un agent peut fonctionner dans un bac à sable étroit, sous des permissions strictes, avec une approbation requise avant chaque action conséquente. Le système reste agentique si le modèle choisit dynamiquement parmi les étapes suivantes autorisées.

L'architecture importe donc plus que l'étiquette. « Agent » devrait décrire un comportement système : une prise de décision itérative pilotée par le modèle sur des outils, un état et des retours — et non simplement un chatbot avec un prompt plus grand.

L'exemple le plus simple

Supposons qu'un développeur demande à un système d'IA : « Trouve pourquoi la suite de tests échoue et corrige le bug. » Un seul appel de modèle ne pourrait que suggérer des causes probables à partir du texte qui lui a été fourni.

Un système de codage agentique peut inspecter le dépôt, rechercher le test qui échoue, lire les fichiers pertinents, proposer une modification, éditer le code, exécuter le test, observer l'échec, réviser l'implémentation et exécuter à nouveau le test.

La partie agentique ne réside pas simplement dans l'existence d'outils de shell et de fichiers. Elle réside dans le fait que le modèle peut utiliser les retours de l'environnement pour choisir l'étape suivante au lieu de suivre une séquence entièrement prédéfinie.

Où s'arrête l'exemple simple

Tous les systèmes d'IA multi-étapes ne sont pas également agentiques. Un workflow peut utiliser plusieurs appels de LLM et outils alors que chaque étape est prédéterminée dans le code. Un autre système peut laisser le modèle décider quel outil appeler, dans quel ordre, combien de fois et quand s'arrêter.

Les deux peuvent être utiles. La différence réside dans l'endroit où se trouve le contrôle. Les workflows prédéfinis placent plus de contrôle dans le code de l'application. Les agents déplacent davantage de décisions tactiques de processus dans la boucle modèle/environnement d'exécution.

Agent vs workflow

Anthropic sépare explicitement ces deux modèles : les flux de travail orchestrent les modèles et les outils via des chemins de code prédéfinis, tandis que les agents laissent les modèles diriger dynamiquement leurs propres processus et l'utilisation des outils. Ce n'est pas la seule terminologie possible, mais c'est une frontière architecturale utile.

Le comportement agentique est un spectre, pas une étiquette binaire

Appeler chaque système ci-dessus un « agent » peut masquer des différences opérationnelles importantes. Plus le contrôle du modèle sur la séquence, la durée et les actions est fort, plus l'isolation de l'environnement d'exécution, les permissions, la traçabilité, les conditions d'arrêt et l'évaluation de la trajectoire deviennent importants.

L'architecture minimale d'un système agentique

Un modèle n'est pas un agent

Un modèle de langage produit des sorties à partir d'entrées. Il ne possède pas en soi un système de fichiers, n'exécute pas de commande shell, ne maintient pas d'état de tâche durable, n'applique pas de permissions et ne s'appelle pas automatiquement à nouveau.

Ces capacités proviennent de l'environnement d'exécution environnant. Le même modèle peut se comporter comme un simple modèle de chat dans une application et comme le moteur de décision au sein d'une boucle d'agent dans une autre.

L'utilisation d'outils est centrale — mais l'utilisation d'outils seule ne fait pas un agent

Les outils permettent au modèle d'acquérir des informations et d'affecter des systèmes externes. Les exemples incluent les lectures de base de données, les opérations sur fichiers, l'exécution de shell, la recherche web, le contrôle de navigateur, les appels API, les mises à jour de tickets ou les agents spécialistes délégués.

Un appel unique au modèle peut utiliser un outil et rester une réponse assistée par outil limitée plutôt qu'un agent de longue durée. Le comportement agentique apparaît lorsque les observations des outils alimentent une boucle adaptative dans laquelle le modèle choisit quoi faire ensuite.

La conception des outils est importante car les outils sont le contrat entre le raisonnement du modèle et la réalité externe. Des outils ambigus ou qui se chevauchent créent des erreurs de routage ; de grandes sorties non structurées polluent le contexte ; des outils à large effet de bord augmentent le rayon d'impact.

Capacité, permission et autorité des outils sont différentes

Ces couches sont souvent fusionnées dans les prototypes. Un modèle voit un outil de remboursement et semble donc capable d'émettre des remboursements. En production, l'outil doit toujours valider le compte, l'utilisateur, la transaction, le montant, la politique et les conditions d'approbation indépendamment de la demande du modèle.

Le runtime ou harnais est le véritable système d'exécution

La documentation actuelle d'OpenAI sur les agents rend explicite la distinction de runtime. Différents runtimes peuvent gérer l'orchestration, l'état, les outils, les sandboxes et l'exécution à différents endroits, tandis que le modèle ne reste qu'une partie du système.

Le SDK Agents décrit une boucle qui appelle de manière répétée le modèle actuel, inspecte la sortie, exécute les outils ou transferts demandés, et continue jusqu'à ce que le modèle renvoie une réponse finale ou un autre point d'arrêt réel.

Cela signifie que les décisions d'architecture d'agent incluent où l'orchestration s'exécute, où réside l'état, qui exécute les outils, quelle sandbox contient les effets de bord, et qui est responsable des tentatives, des délais d'attente et de la reprise.

La planification est utile, mais un plan explicite n'est pas requis

Les agents sont souvent décrits comme des systèmes qui « planifient ». En pratique, la planification peut être explicite ou implicite. Un agent peut d'abord produire un plan visible en plusieurs étapes, ou choisir une action à la fois et réviser après chaque observation.

Pour les tâches très incertaines, une planification à court terme peut être plus sûre car l'environnement peut invalider un plan à long terme. L'exigence architecturale est la capacité de choisir et de réviser des actions en fonction de l'objectif, de l'état actuel et des nouvelles preuves.

Le retour d'information environnemental est ce qui rend la boucle utile

Un agent devient opérationnellement significatif lorsqu'il peut observer si son action a fonctionné. La sortie d'outil, les résultats de tests, les réponses d'API, l'état du système de fichiers, l'état du navigateur et les enregistrements d'application fournissent des preuves externes que le système peut utiliser pour réviser sa prochaine décision.

Les conseils d'Anthropic sur les agents mettent l'accent sur cette boucle de rétroaction : les agents utilisent des outils, obtiennent la vérité terrain de l'environnement, évaluent les progrès et continuent ou demandent une intervention humaine.

L'état de l'agent n'est pas la même chose que le contexte du modèle

Une tâche de longue durée peut nécessiter un état qui ne peut pas ou ne devrait pas rester dans le contexte du modèle : identifiants de tâche, points de contrôle, artefacts, approbations, identifiants d'objets externes, compteurs de tentatives et statut du flux de travail.

Le runtime peut préserver cet état durable en dehors de la fenêtre du modèle et reconstruire le contexte nécessaire pour l'étape suivante. Cela permet de garder le contexte visible par le modèle ciblé tout en maintenant la continuité et la reprise.

La mémoire est optionnelle, pas la définition d'un agent

Un agent peut fonctionner avec succès sans mémoire à long terme si la tâche complète tient dans une seule exécution bornée. La mémoire devient utile lorsque les informations doivent persister à travers les sessions, les tâches ou de longs horizons d'exécution.

RAG, mémoire, état et contexte résolvent des problèmes différents. Traiter une base de données vectorielle comme « la mémoire de l'agent » ou l'historique de conversation comme « la machine à états » masque généralement des frontières importantes de cycle de vie et d'autorité.

L'ingénierie du contexte devient dynamique dans les agents

Chaque appel d'outil peut produire un nouveau contexte. Chaque étape peut aussi rendre obsolètes les informations antérieures. Un runtime d'agent robuste reconstruit ou organise donc le contexte au fur et à mesure de l'exécution plutôt que de tout rejouer indéfiniment.

Les définitions d'outils, l'état de la tâche, les preuves récupérées, les observations et la mémoire se disputent tous l'attention du modèle. Les agents de longue durée ont besoin d'élagage, de compactage ou de chargement juste-à-temps pour que le contexte reste pertinent pour la décision en cours.

Les outils de lecture et les outils à effet de bord présentent des risques différents

L'humain dans la boucle est un mécanisme de contrôle, pas l'opposé de l'IA agentique

Un agent ne cesse pas d'être agentique parce qu'un humain approuve des étapes conséquentes. Le modèle peut toujours inspecter, raisonner, rechercher et préparer une action de manière autonome, tandis que le runtime exige une confirmation humaine avant l'exécution.

Les directives actuelles d'OpenAI en matière de sécurité des agents recommandent explicitement des approbations pour les opérations d'outils dans les flux de travail à risque élevé. Anthropic met également l'accent sur les points de contrôle et le jugement humain lorsque les agents rencontrent des blocages ou des décisions conséquentes.

La question architecturale utile n'est pas « humain ou autonome ? » mais quelles décisions peuvent être déléguées, lesquelles nécessitent une revue et lesquelles doivent rester déterministes ?

Les agents ont besoin de conditions d'arrêt explicites

La récupération fait partie du comportement de l'agent

Les agents opèrent dans des environnements qui échouent : les API expirent, les fichiers changent, les identifiants expirent, les pages web se déplacent et les outils renvoient des sorties malformées. Un système agentique utile a donc besoin d'un comportement de récupération, pas seulement d'une boucle d'outils idéale.

La récupération peut inclure une nouvelle tentative avec limites, le choix d'un autre outil, la relecture de l'état actuel, demander à l'utilisateur, annuler une action partielle ou escalader vers un humain.

Les nouvelles tentatives doivent aussi tenir compte de l'idempotence. Répéter une lecture est généralement à faible risque ; répéter un paiement ou l'envoi d'un message peut créer des effets de bord en double.

L'IA agentique ne nécessite pas plusieurs agents

Un agent unique avec un ensemble d'outils clair est souvent plus simple et plus facile à évaluer qu'une architecture multi-agents. Plusieurs agents sont utiles lorsque la spécialisation améliore matériellement l'isolation des outils, l'isolation des politiques, la clarté des invites, la propriété ou la lisibilité des traces.

Les directives actuelles d'orchestration d'OpenAI recommandent explicitement de commencer avec un seul agent lorsque c'est possible et d'ajouter des spécialistes uniquement lorsque le contrat ou la frontière de propriété change matériellement.

Les systèmes multi-agents ajoutent de nouveaux problèmes : qualité de la délégation, contexte dupliqué, état conflictuel, sémantique de transfert, identité, coût et gestion des défaillances distribuées.

Les protocoles d'agents sont des couches d'interopérabilité, pas l'agent lui-même

Des protocoles tels que MCP et A2A peuvent rendre une architecture d'agent interopérable, mais ils ne créent pas la boucle de l'agent à eux seuls. MCP peut exposer des outils et des ressources. A2A peut connecter des agents implémentés indépendamment. L'application a toujours besoin d'un runtime, d'une autorisation, d'un état, d'une évaluation et d'une logique métier.

C'est pourquoi la capacité du protocole doit rester séparée de l'autorité métier. Découvrir un outil via MCP ne prouve pas que le principal actuel est autorisé à l'utiliser. Recevoir une tâche via A2A ne prouve pas que l'agent distant peut effectuer toutes les actions demandées.

La trajectoire fait partie de la fiabilité de l'agent

Une réponse finale est une preuve insuffisante pour un système agentique car un agent peut atteindre le bon résultat par un chemin dangereux ou invalide. Il peut utiliser un outil non autorisé, sauter une vérification requise, répéter un effet de bord, s'appuyer sur un état obsolète ou réussir accidentellement.

L'évaluation nécessite donc des traces d'exécution : décisions, appels d'outils, approbations, observations, changements d'état et résultat final. Les recommandations actuelles d'OpenAI en matière de sécurité préconisent des évaluateurs de traces et des évaluations ; les recommandations d'Anthropic de 2026 sur l'évaluation des agents traitent de la même manière les trajectoires d'outils multi-tours comme des objets d'évaluation de premier ordre.

La question de fiabilité plus forte est : l'agent a-t-il atteint un résultat acceptable par une trajectoire acceptable, récupérable et auditable ?

Les systèmes agentiques augmentent la surface de sécurité

L'observabilité de l'agent doit suivre la boucle

L'observabilité traditionnelle des services enregistre les requêtes, la latence et les erreurs. L'observabilité des agents nécessite un modèle d'exécution supplémentaire : quel agent était actif, quelle version du modèle a pris la décision, quel contexte était disponible, quel outil a été sélectionné, quels arguments ont été envoyés, quel résultat est revenu et pourquoi l'exécution s'est arrêtée.

Pour les systèmes sensibles, les traces elles-mêmes nécessitent un contrôle d'accès et une politique de rétention car les prompts, les sorties d'outils et les artefacts peuvent contenir des données confidentielles.

Comment évaluer un système agentique

Quand un agent est approprié

Un bon défaut consiste à commencer par la solution la plus simple qui fonctionne et à n'augmenter la complexité agentique que lorsque la flexibilité produit une valeur mesurable. Les agents échangent la prévisibilité, la latence et le coût contre une exécution adaptative.

Preuves d'implémentation originales

Aaasaasa AI Client : modèle, runtime et permission sont séparés

Aaasaasa AI Client sépare explicitement l'agent/client, le fournisseur, le modèle, l'emplacement du runtime et les permissions. Sa documentation d'architecture traite les permissions comme une politique centrale d'outil/espace de travail plutôt que comme une propriété du modèle.

La même application peut exposer un Direct Chat sans outils de système de fichiers ou de shell, tandis qu'un runtime Codex fonctionne sous un espace de travail et un profil de permissions sélectionnés. Cela démontre une frontière architecturale agentique essentielle : changer la surface du runtime/outils change ce que le système peut faire, même lorsque l'accès au modèle reste disponible.

Le dépôt distingue également un runtime Codex local de l'emplacement du modèle : un runtime local peut appeler un modèle cloud. Cela évite l'erreur courante consistant à assimiler « l'agent s'exécute localement » à « l'inférence est locale ».

L'implémentation désactive les chemins d'exécution intégrés dont la sémantique d'approbation ne satisfait pas le modèle de permissions requis. Cela soutient le principe selon lequel la capacité d'un agent ne doit pas contourner l'autorisation du runtime simplement parce qu'un framework sous-jacent peut exécuter des outils.

Source of Truth Research Engine : étapes de recherche agentique bornées

Le Source of Truth Research Engine utilise un pipeline de recherche borné : découvrir → acquérir → extraire → vérifier → contredire → synthétiser. Les tâches de recherche peuvent s'exécuter via un runtime IA tandis que les preuves, sources, affirmations et contradictions restent dans un stockage persistant externe.

C'est intentionnellement plus contrôlé qu'un agent de recherche autonome non contraint. Les étapes fournissent des garde-fous sur le type de travail à effectuer ensuite tout en permettant une recherche pilotée par le modèle à l'intérieur de chaque tâche bornée.

Cette distinction est une preuve utile pour la conception d'agents : l'autonomie peut être placée à l'intérieur d'une enveloppe de livraison structurée plutôt qu'appliquée uniformément à l'ensemble du processus.

Modes de défaillance courants de l'IA agentique

Idées fausses courantes

Une séquence pratique de conception d'agent

Liste de contrôle de l'architecture d'IA agentique

Cas limites et limitations

Certains systèmes ne sont « agentiques » que dans un sens étroit de routage : le modèle sélectionne un spécialiste ou un outil, puis le reste du flux de travail est déterministe. Cela peut rester utile, mais cela ne doit pas être décrit comme équivalent à un agent autonome de longue durée.

Les domaines à fort enjeu peuvent intentionnellement restreindre l'autonomie de l'agent. Un système d'IA peut examiner des preuves, préparer des recommandations et remplir des formulaires structurés tandis qu'un humain reste le seul acteur autorisé à valider la transaction finale.

Certains environnements sont bien adaptés aux agents parce que le retour d'information est objectif. Les agents de codage peuvent exécuter des tests ; les agents d'infrastructure peuvent inspecter des métriques ; les agents de données peuvent valider les résultats de requêtes. Les domaines ouverts avec un retour d'information faible exigent une évaluation plus prudente.

Un agent peut fonctionner entièrement en local, entièrement via des services cloud gérés ou dans une architecture hybride. Le comportement agentique décrit le flux de contrôle, non l'emplacement d'hébergement.

Le terme « raisonnement » ne doit pas être utilisé comme preuve que le processus interne de l'agent est correct. L'assurance en production doit s'appuyer sur des entrées, des actions, des sorties, des états et des évaluations observables plutôt que sur des affirmations non vérifiables concernant un raisonnement caché.

Qu'est-ce qui changerait cette réponse ?

Les API des fournisseurs et les frameworks d'agents continueront d'évoluer, mais la frontière architecturale est stable : un modèle propose des décisions, un runtime gère la boucle, les outils se connectent à l'environnement, les permissions contraignent les actions et les observations externes déterminent ce qui s'est réellement produit.

À mesure que les modèles deviennent plus fiables, les systèmes peuvent déléguer en toute sécurité des horizons plus longs ou un comportement de récupération plus complexe. À mesure que la vérification et l'autorisation au runtime s'améliorent, certaines étapes d'approbation peuvent être automatisées. Ce sont des changements de niveau d'autonomie, non des changements des couches de responsabilité fondamentales.

L'architecture recommandée change également selon les conséquences. Un agent de recherche qui ne lit que des sources publiques peut tolérer des contrôles différents de ceux d'un agent qui écrit de la configuration de production ou déplace de l'argent.

Connaissances canoniques associées

L'IA agentique se situe au-dessus de plusieurs couches prérequises : l'ingénierie du contexte détermine ce que le modèle voit ; l'architecture de la source de vérité détermine quelles informations font autorité ; la récupération fournit des preuves externes ; l'architecture du runtime détermine ce qui peut s'exécuter.

Les nœuds en aval incluent l'appel d'outils, MCP, A2A, l'identité des agents, les permissions, l'auditabilité, l'humain dans la boucle, l'orchestration, la mémoire et les systèmes multi-agents.

L'article sur la pile de protocoles doit donc être lu après le concept de base d'agent : les protocoles normalisent les frontières autour des agents ; ils ne définissent pas le comportement agentique lui-même.

Questions fréquentes

Glossaire

Conclusion

L'IA agentique n'est pas simplement un modèle plus intelligent ou un chatbot doté de plus d'outils. C'est une architecture système dans laquelle un modèle participe à une boucle de contrôle itérative : décider, agir, observer, mettre à jour et continuer.

Le modèle fournit une prise de décision flexible, mais l'environnement d'exécution environnant doit assumer la réalité de l'exécution : permissions, accès aux outils, état, approbations, nouvelles tentatives, budgets, conditions d'arrêt, traçage et vérification.

Le principe de conception le plus utile est donc le suivant : déléguer le choix tactique au modèle uniquement à l'intérieur de frontières techniques et commerciales explicites. La capacité agentique ne devient une capacité de production que lorsque l'autonomie, l'autorité et les preuves restent séparables.

Sources primaires et orientations actuelles

Les sources ci-dessous étayent les distinctions architecturales actuelles autour des agents, des flux de travail, des boucles, des outils, de l'orchestration, de la sécurité et de l'évaluation. Les sections du projet constituent des preuves de mise en œuvre originales et sont explicitement limitées à ce que les dépôts démontrent.