Modèles IA agentiques : ce qui change vraiment sous le capot
Depuis 2024, chaque annonce de nouveau modèle est accompagnée du mot « agentique ». Claude est une IA agentique. GPT-5 est agentique. Llama 4 est agentique. Le terme est devenu un argument marketing à part entière — ce qui rend d’autant plus difficile de comprendre ce qu’il recouvre réellement.
La réalité est plus précise : un modèle agentique n’est pas simplement un modèle « plus puissant ». C’est un modèle doté d’un ensemble de primitives techniques spécifiques, conçues pour fonctionner dans une boucle d’action continue plutôt que dans un échange question-réponse. Ces primitives n’existaient pas — ou fonctionnaient mal — dans les modèles de la génération précédente.
Cet article démonte les quatre ruptures qui font concrètement basculer un modèle dans la catégorie agentique, pourquoi les modèles antérieurs ne pouvaient pas y prétendre honnêtement, et ce qui reste encore à résoudre.
Des modèles conçus pour répondre, pas pour agir
Pour comprendre ce qui a changé, il faut revenir à ce que les premiers grands modèles de langage étaient réellement : des systèmes d’anticipation du prochain token. Très sophistiqués, capables de prouesses impressionnantes en génération de texte — mais fondamentalement réactifs. On pose une question, on obtient une réponse. Le modèle ne fait rien entre les deux.
IA agentique : une architecture pensée pour le dialogue, pas pour l’exécution
Les LLM classiques fonctionnent selon un schéma simple : un prompt entre, une complétion sort. Il n’y a pas de notion d’étape, d’outil, de vérification du résultat, ni de reprise sur erreur. Le modèle optimise pour la cohérence textuelle de sa réponse, pas pour l’efficacité d’une action dans le monde réel.
Quand les premières tentatives d’agents ont émergé — AutoGPT en 2023 en est l’exemple le plus connu — elles reposaient entièrement sur des architectures externes qui forçaient le modèle à simuler une boucle d’action : un orchestrateur appelait le modèle en boucle, injectait les résultats des actions précédentes dans le prompt, et espérait que le modèle « comprenne » ce qu’il était censé faire ensuite. Le modèle lui-même n’avait aucune primitive pour gérer cela nativement. Le résultat : des agents instables, coûteux en tokens, et qui s’égaraient facilement sur les tâches longues.
4 096 tokens : une fenêtre trop courte pour tenir une tâche longue
GPT-3 opérait avec une fenêtre de contexte de 4 096 tokens — soit environ 3 000 mots. GPT-3.5 Turbo montait à 16 000 tokens, mais avec un output plafonné à 4 096 tokens. GPT-4, dans ses premières versions, proposait deux variantes : 8K et 32K tokens.
Ce que ces chiffres signifient en pratique : dès qu’une tâche dépassait quelques échanges ou impliquait des documents un peu longs, le modèle perdait littéralement le début de la conversation. Les premières étapes d’un workflow disparaissaient du contexte. L’agent ne pouvait plus se souvenir de ce qu’il avait décidé deux étapes plus tôt, ni des erreurs qu’il avait rencontrées.
Un agent qui oublie son propre historique ne peut pas planifier sur la durée. La limite de contexte n’était pas un détail technique — elle était une contrainte architecturale qui rendait les tâches longues structurellement impossibles à tenir.
Sans tool calling natif : le JSON comme rustine
La capacité à appeler des outils externes de façon fiable est au cœur de tout système agentique. Un agent qui ne peut pas interagir avec des APIs, des bases de données ou des services tiers ne peut rien faire dans le monde réel.
Les premiers modèles n’avaient pas cette capacité nativement. La solution de contournement consistait à demander au modèle, dans le prompt, de produire un JSON bien formé que l’orchestrateur analyserait ensuite pour décider quelle action lancer. Le problème : le modèle ne « produisait pas du JSON » — il générait du texte qui ressemblait à du JSON. La différence est fondamentale.
OpenAI a introduit le function calling en juin 2023 avec GPT-4. Mais même après cette introduction, la fiabilité sur des schémas JSON complexes restait inférieure à 40 % pour les versions initiales. Une tâche sur trois générait une sortie malformée. Dans un workflow automatisé, chaque sortie incorrecte signifie une erreur à gérer, une logique de retry à coder, ou une interruption du processus.
Les quatre ruptures qui font basculer un modèle en modèle agentique
Les modèles récents — Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro, Llama 4 — ne sont pas juste « plus intelligents ». Ils embarquent des primitives spécifiquement conçues pour l’agentique, qui n’existaient pas ou ne fonctionnaient pas dans les générations précédentes. Ces primitives sont au nombre de quatre.
Tool calling natif : du JSON inférieur à 40 % de fiabilité à 100 %
Avec l’introduction des Structured Outputs (OpenAI, août 2024) et du tool calling natif dans Claude, le modèle ne génère plus du texte qui ressemble à du JSON — il génère directement la structure, avec une garantie de conformité au schéma demandé.
GPT-4o avec Structured Outputs atteint 100 % de fiabilité sur les évaluations de conformité JSON. Claude Sonnet 4 atteint 92 % de précision dans les tests de sélection d’outil — la capacité à choisir le bon outil parmi un ensemble disponible, au bon moment. C’est le meilleur score parmi les modèles évalués à cette date.
Une nuance mérite d’être signalée : forcer un schéma JSON rigide peut, dans certains cas, réduire la qualité du raisonnement du modèle. Les modèles récents gèrent mieux cette tension — ils structurent leur sortie sans dégrader leur réflexion — mais c’est un paramètre à surveiller lors de la conception des workflows.
Extended thinking : allouer un budget de réflexion avant d’agir
Le raisonnement en chaîne (chain-of-thought) est connu depuis plusieurs années : en demandant au modèle de « réfléchir étape par étape », on améliore sa précision sur les tâches complexes. Mais cette approche reste limitée : elle mobilise uniquement les connaissances internes du modèle, sans interaction avec l’environnement.
L’extended thinking, introduit avec Claude 3.7 Sonnet et généralisé dans Claude 4, va plus loin. Le modèle se voit allouer un budget de réflexion — un nombre de tokens « internes » qu’il peut utiliser pour explorer le problème avant de répondre ou d’agir. Ce raisonnement est visible, auditable, et se déroule avant chaque action dans la boucle.
Concrètement : là où un modèle antérieur choisissait un outil par réflexe probabiliste, un modèle avec extended thinking peut évaluer plusieurs options, anticiper les conséquences d’une action, et ajuster son plan. Sur les tâches de développement logiciel — un bon indicateur de la complexité agentique — Claude Sonnet 4.6 atteint 79,6 % sur SWE-bench Verified, contre 52 % pour GPT-4.
Contexte long : tenir un workflow de plusieurs heures sans perdre le fil
Claude Opus 4.6 supporte jusqu’à 1 million de tokens en contexte. Llama 4 pousse cette limite à 10 millions de tokens — le plus grand contexte disponible sur le marché à ce jour. GPT-5.4 et Gemini 3.1 Pro s’alignent également sur le million de tokens.
Ce que cela change en pratique : un agent peut désormais traiter un audit de 500 pages, parcourir l’intégralité d’un historique de tickets CRM, ou analyser un codebase complet en une seule passe — sans découpage manuel, sans perte d’information entre les blocs. La trace complète des actions précédentes reste accessible tout au long du workflow.
Claude Sonnet 4.6 va plus loin encore en termes d’autonomie documentée : le modèle maintient sa focalisation sur une tâche pendant plus de 30 heures sans perte de contexte notable. Pour Opus 4, des workflows impliquant plusieurs milliers d’étapes successives ont été documentés.
L’évolution est spectaculaire comparée aux 4 096 tokens de GPT-3 — mais la section sur les limites actuelles reviendra sur un point important : une fenêtre plus grande ne garantit pas une meilleure qualité de traitement.
Interleaved thinking : la boucle Think → Act → Think qui change tout
C’est probablement la rupture la plus structurante, et la moins visible dans les communications marketing. L’interleaved thinking, introduit en bêta avec Claude 4, permet au modèle d’alterner raisonnement et action dans la même séquence, plutôt que de raisonner une fois puis d’enchaîner les actions.
Le schéma antérieur : penser → décider → exécuter (séquentiellement). Le schéma avec interleaved thinking : penser → agir → observer → repenser → agir → observer. La boucle se déroule de façon continue, à chaque étape.
L’impact direct : quand un outil renvoie un résultat inattendu, ou qu’une API échoue, le modèle ne continue pas aveuglément sur sa trajectoire initiale. Il observe l’anomalie, raisonne sur ce qu’elle implique, et ajuste son plan avant l’étape suivante. C’est ce qui distingue un agent qui récupère ses erreurs d’un agent qui les propage jusqu’à un échec terminal plusieurs étapes plus loin.
Dans les workflows longs, la propagation d’erreurs est l’une des causes principales d’échec. L’interleaved thinking réduit ce risque structurellement, au niveau du modèle lui-même — sans nécessiter une logique de gestion d’erreurs complexe dans l’orchestrateur.
Tableau comparatif : d’une génération à l’autre
| Critère | GPT-3.5 Turbo | GPT-4 (initial) | Claude 2.1 | Claude Sonnet 4.6 | GPT-5.4 | Gemini 3.1 Pro | Llama 4 |
|---|---|---|---|---|---|---|---|
| Fenêtre de contexte | 16K (output 4K) | 8K–32K | 200K | 200K (output 128K) | 1M | 1M | 10M |
| Tool calling natif | Non | Partiel (juin 2023) | Non | Oui | Oui | Oui | Oui |
| Fiabilité JSON | Faible | < 40 % | Faible | Elevée | Elevée | Elevée | Elevée |
| Extended / deep thinking | Non | Non | Non | Oui | Oui (variante Thinking) | Oui | Non |
| Autonomie longue durée | Non | Non | Non | 30h+ documentées | Non documentée | Non documentée | Non documentée |
| Open source | Non | Non | Non | Non | Non | Non | Oui |
Le tableau illustre le saut de génération. GPT-4 initial était un modèle remarquable pour la compréhension et la génération de texte — mais il manquait de trois des cinq primitives agentiques listées ici. Claude 2.1 avait une fenêtre de contexte impressionnante mais aucune des mécaniques de raisonnement et d’action qui définissent l’agentique. Les modèles récents embarquent l’ensemble.
Deux points méritent d’être notés. Sur SWE-bench Verified — le benchmark de référence pour les tâches agentiques complexes — Gemini 3.1 Pro atteint 80,6 % et Claude Sonnet 4.6 atteint 79,6 %, les deux modèles se situant au même niveau de performance agentique. GPT-5.4 ne publie pas de score SWE-bench Verified, mais se distingue sur d’autres métriques agentiques : 75 % sur OSWorld — premier modèle à dépasser l’expert humain (72,4 %) sur les tâches de contrôle de bureau autonome. Llama 4 apporte une dimension distincte : en tant que modèle open source auto-hébergeable, il permet de garder les données en interne tout en bénéficiant d’une fenêtre de contexte de 10 millions de tokens — un avantage décisif pour les organisations soumises à des contraintes de souveraineté des données.
Ce que ça ne résout pas encore
Les ruptures décrites ci-dessus sont réelles. Elles changent substantiellement ce qu’on peut construire avec ces modèles. Mais elles ne résolvent pas tout — et plusieurs limites structurelles subsistent.
Context rot : plus de tokens ne garantit pas plus de précision
Une fenêtre de contexte d’un million de tokens ne signifie pas qu’un modèle traite un million de tokens avec la même attention. Au-delà d’un certain seuil, la précision et la capacité de rappel dégradent — c’est le phénomène connu sous le nom de « context rot ». Le modèle peut techniquement lire tout le contexte, mais sa cohérence et sa fiabilité diminuent à mesure que la longueur augmente.
Les stratégies de mitigation existent : compaction côté serveur, checkpointing, écriture de l’état en stockage externe entre les étapes. Mais elles impliquent une conception active du workflow — elles ne sont pas gérées automatiquement par le modèle.
Avoir accès à un modèle avec 10 millions de tokens de contexte ne dispense donc pas de réfléchir à ce qu’on met réellement dans ce contexte, et dans quel ordre.
La conception du workflow reste le vrai différenciateur
Les modèles agentiques abaissent considérablement le seuil technique d’entrée. Là où il fallait coder une logique de retry complexe, un parseur JSON robuste, une gestion fine des erreurs — le modèle prend en charge une partie de ce travail. Mais il ne se substitue pas à une architecture bien pensée.
Un workflow mal conçu — mauvaise décomposition des tâches, mauvaise gestion de l’état, dépendances non anticipées — produira des résultats médiocres même avec le meilleur modèle disponible. Comme le relèvent les analyses sur les systèmes agentiques en conditions réelles, beaucoup de modèles performent bien sur des tâches contrôlées et se dégradent significativement sur des workflows plus complexes, avec plus de distracteurs ou d’imprévus.
Le modèle est une brique. L’architecture du système reste la responsabilité du concepteur.
Autonomie ne signifie pas infaillibilité
Claude Sonnet 4.6 peut tenir 30 heures sur une tâche. GPT-5.4 et Gemini 3.1 Pro enchaînent des dizaines d’appels d’outils en parallèle. Ces capacités sont réelles — et elles ouvrent des cas d’usage qui n’étaient pas envisageables il y a deux ans. Mais l’autonomie accrue s’accompagne d’une exigence accrue de supervision.
Plus un agent est autonome, plus les erreurs qu’il commet ont le temps de se propager avant d’être détectées. Un agent qui travaille 30 heures sans supervision peut avoir pris une mauvaise décision à l’heure 2 et construit 28 heures de travail sur une base incorrecte. L’autonomie est un levier de productivité, pas une garantie de qualité.
Les équipes qui déploient ces systèmes en production intègrent systématiquement des points de contrôle humains sur les décisions à fort impact, indépendamment des capacités du modèle. Ce n’est pas une limitation temporaire en attendant des modèles meilleurs — c’est une exigence de conception durable.
La distinction entre un LLM classique et un modèle agentique n’est pas une question de puissance brute ou de score sur un benchmark. C’est une question de primitives : tool calling natif, raisonnement intégré dans la boucle d’action, contexte suffisant pour tenir une tâche longue, et capacité à se corriger en cours de route.
Ces primitives existaient de façon partielle ou bricolée dans les modèles antérieurs. Elles sont désormais intégrées nativement dans les modèles récents — et c’est ce qui rend les systèmes agentiques réellement viables en production, là où ils ne l’étaient pas auparavant.
La bonne question pour une organisation qui automatise n’est plus « est-ce que ce modèle peut faire ça ? » — les capacités sont désormais au rendez-vous. La question est « est-ce que mon workflow est conçu pour en tirer parti ? » C’est là que se joue la différence entre un projet pilote qui impressionne et un système qui tient en production.
Pour aller plus loin sur les fondements de l’IA agentique, notre article L’émergence de l’IA agentique pose les bases du concept. Pour comprendre le protocole qui permet aux agents de se connecter à des outils externes, l’article sur le MCP détaille comment ce standard change concrètement les intégrations.
