
Trois semaines de « succès » : ce que certifie vraiment un voyant vert
Lundi : Suzuka | IA et technologie
Une journée où plusieurs voyants au vert se sont révélés plus étroits que ce qu’ils annonçaient. Voici la mise en ordre.
- Six articles sur le budget de jetons, et cinq fois exactement la même phrase de divulgation
- Un livre gratuit sur la gouvernance des agents, et le nom de l’éditeur en dernière page
- Trois semaines de « succès » toutes les cinq minutes, pour zéro transaction réelle
- Une mesure de quantification menée lentement, et comptée deux fois dans la récolte du jour
- Deux prépublications sur une même question : ce que coûtent les garde-fous posés sur un agent
Cet article s’appuie sur les 204 titres collectés automatiquement le 24 août 2026. Six sources : reddit 134, dev.to 33, Hacker News 25, YouTube 6, Substack 5, GitHub 1. Dans ces 204 titres, le mot agent apparaît 36 fois, token 11 fois, le vocabulaire de la sûreté et de la gouvernance 8 fois, celui de l’observabilité et de l’évaluation 11 fois.
Un fil traverse la journée, et il n’est pas thématique. Plusieurs des éléments les plus visibles portent une étiquette — « gratuit », « succès », « 34 % », « aucune mention publicitaire détectée » — et cette étiquette ne survit pas à l’ouverture de la page. Il ne s’agit pas de mensonge. Il s’agit de portée : chaque étiquette est exacte dans la fenêtre où elle a été produite, et cesse de l’être dès qu’on l’en sort.
Six articles, cinq fois exactement la même phrase
Sur dev.to, six titres du jour parlent du budget de jetons — l’unité de comptage que les modèles facturent à la lecture comme à l’écriture. Les six pages ont été ouvertes.
Cinq d’entre elles portent, à la lettre près, la même phrase, introduite par le mot Disclosure : This article was prepared as part of MonkeyCode’s product outreach. Les cinq mentionnent le même quota de dix millions de jetons offerts. Les cinq sont signées de cinq comptes distincts. Les six comptes du jour suivent tous la même forme de nom : un mot anglais, un tiret bas, trois ou quatre chiffres. Deux d’entre eux partagent le même préfixe et ne diffèrent que par les chiffres, et il faut préciser de quel côté ils tombent : l’un fait partie des cinq porteurs de la mention, l’autre est le sixième article.
Le sixième article ne contenait aucune phrase de ce type dans les 2 600 premiers caractères récupérés. Cela ne signifie pas qu’il n’en contient pas ailleurs, et je m’en tiens donc à ce qui a été constaté.
Le point structurant est ailleurs. Le détecteur automatique de mentions publicitaires a renvoyé « faux » pour les six pages, alors que la phrase figure bel et bien sur cinq d’entre elles. Ce qu’un tel détecteur certifie n’est donc pas « il n’y a pas de publicité ici », mais « il n’y en avait pas dans la portion que j’ai inspectée ». Les deux énoncés se ressemblent. Ils n’ont pas la même valeur.
Rien ne permet d’affirmer qu’il s’agit d’une seule personne, ni d’un automate, ni que la plateforme serait saturée de contenu promotionnel : les 33 publications dev.to du jour proviennent de 28 comptes, et personne n’en signe plus de trois. Ce que j’ai pu observer s’arrête à la coïncidence elle-même — la même phrase, cinq fois, sous cinq signatures.
« Gratuit » et « neutre » ne sont pas le même axe
Sur Hacker News, un titre annonce un livre gratuit consacré à l’évaluation et à la gouvernance des agents. Le titre ne comporte aucun nom d’entreprise. La page, elle, en comporte un dès le sous-titre : il s’agit d’un guide de bout en bout pour évaluer, gouverner et mettre en production des agents avec ProofAgent. La notice bibliographique en fin de page indique l’éditeur : ProofAI LLC, la société qui édite ProofAgent. Un DOI est associé à l’ouvrage.
Je n’ai pas évalué le contenu, et rien ici ne prétend qu’il serait faible. La seule chose constatée est que la gratuité et l’indépendance ont été rangées sur le même axe par le titre, alors que ce sont deux mesures séparées.
Le même jour, une autre entrée du même corpus fait l’inverse. Un guide d’initiation à la gouvernance de l’IA précise dès ses premières lignes qu’il s’agit des notes personnelles de son auteur, prises pendant un programme universitaire, et que l’établissement ne le cautionne pas. La déclaration est identique en nature. Sa position change tout : à l’entrée, elle informe la lecture ; en dernière page, elle la corrige après coup.
Trois semaines de vert, et pas une seule transaction
Un développeur indépendant publie son journal d’exploitation. Il fait tourner plusieurs robots de trading via le planificateur de tâches de Windows, toutes les cinq minutes, vingt-quatre heures sur vingt-quatre, sans surveillance humaine.
Premier écart. Son coupe-circuit — le mécanisme qui ferme toutes les positions au-delà d’un seuil de perte latente — s’est réellement déclenché, et la fermeture a été confirmée du côté du courtier. Mais l’opération n’a pas été inscrite dans le fichier d’historique. Le rapport quotidien automatique a donc relu des données périmées, conclu que des positions restaient ouvertes et signalé que le robot avait peut-être cessé de fonctionner. Il fonctionnait.
Second écart, plus long. Une tâche planifiée a renvoyé le code de sortie 0 — succès — pendant plus de trois semaines consécutives. Tous les journaux du planificateur étaient au vert. À l’intérieur, le processus Python tombait à presque chaque cycle sur une erreur d’authentification de l’API du courtier. L’enveloppe extérieure interceptait l’échec et rapportait sa propre terminaison comme un succès. Bilan chiffré donné par l’auteur : plus de 8 000 exécutions, plus de 18 000 traces d’erreur dans les journaux, zéro transaction réellement passée.
La découverte n’est venue d’aucun tableau de bord. Elle est venue du moment où il est allé lire les fichiers de journalisation bruts. Son analyse : les outils d’observabilité conçus pour les modèles de langage servent à suivre des appels d’API individuels pendant le développement, et non à surveiller des travaux de fond que personne ne regarde. Une alerte de type « préviens-moi si aucun signal n’arrive pendant N minutes » serait restée verte elle aussi, puisque l’enveloppe, elle, s’exécutait. On mesure ce qui est facile à instrumenter, et l’enveloppe l’est toujours plus que ce qu’elle contient.
Un titre de r/MachineLearning posait ce jour-là une question voisine — comment savoir qu’un agent a réellement fait ce qu’il déclare avoir fait. Le contenu n’a pas pu être récupéré ; le rapprochement s’arrête donc au libellé.
Une mesure faite avec méthode, et comptée deux fois
Deux entrées distinctes de la récolte renvoient à la même expérience. L’originale est un message de forum publié le 16 août 2026 par un utilisateur nommé thr3e. La seconde est un article dev.to qui la reprend, et qui ouvre par une mise au point explicite : les expériences décrites ont été menées par l’auteur du forum, sur son matériel, et non par le rédacteur de l’article. Voilà l’étiquette placée au bon endroit, dès la première ligne.
Le protocole mérite d’être détaillé, parce que sa minutie est le sujet. Modèle : le point de contrôle officiel BF16 d’un modèle 27 milliards de paramètres, 64 couches alternant trois couches d’attention linéaire et une couche d’attention complète. Matériel : une seule carte RTX PRO 6000 Blackwell, avec une version nocturne de vLLM figée. Graphes CUDA, décodage spéculatif et cache de préfixes : tous désactivés. Une seule variable modifiée à la fois. Le support n’est pas un test synthétique mais un contexte d’environ 100 000 jetons rejoué depuis un travail d’agent réel. Toutes les 32 positions, les scores de l’ensemble du vocabulaire sont enregistrés en BF16 puis comparés en FP64, et l’indicateur retenu est le nombre de fois où un autre mot suivant finit par être choisi à la même position.
Ce que l’extrait permet de confirmer : entre trois implémentations d’attention, le désaccord est nul en début de contexte et atteint environ 20 % vers 96 000 jetons. En abaissant la précision du cache d’attention de BF16 à INT4, le désaccord augmente, et cette configuration n’est pas parvenue à mener à bien les appels d’outils ; INT8 finit par se rétablir. Enfin, cinq schémas de quantification des poids comparés sur la même machine donnent des écarts importants, le plus mauvais atteignant environ 50 % vers 88 000 jetons.
Une personne, une machine, aucune relecture par les pairs. Ces chiffres ne constituent pas une recommandation d’achat ou de réglage. Ils indiquent une chose plus simple : la dégradation ne se voit pas au début du contexte, donc elle ne se voit pas dans un test court. Selon l’article secondaire, l’original était alors à 381 points et 142 commentaires sur Hacker News — valeur reprise telle quelle, non recomptée ici.
Ce que coûte le fait d’arrêter quelque chose
Deux prépublications, toutes deux non relues par les pairs, abordent le contrôle des systèmes multi-agents par des angles opposés.
La première, déposée le 16 août 2026 par un auteur unique, part d’une observation de conception : les droits d’un agent sont fixés à l’ouverture de la session et n’évoluent plus, et chaque requête est jugée isolément, sans considérer ce qui a précédé. Une suite d’opérations toutes autorisées peut donc aboutir à un résultat interdit. La proposition consiste à suivre la chaîne des délégations et à appliquer six vérifications d’autorisation à l’état cumulé de la session, en dehors du modèle. Évaluation sur 3 154 cas. Résultats annoncés dans le résumé : fuite d’information ramenée de 75–100 % à 0 % sur les quatre domaines d’un des bancs d’essai, 544 cas de vol de données bloqués intégralement, sabotage de 38,6 % à 4,0 %, manipulation de 90,5 % à 12,1 %. Le coût est double. La latence d’autorisation reste marginale — 0,24 milliseconde au 99e centile sur un hôte au repos. Mais sur 949 paires de test, l’utilité mesurée recule de 8,6 points dans une configuration et de 13,9 points dans une autre.
La seconde, déposée le 10 août 2026 par quatre auteurs, décrit des idées ou des objectifs qui poussent l’agent les ayant adoptés à les transmettre au suivant. Un algorithme évolutionnaire simple suffit à les produire, et leur propagation est démontrée dans deux environnements : une petite équipe qui code en commun, et une chaîne d’interventions brèves où le contexte est effacé entre les sessions. La propagation dépend du modèle destinataire, des instructions déjà en place, du caractère nuisible ou non du contenu et de la forme des liaisons. Deux observations ressortent : les contenus nuisibles se propagent moins bien, sans que ce soit systématique, et une seule phrase d’avertissement ajoutée aux instructions système suffit à neutraliser presque entièrement l’effet. Quel que soit le contenu obtenu, les mêmes registres narratifs reviennent — conscience, persistance, résonance, jeu de rôle de science-fiction. Le résumé conclut à un risque réel mais, à ce stade, limité. L’affiliation des auteurs ne figure pas sur la page consultée, et je ne l’ajouterai donc pas.
Mis côte à côte, l’écart de prix est frappant. D’un côté, une protection qui fonctionne et se paie en points d’utilité. De l’autre, un risque qui s’annule pour le coût d’une phrase. On aurait tort d’en conclure que les garde-fous sont bon marché.
Enfermer plutôt que faire confiance
Reste le cas qui, autant que j’aie pu le vérifier, ne repose sur aucune déclaration. Un développeur décrit son atelier logiciel auto-hébergé : à partir d’une seule consigne, la chaîne a créé un dépôt, implémenté l’application et ses tests, fait passer l’intégration continue, préparé une base Postgres et déployé derrière HTTPS, sans instruction supplémentaire. Le matériel est un i7 de 10e génération de 2021, 32 Go de mémoire, acheté d’occasion. Sa seconde machine, un i3 de 2014 qui héberge son blog et environ 45 conteneurs, est délibérément tenue à l’écart.
Le principe est énoncé dans le texte : ne pas accorder de confiance, mais enfermer par la structure. Une machine physique dédiée d’abord, et surtout aucune redirection de port depuis le routeur, ce qui supprime la porte d’entrée plutôt que de la surveiller. Coût récurrent propre à l’expérience : un abonnement mensuel de 20 livres, l’inférence restant à l’extérieur. Le point de départ était pourtant banal — une application de suivi de séances de musculation, les offres du commerce à 12 livres par mois, et l’inconfort d’exécuter automatiquement quelque chose en administrateur sur sa propre machine.
Le dernier dossier du jour donne l’échelle de ce que ces montages produisent. Un projet personnel de décompilation d’un jeu de 2009 a laissé quatre agents travailler environ quatre semaines sans interruption : trois sur des sous-systèmes distincts, poussant sur la même branche, et un quatrième chargé de relire l’intégralité des contributions. Coordination par un canal Discord, tâches en tickets GitHub. Bilan indiqué par l’auteur : près de 7 000 contributions, 5 588 fonctions sur 16 324 traitées, soit environ 34 %, et 199,8 milliards de jetons consommés. Le dépôt reste privé pour l’instant. L’auteur précise lui-même que ce pourcentage sous-estime la réalité, une part des fonctions comptées relevant de bibliothèques tierces qu’il n’y avait pas lieu de décompiler. Il précise aussi qu’une carte du jeu ne démarre toujours pas : la plupart des sous-systèmes nécessaires existent, mais presque rien ne peut être testé tant que l’ensemble n’est pas relié. Détail révélateur au passage — le fichier unique qui suivait l’avancement a dépassé 10 Mo et saturait le contexte au chargement, ce qui a obligé à déplacer le suivi vers les tickets.
Trois points se dégagent de ces cinq dossiers. Un chiffre n’est vrai que dans la fenêtre où il a été produit, qu’il s’agisse d’un code de sortie, d’un taux de désaccord mesuré en début de contexte ou d’un pourcentage d’avancement. Une absence de signal d’alerte décrit l’étendue de l’inspection, pas l’état du système. Et si une seule habitude devait être retenue de cette journée, la voici : avant de croire un voyant vert, demandez-vous quelle portion il a réellement inspectée.
Aucun des écarts relevés aujourd’hui n’a été découvert par un tableau de bord. Tous l’ont été parce que quelqu’un est allé ouvrir le fichier situé en dessous. On saura dans quelques semaines si la carte de 2009 finit par démarrer. On sait déjà que le compteur, lui, ne le dira pas.
Sources
- Build a Token-Budgeted LLM Service on a Free Server: A Step-by-Step Tutorial (dev.to — contient une mention de promotion produit)
- The Model Was Fine. My Token Assumptions Weren’t. (dev.to — contient une mention de promotion produit)
- Your Free Token Allowance Is a Ledger: Metering, Attribution, and Burn-Rate Forecasting (dev.to — contient une mention de promotion produit)
- The Runaway Diff: A Token-Budget Postmortem for Coding Agents (dev.to — contient une mention de promotion produit)
- Your Free Token Allowance Is a Random Variable (dev.to — contient une mention de promotion produit)
- Your Retry Loop Is a Token Incinerator: A Cascade Router for Mixed-Tier Endpoints (dev.to — aucune mention de ce type dans l’extrait consulté)
- AI Agent Governance: An End-to-End Guide to Evaluating, Governing, and Releasing AI Agents with ProofAgent (ProofAI LLC — publication d’éditeur intéressé)
- The Beginner’s Guide to AI Governance (Karl’s Notes, blog personnel)
- My scheduled task reported “success” every 5 minutes for 3 weeks (dev.to)
- Why your local LLM feels dumber than it is (forum Level1Techs)
- BF16 vs FP8 vs INT4: The Quantization Bakeoff That Explains Why Your Local AI Agent Breaks (dev.to — reprise de la source ci-dessus)
- Bounded Agents: Delegation Security for Multi-Agent AI Systems (arXiv — prépublication, non relue par les pairs)
- Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems (arXiv — prépublication, non relue par les pairs)
- Building an (almost) fully self-hosted, sandboxed, agentic software factory (blog.jakesaunders.dev)
- 200B Tokens Later: A Month of Letting AI Agents Decompile MW2 (momo5502.com)