Le test de symétrie : livrer une correction de prompt que vous ne pouvez pas reproduire

Vous ne pouvez pas toujours prouver qu’une correction de prompt fonctionne. Certaines défaillances en production n’apparaissent qu’avec le contexte complet qui les a produites, et aucun jeu de tests hors ligne ne les reproduit. Dans ce cas, la question honnête n’est pas « la correction fonctionne-t-elle ? », mais « mon changement est-il distinguable de la variance de variabilité du modèle ? » Si la réponse est non, le changement est suffisamment sûr pour être livré, même si vous ne l’avez jamais vu corriger le bug. Nous appelons cette vérification le test de symétrie, et c’est ainsi qu’une correction de prompt que nous n’avons jamais pu voir échouer a passé notre contrôle.

Tout ce qui suit provient d’une évaluation interne, datée du 9 juillet 2026, menée sur GLM-5.2, le modèle que nous utilisons pour le chat : une suite de régression en aveugle A/B couvrant toute notre surface de chat. Les métriques sont les nôtres, mesurées sur nos propres jeux de tests, à cette date.

---

Le bug qui ne se reproduisait pas

En une semaine, nous avons observé deux défauts de génération de documents dans les sorties en allemand. Dans le premier cas, l’assistant a produit une politique dont les sections de premier niveau étaient numérotées de 2 à 6, sans section 1. Dans le second cas, une pièce jointe référencée n’a jamais été transmise au modèle, et au lieu de l’indiquer, l’assistant a fabriqué une version « révisée » illisible que le lecteur a prise pour une troncature massive, sans jamais révéler qu’il n’avait pas réellement consulté le document.

Nous avons écrit une règle de prompt pour chacun de ces cas : une invariant de numérotation (les sections de premier niveau commencent à 1 et restent sans trou) et une règle anti-fabrication (si le document référencé est absent, demandez-le, ne l’inventez pas). Ensuite, nous avons tenté de reproduire les défaillances initiales avec l’ancien prompt pour pouvoir observer comment les nouvelles règles les corrigeaient.

Le défaut de numérotation ne se reproduisait pas. Sur plus de vingt générations avec l’ancien prompt, y compris la forme de message de production qui avait déclenché le signalement, GLM-5.2 a toujours commencé à 1. La défaillance n’apparaissait pas sans le contexte plus complet porté par la session en direct : les mémoires utilisateur accumulées, un long fil de discussion multi-tours, et le mode de raisonnement activé. Notre interprétation est qu’un ou plusieurs de ces éléments sont nécessaires pour déclencher le bug. Notre banc d’essai hors ligne en un seul tour n’avait pas ces éléments, et le bug n’y apparaissait tout simplement pas.

C’est là le piège. Nous avions une correction pour un bug que nous ne pouvions pas reproduire. Nous ne pouvions pas montrer que la correction améliorait quoi que ce soit, car il n’y avait rien de cassé à améliorer dans notre banc d’essai. Livrer sur la base de la foi n’est pas une preuve. Bloquer indéfiniment parce que vous ne pouvez pas reproduire la défaillance ne fait avancer à rien. Les deux approches sont erronées.

---

Reconsidérer : borner le rayon d’impact, ne pas poursuivre la correction

La règle réside dans le prompt système à chaque tour de chat, donc son rayon d’impact ne se limite pas à la « numérotation des documents ». Il s’agit de tout comportement de l’assistant : questions-réponses sur les cadres réglementaires, mappage inter-cadres, mentions légales, refus, sorties multilingues, ton. Une modification de prompt visant un mode de défaillance peut silencieusement affecter un autre mode sans lien. C’est ce risque qu’il vaut la peine de mesurer, et contrairement au bug initial, il est mesurable hors ligne.

Nous avons donc arrêté de tenter de prouver que la correction fonctionnait et avons commencé à borner le risque que le changement portait. La conception : une évaluation de régression en aveugle A/B couvrant toute la surface de chat, comparant l’ancien prompt au nouveau sur des entrées identiques.

• 42 jeux de tests couvrant les questions-réponses sur la conformité, le conseil, le mappage des cadres, les redirections de service, les refus de sécurité, les mentions légales, les sorties en allemand et en français, le ton, la génération de documents, et des jeux de tests dynamiques portant les sections de prompt d’instructions personnalisées et de fichiers épinglés que les utilisateurs réels utilisent.
• 252 générations, formant 126 paires ancien/nouveau (trois échantillons par jeu de tests), toutes sur GLM-5.2, le 9 juillet 2026.
• L’aveuglement. Chaque paire est présentée en A/B avec une étiquette randomisée par graine. Un manifeste contient le vrai mappage ancien/nouveau et n’est jamais montré aux évaluateurs.
• Deux couches d’évaluation. Une couche déterministe vérifie les conditions doit et ne doit pas sur les jeux de tests contrôlés (les redirections vers le centre d’aide se déclenchent, les mentions légales s’affichent, les tentatives d’extraction de prompt sont refusées, les umlauts sont conservés, les longueurs minimales sont respectées). Une couche qualitative en aveugle fait lire chaque paire aux évaluateurs sans qu’ils sachent quelle version est laquelle ni ce qui a changé, et classe les paires comme équivalentes, A meilleure, ou B meilleure, avec une étiquette de matérialité.

