DeReAct : ce qu’il reste à vérifier sur ses résultats et son approche du contrôle

La proposition ne constitue pas encore un résultat confirmé

Dans la proposition examinée ici, DeReAct est présenté comme une conception visant à séparer deux décisions au sein d’un agent d’intelligence artificielle : déterminer si une action sur un outil est autorisée et vérifier si la tâche peut être considérée comme terminée. Cette idée est importante, car un agent ne se contente pas toujours de rédiger une réponse : il peut aussi appeler des outils, modifier des informations ou lancer des opérations. Toutefois, les sources vérifiées disponibles ne permettent pas de confirmer l’existence d’un article de recherche sur DeReAct contenant les détails décrits, ni de valider sa méthode ou ses résultats.

Cette limite concerne le cœur même du sujet. Aucun élément primaire vérifiable ne permet ici de contrôler les scores Pass@1, les variantes évaluées, les références de comparaison, les traces expérimentales ou la disponibilité du code et des prompts. Les améliorations supposées sur GAIA et SWE-bench Verified ne doivent donc pas être présentées comme des résultats démontrés. Il est également impossible d’attribuer au système des chiffres, des mécanismes de décision précis ou des garanties opérationnelles.

Il existe néanmoins des éléments de contexte général pour expliquer le problème de conception. ReAct est décrit comme une approche qui associe raisonnement et actions, notamment celles effectuées au moyen d’outils. Ce cadre aide à comprendre pourquoi la planification d’une action et son exécution peuvent s’inscrire dans un même flux. Il ne confirme toutefois ni l’existence de DeReAct ni sa capacité à résoudre les limites de cette approche.

Ce que l’architecture propose de séparer

La description de la proposition attribue deux fonctions à des composants distincts. Le Critic déciderait si l’action que l’agent prévoit d’effectuer doit être autorisée. Le Context Manager rassemblerait des informations sur l’état de la tâche et déterminerait si les éléments disponibles suffisent à certifier son achèvement. Cette séparation cherche à éviter que le même processus qui déclenche une action s’accorde aussi lui-même la permission de l’exécuter ou déclare sa réussite sans vérification indépendante.

Cette distinction est utile sur le plan conceptuel, mais elle ne suffit pas à évaluer un système. Pour comprendre ce que ferait concrètement un Critic, il faudrait notamment savoir quelles actions il considère comme sensibles, quelles règles il applique, quelles informations il reçoit et ce qui se passe lorsque sa décision est incertaine. Il faudrait également mesurer les refus incorrects — les actions valides qu’il empêche — et les autorisations incorrectes — les actions qu’il laisse passer alors qu’elles ne respectent pas la politique. Aucun résultat vérifié concernant DeReAct ne répond à ces questions.

La fonction attribuée au Context Manager soulève une autre question : qu’est-ce qui constitue une preuve d’achèvement ? Un résumé de la conversation peut omettre des changements effectués par un outil ; l’agent peut affirmer qu’une opération a réussi sans le démontrer. Pour vérifier la tâche, il faudrait savoir quel état le composant conserve, quels signaux externes il consulte et comment il traite les contradictions entre l’historique et le résultat fourni par un outil. La proposition suggère cette séparation, mais les informations disponibles ne permettent de confirmer ni son implémentation ni ses critères.

Les benchmarks ne remplacent pas la vérification de l’article

La proposition cite GAIA et SWE-bench Verified comme des tests dans lesquels des améliorations auraient été mesurées. Pour interpréter un score Pass@1, connaître le nom du benchmark ne suffit pas : il faut aussi connaître sa version, les modèles utilisés, les outils disponibles, le nombre de tentatives, les conditions d’exécution et la référence de comparaison. Il importe également de savoir si les écarts sont constants et comment les échecs sont comptabilisés. Sans confirmation de ces détails, un chiffre isolé ne permettrait pas d’attribuer le résultat au Critic, au Context Manager ou à un autre changement de configuration.

Les benchmarks évaluent des tâches délimitées dans des conditions expérimentales. Même un résultat reproductible dans l’un de ces tests décrirait les performances dans cet environnement ; il ne démontrerait pas automatiquement que l’agent est sûr pour des utilisateurs, des données sensibles ou des outils reliés à des systèmes réels. Pour étayer une affirmation sur la sécurité opérationnelle, il faudrait des évaluations spécifiques portant sur les politiques, les erreurs d’autorisation, les tentatives de manipulation et le comportement en situation d’incertitude.

