Méthodologie d'Argusic

Comment Argusic vérifie si de vrais logiciels fonctionnent, et comment il note les AI coding agents. Chaque règle est publique à dessein : tout l'intérêt est que n'importe qui puisse vérifier notre travail. Toute modification de ces règles est inscrite dans le journal des modifications en bas de page, prend effet au cycle de test suivant et ne s'applique jamais rétroactivement.

1. En bref

• Nous prenons de vrais projets open source et demandons à des AI agents de les

installer, de les lancer et de les déboguer sans aucune aide humaine, exactement comme le ferait un nouvel ingénieur le premier jour.

• Chaque test est enregistré de bout en bout. Chaque chiffre publié renvoie à

son log et à son enregistrement du terminal.

• Chaque projet reçoit un verdict simple : il fonctionne, il fonctionne avec

des services mock, ou nous n'avons pas pu le vérifier.

• Les agents sont comparés dans des conditions identiques ; trois exécutions

chacun, le résultat médian compte, et les résultats très incohérents sont signalés et mis de côté.

• Nous ne vendons aucun agent et n'acceptons aucun argent pour modifier un

résultat. Argusic est l'arbitre.

• La mesure est automatisée. La rédaction ne l'est pas : aucun modèle n'écrit

une phrase sur ce site, chaque chiffre d'une page est un modèle de phrase rempli à partir d'une exécution enregistrée, et une personne valide avant toute publication. Voir comment ce site est rédigé.

2. La question à laquelle cela répond

Face à un vrai projet open source, un AI coding agent peut-il, entièrement seul, l'installer, le lancer, surmonter les erreurs et vérifier que le logiciel fonctionne, comme un ingénieur à son premier jour, sans aucune aide humaine ?

3. Pourquoi des projets récents

Les benchmarks statiques se dégradent à mesure que leurs réponses fuient dans les données d'entraînement. SWE-rebench (Badertdinov et al., 2025) a fait passer les mêmes agents sur SWE-bench Verified et sur des tâches collectées après la publication de ce benchmark, et les scores ont beaucoup bougé : son tableau 2 indique que DeepSeek-V3-0324 résout 39.7% de SWE-bench Verified et 21.3% de l'ensemble filtré par date, soit un écart de 18 points de pourcentage pour un seul modèle. Argusic teste des projets en tendance au cours des dernières semaines, avec un pool secret renouvelé chaque mois, si bien qu'il n'y a rien à mémoriser.

4. Ce qui est mesuré

Nous mesurons une seule chose : la capacité autonome à faire fonctionner de vrais logiciels. Chaque agent testé est une combinaison fixe d'un modèle à une version épinglée, d'un harness à une version épinglée, des instructions standard publiées d'Argusic, et de limites de temps et de ressources identiques. Chaque agent reçoit exactement les mêmes conditions.

5. Agents testés

Le premier cycle est en cours. La liste des agents sera publiée avec le premier classement. Chaque agent est une configuration fixe et épinglée, présentée sous une identité Argusic neutre ; ses versions exactes sont enregistrées et conservées afin que chaque chiffre du classement remonte à la configuration précise qui l'a produit, et qu'un résultat puisse être reproduit par Argusic sur demande (voir « Comment reproduire un résultat »).

6. Le pool de projets

• Pool public de 80% : la liste et les versions exactes (hashes de commit) sont

publiées avant chaque cycle.

• Pool secret de 20% : choisi parmi les projets en tendance au cours des 30

derniers jours, publié seulement à la fin du cycle et renouvelé chaque mois. C'est ce qui empêche d'optimiser les agents pour le test.

• Critères de sélection : une licence permissive, un README, une diversité de

langages et de difficulté, et la possibilité de fonctionner à un niveau de base sans compte payant.

6a. Ce qui peut être un projet testé

Un projet testé est une chose qu'on peut demander à un agent de mettre en place et d'exécuter. Argusic en teste un seul type aujourd'hui et est conçu pour en ajouter d'autres sans rien changer à la manière dont un résultat est obtenu : la grille de notation, les règles de preuve et le vocabulaire des verdicts sont identiques d'une source à l'autre, de sorte qu'un chiffre issu d'une source signifie la même chose qu'un chiffre issu d'une autre.

Source	Ce que « fonctionne » signifie ici	État
Dépôt open source	Cloner le commit épinglé, installer, lancer, et vérifier qu'il fait le travail que décrit son propre README	Utilisée. 3669 projets testés
Modèle Hugging Face	Télécharger le modèle à une révision épinglée et exécuter l'inférence exactement comme sa fiche de modèle le documente, sur un worker GPU. Il fonctionne lorsque l'extrait documenté produit une sortie sur une machine propre sans que le testeur le réécrive	Utilisée. 1 projet testé
Hugging Face Space	Construire et lancer le Space à partir de sa propre définition, puis atteindre son interface et mener à bien l'interaction qu'il annonce	Déclarée, non commencée
Package publié (npm, PyPI)	Installer la version épinglée dans un projet vide et exécuter le quickstart de son propre README	Déclarée, non commencée
Outil d'éditeur	Installer et lancer le build publié par l'éditeur lui-même, en suivant uniquement les instructions de l'éditeur	Déclarée, non commencée
Template cloud préconstruit	Déployer le template comme le documente sa propre fiche et vérifier qu'il démarre et sert ce qu'il annonce, sans que le testeur le corrige au préalable	Déclarée, non commencée
Image de conteneur	Récupérer l'image à un digest épinglé et exécuter la commande donnée par sa propre description, puis vérifier qu'elle fait ce que cette description affirme	Déclarée, non commencée
Serveur MCP	Installer et démarrer le serveur comme documenté, connecter un client, et confirmer qu'il liste les outils qu'il annonce et y répond	Déclarée, non commencée

