Un agent IA n’est pas un chatbot déguisé. C’est un système qui observe, décide et agit — puis observe à nouveau en fonction de ce qui s’est passé. La plupart du battage médiatique autour des agents manquent ce point : la boucle est là où réside la valeur, pas le LLM.
C’est important car 2025 nous a montré qu’intégrer Claude ou GPT-4o dans une boucle ne le rend pas automatiquement utile. Il faut une architecture. Il faut des retours. Il faut cartographier les états d’échec avant de déployer.
Ce qu’est réellement un agent IA
Un agent est un logiciel qui fonctionne en cycle :
- Percevoir : Lire l’entrée, accéder aux outils, observer l’état de l’environnement
- Raisonner : Décider quoi faire ensuite
- Agir : Exécuter un outil, prendre une décision ou retourner une sortie
- Boucler : Revenir à la première étape
Cette boucle est essentielle. Un seul appel LLM — ce n’est pas un agent. C’est un prompt. Une boucle avec des points de contrôle, une gestion des erreurs et une logique de décision — c’est là que les agents deviennent industrialisables.
Le LLM est la couche de raisonnement. Ce n’est pas l’agent. Les outils sont ce qui permet à l’agent de changer le monde : appels API, requêtes de base de données, opérations sur fichiers, recherches. Sans outils, un agent ne fait que penser à voix haute.
Pourquoi les agents fonctionnent mieux que les prompts statiques
En novembre 2024, j’ai construit un agent pour auditer les schémas de bases de données pour un client fintech. Un prompt statique — même bon — a halluciné des structures de tables qui n’existaient pas. Un agent capable d’interroger le schéma de base de données réel, d’obtenir de vrais résultats, de les analyser et de revenir pour vérifier ? Cela a fonctionné.
Voici la comparaison :
Approche par prompt statique :
# Mauvais : Appel LLM unique pour analyser la base de données
Prompt système : « Vous êtes un auditeur de base de données. Analysez ce schéma pour des problèmes de sécurité. »
Entrée : [dump brut du schéma SQL, 5000 tokens]
Sortie : Recommandations génériques, noms de colonnes halluciné
Taux d'échec : ~35% sur les schémas complexesApproche par agent :
# Amélioré : Agent avec accès aux outils
1. L'agent reçoit la tâche : « Auditer cette base de données »
2. L'agent appelle l'outil : list_tables()
3. Données réelles retournées : [« users », « transactions », « audit_log »]
4. L'agent appelle l'outil : get_schema(« users »)
5. Schéma réel retourné avec les types de colonnes actuels
6. L'agent raisonne : « Je vois que user_id est INT mais je vois des valeurs NULL,
suggérant que les contraintes pourraient manquer »
7. L'agent appelle l'outil : check_constraints(« users »)
8. La boucle continue jusqu'à ce que le seuil de confiance soit atteint
Taux d'échec : ~4 % — seulement sur des cas limites que l'agent n'avait pas rencontrésL’agent reste ancré dans la réalité car il continue de vérifier. Les prompts statiques ne peuvent qu’halluciner une fois et s’y tenir.
Les trois parties essentielles dont vous avez besoin
1. Le moteur de raisonnement — le LLM qui décide quoi faire. Claude Sonnet 3.5 et GPT-4o fonctionnent tous deux ici. Sonnet est plus rapide et moins cher (~30% de coût de token en moins) ; GPT-4o est marginalement plus précis sur les cas limites. Pour la plupart des travaux sur les agents, Sonnet gagne.
2. Définitions et exécution des outils — les contrats API que votre agent peut appeler. Ceux-ci nécessitent des schémas clairs, une validation des entrées et une gestion des erreurs.
# Définition de l'outil (format OpenAI)
{
« type »: « function »,
« function »: {
« name »: « query_database »,
« description »: « Exécuter des requêtes SQL en lecture seule sur la base de données de production »,
« parameters »: {
« type »: « object »,
« properties »: {
« sql »: {
« type »: « string »,
« description »: « Instruction SELECT SQL uniquement. Pas d'INSERT/UPDATE/DELETE. »
}
},
« required »: [« sql »]
}
}
}3. La boucle et la gestion de l’état — ce qui se passe entre les appels d’outils, le nombre d’itérations autorisé, quand s’arrêter. C’est là que la plupart des projets d’agents échouent.
Là où les agents échouent réellement
Boucles infinies. C’est le cauchemar.
J’ai vu des agents se bloquer en appelant le même outil avec de légères variations car la sortie était ambiguë. Un agent de service client qui continuait à demander des clarifications, sans jamais résoudre le problème. Un agent analyste de données qui a interrogé la même table 47 fois à la recherche d’un champ inexistant.
Il faut des arrêts stricts : itérations maximales (généralement 8 à 12 pour les tâches complexes, 3 à 5 pour les simples), seuils de temps imparti et chemins explicites « Je ne peux pas résoudre cela ».
Deuxième mode d’échec : hallucination d’outil. L’agent invente des noms d’outils ou des paramètres qui n’existent pas. Cela arrive moins avec Claude Sonnet 3.5 qu’avec GPT-4 Turbo (observé ~2% contre ~6% dans mes tests), mais cela arrive quand même. Une validation stricte des outils en attrape la plupart.
Troisième : explosion du contexte. Un agent qui boucle 10 fois accumule 50 000 tokens de raisonnement, de résultats précédents et de sorties tentées. Le LLM commence à se dégrader. Résumez le contexte au fur et à mesure. Après 3 à 4 appels d’outils, distillez ce que vous savez dans un objet d’état compact.
Créez-en un aujourd’hui : agent pour tâche simple
Voici un agent minimal que vous pouvez exécuter en 20 minutes :
# Squelette d'agent Python utilisant l'API Claude
import anthropic
import json
client = anthropic.Anthropic()
tools = [
{
« name »: « search_web »,
« description »: « Rechercher des informations en ligne »,
« input_schema »: {
« type »: « object »,
« properties »: {
« query »: {« type »: « string »}
},
« required »: [« query »]
}
}
]
def run_agent(task):
messages = [{