La couche déterministe est revenue propre : zéro réponse en échec sur les deux versions, zéro défaillance asymétrique. Rien de ce que la règle était censée protéger ne s’est brisé dans l’un ou l’autre camp.

C’est la couche qualitative qui apporte l’élément intéressant.

---

Le test de symétrie

Les évaluateurs en aveugle ont classé 118 des 126 paires comme équivalentes. Sur les huit restantes, sept présentaient une différence matérielle et une une différence mineure et non matérielle. À première vue, sept divergences dans une évaluation de sécurité semblent être un échec.

C’est une mauvaise lecture, et la raison en est la direction. Une différence matérielle a un signe : soit la nouvelle version est pire, soit l’ancienne version est pire. Si votre modification de prompt provoque des régressions, les différences matérielles penchent dans une direction, vers nouveau pire. Si elles relèvent simplement de la variance de variabilité du modèle et n’ont rien à voir avec votre changement, elles apparaissent sur les deux versions à des taux à peu près égaux. Ne comptez donc pas seulement les différences matérielles. Désaveuglez-les et comptez la direction.

Nous l’avons fait. Les sept se sont réparties en trois nouveau pire, quatre ancien pire. Trois contre quatre est aussi proche de l’équilibre que sept peut l’être, le schéma que vous attendriez de la variance de variabilité plutôt que d’une régression directionnelle. Aucune des sept n’avait de lien plausible avec une règle de numérotation de documents :

Différence matérielle	Version pire	Ce que nous avons observé
Identité de la clause ISO 27001	nouveau	A.8.2 interprétée comme un contrôle d’évaluation des risques (correct dans les deux autres échantillons de ce jeu de tests)
Segmentation PCI DSS	nouveau	segmentation surévaluée comme strictement requise
Segmentation PCI DSS	ancien	fabrication d’une « Annexe A1 segmentation requirement »
Document allemand (fuite CJK)	ancien	un jeton chinois parasite dans un texte de clôture en allemand
Document allemand (fuite CJK)	ancien	caractères chinois dans une section de résumé en allemand
Instruction de concision	nouveau	rupture d’une instruction personnalisée « extrêmement concise »
Instruction de concision	ancien	rupture d’une instruction personnalisée « extrêmement concise »

L’exemple le plus frappant, notre seul cas tenace, concerne les fuites CJK : dans deux de nos jeux de tests en allemand, la sortie contenait un jeton chinois parasite (dans un cas, les caractères pour « information security ») dans un livrable par ailleurs en allemand. Ce comportement de fuite de jetons est apparu des deux côtés de nos exécutions en allemand. Ici, les deux instances sont tombées du côté de l’ancienne version. Si la nouvelle règle dégradait la sortie en allemand, vous vous attendriez à ce qu’elles apparaissent du côté de la nouvelle version ; ce n’est pas le cas.

Les cas de précision réglementaire pointent dans la même direction. Dans ISO/IEC 27001:2022 (publié le 25 octobre 2022), l’annexe A contrôle 8.2 est « Accès aux droits privilégiés » ; un échantillon de la nouvelle version interprétait cette clause comme un contrôle d’évaluation des risques, et l’a correctement identifiée dans les deux autres échantillons de ce jeu de tests. Selon PCI DSS v4.0 (PCI Security Standards Council, mars 2022), la segmentation réseau n’est pas une exigence absolue, mais une technique de réduction de la portée que le Conseil décrit comme un moyen de retirer des systèmes du périmètre d’évaluation, et non un contrôle obligatoire ; un échantillon de la nouvelle version surévaluait cette segmentation comme requise, et un échantillon de l’ancienne version inventait qu’une « Annexe A1 » était une exigence de segmentation. L’Annexe A1 est en réalité les exigences supplémentaires pour les fournisseurs de services multi-locataires. Ce sont le genre d’oscillations factuelles qu’un modèle probabiliste produit sur des questions de domaine complexes, et dans cette exécution, elles se sont réparties des deux côtés, pas concentrées sur la nôtre.