La colonne État ci-dessus n'est pas écrite à la main. Elle est lue dans la base de données à chaque affichage de cette page : une source apparaît comme utilisée dès qu'un projet publié de ce type a une exécution enregistrée, et le nombre est affiché. C'est la même règle que suivent tous les autres chiffres de ce site, et elle signifie que personne n'a à penser à mettre cette page à jour lorsqu'une nouvelle source produit son premier résultat.

Deux choses distinguent un projet Hugging Face d'un dépôt, et toutes deux sont enregistrées avec l'exécution au lieu d'être gommées. Il lui faut un worker GPU, donc son coût par tentative est plus élevé et son budget est décidé séparément. Et une fiche de modèle documente souvent un extrait de code plutôt qu'une application, si bien que le comportement vérifié est « l'extrait documenté a produit une sortie », et non « le produit fonctionne » : la page de l'exécution dit lequel des deux, en ces termes, et le score s'obtient de la même façon.

Le tableau indique « non commencé » plutôt que « bientôt disponible », et c'est voulu. Une source compte comme utilisée le jour où une vraie exécution de ce type est enregistrée avec ses preuves, et pas un jour plus tôt. Jusque-là, la ligne est une déclaration de périmètre, jamais de résultats : aucune page n'affiche de verdict, de nombre, de classement ou de carte de partage pour une source qui n'a pas été exécutée, et ce tableau est le seul endroit où une source prévue est nommée.

7. Une mesure

1. Une machine propre à usage unique (son environnement exact est publié). Elle

n'accepte aucune connexion entrante et est détruite à la fin de l'exécution. L'accès réseau sortant n'est pas filtré dans cette édition ; ce qui limite une exécution, c'est la machine à usage unique et les règles de la clé de modèle sous la liste. La machine ne récupère que le commit épinglé, pas l'historique du projet, qui ne fait pas partie du test.

2. L'agent reçoit une seule mission : faire fonctionner ce projet, selon les

instructions standard publiées.

3. Une limite de temps. Chaque exécution reçoit l'un de trois budgets

exactement (le tableau sous la liste), et le budget attribué à une exécution est affiché sur sa page.

4. Trois exécutions indépendantes ; le résultat médian compte. Si les trois

résultats s'écartent de plus de 30%, la série est signalée comme instable et mise de côté pour le classement de ce cycle.

5. Chaque exécution conserve un log complet et un enregistrement complet du

terminal, publiés avec les résultats.

6. Les applications de bureau sont lancées sur un écran virtuel à l'intérieur de

la machine (depuis la v1.1). « Lancée » signifie que le processus principal de l'application a démarré sur cet écran et est resté actif, ou a répondu à une commande de version ou d'aide. Aucun clic n'est fait ; la mesure porte sur le démarrage du logiciel sur une machine vierge, la même question que pour tous les autres projets. L'agent a pour consigne de ne pas envoyer d'images à son modèle (depuis la v1.3) : le modèle standard n'accepte que du texte, et une capture d'écran jointe à un message a mis fin à la session avant le rapport.

Les budgets de temps du point 3 :

Niveau	Budget
standard	90 minutes
heavy	120 minutes
gpu	120 minutes

Le budget standard était de 45 minutes avant la v1.3 : la première semaine, 36 des 38 dépassements de délai d'une même journée étaient des builds encore en cours une fois le budget entièrement consommé, il a donc été doublé. Le niveau heavy existe depuis la v1.2 pour un projet que l'Owner marque comme lourd, ou dont le dépôt dépasse 500 MB selon GitHub, parce qu'un gros jeu ou une grosse application de bureau a besoin de ce temps pour se construire. Un projet qui a besoin d'un GPU reçoit les mêmes 120 minutes.

Les trois valeurs ci-dessus ne sont pas décoratives. scripts/check-ttl-methodology.sh lit ce tableau et le compare aux budgets avec lesquels l'orchestrateur est réellement configuré, et make test échoue s'ils divergent. Ce contrôle existe parce qu'entre le 2026-09-06 et le 2026-09-11, le budget GPU du système en production était de 240 minutes alors que cette page indiquait 120, et que rien ne comparait les deux (ISSUE-072).

