Qu'est-ce qu'un agent IA ? (2026)

Parcourez la partie dont vous avez besoin :

1. Une définition précise d'un agent IA.

2. La boucle de l'agent — percevoir, planifier, agir, observer.

3. L'utilisation d'outils — ce qui rend un agent plus qu'un chatbot.

4. Le pattern ReAct — raisonnement et action entrelacés.

5. Agent vs chatbot vs workflow — la comparaison qui met fin à la confusion.

6. Quand utiliser un agent (et quand ne pas l'utiliser).

7. Les risques et comment les contenir.

8. Comment commencer petit.

9. FAQ et Sources & lectures complémentaires.

Les sources incluent l'article ReAct (Yao et al.) et le Guide de l'ingénierie des invites DAIR.ai, tous deux liés avec les dates dans la section finale.

Un agent IA est un système piloté par LLM qui, donné un objectif, décide à plusieurs reprises et exécute des actions — y compris l'appel d'outils externes — et utilise les résultats de ces actions pour informer sa prochaine décision, continuant jusqu'à ce que l'objectif soit atteint ou qu'une condition d'arrêt se déclenche.

Décomposez les trois mots porteurs de charge. **Objectif :** vous donnez à l'agent un objectif (« réserver le vol le moins cher selon ces contraintes », « trier ces 40 tickets d'assistance »), pas une seule instruction. **Décide :** le modèle, pas un script codé en dur, choisit l'étape suivante. **Outils :** l'agent peut affecter le monde ou récupérer des informations nouvelles — rechercher sur le web, exécuter du code, interroger une base de données, appeler une API — plutôt que de s'appuyer uniquement sur ce qui est dans ses poids.

Contraste avec un simple appel LLM : vous envoyez une invite, vous obtenez une réponse, l'interaction se termine. Le LLM n'a pas choisi de chercher quoi que ce soit ou de prendre une mesure ; il a simplement produit du texte. Au moment où vous ajoutez une boucle, l'accès aux outils et la prise de décision orientée vers un objectif, vous avez un agent.

Presque chaque agent exécute une version de la même boucle : percevoir l'état actuel, planifier l'étape suivante, agir (souvent en appelant un outil) et observer le résultat — puis répéter.

**Percevoir.** L'agent lit son contexte actuel : l'objectif, la conversation/l'historique et tous les résultats des actions précédentes.

**Planifier / raisonner.** Il décide ce qu'il faut faire ensuite. Cela pourrait être « chercher X », « exécuter ce code », « poser une question de clarification à l'utilisateur » ou « j'ai assez — produire la réponse finale ».

