DocOps vient de sortir, un framework d’évaluation déterministe pour les agents autonomes qui manipulent des documents numériques. Présenté dans un paper sur arXiv (2607.19865) par l’équipe d’icip-cas, avec code et page de projet publics.

L’écart qu’il comble est concret. SWE-bench mesure les agents sur le code, et là on sait ce qui fonctionne et ce qui ne fonctionne pas. Mais les opérations sur les documents, les PDF, les Word, les formulaires, restaient sans banc d’essai systématique. Si en entreprise tu envisages de confier à un agent la rédaction d’un contrat ou la modification d’un long rapport, tu n’avais pas de moyen standard pour savoir si le modèle que tu as choisi était à la hauteur.

DocOps décompose les opérations sur les documents en dimensions atomiques et niveaux de complexité croissants, s’inspirant de pratiques réelles. L’évaluation est vérifiable de manière déterministe, sans dépendre d’un LLM arbitre qui pourrait fausser les résultats (un problème qu’on a déjà vu dans d’autres benchmarks).

Les résultats du paper sont honnêtes sur où nous en sommes : même les configurations les plus avancées montrent des limites profondes sur les tâches avec beaucoup de dépendances et un horizon long. Les trois modes de défaillance identifiés sont la partie la plus utile pour qui construit : perte d’état sur les tâches longues, vérification sémantique superficielle et modification destructrice des métadonnées structurelles. Ce sont exactement les défauts qui te gâchent la journée quand un agent corrompt un fichier que tu ne peux pas récupérer.

Si tu veux l’examiner de près, le repo est sur GitHub (github.com/icip-cas/DocOps) avec la page de projet sur docopsbench.github.io.

En détail

Le point de départ est une vraie carence dans l’évaluation des agents. SWE-bench, dont on a parlé comme banc d’essai pour le code, a montré comment évaluer un agent sur des tâches vérifiables et réalistes. DocOps applique le même principe à un domaine qui touche presque tous les professionnels : les documents.

La structure du benchmark repose sur une taxonomie hiérarchique qui décompose les opérations sur les documents en dimensions atomiques (actions élémentaires isolées) puis les recombine en workflows de complexité croissante. L’idée est de passer du geste isolé (change cette valeur dans le formulaire) au processus long (mets à jour un rapport de vingt pages en maintenant la cohérence entre les sections, les références et les métadonnées). La vérification est déterministe : on contrôle l’état final du document contre un résultat attendu, sans s’en remettre à un modèle qui vote.

Les trois modes de défaillance que le paper isole méritent attention car c’est le type de problème qu’on découvre en production, pas en démo :

• Long-term state tracking collapse : l’agent perd la trace de ce qu’il a déjà fait et de comment les parties du document se connectent. Ça arrive quand la tâche demande de maintenir la cohérence entre des sections éloignées.
• Shallow semantic verification : l’agent vérifie seulement en surface que le résultat semble correct, sans vérifier que le sens soit cohérent avec l’intention du document.
• Destructive editing of structural metadata : l’agent modifie ou supprime les informations structurelles du fichier (styles, références, champs cachés) en travaillant, ce qui détruit le document d’une manière qui n’est pas immédiate mais se manifeste après.

Ces modes de défaillance convergent avec ce qu’on racontait le 20 juillet : l’orchestration et la vérification comptent plus que le modèle seul (/fr/radar/agent-failures-orchestration-over-model-three-papers). DocOps le démontre sur un domaine nouveau et le fait avec une méthode vérifiable.

Pour qui évalue un agent pour des tâches documentales, la leçon est directe : teste sur des tâches longues et couplées, pas juste sur des opérations isolées. Le paper suggère que c’est là que tout s’effondre. Et si tu ne sais pas par où commencer pour construire ton propre banc de test, la leçon du cours sur comment évaluer sans benchmark est le bon endroit.

Limites : le paper est frais (publié le 22 juillet 2026) et l’abstract ne reporte pas de scores spécifiques par modèle. Le code est public, mais pour voir les tables complètes il faut aller au repo ou au PDF. Le nombre de upvotes sur Hugging Face (2) suggère que c’est encore peu circulé, et ça se lit comme une contribution de recherche, pas comme un verdict établi.