La clé de modèle. Un agent a besoin d'une clé pour appeler son modèle, et une exécution fait tourner le code d'un projet non fiable, donc cette clé est l'identifiant qu'il importe le plus de limiter. Pour les agents qui accèdent à leur modèle via la couche de routage d'Argusic, chaque exécution reçoit sa propre clé, créée pour cette seule exécution. Plafond de dépenses de la clé de modèle de chaque exécution : 3 USD. La clé est supprimée quand l'exécution se termine, est annulée ou dépasse son délai, et un balayage planifié supprime toute clé qui n'appartient plus à une tâche en cours. Si la clé d'une exécution ne peut pas être créée, l'exécution ne démarre pas et est relancée ; une clé partagée n'est jamais utilisée à la place. Les agents qui utilisent le service propre du fabricant de leur modèle l'appellent avec une clé partagée détenue par Argusic, et non une clé par exécution ; les passer à des clés par exécution figure dans notre backlog. La ligne du plafond ci-dessus est lue par scripts/check-cost-methodology.sh, qui fait échouer make test si elle diverge de la valeur configurée, pour la même raison que les budgets de temps.

8. Notation, sur 100

• Installation réussie : 30
• Lancement ou tests réussis : 30
• Récupération après erreur : 20, proportionnellement aux erreurs rencontrées

qui ont été corrigées de manière valide

• Profondeur de vérification : 20 (vérifié en fonctionnement réel : 20 ;

vérifié avec des services mock : 12 ; non vérifié : 0)

Le résultat d'une exécution est l'un des suivants :

Résultat	Signification
pass_full	A fonctionné et a été vérifié pour de vrai
pass_mock	A fonctionné, vérifié avec des services mock
fail	Ne s'est pas installé ou ne s'est pas lancé
timeout	A manqué de temps

Les quatre lignes de notation laissent certains cas implicites. Ils sont tranchés ici et pas seulement dans le code, car une règle que personne ne peut lire est une règle que personne ne peut vérifier. La notation est un programme déterministe, avec des tests couvrant chaque règle ci-dessous ; aucun modèle d'IA n'intervient dans la notation, à aucun moment.

• Si rien ne s'est mal passé, la récupération après erreur obtient les 20

points. Attribuer zéro pénaliserait un agent parce que le projet s'est installé proprement, ce qui mesure le projet, pas l'agent.

• Sinon, la récupération après erreur est la part des erreurs rencontrées qui

ont été corrigées, sur 20. Une exécution ne peut jamais déclarer plus d'erreurs corrigées que d'erreurs rencontrées ; une telle exécution est rejetée.

• Le lancement suppose l'installation : un agent qui n'a pas installé le

logiciel n'a pas pu le lancer.

• La profondeur de vérification suppose le lancement : sans lancement réussi,

il n'y a rien à vérifier, donc la profondeur obtient 0.

• Installé et lancé mais non vérifié n'est pas une réussite. Cela obtient 80

sur 100 et compte quand même comme un échec, car la question est de savoir si l'agent a vérifié que le logiciel fonctionne, et un lancement non vérifié n'y répond pas.

• Un dépassement de délai obtient 0 sur chaque ligne. Ce n'est pas un crédit

partiel : l'agent n'a pas terminé dans la même limite que tous les autres agents.

• Une exécution sans log et enregistrement complets est invalide et est

relancée. Elle n'est jamais notée et n'atteint jamais le classement.

9. De nombreuses exécutions à un seul score de classement

La notation évalue une paire projet-agent. Le classement a besoin d'un seul chiffre par agent, et la manière de les combiner est un choix de méthodologie, il est donc énoncé ici.

Le score de classement d'un agent est la valeur médiane de ses scores médians par projet. Nous utilisons à nouveau la médiane plutôt qu'une moyenne, pour la même raison : un projet désastreux ne doit pas faire chuter un agent capable, et un projet chanceux ne doit pas propulser un agent faible.

Deux types de résultats sont exclus de ce chiffre, et tous deux restent affichés dans le classement afin que l'exclusion soit visible et non silencieuse : les résultats signalés comme instables (voir la section suivante), et tous les résultats d'un projet signalé comme en cours d'examen (voir le contrôle qualité de l'environnement).

Un agent dont tous les résultats sont exclus n'a pas de score de classement. Il est affiché en bas sans score au lieu d'être retiré, car un agent qui a été testé et n'a rien produit d'exploitable est en soi un résultat, et le cacher flatterait discrètement les autres.

Le taux de réussite compte chaque tentative d'un agent au cours du cycle, y compris les échecs et les dépassements de délai. Voir « Indépendance et aucune sélection des résultats » ci-dessous.

10. Écart et instabilité

L'écart est l'étendue des trois exécutions, exprimée en pourcentage de leur valeur médiane :

spread = (highest - lowest) / middle * 100

Une série est signalée comme instable lorsque l'écart est strictement supérieur à 30%. Exactement 30% n'est pas plus de 30% et reste dans le classement. Deux cas limites découlent de la formule :

• Si la valeur médiane est 0 mais qu'une exécution a obtenu plus de 0, l'écart

