Le meilleur modèle d’IA ne résout que 12% des tâches professionnelles dans le nouveau benchmark GDPx

Le meilleur modèle actuel résout 12% des tâches professionnelles réelles. Le chiffre ressemble à une coquille, surtout si votre dépôt contient déjà un projet écrit par une IA. C’est pourtant le résultat du nouveau benchmark GDPx de SemiAnalysis.

Quel est ce benchmark

SemiAnalysis est connu pour ses analyses du marché des semi-conducteurs et de l’économie de l’IA. Le 2 novembre, le cabinet a publié GDPx. Ses auteurs, Max Kahn, Andrew Megalaa et Dylan Patel, fondateur du cabinet, l’ont conçu comme le test le plus exigeant des capacités des agents. Il n’évalue ni les connaissances factuelles ni l’aptitude à résoudre des problèmes d’olympiades, mais la réalisation de tâches que les entreprises sont prêtes à rémunérer.

Ce choix est révélateur : le cabinet aborde l’IA sous l’angle économique, du coût des puces à celui des centres de données et des tokens. Pour lui, la question centrale n’est pas « le modèle est-il intelligent ? », mais « est-il rentable ? ». D’où l’accent mis sur les tâches rémunérées.

Claude Opus 5.5, d’Anthropic, obtient le meilleur résultat global. Ce sont les fameux 12%. Les autres modèles font donc moins bien.

Une réserve importante : l’extrait dont nous disposons ne détaille pas la méthodologie, qu’il s’agisse de la composition des tâches, du mode d’évaluation ou des résultats des autres modèles. Avant de citer ce chiffre dans une présentation, consultez la publication originale de SemiAnalysis.

Pourquoi les agents peinent autant

Une véritable tâche professionnelle ne se résume pas à une réponse. Elle demande une succession d’étapes : comprendre le contexte, choisir les outils, exécuter, vérifier, corriger. Un calcul simple montre le risque. Si un agent réussit chaque étape dans 90% des cas, il ne mènera à bien une séquence de dix étapes que dans environ 35% des cas. Il s’agit d’une illustration, pas de données de GDPx, mais le mécanisme est le même : les erreurs s’accumulent et, dans un contexte commercial, un résultat « presque correct » ne vaut souvent rien.

Cela explique l’écart entre les impressions et le chiffre. Quand vous demandez à un modèle d’écrire une fonction ou d’ébaucher un script, il vise souvent juste. Quand vous lui confiez une tâche entière, avec un brief incomplet, du code écrit par d’autres et l’obligation de livrer un résultat opérationnel, le tableau change. Un projet écrit par une IA qui « semble fonctionner » et une tâche achevée pour laquelle le client a payé sont deux choses différentes.

Que faire

Pour les développeurs : ne jugez pas un agent sur une démo. Réunissez 20–30 de vos tâches réelles, assorties de critères d’acceptation clairs, et soumettez-les au modèle. Vous aurez ainsi votre propre mini-GDPx. Mesurez la proportion de tâches achevées sans correction humaine : cet indicateur est plus honnête que n’importe quelle note moyenne.

Pour les responsables produit : prévoyez une intervention humaine dans le processus. Si une fonctionnalité promet de fonctionner en totale autonomie, son périmètre réel pourrait être plusieurs fois plus restreint que celui annoncé dans les présentations marketing. Intégrez le coût de la vérification et des corrections à vos calculs de rentabilité.

Pour les fondateurs : 12% ne justifie pas d’abandonner les projets d’agents. C’est une raison de choisir des cas d’usage ciblés, avec des séquences courtes et une vérification peu coûteuse, et de ne pas vendre un « remplaçant de salarié ». Un benchmark dont le meilleur score reste aussi bas a d’ailleurs un intérêt : il ne sature pas. La marge de progression est réelle, et il permettra de suivre les progrès des prochains modèles.

Limites

Un benchmark ne représente pas toute la réalité. Ses auteurs ont défini ce qui constitue une « tâche professionnelle réelle », et un autre ensemble de tâches donnera d’autres chiffres. Par ailleurs, SemiAnalysis est un cabinet d’analyse, pas un laboratoire indépendant : il faut donc examiner la reproductibilité des résultats et vérifier si le jeu de tâches est ouvert. Mais le signal est clair : il reste un écart considérable entre « écrire du code » et « accomplir le travail ». Et cet écart mérite d’être mesuré sur vos propres tâches.