Quels papiers Agentic AI lire pour comprendre 2026 ?

Je lirais d’abord ALE, ClawBench, Code as Agent Harness, AutoResearchClaw et AREX. Ces papiers montrent un basculement net de l’Agentic AI vers l’exécution réelle, vérifiable, longue, et capable de s’améliorer sans supervision permanente.

Pourquoi 2026 change le sujet ?

L’année 2026 marque le passage de la théorie à l’exécution concrète pour l’Agentic AI.

La question n’est plus seulement de savoir si un modèle peut appeler un outil. C’est trop simple maintenant. La vraie question, c’est est-ce qu’il peut terminer un workflow long, produire un livrable vérifiable, agir sur des sites web réels, détecter ses erreurs, les réparer, puis s’améliorer avec le temps.

Pour les équipes data, IA, automatisation et business, ça change tout. On sort des démos propres, avec trois étapes bien cadrées et un joli résultat en sortie. On rentre dans le terrain. Le terrain, c’est des sessions web qui expirent, des formulaires mal fichus, des documents ambigus, de l’authentification, des actions irréversibles, des états intermédiaires qu’il faut tracer, et surtout de la vérification.

Je vois ça très souvent chez les clients. Le vrai sujet n’est presque jamais la beauté du prompt. C’est la robustesse de l’exécution. C’est la capacité à reprendre après une erreur. C’est aussi la capacité à prouver que le résultat est correct, pas juste plausible.

Les cinq papiers à lire se complètent bien, parce qu’ils attaquent le problème par des angles différents :

• Agents’ Last Exam regarde les workflows professionnels vérifiables. C’est important, parce qu’un agent utile en entreprise doit produire quelque chose qu’on peut contrôler.
• ClawBench teste les agents sur le web réel. Pas un bac à sable parfait. Le web réel, avec ses frictions, ses pièges, ses pages qui changent.
• Code as Agent Harness parle de l’infrastructure d’exécution. Le harness, c’est l’environnement qui encadre l’agent, lance ses actions, garde l’état, vérifie, relance si besoin.
• AutoResearchClaw s’inscrit dans la famille des systèmes de recherche autonomes. L’idée générale, c’est de comprendre comment des agents peuvent mener des tâches de recherche avec plus d’autonomie.
• AREX appartient aussi à cette famille de travaux sur la recherche autonome. Je le vois comme une autre pièce du puzzle pour comprendre où vont les agents capables d’explorer, raisonner et produire.

Ce qui m’intéresse en 2026, ce n’est pas l’agent qui impressionne en vidéo. C’est l’agent qui tient dans un vrai process, avec des garde-fous, des preuves, des reprises sur erreur, et un résultat qu’une équipe peut accepter sans croiser les doigts.

Que mesure Agents Last Exam ?

Agents’ Last Exam mesure la capacité d’un agent IA à finir des workflows professionnels complets et vérifiables, pas juste à produire une réponse plausible. C’est ça qui m’intéresse dans ce papier. On sort du “le modèle a l’air malin” pour aller vers “est-ce qu’il livre vraiment quelque chose d’utilisable”.

Le benchmark a été construit avec l’apport de plus de 250 experts, sur plus de 1 000 tâches, couvrant 55 sous-domaines et 13 industries. Ce n’est pas un petit jeu de questions-réponses. L’idée, c’est de tester des agents sur des tâches longues, avec plusieurs étapes, des décisions intermédiaires, des outils à utiliser, et surtout un livrable final qu’on peut vérifier.

La vérifiabilité est centrale ici. Un agent peut écrire un joli résumé, générer un plan convaincant, ou simuler une analyse. Mais dans une entreprise, ça ne suffit pas. Si le livrable final est faux, incomplet, ou impossible à contrôler, la valeur opérationnelle tombe vite. J’ai vu ça chez des clients avec des prototypes très séduisants en démo, mais qui perdaient leur intérêt dès qu’on leur demandait de gérer des cas réels, avec des données sales, des contraintes métier, et une sortie attendue précise.

Le point dur, c’est l’exécution long terme. Un agent peut réussir trois étapes, puis rater la quatrième. Et si la quatrième est celle qui valide le contrat, met à jour le CRM, prépare le reporting ou déclenche une action métier, l’échec final annule presque tout le travail avant. C’est brutal, mais c’est comme ça que la production fonctionne.

Le chiffre marquant reste sobre, mais il pique un peu. En configuration standard, les agents obtiennent environ 2,6 % de réussite complète sur le palier le plus difficile. Ça ne veut pas dire que les agents sont inutiles. Ça veut dire que les benchmarks réalistes montrent encore un écart massif entre une démonstration impressionnante et un système fiable en production.

Ce benchmark est aussi pensé comme évolutif. C’est important parce que les modèles progressent vite. Un test figé devient vite obsolète. Là, l’intérêt est de suivre la montée en capacité des agents sur des tâches qui ressemblent vraiment au travail.