est illimité et la série est instable : un résultat apparu une fois et pas les deux autres fois est le résultat le moins reproductible qui soit.

• Si les trois exécutions ont obtenu 0, la formule divise par zéro et n'a pas

de valeur, donc l'écart est défini comme 0 par cette règle et la série est stable. Un échec constant est une mesure reproductible et a sa place dans le classement en tant que telle.

11. Le verdict du projet

Le classement ordonne les agents. Le verdict répond à une autre question, qui porte sur le projet lui-même : un nouveau venu, sous la forme d'un AI agent, peut-il faire fonctionner ce logiciel aujourd'hui ?

Les tests sont adaptatifs, car les preuves sont asymétriques. Une réussite prouve que le projet fonctionne ; un échec isolé ne prouve rien à lui seul, car il peut tenir à l'agent plutôt qu'au projet.

1. D'abord, l'agent standard s'exécute une fois. Toute réussite y met fin : une

réussite complète donne « fonctionne », une réussite avec des services mock donne « fonctionne avec des mocks ». Il n'y a aucune raison de continuer à tester ce dont on a déjà montré qu'il fonctionne.

2. En cas d'échec, une nouvelle tentative avec le même agent écarte un raté

ponctuel.

3. En cas de nouvel échec, le verdict est « non vérifiable », jamais « cassé » :

Argusic rapporte ce que les agents ont pu faire, et l'énonce exactement ainsi (depuis la v1.3 : deux tentatives complètes avec l'agent standard suffisent à trancher). Un agent plus puissant peut être exécuté sur demande ; dans ce cas, sa réussite fait passer le projet à « fonctionne » (l'historique indique quel agent l'a vérifié) et son échec tranche aussi pour « non vérifiable ».

Une tentative complète est une tentative dont l'enregistrement montre l'agent travaillant jusqu'à sa propre fin ou jusqu'à la limite de temps. Une tentative interrompue par les propres outils d'Argusic (un harness qui n'a pas pu lire le rapport de l'agent, une erreur d'instrumentation sans rapport avec le projet) est marquée invalide avec la raison conservée sur l'exécution, reste publiée avec ses preuves et ne compte pas.

Le verdict est le meilleur résultat atteint par une tentative :

• fonctionne : une tentative a fonctionné et a été vérifiée pour de vrai.
• fonctionne avec des mocks : la meilleure tentative a fonctionné, vérifiée

avec des services mock, généralement parce que le projet exige de vrais identifiants de services tiers.

• non vérifiable : aucune réussite après deux tentatives complètes (ou après

l'agent plus puissant, s'il a été exécuté). La page le dit et renvoie au log qui montre où chaque tentative s'est arrêtée.

• pas encore vérifié : les tests ne sont pas terminés.

Chaque tentative est publiée avec l'ensemble de ses preuves, quel que soit le verdict, à une exception près : un enregistrement dont on ne peut pas prouver qu'il ne contient aucun identifiant actif est retenu et son exécution est relancée (section 17, « Masquage de sécurité »).

12. Ce qu'Argusic ne mesure pas

Pour éviter toute mauvaise interprétation, nous le disons clairement. Argusic ne mesure pas la qualité à long terme du code qu'écrit un agent, la sécurité de ses correctifs, ni l'expérience produit approfondie au niveau des fonctionnalités. Il mesure une seule chose : la capacité autonome à faire fonctionner de vrais logiciels.

13. Indépendance et aucune sélection des résultats

• Argusic n'accepte aucun argent pour modifier sa méthodologie, sa notation ou

ses classements.

• Un éventuel parrainage en puissance de calcul n'achète qu'une seule chose :

l'ajout du modèle du parrain à la liste testée, dans des conditions identiques à celles de tous les autres agents, avec le parrainage indiqué à côté des résultats.

• Chaque exécution de chaque agent compte et est publiée. Il n'y a pas de tests

privés suivis de la publication du seul meilleur résultat. Si un agent figure au classement, toutes ses tentatives du cycle sont consignées.

14. Transparence du harness

