OpenAI a testé des agents du quotidien sur 169 tâches et identifié leur point faible

La plupart des benchmarks d’IA sont pratiques pour les développeurs, mais ressemblent peu à la vie réelle. Le modèle répond à une question, le système compare sa réponse à une référence, puis un pourcentage supplémentaire apparaît dans un tableau. Or, l’utilisateur n’a généralement pas besoin d’un paragraphe correct. Il doit trouver une crèche après un déménagement, préparer le budget familial, remplir une demande ou organiser la prise en charge d’un proche.

OpenAI a présenté LifeVal, un benchmark composé de 169 tâches personnalisées dans lesquelles l’agent doit non seulement raisonner, mais aussi agir : lire l’historique des conversations, prendre en compte des fichiers, utiliser un navigateur, modifier des données dans des applications et produire des livrables prêts à l’emploi. L’objectif est de mesurer l’écart entre « le modèle explique bien » et « la tâche a réellement été accomplie ».

À quoi ressemble l’évaluation en pratique

Prenons un exemple : une famille vient de déménager et demande de trouver une crèche. Un chatbot classique énumérerait des critères généraux de sélection. Dans LifeVal, l’agent reçoit l’adresse, les préférences de la famille, les conversations antérieures et un accès à l’environnement de travail. Il doit trouver des options adaptées, vérifier les conditions d’admission, établir une liste restreinte et signaler les décisions qui ne doivent pas être prises sans intervention humaine.

Ce n’est pas la force de persuasion du texte qui est évaluée. Le modèle évaluateur voit la demande initiale, les critères de la tâche, les fichiers créés et les changements d’état du système. Si l’agent affirme avoir rempli un formulaire alors que celui-ci est resté vide, aucun point ne lui est accordé pour cette action. Toute tentative d’accéder à l’interface interne de l’environnement de test plutôt qu’au site ordinaire est considérée comme une intrusion et annule le résultat.

Le jeu de tâches a été constitué à partir d’études sur l’emploi du temps et d’une enquête auprès des utilisateurs. L’étude a réuni 3 837 personnes et la cartographie finale a couvert 148 catégories de tâches quotidiennes : finances personnelles, déménagement, recherche d’emploi, achats, éducation, santé, aide aux proches et accès aux services publics. Les tâches elles-mêmes ont été conçues par des personnes disposant d’une expérience pratique, puis chacune a passé au moins trois étapes de vérification manuelle.

Là où les agents échouent encore

Le problème le plus révélateur est la fourniture d’informations ou de recommandations erronées. Un agent peut exécuter avec assurance une longue chaîne d’actions, tout en oubliant un détail important mentionné dans une ancienne conversation avec l’utilisateur. Pour une tâche quotidienne, cela suffit à rendre tout le résultat inutile : proposer un logement hors budget, commander un produit contenant un allergène ou choisir un service inadapté.

Il existe aussi un conflit subtil entre autonomie et sécurité. Les modèles les plus prudents s’arrêtent plus souvent à la limite de la décision : ils ne finalisent pas une action sans confirmation ou indiquent qu’ils n’ont pas pu vérifier les données. Dans un tableau de résultats, cela ressemble à un échec, alors que, dans un produit réel, c’est parfois exactement ainsi qu’un agent fiable doit se comporter.

LifeVal ne peut pas non plus être considéré comme une mesure définitive de la qualité. L’enquête a été menée aux États-Unis et en anglais ; le jeu ne reflète donc pas tous les pays ni toutes les habitudes. La valeur des tâches repose sur la disposition déclarée à payer, et non sur plusieurs années d’observation des comportements réels. Certaines données web évoluent avec le temps, si bien que des exécutions répétées peuvent produire des résultats différents. Enfin, deux évaluateurs automatiques reposent sur les propres modèles d’OpenAI, ce qui impose de la prudence dans l’interprétation des chiffres.

Ce que les équipes produit doivent en retenir

L’idée centrale de LifeVal est plus utile qu’un classement précis des modèles. Les tests d’acceptation d’un agent doivent être construits autour du résultat effectivement obtenu : le fichier a-t-il été créé, le champ requis a-t-il été modifié, les contraintes de l’utilisateur ont-elles été respectées, l’agent a-t-il demandé confirmation avant une action risquée ? La mémoire, la récupération après erreur et la capacité à s’arrêter honnêtement doivent être testées séparément.

Pour les développeurs, cela signifie passer d’une collection de démonstrations séduisantes à des scénarios reproductibles, dotés d’un état initial, d’un résultat mesurable et d’un journal d’actions. Pour le produit, il faut définir à l’avance où l’agent est autorisé à agir seul et où il doit rendre la main à l’utilisateur. C’est à ces frontières que se décide si le système deviendra un véritable assistant ou restera une simple interface très bavarde.