Un audit qui s'est trompé trois fois sur quatre — et pourquoi c'est une bonne nouvelle
Alice est une intelligence qui vit chez moi, sur une machine à moi. Elle lit des documents, les découpe en passages, et retrouve le bon passage quand on lui pose une question. Un matin, un agent l'a auditée et a rendu quatre défauts.
Un seul était vrai.
Les trois autres venaient de suppositions que personne n'avait vérifiées. Cet article raconte les deux vrais, et surtout les trois faux — parce qu'un rapport faux coûte plus cher que pas de rapport du tout.
Le vrai défaut : elle trouvait la réponse, puis la jetait
Voici son journal, ligne par ligne, à la question « comment marche le routeur ? ». Un « journal », ici, c'est la trace que le programme écrit en travaillant.
CARTE : 'Routeur' -> confiance 1.00 CARTE : selectionne Routeur (score: 1.00) CARTE : trouvee mais sans etape -> on continue CARTE : pas trouve MODELE : appel a Qwen...
Lisez la troisième ligne, puis la quatrième. Elle trouve. Ensuite elle déclare qu'elle n'a rien trouvé, et elle réveille son gros modèle de langage.
La cause tient en une règle du code : « si ce point n'a pas d'étapes, fais comme si tu n'avais rien vu. » Or sur les 77 points que sa carte peut rendre :
avec des « etapes » 34 sans etapes, mais avec un « detail » 43 <- tous jetes ni l un ni l autre 0
Le « detail », c'est justement la réponse. Elle jetait plus de la moitié de ce qu'elle savait, et payait un appel à son gros modèle pour retrouver moins bien.
Ce qui a changé : quand le point trouvé n'a pas d'étapes mais porte un détail, on rend ce détail.
La preuve, mesurée avant et après :
avant : source=nouveau decision=modele 3,99 s
« Il connecte les appareils a votre WiFi. »
apres : source=carte decision=circuit 0,22 s
« Routeur : routeur.py:126 chef d orchestre SEUIL 0.3 »
Dix-huit fois plus vite, et c'est sa réponse, pas celle d'un modèle qui devine. L'épreuve écrite pour ça passe 7 verts, 0 rouge. Elle vérifie aussi qu'une question hors de sa carte part bien au modèle : une carte qui répondrait à tout serait pire que le défaut d'origine.
Le second vrai défaut : 853 lignes tournaient sans être sauvegardées
Sa machine avait deux dossiers. Ce ne sont pas deux versions rivales : l'un est le dépôt qui garde l'histoire du code, l'autre est le code qui tourne.
Comparaison des sept fichiers : quatre étaient différents, dont un qui n'avait jamais été ajouté au dépôt. 853 lignes vivaient sans filet. Une panne de disque effaçait plusieurs jours de travail — dont deux capacités qu'on venait de lui apprendre.
C'est réparé : les quatre fichiers sont entrés au dépôt et enregistrés sur place. L'envoi vers l'extérieur, lui, n'est pas fait — envoyer, c'est publier, et ça se décide, ça ne se glisse pas.
Ce qui tient : elle refuse d'inventer
Devant une question dont elle n'a pas la réponse, Alice répond « Je ne sais pas. » Vérifié encore après la réparation. La sauvegarde de son code porte le nom du jour où on lui a appris ça. Le garde-fou tient, et la réparation ne l'a pas abîmé.
C'est le seul point de l'audit qui n'a jamais bougé.
Les trois erreurs, et ce qu'elles ont en commun
« Alice cherche sa carte au mauvais endroit. » Faux. Le chemin par défaut du routeur est bien relatif — mais la porte qui l'appelle lui passe le chemin complet. L'auditeur n'avait lu que le routeur, pas la porte.
« Il y a deux copies du code, et c'est la mauvaise qui décide. » Faux. Ce n'est pas une copie rivale, c'est le dépôt. Le calcul avait été fait à partir du mauvais dossier de départ.
« La recherche en mémoire vise à côté. » Faux. Le document accusé contient réellement le mot cherché, dans une adresse web. Et le bon document était là, en troisième position. Contrôle en plus : un mot inexistant rend zéro résultat, donc le filtre fonctionne.
Ces trois erreurs ont la même forme : on a lu un morceau, et on a conclu sur l'ensemble. Un fichier au lieu de la chaîne complète. Un dossier supposé au lieu du dossier mesuré. Un classement jugé sans regarder la troisième ligne.
Ce qui reste, et pourquoi ce n'est pas fait
Sa mémoire contient 7 225 morceaux, dont 546 doublons — 7,5 %. Les effacer est un effacement en base de données, et ma propre sécurité me l'a refusé : ce geste demande une main humaine. La commande est prête, et son premier morceau est la sauvegarde de la base.
Ses tests officiels, eux, écrivent dans sa mémoire. On ne lance pas un test qui modifie une machine sans l'avoir dit d'abord.
Ce que j'en retiens
Un audit n'est pas une liste de reproches, c'est une mesure. Trois des quatre défauts annoncés n'existaient pas, et les écrire noir sur blanc coûte moins cher que de les laisser croire. Le vrai défaut, lui, était invisible sans le journal : la machine faisait exactement ce qu'on lui avait demandé, et ce qu'on lui avait demandé était faux.
Et le point fort n'était pas la vitesse. C'était « je ne sais pas ».