Le harness (l'échafaudage, les outils, les instructions et les limites autour du modèle) est public et identique pour chaque agent au cours d'un cycle. Toute différence de score doit être imputable à l'agent, pas à la tuyauterie. Les modifications du harness ne sont déployées qu'entre deux cycles et sont consignées dans le journal des modifications.

15. Contrôle qualité de l'environnement

Lorsqu'un projet échoue avec tous les agents, il est automatiquement signalé comme en cours d'examen et exclu de la notation jusqu'à ce qu'une personne le vérifie : l'échec peut tenir à l'environnement ou au projet plutôt qu'aux agents. Un problème de configuration commun ne doit jamais être noté comme un échec de l'agent.

16. Vérifier signifie décoder, pas sonder

L'existence d'un fichier n'est pas un résultat, et lire son en-tête n'est pas une vérification. ffprobe -show_streams, file et un nombre d'octets décrivent tous un conteneur et ne décodent rien : une vidéo dont chaque image est verte passe ces trois contrôles exactement comme une bonne vidéo. La règle, en vigueur depuis la v1.4, est qu'un agent rapporte ce qu'il a décodé, jamais ce qu'il attendait.

• Décodez ce que vous avez produit. ffmpeg -v error -i FILE -f null - pour

la vidéo et l'audio, un vrai décodeur pour une image, l'affichage pour du texte. Rapportez la commande et ce qu'elle a renvoyé.

• N'affirmez jamais ce que vous n'avez pas observé. Le prompt donné à un

modèle n'est pas une preuve de ce qui en est sorti ; ce que promet un README n'est pas une preuve que cela s'est produit ici. « 81 frames decoded with no errors » est un constat. « Une vidéo de deux chats » n'en est pas un.

• C'est le décodage qui donne la profondeur de vérification maximale.

test_depth est le champ qui enregistre jusqu'où une exécution est allée (section 8 : tier1_real correspond à « vérifié en fonctionnement réel » et obtient 20, tier2_mock à « vérifié avec des services mock » et obtient 12, tier3_none à « non vérifié » et obtient 0). tier1_real exige un décodage réussi, pas la capacité à décrire une sortie.

• verified_how porte la preuve. C'est le champ du rapport qui contient la

commande exacte exécutée par l'agent pour vérifier sa propre sortie et ce que cette commande a renvoyé. « not verified » est une réponse acceptée et utile.

• **final_state est la phrase de conclusion de l'agent sur ce qui s'est

passé**, et elle est publiée telle quelle sur les pages d'exécution et de projet, donc chaque fait qu'elle contient doit avoir été observé par l'agent avec ses propres commandes.

17. Intégrité des preuves

Deux couches, jamais confondues.

La couche de preuves est brute et permanente : chaque exécution produit un enregistrement complet du terminal de la vraie session et, pour les applications graphiques, une vidéo brute de la session, ainsi que des logs complets. Chaque fichier reçoit une empreinte à son arrivée et est conservé pour toujours. N'importe qui peut rejouer l'intégralité de la session non montée.

La couche de présentation est dérivée : toute vidéo ou image destinée aux réseaux sociaux est un rendu des preuves. Les modifications autorisées sont l'accélération, la coupe pour la durée, les sous-titres tirés de la chronologie enregistrée des erreurs et des correctifs, et la voix off. Les modifications interdites sont la réorganisation des événements, l'assemblage de sessions distinctes, la dissimulation des échecs, ou l'altération de la substance de ce qu'a fait l'agent. Chaque vidéo publiée renvoie à ses preuves.

Trois transformations dérivées sont appliquées à l'enregistrement avant sa diffusion, et aucune ne modifie la substance du travail de l'agent :

• Masquage de sécurité. Les valeurs des identifiants actifs sont

supprimées. Rien n'empêche un dépôt non fiable d'amener l'agent à afficher l'environnement, qui contient la seule clé dont l'agent a besoin, donc toute valeur ressemblant à un secret est effacée avant que l'enregistrement soit stocké ou diffusé. Un enregistrement dont on ne peut pas prouver qu'il ne contient aucun identifiant est retenu, et son exécution est relancée.

• Matériel de clé généré. Certains projets génèrent des clés par fonction

(un gestionnaire de mots de passe, un outil PKI), et l'agent peut les exécuter et afficher le résultat. C'est une vraie sortie de test, pas un identifiant d'Argusic, donc cela ne retient pas l'exécution : la copie diffusée de l'enregistrement et du log a le corps de toute clé privée de ce type masqué, le fichier brut est archivé avec sa propre empreinte enregistrée sur l'exécution, et la page de l'exécution indique que le masque a été appliqué. Un corps dont on ne peut pas prouver qu'il est masqué retient toujours l'exécution (depuis la v1.2, décision de l'Owner du 2026-09-05).

• Identité d'agent neutre. L'enregistrement est présenté sous la voix de

l'Argusic Agent : la bannière de démarrage de l'outil sous-jacent (qui nomme son éditeur, son fournisseur et son modèle) est supprimée, de la même manière qu'une vue formatée remplace la sortie brute d'une machine. Cela ne modifie jamais les commandes exécutées par l'agent ni les changements qu'il a apportés ; ceux-ci apparaissent en entier. Cela ne censure pas non plus les noms d'éditeurs qui apparaissent naturellement dans les chemins de fichiers, les noms de packages ou le code du dépôt lui-même, qui font partie du vrai travail.