Dans ce cas, la première étape n’est pas de déterminer si les améliorations sont importantes ou modestes, mais de confirmer ce qui a été mesuré et où. Les éléments vérifiés ne permettent pas de connaître les valeurs exactes de Pass@1 rapportées pour chaque variante de DeReAct, les références comparées ni le degré de reproductibilité du protocole. Tant que la documentation primaire pertinente n’est pas disponible, il ne convient pas de combler ces lacunes par des chiffres ou des détails déduits.

Coûts, erreurs résiduelles et généralisation

Séparer les décisions peut faciliter la supervision, mais aussi ajouter de la latence, des appels aux modèles et des points de défaillance. Un Critic trop strict pourrait bloquer des tâches légitimes ; un Critic trop permissif pourrait laisser passer des actions qui devraient être refusées. Un Context Manager disposant d’informations incomplètes pourrait certifier prématurément l’achèvement d’une tâche, tandis qu’un composant trop prudent pourrait la laisser ouverte alors que l’objectif est déjà atteint. Il s’agit de risques généraux qu’il faudrait mesurer, et non de défauts démontrés de DeReAct.

L’évaluation devrait inclure des cas limites et des défaillances, et pas seulement le pourcentage de tâches accomplies. Il faudrait notamment déterminer ce qui se passe lorsqu’un outil renvoie une erreur, lorsque l’agent reçoit des informations contradictoires ou lorsque l’état change après une action. Il serait également important de vérifier si le système distingue le fait d’avoir demandé une opération du fait d’avoir confirmé qu’elle a bien été exécutée.

La généralisation ne peut pas non plus se déduire de la seule mention de deux benchmarks. Une méthode peut obtenir de bons résultats sur des tâches de programmation ou d’utilisation d’outils dans des conditions contrôlées, et se comporter autrement face à des processus d’entreprise, à des systèmes ayant des permissions différentes ou à des données personnelles. Dans ses informations générales sur l’IA agentique, l’AEPD indique que ces systèmes peuvent accroître l’automatisation de traitements de données personnelles. Ce contexte rend pertinentes les questions relatives aux limites et à la supervision, mais ne constitue pas une preuve concernant la conception ou la sécurité de DeReAct.

Ce qui manque pour achever la vérification

Pour faire de cette proposition un sujet vérifiable, il faut une source primaire accessible qui identifie le travail et décrive la version évaluée. Il faudrait ensuite examiner la méthode : comment la politique du Critic est définie, d’où provient son contexte, quels états le Context Manager conserve et quel critère il applique pour certifier une tâche. Sans ces éléments, les noms des composants expriment une intention, pas nécessairement le comportement d’une implémentation.

La vérification des résultats nécessite, au minimum, les tableaux complets des scores Pass@1 pour chaque variante, la configuration des références de comparaison et une explication du déroulement des évaluations sur GAIA et SWE-bench Verified. La disponibilité du code, des prompts et des traces faciliterait la reproduction de l’expérience ; si certains de ces éléments ne sont pas publiés, il faudrait préciser explicitement ce qui ne peut pas être reproduit. Il n’est pas valable de supposer qu’ils sont disponibles, pas plus que d’affirmer que l’étude ne les fournit pas sans avoir consulté l’article.

En attendant cette documentation, la conclusion doit rester limitée : dissocier l’autorisation des actions de la vérification de l’achèvement est une proposition qui peut être expliquée et évaluée comme principe de conception, mais ses résultats expérimentaux et ses garanties ne peuvent pas être confirmés ici. Cette distinction compte pour toute personne qui compare des outils ou envisage de déployer des agents : une architecture prometteuse n’équivaut ni à une validation indépendante ni à une évaluation des risques dans le contexte d’utilisation concerné.

Pour poursuivre l’analyse, il est utile de distinguer trois questions : que peut faire un agent, quels contrôles applique-t-il avant d’agir et comment le résultat est-il vérifié ? Une explication générale de ReAct aide à contextualiser la première ; une comparaison de systèmes devrait examiner la deuxième ; une évaluation de découverte devrait vérifier la troisième à l’aide d’éléments propres à chaque outil connecté. Aucun de ces axes ne modifie l’état de vérification de DeReAct : le document primaire et ses résultats restent à confirmer.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.