**Agir.** Si le plan appelle un outil, l'agent émet un appel d'outil structuré (par exemple, une requête de recherche ou une demande d'API). Un programme environnant exécute cet appel.

**Observer.** La sortie de l'outil est réintégrée dans le contexte de l'agent. Avec les nouvelles informations, la boucle se répète. Une condition d'arrêt — objectif atteint, budget d'étapes/coût épuisé ou une erreur — la termine. Pour les calculs précis des prix en juin 2026, consultez notre calculateur de coûts d'agent IA. <!-- calc-link-mesh:v2 -->

Cette boucle est ce qui distingue le comportement agentique. Supprimez la boucle et les outils et vous êtes de retour à un chatbot.

L'utilisation d'outils (aussi appelée function calling) est le mécanisme qui permet à un modèle de langage de faire plus que générer du texte. Vous décrivez les outils disponibles — nom, ce qu'ils font et les paramètres qu'ils acceptent — et le modèle peut répondre avec une demande structurée d'appeler un. Votre code exécute l'outil et retourne le résultat, que le modèle lit au tour suivant.

Outils courants : recherche web (informations à jour), un interpréteur de code (calcul, travail sur les données), requêtes de base de données/API (vos systèmes et données), opérations sur les fichiers et même d'autres agents. L'idée clé est que le modèle décide quel outil utiliser et avec quels arguments ; ce n'est pas un pipeline fixe que vous avez écrit à l'avance.

L'utilisation d'outils est aussi là où les agents gagnent leur vie : un LLM seul ne peut pas connaître le taux de change d'aujourd'hui, exécuter une véritable requête contre vos données ou envoyer un e-mail — mais un agent avec les bons outils peut. Pour le côté conception des invites de description des outils correctement, le Guide de l'ingénierie des invites DAIR.ai est une bonne référence.

Le pattern le plus influent derrière les agents modernes est ReAct — abréviation de « Reasoning and Acting » — introduit par Yao et al. en 2022 (arXiv:2210.03629). ReAct entrelace les étapes de raisonnement (« pensées » sur ce qu'il faut faire) avec les actions (appels d'outils) et les observations (résultats des outils), afin que le modèle raisonne sur un problème et agisse en conséquence dans la même boucle plutôt que séparément.

Une trace ReAct simplifiée ressemble à ceci :

``` Thought: I need the current population of the city to answer this. Action: search("current population of <city>") Observation: <search result> Thought: Now I can compute the per-capita figure. Action: calculator("<number> / <population>") Observation: <result> Thought: I have what I need. Answer: <final answer with the figure> ```

La valeur de ReAct est que le raisonnement fonde les actions (le modèle explique pourquoi il appelle un outil) et les observations fondent le raisonnement (le modèle se met à jour en fonction de vrais résultats au lieu de deviner). Cela réduit les réponses non justifiées et rend le comportement de l'agent plus inspectable. La section ReAct du guide DAIR.ai la parcourt avec des exemples.

Ces trois sont constamment confondus, et la distinction concerne principalement qui contrôle les étapes.

**Chatbot :** répond à chaque message à tour de rôle. Pas d'autonomie multi-étapes orientée vers un objectif de sa part ; il répond à ce que vous demandez. Excellent pour la Q&A, la déflexion du support et la conversation.

**Workflow :** une séquence d'étapes fixe et prédéfinie que vous, le développeur, avez câblée. Un LLM peut être une étape (« résumer ceci », « classer cela »), mais le flux de contrôle est codé en dur. Prévisible, bon marché, facile à tester.

**Agent :** le LLM décide dynamiquement les étapes en utilisant des outils en boucle. Flexible et capable de gérer des tâches ouvertes, mais moins prévisible, plus difficile à tester et plus coûteux (plus d'appels de modèle).

La règle pratique : si vous pouvez écrire les étapes à l'avance, construisez un workflow. Si les étapes dépendent vraiment de ce qui est découvert en chemin, un agent justifie sa complexité. Notre guide plus approfondi couvre ce compromis en production : agents vs workflows : quand utiliser chacun.

Utiliser un workflow quand : vous pouvez spécifier les étapes à l'avance, vous voulez un coût et un comportement prévisibles, et la tâche a la même forme à chaque fois.
Utiliser un agent quand : les étapes requises dépendent de ce qui est découvert en milieu de tâche, l'espace d'entrée est ouvert, et l'utilisation dynamique d'outils surpasse vraiment un pipeline fixe.

**Bons cas pour un agent :** recherche ouverte où la requête suivante dépend du dernier résultat ; tâches nécessitant de choisir parmi de nombreux outils selon l'entrée ; workflows multi-étapes où la ramification est trop variable pour être codée en dur ; et travail exploratoire où vous ne connaissez vraiment pas les étapes à l'avance.

**Mauvais cas (utiliser plutôt un workflow ou un seul appel LLM) :** tout ce qui a une séquence d'étapes fixe et connue ; tâches simples en haut volume où les appels de modèle supplémentaires d'une boucle d'agent sont gaspillés ; tâches où la prévisibilité et l'auditabilité importent plus que la flexibilité ; et cas où une seule invite bien conçue fait déjà le travail.

Une erreur courante et coûteuse est de se tourner vers un agent parce que c'est l'option passionnante. Les agents multiplient votre coût en tokens (chaque étape de boucle est un appel de modèle), ajoutent de la latence et introduisent de l'imprévisibilité. Commencez par la chose la plus simple qui fonctionne — souvent une seule invite ou un petit workflow — et n'escaladez vers un agent que lorsque la variabilité de la tâche l'exige.

Les agents agissent, ce qui signifie que leurs erreurs ont des conséquences au-delà d'une mauvaise phrase. Trois risques méritent l'attention.

**Coût et boucles incontrôlables.** Parce que chaque étape est un appel de modèle, un agent qui boucle peut accumuler rapidement les coûts. Toujours définir des limites strictes : étapes maximales, coût/tokens maximal et délais d'expiration.

**Actions non sûres.** Un agent avec des outils qui peuvent envoyer un e-mail, dépenser de l'argent ou modifier des données peut faire de vrais dégâts. Mettez les actions conséquentes derrière l'approbation humaine, limitez les permissions d'outils et préférez les outils en lecture seule si possible.

**Injection d'invites.** Quand un agent lit du contenu externe (pages web, documents, e-mails), ce contenu peut contenir des instructions qui tentent de détourner l'agent. L'injection d'invites est le #1 risque dans le OWASP LLM Top 10 (LLM01:2025). Traitez le contenu récupéré comme des données non fiables, pas comme des instructions. Pour les défenses pratiques, consultez notre checklist de défense contre l'injection d'invites.

Ce ne sont pas des raisons d'éviter les agents — ce sont des raisons de les limiter. Un agent bien délimité avec des limites d'étapes, des portails de permissions et une sensibilisation à l'injection est sûr à exécuter.

Ne construisez pas un système multi-agents le premier jour. Commencez avec un agent, un ou deux outils et un objectif étroit. Donnez-lui une seule capacité qu'il ne peut pas obtenir à partir d'une simple invite — la recherche web, par exemple — et regardez comment il raisonne la boucle.

Instrumentez tout : enregistrez chaque pensée, action et observation afin de pouvoir voir pourquoi l'agent a fait ce qu'il a fait (la trace ReAct le rend naturel). Définissez une limite d'étapes basse. Exécutez-le sur des tâches réelles et lisez les traces — vous apprendrez rapidement où il se bloque ou surréagit.

Ajoutez seulement plus d'outils, plus d'autonomie ou plus d'agents une fois que la version simple prouve qu'elle en a besoin. Pour écrire les invites et les descriptions d'outils qui pilotent un agent, le Code Prompt Builder et notre guide des invites système vous aident à être précis sur le rôle et les contraintes.

Les définitions et patterns ci-dessus s'appuient sur ces sources — confirmez les détails dans les originaux :

ReAct : Yao et al., 2022, 'ReAct: Synergizing Reasoning and Acting in Language Models' — arXiv:2210.03629 (consulté en juin 2026).

Guide de l'ingénierie des invites DAIR.ai — agents, utilisation d'outils et pattern ReAct : promptingguide.ai (consulté en juin 2026).

OWASP GenAI / LLM Top 10 — injection d'invites (LLM01:2025) : genai.owasp.org/llm-top-10 (consulté en juin 2026).

Learn Prompting — explications sur les agents et l'utilisation d'outils : learnprompting.org.

Lectures sur le site : agents vs workflows : quand utiliser chacun et checklist de défense contre l'injection d'invites.