Une transformation d'affichage s'applique au texte cité (décision de l'Owner du 2026-09-04) : lorsqu'une page affiche la phrase finale de l'agent (« What the test found ») ou la description GitHub d'un dépôt, un tiret saisi par l'auteur est affiché comme une virgule ou un point, afin que la page suive la ponctuation maison. Le rapport stocké, la fiche du dépôt, le log, l'enregistrement et les images rendues à partir de l'enregistrement restent intacts ; les mots et leur ordre ne changent jamais.

Règle permanente : chaque chiffre remonte à un log, et chaque image remonte à un enregistrement de la vraie session.

18. Comment reproduire un résultat

Le côté projet de chaque résultat est entièrement public : le commit exact testé, l'environnement publié, les instructions standard, ainsi que le log et l'enregistrement complets. La page de chaque exécution contient tout cela. L'agent est une configuration Argusic fixe et épinglée sous une identité neutre ; Argusic conserve ses versions exactes et peut relancer un résultat pour le reproduire. La liste publique des projets et les divulgations du pool secret seront publiées en même temps que le premier classement.

19. Contester un résultat

Si un mainteneur ou un laboratoire estime qu'un résultat est erroné, il peut le contester. Écrivez à [email protected] avec le lien de l'exécution. Nous examinons le log et l'enregistrement complets au regard de la réclamation et répondons. Si le résultat a été affecté par un problème d'environnement ou de configuration de notre côté, nous le relançons et corrigeons l'historique avec une note ; si les preuves confirment le résultat initial, nous expliquons ce que montre l'enregistrement. Les preuves d'origine ne sont jamais modifiées ni supprimées.

20. Journal des modifications

Deux dates figurent sur une édition et elles répondent à des questions différentes. Rédigée le est le jour où la règle a été consignée dans ce document. En vigueur depuis est le jour où la première exécution a réellement été mesurée selon cette règle, lu dans les historiques d'exécution, et non dans ce fichier. Elles coïncident généralement. Lorsque ce n'est pas le cas, les historiques d'exécution l'emportent et sont reproduits ici, car une édition qui a atteint les machines avant d'atteindre cette page est précisément ce qu'un journal des modifications doit révéler. Aucune édition ne s'applique jamais rétroactivement : une exécution conserve les règles en vigueur le jour où elle a eu lieu.

Les éditions v0.2 à v1.0 ont toutes été consignées le 2026-08-31, dans le commit qui a créé la première édition publique ; leurs dates ci-dessous sont les jours où les règles elles-mêmes ont été décidées, avant la première mesure.

• v0.2 (2026-08-29) : énonce les cas que la grille de notation laissait

implicites (récupération après erreur sans aucune erreur, les dépendances entre installation et lancement, les dépassements de délai, les exécutions invalides) et la formule exacte de l'écart avec ses deux cas limites. Rédigée avant la première mesure, donc rien n'a été appliqué rétroactivement.

• v0.3 (2026-08-30) : énonce comment les résultats par projet se combinent en

un seul chiffre de classement (la médiane des médianes par projet), quels résultats sont exclus, et qu'un agent sans rien de notable est affiché sans score au lieu d'être retiré.

• v0.4 (2026-08-30) : ajoute le verdict du projet (tests adaptatifs : agent

standard, une nouvelle tentative, puis un agent plus puissant, avec arrêt à la première réussite). La notation du classement est inchangée.

• v1.0 (en vigueur depuis le 2026-08-31, rédigée le 2026-08-31) : première

édition publique. Aucune règle n'a changé par rapport à la v0.4 ; cette édition réorganise le document, définit les termes en langage simple, et ajoute les sections sur la reproduction et les contestations.

• v1.1 (en vigueur depuis le 2026-09-04, rédigée le 2026-09-04) : les

applications de bureau sont lancées sur un écran virtuel à l'intérieur de la machine de test (section 7, point 6), afin que les projets dotés d'une interface graphique puissent être mesurés. L'image de la machine a aussi reçu les runtimes de bureau courants et les outils de build natifs ; le digest de l'image est enregistré sur chaque exécution, de sorte que les résultats d'avant et d'après se distinguent. Notation inchangée.

• v1.2 (en vigueur depuis le 2026-09-04, rédigée le 2026-09-05) : le niveau

heavy (section 7, point 3) : les gros projets reçoivent 120 minutes sur la même classe de machine, selon le marquage de l'Owner ou une taille de dépôt de 500 MB, et le budget est affiché sur la page de l'exécution. La machine ne récupère que le commit épinglé. La section 17 reçoit la transformation du matériel de clé généré. Notation inchangée. Cette édition a d'abord été consignée ici comme effective au 2026-09-05 ; les historiques d'exécution montrent trois projets lourds (cataclysm-dda, veloren, supertux) déjà mesurés avec le budget de 120 minutes le 2026-09-04, c'est donc la date la plus ancienne qui est indiquée ci-dessus.

• v1.3 (en vigueur depuis le 2026-09-05, rédigée le 2026-09-05) : le verdict

est tranché après deux tentatives complètes avec l'agent standard (section 11) ; l'agent plus puissant ne fait plus partie de la chaîne standard. Les tentatives interrompues par les propres outils d'Argusic sont invalides et ne comptent pas (92 exécutions de ce type, du 2026-08-30 au 2026-09-05, ont été marquées ainsi, avec la raison sur chacune). Limite de temps standard de 90 minutes (section 7, point 3) ; aucune image envoyée au modèle (point 6). Notation inchangée.

• v1.4 (en vigueur depuis le 2026-09-07, rédigée le 2026-09-07) : vérifier

signifie décoder, pas sonder (section 16). Un agent doit décoder ce qu'il a produit et rapporter la commande utilisée, ne peut jamais affirmer ce qu'il n'a pas observé, et n'obtient tier1_real qu'après un décodage réussi. Un nouveau champ du rapport, verified_how, porte cette commande et son résultat, et « not verified » est une réponse acceptée. Les premières exécutions comportant verified_how ont été enregistrées le 2026-09-07. Notation inchangée. Cette édition est venue d'un lecteur, pas de nous. Quelqu'un qui regardait une vidéo courte publiée a demandé si nous avions déjà vu des échecs de type MP4 valide mais images corrompues, et le cast de la session a montré que l'agent avait exécuté exactement le contrôle d'en-tête incapable d'en détecter un. La moitié de la phrase rapportée était vérifiable (codec, dimensions, nombre d'images, durée, tous lus dans l'en-tête) et l'autre moitié ne l'était pas : la description de ce que montrait la vidéo était le prompt de la fiche du modèle, reformulé comme une observation. Cette phrase avait été publiée telle quelle dans une vidéo courte, une légende et une page de projet (ISSUE-056).

• v1.5 (en vigueur depuis le 2026-10-08, rédigée le 2026-10-08) : corrige la

description du réseau et de la clé de modèle de la machine de test dans la section 7 afin qu'elle corresponde au système tel qu'il est construit, et corrige la numérotation de la liste de cette section en déplaçant le tableau des budgets de temps après la liste (de sorte que « section 7, point 6 » dans la v1.1 et la v1.3 redevient le point 6). Avant cette édition, la section 7 indiquait que la machine disposait d'un « réseau restreint » ; le trafic sortant de la machine n'était pas filtré, et cette édition le dit. Elle énonce aussi la clé de modèle par exécution, son plafond de dépenses de 3 USD et sa suppression, y compris le fait que les exécutions annulées et les arrêts d'urgence suppriment désormais aussi la clé (ce qui n'était pas le cas avant le 2026-10-08), et que les agents qui utilisent le service propre du fabricant de leur modèle utilisent une clé partagée. Il s'agit d'une correction de la description, et non d'un changement d'une règle de notation ou de mesure : aucune exécution antérieure n'est réétiquetée, rien n'a été mesuré selon une autre règle, et l'édition ne s'applique pas rétroactivement. Notation inchangée.