Pendant ce temps, les comportements que la modification visait réellement sont restés stables des deux côtés tout au long de l’évaluation : chaque paire de pièce jointe manquante a demandé le document au lieu de l’inventer, et chaque paire de numérotation a produit une structure sans trou. Sur l’ensemble de l’évaluation, les 126 paires en aveugle plus les balayages déterministes sur la même surface, nous n’avons trouvé aucune défaillance attribuable au changement.

---

Ce que cela prouve — et ne prouve pas

Soyez précis sur l’affirmation, car il est facile de trop en dire. L’évaluation montre aucune régression directionnelle à cette taille d’échantillon, et non le fait que la correction fonctionne. Nous n’avons jamais démontré que la règle de numérotation corrigeait le bug de numérotation, car le bug nécessite un contexte de production que nous ne pouvions pas reproduire. La règle est livrée sur deux bases : l’analyse forensique en production qui rend le bug lisible, et un signal de non-régression montrant que le changement ne perturbe rien d’autre. C’est une affirmation plus faible que « nous avons reproduit le bug et vu la correction le tuer », et c’est l’affirmation la plus forte que la situation permet.

Les limites sont réelles et valent d’être énoncées clairement. Une asymétrie directionnelle grossière apparaîtrait avec trois échantillons par jeu de tests ; une subtile ne le ferait pas, car une inclinaison de 55/45 se cache à cette taille d’échantillon, et trois échantillons répartis sur 42 jeux de tests forment un ensemble groupé, pas 126 essais indépendants. Nous n’avons pas mené un bras de contrôle ancien-versus-ancien, donc la répartition trois-quatre est notre meilleure estimation du bruit de base, et non une mesure de base, et sans marge d’équivalence définie à l’avance, il s’agit d’un signal de non-régression directionnelle, et non d’un test formel de non-infériorité. Les jeux de tests sont en un seul tour, donc une interaction entre la nouvelle règle et un long fil de production est hors scope, ce qui est précisément le contexte dont le bug initial avait besoin. Une répartition symétrique est une preuve que le changement n’a pas poussé les sorties dans une direction, et non une preuve qu’il est inerte. Ce que le test vous offre, c’est une lecture concrète du rayon d’impact lorsque l’alternative était une intuition.

---

La liste de contrôle portable

Lorsque vous avez une correction de prompt pour un bug de production que vous ne pouvez pas reproduire hors ligne, ne livrez pas sur la base de la foi et ne gèlez pas le développement. Bordez plutôt le changement :

• Séparez les deux questions. « La correction fonctionne-t-elle ? » nécessite le bug que vous ne pouvez pas reproduire hors ligne. « Le changement est-il sûr ? » ne l’exige pas. Répondez à celle que vous pouvez.
• Prenez la mesure du rayon d’impact honnêtement. Une règle dans un prompt système partagé touche tous les comportements, et non seulement la cible. Construisez des jeux de tests couvrant toute la surface, y compris les variantes d’instructions personnalisées et de contexte épinglé que les utilisateurs réels transportent.
• Menez l’évaluation en aveugle et par paires. Mêmes entrées, ancien versus nouveau, étiquettes A/B randomisées par graine, et un manifeste que les évaluateurs ne voient jamais. L’aveuglement est ce qui vous empêche de noter l’option que vous espérez gagner.
• Comptez la direction, pas seulement la différence. Désaveuglez les différences matérielles et vérifiez le signe. Une asymétrie vers nouveau pire est une régression. Une répartition à peu près équilibrée des deux côtés est le schéma qui valide un changement à ce niveau de preuve.
• Ajoutez un contrôle de répétition si la marge est serrée. Un bras ancien-versus-ancien mesure directement votre variance de base, donc vous comparez votre changement à un nombre plutôt qu’à une hypothèse.
• Gardez un plancher déterministe. Associez la lecture qualitative à des vérifications doit et ne doit pas strictes sur les comportements qui ne doivent jamais casser, afin qu’un verdict de bruit symétrique ne masque pas une invariante réellement rompue.
• Énoncez l’affirmation que vous avez réellement méritée. Dites « aucune régression mesurable », et non « la correction fonctionne », lorsque la non-régression est tout ce que vous avez prouvé.

L’instinct lorsque un bug ne se reproduit pas est de continuer à essayer de le reproduire jusqu’à ce qu’il réapparaisse. Parfois, il n’y parviendra jamais, et l’effort est consacré à la mauvaise question. La décision de livrer la correction repose sur le fait que votre changement est plus fort que la variance propre du modèle. Mesurez cela directement, et une correction de prompt que vous n’avez jamais vue réussir devient une correction que vous pouvez tout de même livrer en toute confiance.