Objectif du benchmark	Mesurer la réussite complète de workflows professionnels vérifiables.
Taille	Plus de 1 000 tâches, 55 sous-domaines, 13 industries, avec plus de 250 experts impliqués.
Difficulté	Très élevée, surtout sur les tâches longues avec livrable final contrôlable.
Enseignement principal	Les agents progressent, mais la production exige bien plus qu’une bonne réponse intermédiaire.

Pourquoi ClawBench est plus dur ?

ClawBench est plus dur parce qu’il teste les agents dans le web réel, avec ses frictions, ses interfaces dynamiques et ses actions à risque. C’est exactement là que les agents arrêtent d’avoir l’air brillants en démo, et commencent à montrer ce qu’ils savent vraiment faire.

Le benchmark couvre 153 tâches sur 144 plateformes. On n’est pas sur un petit environnement propre, figé, pensé pour être gentil avec un modèle. On parle de shopping, de voyages, de recrutement, de finance, de travail de bureau. Avec tout ce qui va avec : authentification, pages qui changent, formulaires longs, documents à ouvrir ou modifier, menus bizarres, pop-ups, filtres, calendriers, interfaces non standardisées.

Et ça, je le vois souvent chez les clients. Le problème n’est pas seulement de “répondre juste”. Le problème, c’est de tenir une trajectoire dans un environnement qui résiste. Se connecter. Comprendre où cliquer. Ne pas remplir le mauvais champ. Ne pas valider une action irréversible. Revenir en arrière sans casser le flux.

ClawBench collecte cinq couches d’information pendant les tests, et c’est une grosse différence. Ça permet d’auditer finement ce qui s’est passé, pas juste de regarder le score final.

Relecture de session	Je peux revoir le déroulé complet de la tâche.
Captures d’écran	Je comprends ce que l’agent a réellement vu.
Trafic HTTP	Je vois ce qui a été envoyé ou reçu côté web.
Messages de l’agent	Je suis son raisonnement et ses décisions.
Actions du navigateur	Je sais où il a cliqué, saisi, navigué, ou dérapé.

Le papier ajoute aussi une interception légère pour bloquer les soumissions irréversibles pendant les tests. C’est important. Évaluer un agent sur le web, ce n’est pas lui laisser acheter n’importe quoi, envoyer un formulaire RH ou déclencher une opération sensible juste pour voir s’il y arrive. La sécurité fait partie de l’évaluation.

La meilleure performance rapportée reste basse : 33,3 % de tâches complétées par le modèle le plus performant mesuré. Ça remet les pendules à l’heure.

ALE regarde plutôt les workflows professionnels vérifiables. ClawBench expose la friction du web réel. Les deux racontent la même chose : l’Agentic AI doit être testée sur des tâches longues, observables et risquées, pas seulement sur des conversations bien propres.

À quoi sert Code as Agent Harness ?

Code as Agent Harness sert à considérer le code comme l’infrastructure d’exécution de l’agent, pas seulement comme le résultat final produit par l’IA.

L’idée centrale, c’est que le code devient le substrat runtime de l’agent. Runtime, ça veut dire l’environnement qui fait tourner le système pendant son exécution. Pas juste un script généré à la fin, mais une couche vivante qui relie le raisonnement, les outils, l’état, les contrôles et les mécanismes de vérification.

Dit simplement, au lieu d’avoir un agent qui “discute” avec des outils de façon un peu fragile, on construit un environnement d’exécution qui organise les appels, garde le contexte, contrôle les étapes et permet de vérifier le travail. C’est moins spectaculaire qu’une démo où l’agent répond en langage naturel, mais c’est beaucoup plus proche de ce qu’il faut pour produire un vrai système.

Je reste prudent sur les détails, parce que sans avoir tout le papier sous les yeux, je ne vais pas prétendre décrire chaque mécanisme. Mais la direction est claire. On peut lire cette approche comme une architecture en couches :

• Interface de harness : Elle définit comment l’agent interagit avec son environnement.
• Orchestration des outils : Elle décide quels outils appeler, dans quel ordre, avec quels paramètres.
• Gestion de l’état : Elle conserve ce qui a déjà été fait, les résultats, les erreurs, les décisions.
• Vérification : Elle contrôle que la sortie est cohérente, exploitable, conforme aux attentes.
• Réparation éventuelle : Elle permet de relancer, corriger ou contourner une étape quand ça casse.

Pour moi, c’est une idée importante pour la production. Un agent sans harness solide peut avoir l’air intelligent en démo, puis devenir instable dès qu’on l’expose à des cas réels. Le prompt donne l’intention. Le harness donne la structure d’exécution. Dans mes missions data et automatisation, c’est souvent cette couche qui fait la différence entre un prototype sympa et un système qu’on peut laisser tourner sans regarder l’écran toutes les dix minutes.

Vision naïve	Vision harness
Réponse texte produite par l’agent	Réponse inscrite dans un flux d’exécution contrôlé
Appel outil lancé quand le modèle le propose	Appel outil orchestré avec paramètres, contraintes et ordre précis
État implicite dans la conversation	État conservé dans une couche dédiée et réutilisable
Vérification laissée au modèle ou à l’utilisateur	Vérification intégrée dans le processus
Reprise après erreur improvisée	Reprise prévue avec correction, relance ou fallback