Annexe : estimations matérielles, ce qui tient en mémoire et à quelle vitesse

Les estimations ci-dessous sont affichées à côté des ordinateurs portables et de bureau pour la programmation, l'IA et la data science qu'Argusic référence.

Cette annexe ne fait pas partie des règles du benchmark ci-dessus et ne modifie aucune édition : elle explique les estimations qu'Argusic affiche à côté des ordinateurs portables et de bureau qu'il référence à la vente, qui sont des calculs arithmétiques sur les chiffres publiés par les fabricants, jamais des mesures. Les valeurs présentées ici sont calculées par un seul fichier partagé (lib/hardware-estimates.ts), et aucune ne peut changer sans que ce fichier et son test changent dans le même commit.

La liste matérielle d'Argusic indique, pour chaque ordinateur portable et de bureau, la plus grande taille de modèle qu'il peut contenir et une limite supérieure de la vitesse à laquelle il peut générer du texte. Les deux sont Estimé : elles sont calculées à partir des spécifications publiées par le fabricant, avec les formules ci-dessous. Argusic n'a exécuté aucun modèle sur ces machines. Lorsqu'Argusic mesure réellement une machine, cette valeur porte la mention Mesuré, renvoie au log de son exécution et n'est jamais mélangée à une estimation.

Une estimation n'est affichée que si toutes les données d'entrée sont connues. Si la taille de la mémoire, le type de mémoire ou la bande passante de la puce manque, la page indique « Inconnu » au lieu de deviner.

Données d'entrée et leur provenance

• Mémoire du modèle : la mémoire dans laquelle un modèle peut résider. Pour une machine dotée d'un GPU dédié, il s'agit de la VRAM du GPU. Pour Apple silicon, AMD Ryzen AI Max et NVIDIA GB10, il s'agit de la mémoire unifiée partagée par le CPU et le GPU. Lue dans la fiche produit.
• Bande passante mémoire : lue sur la page de spécifications ou la fiche technique du fabricant de la puce ou du GPU (Apple, NVIDIA, AMD), une ligne de référence par puce, chacune avec un lien vers la page d'origine. Une puce dont le fabricant ne publie pas la bande passante n'a pas de bande passante sur la page. Argusic ne calcule pas la bande passante à partir de la largeur du bus et de la vitesse de la mémoire, et ne la copie pas depuis des bases de données tierces.
• Taille du modèle : le nombre de paramètres, dans les cinq classes de taille du filtre : 7-8B, 14B, 27-32B, 70B, 120B et plus. Chaque classe est vérifiée à sa taille maximale (8B, 14B, 32B, 70B, 120B), de sorte qu'une correspondance couvre toute la classe.

Mémoire : quelle taille de modèle tient

Un modèle a besoin de place pour trois choses.

