Dossier AGI · Intermédiaire · 10 min
Mesurer les progrès vers l’AGI : benchmarks, leurs limites, saturation et contamination
Les benchmarks mesurent des capacités précises, pas une distance vers l’AGI. Comprenez leurs limites, la saturation et la contamination pour lire les scores.
Les benchmarks mesurent la réussite de systèmes d’IA sur des épreuves définies ; ils ne donnent pas directement une distance restante vers l’AGI. Pour interpréter un progrès, vous devez examiner les tâches, les conditions d’évaluation, les ressources mobilisées et les possibilités de contamination. Une mesure crédible associe plusieurs tests à une analyse de la généralisation, des erreurs et du coût.
Définir ce que l’on cherche à mesurer
Un benchmark réunit des tâches, une procédure de passation et une règle de notation. Son score répond à une question précise : avec cette configuration, quelle performance le système obtient-il sur ces épreuves ? Passer de cette observation à une affirmation sur l’intelligence générale exige des arguments supplémentaires.
Il faut notamment distinguer la compétence acquise, l’étendue des compétences et la capacité à en acquérir de nouvelles. Répondre à une question scientifique mobilise des connaissances ; découvrir les règles d’un environnement inconnu demande de l’adaptation. Un système peut progresser sur la première dimension sans progresser autant sur la seconde.
La fiabilité constitue encore une autre dimension. Une solution correcte obtenue après de nombreuses tentatives ne décrit pas le même comportement qu’une réussite reproductible sans aide. Pour une application concrète, le temps nécessaire, les interventions humaines et les conséquences des échecs comptent aussi.
Avant de lire un classement, formulez donc l’affirmation que vous voulez vérifier. Cherchez-vous un meilleur assistant documentaire, un système capable d’apprendre une règle nouvelle ou un agent autonome sur des tâches longues ? Le dossier AGI et recherche distingue ces questions, qui ne se résument pas à une seule échelle.
Des définitions de l’intelligence qui orientent les tests
Dans On the Measure of Intelligence, publié en novembre 2019, François Chollet propose de mesurer l’intelligence par l’efficacité d’acquisition de compétences, en tenant compte des connaissances préalables, de l’expérience et de la difficulté de généralisation. Sa critique porte sur l’assimilation entre maîtrise d’une tâche et intelligence : davantage d’entraînement peut améliorer la première sans établir à lui seul une meilleure capacité d’adaptation.
Cette perspective conduit à demander ce que le système savait avant l’épreuve et ce qu’il doit découvrir pendant celle-ci. Elle ne signifie pas que les connaissances seraient inutiles. Elle exige de distinguer leur contribution de celle de l’apprentissage face à la nouveauté.
D’autres cadres privilégient une description des capacités observables. Dans Levels of AGI for Operationalizing Progress on the Path to AGI, Meredith Ringel Morris et ses coauteurs distinguent notamment profondeur de performance et largeur des capacités, puis discutent leur relation avec l’autonomie. Une performance élevée dans un domaine étroit ne suffit donc pas à caractériser la généralité.
Ces approches déplacent l’accent : l’une insiste sur l’efficacité d’acquisition, l’autre organise les niveaux de capacités. Elles ne fournissent pas une conversion commune entre score et AGI. La page sur la généralisation approfondit cette différence, essentielle pour comprendre pourquoi des chercheurs choisissent des épreuves différentes.
Les familles d’épreuves et leurs angles morts
Un ensemble de tests doit couvrir des capacités complémentaires. Le tableau suivant décrit des familles d’épreuves plutôt qu’un palmarès : la portée d’un résultat dépend toujours du protocole particulier.
| Famille d’épreuves | Ce que l’on observe | Atout principal | Limite à examiner |
|---|---|---|---|
| Questions de connaissances | Réponses à des questions définies | Correction standardisable | Séparation difficile entre savoir et adaptation |
| Problèmes à solution vérifiable | Résultat mathématique, logique ou informatique | Vérification moins subjective | Représentativité des problèmes choisis |
| Tâches de développement logiciel | Modification d’un programme puis validation | Résultat exécutable | Couverture et qualité des tests |
| Environnements interactifs | Actions successives et réactions aux observations | Évaluation de l’exploration | Dépendance à l’interface et au budget |
| Préférences humaines | Choix entre plusieurs réponses | Mesure de l’utilité perçue | Influence du style et des évaluateurs |
| Apprentissage de règles nouvelles | Réussite après démonstrations ou exploration | Observation de l’adaptation | Définition de la nouveauté et des acquis |
Ces familles ne doivent pas nécessairement être fusionnées. Une moyenne peut masquer un déficit important : un agent performant en programmation peut rester fragile lorsqu’il doit comprendre une demande ambiguë ou reconnaître qu’une information manque.
Le choix des tâches exprime aussi une conception de l’usage. Des questions scolaires, des réparations de logiciels et des interactions avec un ordinateur ne représentent pas les mêmes activités. La difficulté seule ne garantit pas qu’une épreuve soit informative sur l’intelligence générale.
Pour lire un palmarès destiné au choix d’un modèle, l’article Benchmark LLM : comment lire les classements complète cette perspective. Ici, l’enjeu est plus large : déterminer ce que chaque résultat autorise à affirmer sur les capacités du système.
Ce qu’ARC-AGI apporte à la mesure
La présentation officielle de la série ARC-AGI rattache ses épreuves à l’acquisition de compétences sur des tâches inconnues. Elle insiste sur la distinction entre une compétence spécialisée et la capacité de généralisation. Cette orientation en fait un point de référence pour étudier l’adaptation, plutôt qu’un simple inventaire de connaissances.
Dans une tâche de transformation de grilles, par exemple, le système doit trouver une règle compatible avec les démonstrations et l’appliquer à une nouvelle entrée. La difficulté pertinente ne tient pas seulement au calcul : il faut choisir une représentation et départager des hypothèses.
L’interprétation dépend toutefois de l’expérience préalable. Résoudre une tâche jamais vue n’est pas équivalent à découvrir une famille de problèmes inconnue. Des entraînements sur des tâches apparentées, des données synthétiques ou des procédures de recherche spécialisées peuvent contribuer au résultat ; leur présence doit être documentée.
Un score ARC-AGI ne mesure pas, à lui seul, toutes les capacités linguistiques, sociales, physiques ou professionnelles. Il ne suffit pas non plus à établir l’autonomie opérationnelle d’un agent. La page de référence ARC-AGI détaille les épreuves et leurs protocoles.
La bonne lecture consiste à relier chaque réussite à son mécanisme et à ses conditions. Le système découvre-t-il une règle avec peu d’information ? Combien de recherche lui faut-il ? La méthode conserve-t-elle son efficacité lorsque la présentation ou la famille de tâches change ?
Saturation : quand le score distingue moins bien les systèmes
Un benchmark sature lorsque les résultats se rapprochent du plafond au point de rendre les différences difficiles à interpréter. Les derniers échecs peuvent alors peser fortement sur le classement, même s’ils reflètent une ambiguïté de notation ou une particularité du jeu de test.
La saturation n’est pas une preuve de contamination. Une communauté peut apprendre à résoudre une classe de problèmes par des progrès transférables. Inversement, un benchmark peut rester difficile tout en ayant été exposé dans les données d’entraînement. Il faut examiner ces phénomènes séparément.
Un test proche de son plafond peut encore servir de contrôle de régression. Il devient moins utile pour départager les systèmes les plus performants. Pour retrouver de l’information, on peut modifier la distribution des tâches, augmenter l’exigence de fiabilité ou comparer les ressources nécessaires à réussite comparable.
Créer une épreuve plus difficile ne suffit cependant pas. Une consigne obscure ou une correction contestable augmente les échecs sans améliorer la mesure. Il faut vérifier que les difficultés ajoutées correspondent à la capacité recherchée.
Enfin, remplacer un benchmark casse la continuité des scores. Une baisse sur une nouvelle épreuve n’indique pas nécessairement une régression du système. Pour suivre les progrès, conservez des évaluations communes entre les périodes et expliquez ce que le nouveau test permet d’observer.
Contamination : exposition, mémorisation et optimisation
La contamination des benchmarks compromet la séparation entre ce qui sert à apprendre et ce qui sert à évaluer. Elle peut provenir de données publiées sur le Web, de corrigés, de traductions ou de reformulations intégrées à l’entraînement. Elle n’implique pas nécessairement une intention de tromper.
Il faut distinguer plusieurs situations. Une question exacte peut avoir été vue avec sa réponse ; seule une question proche peut avoir été rencontrée ; les développeurs peuvent aussi avoir ajusté leur système après avoir observé de nombreux résultats sur le même test. Ces mécanismes n’ont pas les mêmes effets.
L’exposition ne prouve pas automatiquement une mémorisation utile, et une bonne réponse ne prouve pas une exposition. Le problème pratique est de déterminer si le score surestime la performance sur des tâches nouvelles comparables.
Dans ConStat, publié en mai 2024, Jasper Dekoninck, Mark Niklas Müller et Martin Vechev proposent d’étudier cette inflation en comparant un benchmark à des références, relativement à d’autres modèles. Leur approche s’intéresse à la performance qui ne se transfère pas aux épreuves comparables, plutôt qu’à la seule présence d’exemples dans un corpus.
Une chute après reformulation reste toutefois à interpréter : la variante peut avoir changé la difficulté. Les indices doivent être croisés. Sans audit complet, une formulation précise vaut mieux qu’un verdict absolu : contrôles réalisés, données accessibles et incertitudes restantes doivent être explicités.
Préserver des tests nouveaux sans perdre la reproductibilité
Les épreuves publiques permettent d’examiner les erreurs, de reproduire les calculs et de contester la notation. Leur publication facilite aussi leur incorporation dans de futurs entraînements. Les épreuves privées réduisent cette exposition, mais limitent l’audit indépendant.
Une stratégie consiste à séparer les fonctions : un ensemble public pour développer les méthodes, un ensemble réservé pour comparer les systèmes et des tâches renouvelées pour vérifier le transfert. Cette séparation doit aussi concerner les corrigés et les retours détaillés transmis aux participants.
Un test privé peut devenir un outil de développement si les soumissions sont répétées et les retours trop précis. Limiter les tentatives, conserver un historique et réserver une évaluation finale réduit ce risque. La confidentialité seule ne garantit donc pas l’indépendance.
Les tâches générées automatiquement offrent du renouvellement, mais leur quantité ne garantit pas leur diversité. Un générateur peut produire des variantes superficielles d’un même mécanisme. Il faut examiner les familles de règles, les stratégies possibles et les raccourcis disponibles.
Pour documenter ces choix, indiquez la période de création, les conditions d’accès, les contrôles de doublons et la politique de renouvellement. Un jeu créé récemment apporte un indice de nouveauté ; il ne démontre pas que les idées nécessaires étaient absentes de l’expérience du système.
Comparer le système complet et ses ressources
Un résultat attribué à un modèle peut dépendre d’une chaîne entière : instructions, outils, mémoire, recherche de solutions, sélection des réponses et critères d’arrêt. Si ces éléments changent, vous comparez des systèmes différents, même lorsque le modèle sous-jacent reste identique.
Le site officiel de SWE-bench distingue plusieurs ensembles d’épreuves et présente aussi une vue où les modèles utilisent un environnement commun. Cette distinction illustre l’intérêt de séparer le choix des tâches de celui de l’architecture d’exécution.
Le nombre de tentatives mérite une attention particulière. La réussite de la première réponse, la présence d’une bonne solution parmi plusieurs propositions et la capacité du système à sélectionner cette solution sont des mesures différentes. Un évaluateur qui connaît la réponse ne doit pas être confondu avec une sélection autonome.
Le budget doit accompagner le score : durée, consommation, appels aux outils et interventions humaines. Augmenter les ressources peut améliorer la réussite ; cela ne rend pas le progrès sans intérêt, mais en change la portée pratique.
Pour comparer deux systèmes, demandez donc une courbe reliant ressources et performance, plutôt qu’un seul meilleur résultat. Le guide d’évaluation d’un agent IA applique cette logique aux usages concrets, où une réussite trop lente ou trop coûteuse peut ne pas répondre au besoin.
Lire l’incertitude et les erreurs derrière la moyenne
Un score agrégé dépend des tâches retenues. Si celles-ci proviennent surtout d’une même famille, leur nombre peut donner une impression trompeuse de couverture. Des variantes proches ne constituent pas autant d’observations indépendantes d’une capacité générale.
Lorsque vous comparez des systèmes, examinez les mêmes tâches et les désaccords entre leurs résultats. Répétez aussi les exécutions si la procédure comporte de l’aléatoire. Une différence minime peut tenir au tirage des réponses, à la sélection des problèmes ou aux règles de correction.
La notation doit elle-même être examinée. Une réponse exacte peut être pénalisée pour son format ; une solution informatique peut passer des tests incomplets ; une réponse persuasive peut convaincre un juge malgré une erreur. Un audit d’exemples permet de repérer ces limites.
Le programme Holistic Evaluation of Language Models, présenté en novembre 2022, défend une évaluation couvrant plusieurs scénarios et plusieurs dimensions, dont la calibration, la robustesse et l’efficacité. Son apport méthodologique est de rendre visibles des compromis que l’exactitude seule masque.
Dans un rapport, séparez donc le taux de réussite, les erreurs graves, les refus pertinents et les abandons. Ajoutez des résultats par catégorie et des exemples analysés. Une moyenne sert à résumer ; elle ne remplace ni la description du périmètre ni l’étude des défaillances.
Construire un tableau de bord des progrès vers l’AGI
Une évaluation durable doit permettre de repérer des progrès sans prétendre les convertir en pourcentage d’AGI. Elle peut suivre la largeur des tâches réussies, l’adaptation à la nouveauté, la stabilité, l’autonomie et les ressources nécessaires.
Dans sa présentation du cadre cognitif publiée le 17 mars 2026, Google DeepMind propose également d’appuyer la mesure sur une taxonomie de capacités cognitives. Cette démarche constitue une autre façon d’organiser la couverture des évaluations ; elle doit elle aussi être jugée sur les tests qu’elle permet de construire.
Pour chaque nouvelle publication, cherchez des réponses documentées à ces questions :
- Quelle capacité est visée, et quelles capacités restent hors du périmètre ?
- Les tâches sont-elles nouvelles pour le système et pour ses développeurs ?
- Le protocole, les ressources et les critères d’arrêt sont-ils comparables ?
- Le gain se retrouve-t-il sur d’autres tâches de même nature ?
- Les erreurs restantes sont-elles comprises et les résultats reproductibles ?
La preuve devient plus solide lorsque des gains convergent sur des épreuves indépendantes, avec des ressources décrites et un transfert vérifié. Elle reste limitée au périmètre observé. Pour suivre les progrès vers l’AGI, le résultat utile est donc un profil de capacités accompagné de ses incertitudes, plutôt qu’un seuil isolé présenté comme un verdict.
Pages liées
Questions fréquentes
Existe-t-il un benchmark qui prouve qu’une IA a atteint l’AGI ?
Un tel verdict suppose d’abord une définition de l’AGI et des critères d’acceptation partagés. Un test peut établir une capacité dans son périmètre ; son nom ou sa difficulté ne lui donnent pas automatiquement une portée générale.
Un benchmark saturé devient-il inutile ?
Il peut rester utile pour détecter une régression ou comparer des systèmes moins performants. Pour départager les meilleurs systèmes, il faut toutefois des épreuves ou des contraintes qui apportent encore de l’information.
Peut-on détecter la contamination sans connaître les données d’entraînement ?
Des méthodes recherchent des indices dans les probabilités du modèle ou dans les écarts entre épreuves originales et variantes. Leur interprétation dépend d’hypothèses statistiques : elles ne constituent pas un audit exhaustif du corpus.
Pourquoi deux classements donnent-ils des résultats différents ?
Ils peuvent porter sur des tâches, des budgets ou des systèmes de notation différents. Vérifiez aussi si le résultat concerne un modèle seul, un agent avec des outils ou une configuration spécialisée.
Un meilleur score permet-il de prévoir la date de l’AGI ?
Une prévision demande un modèle explicite reliant les mesures observées aux capacités encore manquantes. Prolonger une courbe de scores sans justifier ce lien ne fournit pas une échéance fiable.