Que retenir d AutoResearchClaw et AREX ?

AutoResearchClaw et AREX représentent la partie recherche autonome de cette évolution de l’Agentic AI. C’est là qu’on passe d’agents qu’on évalue, qu’on encadre et qu’on observe, à des systèmes qui commencent à prendre en charge une vraie boucle de recherche.

Je reste prudent ici, parce que les informations disponibles les présentent comme des systèmes de recherche autonomes, sans qu’on ait besoin d’inventer des détails internes. Ce qui compte, c’est leur place dans la séquence. On a d’abord des travaux comme ALE et ClawBench, qui posent la question de l’évaluation des agents. Est-ce qu’ils tiennent dans le temps ? Est-ce qu’ils savent utiliser des outils ? Est-ce qu’ils se plantent proprement ou dangereusement ? Puis on a Code as Agent Harness, qui va plutôt du côté de l’infrastructure, avec l’idée qu’un agent doit pouvoir s’exécuter dans un cadre contrôlé.

La suite logique, c’est ça : Des systèmes capables de mener une recherche, de vérifier leur travail, de corriger certaines erreurs et de s’améliorer au fil du temps. Pas juste répondre à une question. Chercher, comparer, documenter, revenir sur une hypothèse, produire une synthèse plus fiable. C’est exactement le genre de trajectoire que les entreprises regardent de près, parce que beaucoup de travail intellectuel ressemble déjà à ça.

Dans une boîte, la recherche autonome peut être utile sur plusieurs sujets très concrets :

• Explorer un marché, un corpus documentaire ou une base de connaissances interne.
• Comparer des options techniques, juridiques, commerciales ou opérationnelles.
• Documenter une décision avec les sources utilisées et les limites connues.
• Synthétiser vite, sans perdre complètement la traçabilité.

Mais il y a un piège énorme. Si l’agent produit vite quelque chose qui a l’air solide, avec un ton propre, une structure propre, des conclusions propres, on peut se faire avoir. J’ai déjà vu ce problème chez des clients avec des assistants beaucoup plus simples : Le document paraît bon, donc personne ne vérifie vraiment. La recherche autonome n’a de valeur que si elle reste reliée à des preuves, à des sources, à des critères de validation et à des garde-fous.

Au fond, ces cinq papiers ne racontent pas juste des progrès de modèles. Ils dessinent une architecture mentale pour une Agentic AI utile : Évaluer, exécuter, observer, vérifier, réparer, apprendre. C’est probablement ça qu’il faut garder en tête pour comprendre 2026.

Alors, qu’est-ce qu’on en fait maintenant ?

Je retiens surtout une chose : l’Agentic AI devient sérieuse quand on arrête de juger les agents sur des réponses jolies et qu’on les teste sur des workflows longs, réels et vérifiables. ALE montre la difficulté des livrables professionnels. ClawBench rappelle que le web réel casse vite les démos. Code as Agent Harness remet l’infrastructure au centre. AutoResearchClaw et AREX pointent vers des systèmes de recherche plus autonomes. Pour moi, le bon réflexe est simple : mesurer, tracer, vérifier, sécuriser. Le bénéfice pour vous, c’est d’éviter les gadgets IA et de construire des agents vraiment exploitables.

FAQ

• Qu’est-ce que l’Agentic AI en 2026 ?
  L’Agentic AI désigne des systèmes IA capables d’enchaîner des actions, d’utiliser des outils, de gérer un état de travail et de viser un résultat. En 2026, le sujet se déplace vers l’exécution réelle : finir des workflows longs, agir sur le web, vérifier les livrables et corriger certaines erreurs.
• Pourquoi Agents’ Last Exam est important ?
  Agents’ Last Exam est important parce qu’il teste des workflows professionnels vérifiables à grande échelle. Avec plus de 1 000 tâches, 55 sous-domaines et 13 industries, il montre que les agents ont encore beaucoup de mal à réussir complètement les tâches les plus difficiles.
• Quelle est la différence entre ALE et ClawBench ?
  ALE évalue surtout la capacité à terminer des workflows professionnels vérifiables. ClawBench teste les agents sur le web réel, avec des plateformes, des formulaires, des pages dynamiques, de l’authentification et des documents. Les deux approches sont complémentaires.
• Pourquoi le Code as Agent Harness compte pour les agents IA ?
  Parce qu’il place le code au centre de l’exécution. Le code ne sert pas seulement à produire un livrable, il peut organiser les outils, l’état, les contrôles et la vérification. C’est une base plus solide pour passer d’une démo IA à un système exploitable.
• Les agents IA sont-ils prêts pour la production ?
  Ils peuvent l’être sur des périmètres bien cadrés, mais les benchmarks cités montrent que les tâches longues et réelles restent difficiles. Pour aller en production, il faut tracer les actions, limiter les risques, vérifier les résultats et prévoir des mécanismes de reprise.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer des prototypes IA aux systèmes robustes, mesurables et utiles. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer, automatiser ou fiabiliser vos projets IA, vous pouvez me contacter.