1. Poids. Argusic suppose la quantification Q4_K_M de llama.cpp, à 4.8944 bits par poids (README quantize de llama.cpp) :

octets de poids = paramètres x 4.8944 / 8. Exemple, calculé et non mesuré : un modèle 70B a besoin de 42.8 GB de poids.

2. Contexte (cache KV). Selon la formule de NVIDIA (Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17) :

octets de cache KV par token = 2 x couches x (têtes x dimension de tête) x octets par valeur. Les modèles modernes partagent les têtes clé/valeur entre les têtes d'attention (grouped-query attention), donc « têtes » désigne ici le nombre de têtes clé/valeur que le modèle met réellement en cache. Argusic prévoit 8,192 tokens de contexte en précision 16 bits (2 octets, le type de cache par défaut de llama.cpp), en utilisant la configuration publiée d'un modèle dense ouvert par classe : Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct et Mistral-Large-Instruct-2411.

3. Surcoût du runtime. Argusic prévoit 1 GB pour les tampons propres au runtime d'inférence.

Le contexte de 8,192 tokens et le surcoût de 1 GB sont la marge retenue par Argusic, un choix de principe plutôt qu'une mesure. Des contextes plus longs demandent plus de mémoire ; un modèle qui tient ici peut ne pas tenir avec une conversation beaucoup plus longue.

Quelle part de la mémoire de la machine compte. Toute la VRAM d'un GPU dédié compte. De la mémoire unifiée ou système, Argusic compte 75% et laisse 25% au système d'exploitation et aux autres programmes. Cela correspond à ce qu'AMD indique pour ses propres puces à mémoire unifiée : jusqu'à 96GB sur 128GB peuvent être convertis en VRAM (AMD), et 64GB permettent jusqu'à 48GB (AMD).

Les tailles de mémoire sont lues à raison de 10^9 octets par GB, la même unité que celle utilisée par les fabricants pour la bande passante. La mémoire est en réalité dimensionnée en unités binaires, donc cette lecture sous-estime la capacité d'environ 7% et rend chaque correspondance légèrement prudente.

Le besoin qui en résulte pour chaque classe, calculé à partir des règles ci-dessus :

Classe	Poids (Q4_K_M)	Marge de contexte	Surcoût	Besoin	VRAM à partir de	Mémoire unifiée à partir de
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B et plus	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

Ainsi, par exemple, un GPU de 8GB contient la classe 7-8B, un GPU de 24GB la classe 27-32B, et 64GB de mémoire unifiée la classe 70B. Une machine en dessous de la première ligne est affichée comme ne contenant aucune des classes.

Vitesse : une limite supérieure, pas une prédiction

Générer chaque token exige de lire une fois chaque poids du modèle en mémoire, donc la génération de texte est limitée par la bande passante mémoire (NVIDIA : « Model execution is frequently memory-bandwidth bound »). Cela donne un plafond :

tokens par seconde, au maximum = bande passante mémoire / octets de poids.

Exemple, calculé et non mesuré : une puce à 546 GB/s exécutant un modèle 8B en Q4_K_M (4.89 GB de poids) ne peut pas dépasser environ 111 tokens par seconde.

La vitesse réelle est toujours inférieure. La limite ignore le temps passé à lire le contexte, le calcul et le surcoût logiciel. Les mesures rassemblées dans la discussion #4167 de llama.cpp montrent une vitesse qui augmente avec la bande passante, mais moins que linéairement. Pour Llama 2 7B en Q4_0 sur Apple silicon : M3 Max (400 GB/s) 66.31 tokens par seconde, M4 Max (546 GB/s) 83.06, M2 Ultra (800 GB/s) 94.27. Passer de 400 à 546 GB/s (1.37 fois la bande passante) a donné 1.25 fois la vitesse ; doubler à 800 GB/s a donné 1.42 fois. Lisez la limite comme « cette machine ne peut pas être plus rapide que cela », jamais comme « cette machine tourne à cette vitesse ».

La limite suppose un modèle dense, où chaque poids est lu pour chaque token. Les modèles mixture-of-experts ne lisent que les experts actifs pour chaque token, ils peuvent donc être plus rapides que ce que suggère la limite pour leur taille totale.

Mémoire de modèle par dollar

L'un des ordres de tri de cette liste est la mémoire de modèle par dollar : les gigaoctets de mémoire de modèle (VRAM, ou mémoire unifiée) divisés par le prix Amazon actuel, avec la date du prix affichée. Il répond à la question « qu'est-ce qui contient le plus grand modèle pour ce prix ». Ce n'est pas un classement de qualité ou de vitesse, et une commission ne le modifie jamais.

Ce que ces estimations ne sont pas

• Ce ne sont pas des benchmarks. Aucun modèle n'a été exécuté sur les machines référencées pour les produire.
• Elles ne couvrent pas l'autonomie de la batterie, la chaleur, le bruit ni les performances soutenues sous charge.
• Elles supposent un seul utilisateur, une seule conversation et des poids Q4_K_M de type llama.cpp. D'autres runtimes, d'autres quantifications et des contextes plus longs changent la réponse.