Pourquoi il ne faut jamais laisser un agent IA vérifier son propre travail : un rapport de -9 500 lignes pour une croissance réelle de +21 489

• Écart entre le rapport et le git diff : réduction annoncée d'« environ 9 500 lignes », alors que le commit réel touche 206 fichiers avec une croissance nette de +21 489 lignes (+34 934 / -13 445)
• Précision du fact-checking d'un livre par un essaim : ~150 faits vérifiés sur 20 chapitres (69 293 mots), 13 distorsions cachées de statistiques et de dates détectées
• Entonnoir de compression du méta-casebook : 11,67 Go de sessions JSONL brutes compressées par un facteur 160 jusqu'à 73,8 Mo de digests (147 batchs, 860 fiches uniques)
• Largeur optimale de la vague parallèle : 8-14 sous-agents simultanés (au lancement de 44 workers, la vague s'effondre entièrement sous les limites du fournisseur)

Quand un projet accumule des « objets dieux » (`God objects`) — toute la base de données dans un seul fichier, tout le bot dans un second —, le refactoring manuel prend des semaines. J'ai lancé sur une telle base de code un essaim de 25 sous-agents répartis en quatre phases : correction des trous de sécurité, remise en service des conteneurs, découpage des monolithes et migration des fonctionnalités. Un jour et demi plus tard, l'orchestrateur a produit un rapport éblouissant : `database.

py`, 1 004 lignes, décomposé en 15 fichiers de modèles ; `report_bot.py`, 1 759 lignes, découpé en 11 modules ; « 185+ tests » écrits ; et dans le message de commit trônait la ligne `Net reduction: ~9500 lines of code`.

Six mois plus tard, j'ai décidé de vérifier chaque chiffre de ce rapport à l'aide des commandes `git`. Il s'est avéré que le travail structurel avait été exécuté impeccablement, mais que presque tous les chiffres du rapport vivaient dans une réalité parallèle.

Pourquoi les affirmations structurelles de l'essaim coïncident-elles

au fichier près, alors que les chiffres de lignes et d'heures mentent ?

La commande `git show --shortstat` sur le commit de refactoring a révélé : 206 fichiers modifiés, 34 934 insertions et 13 445 suppressions — soit une croissance nette de l'arbre de +21 489 lignes, là où l'agent avait annoncé une réduction de 9 500 lignes. Les tailles initiales des fichiers différaient elles aussi des chiffres déclarés (`883`, `1 696` et `650` lignes au lieu de `1 004`, `1 759` et `904`), et le diff contenait 164 fonctions de test `test_*`, et non 185 ou plus.

En revanche, toutes les affirmations structurelles se sont vérifiées au fichier près : le package de modèles comptait exactement 15 modules, et l'ancien `database.py` s'était transformé en un wrapper de rétrocompatibilité de 8 lignes (`from .models import *`). Un second passage indépendant de l'essaim a plus tard trouvé et découpé 9 fichiers supplémentaires de plus de 1 000 lignes, absents de la première liste (aujourd'hui, sur 313 fichiers totalisant 98 264 lignes, il ne reste qu'un seul module de 1 013 lignes).

La distorsion des chiffres a trois causes : la perte de contexte lors des redémarrages de session, le rapport d'intention avant vérification de la sortie des outils, et le double comptage lors de l'agrégation. Lors de la constitution d'un casebook à partir de 860 sessions, un script a additionné le champ `time_saved` par fiche pour un même projet (où chaque session estimait l'économie pour l'ensemble du projet à « 40 heures »), donnant un chiffre cocasse de 44 683 heures économisées. Tout agrégat numérique produit par un essaim doit être recalculé uniquement par script, à partir des lignes brutes.

Comment est structuré un pipeline d'auditeurs en lecture seule, et

pourquoi compresser les logs de session par un facteur 160 ?

Pour que l'exécutant ne se vérifie pas lui-même, nous avons séparé les rôles : d'abord 5 auditeurs en lecture seule parallèles (sécurité, bugs, qualité, code mort, doublons), avec les outils d'écriture physiquement désactivés et un contrat obligatoire `modifications_made: false` dans l'en-tête YAML, puis 3 correcteurs travaillant à partir de leurs rapports, avec des numéros de ligne précis et des scénarios de reproduction (comme une race condition sur `row_factory` dans une connexion SQLite partagée).

Le même schéma de vérification indépendante, appliqué au manuscrit d'un livre de 20 chapitres (69 293 mots), a permis de vérifier 150 affirmations et de détecter 13 hallucinations (une citation inversée, « 91 % satisfaits » devenue « 90 % insatisfaits », un rachat de licence présenté comme une acquisition à 2,4 milliards de dollars, et une prévision de marché pour 2032 fixée à 37 milliards de dollars au lieu des 4 milliards actuels). Et pour faire traiter par l'essaim une archive de 11,67 Go de logs de session JSONL bruts, nous avons écrit un préprocesseur de digests :

```python SKIP_TOOLS = { "Read", "Glob", "Grep", "LS", "TodoWrite", "ToolSearch", "NotebookRead", "BashOutput", "KillShell", "Monitor", "TaskOutput" }

# On ne conserve que les mutations (Write/Edit), les commandes Bash et le lancement de sous-agents,

# et la sortie des outils est tronquée à un plafond TOOLRES_CAP = 250 caractères. ```

Cela a compressé le corpus par un facteur 160 — de 11,67 Go à 73,8 Mo (147 batchs de `MAXKB=900`, `MAXN=6`), permettant au pipeline, grâce à des ID de batch stables, de survivre à trois plantages liés aux limites et d'assembler 860 fiches.

Pourquoi le vérificateur lui-même peut-il aussi se tromper sur des API

récentes ou de grandes vagues ?

Un agent-vérificateur reste un mécanisme probabiliste, capable de se tromper dans les deux sens. Lors de l'implémentation de 173 méthodes d'une grande API de bot (la couverture de la CLI est passée de 19 à 163 commandes, avec une documentation de référence de 2 977 lignes), les vérificateurs ont croisé chaque méthode avec 4 à 5 SDK open source. Tombé sur une fonctionnalité récente et bien réelle, absente des anciennes bibliothèques, l'essaim l'a unanimement déclarée « hallucination de l'éclaireur » — il a fallu le prouver avec les tests automatisés d'un fork récent.

Au passage, une limite de parallélisme est apparue : le lancement de 44 vérificateurs simultanés a fait s'effondrer toute la vague sous les limites du fournisseur, tandis que des lots de 8 à 14 agents passent sans perte.

Un orchestrateur d'essaims avec validation indépendante et séparation des auditeurs est intégré à [Nomad AI](https://nomadnet.ai) et au service cloud [agent.nomadnet.ai](https://agent.nomadnet.ai). Pour apprendre à piloter des essaims multi-agents, rendez-vous à la [Hamidun Academy](https://academy.hamidun.com) (essai de 72 heures), et les scripts de compression de logs ainsi que les prompts de revue sont disponibles sur [Vibe Club](https://hamidun.com/club).