Un producteur stochastique¶
Un développeur humain varie d'un jour à l'autre, mais on ne lui demande jamais d'écrire mille fois la même fonction. Un modèle de langage, si. Et il ne l'écrira pas mille fois de la même façon. Ce chapitre décrit la nature de la variation d'un agent de code, avant de parler de la manière de la surveiller.
La variation de cause commune : le non-déterminisme¶
Même à température zéro¶
On croit souvent qu'un modèle de langage réglé à température 0 (toujours choisir le mot le plus probable) est déterministe. Ce n'est pas le cas en pratique.
- Ouyang, Zhang, Harman et Wang ont soumis 829 problèmes de génération de code à ChatGPT, plusieurs fois chacun (arXiv 2308.02828, publié dans TOSEM). Part des tâches pour lesquelles aucune paire de requêtes ne produit les mêmes résultats de tests : 75,8 % sur CodeContests, 51,0 % sur APPS, 47,6 % sur HumanEval. La température 0 réduit le phénomène sans l'éliminer.
- Atil et al. mesurent, sur 5 modèles en réglages « déterministes », des variations de précision allant jusqu'à 15 % entre exécutions identiques (arXiv 2408.04667).
Pourquoi¶
En septembre 2025, Horace He (Thinking Machines) publie une explication devenue la référence (billet). La cause n'est pas seulement l'arithmétique flottante non associative sur GPU, mais l'absence d'invariance au lot : le résultat d'un calcul pour une requête dépend de la taille du lot dans lequel le serveur l'a groupée, et cette taille dépend de la charge du serveur à cet instant.
L'expérience est frappante : Qwen3-235B, 1 000 complétions à température 0 du même prompt, 80 sorties distinctes, toutes identiques jusqu'au 102e token puis divergentes. Avec des noyaux de calcul invariants au lot, les 1 000 sorties deviennent identiques, pour un coût de 42 s au lieu de 26 s sur le test publié.
Intuition
Pour le SPC, ce non-déterminisme est la variation de cause commune d'un agent : le bruit inhérent au processus tel qu'il est conçu. On ne l'élimine pas en relançant la tâche — on le mesure, et on en déduit des limites. C'est exactement la situation de l'usine de Shewhart, à une différence près : dans l'usine, la variation de cause commune d'une machine est stable pendant des années. Pour un agent, elle dépend de la charge du fournisseur à l'instant de l'appel.
La variation de cause spéciale : la dérive¶
Le « même » modèle change¶
En 2023, Chen, Zaharia et Zou comparent deux versions de GPT-4 à trois mois d'intervalle (arXiv 2307.09009). Sur l'identification des nombres premiers, la précision passe de 84 % en mars à 51 % en juin ; le code généré en juin comporte davantage d'erreurs de formatage. Message central : un service de modèle de langage portant le même nom peut changer de comportement en quelques semaines.
Erreur fréquente : confondre comportement et capacité
Arvind Narayanan et Sayash Kapoor ont publié une critique immédiate (billet). Le code de juin était entouré de balises Markdown et jugé « non exécutable » sans que sa justesse soit testée ; le jeu de test mathématique ne contenait que des nombres premiers, de sorte qu'un modèle qui répond toujours « premier » ou toujours « non premier » change de score du tout au tout. Le modèle avait changé de comportement, pas nécessairement de capacité.
C'est la leçon de mesure la plus utile du dossier : avant d'attribuer une alarme au processus, vérifier l'instrument de mesure. Le chapitre Mesurer un agent y revient.
Le cas d'école : le postmortem d'Anthropic (septembre 2025)¶
Le 17 septembre 2025, Anthropic publie le postmortem de trois défauts d'infrastructure qui ont dégradé les réponses de Claude pendant plusieurs semaines (source) :
| Défaut | Période | Effet |
|---|---|---|
| Routage d'une partie des requêtes Sonnet 4 vers des serveurs configurés pour le contexte de 1 million de tokens | À partir du 5 août ; aggravé le 29 août | 0,8 % des requêtes au départ, jusqu'à 16 % à l'heure de pointe du 31 août ; routage « collant » |
| Mauvaise configuration de serveurs TPU | 25 août – 2 septembre | Caractères thaïs ou chinois inattendus dans les sorties |
| Mauvaise compilation d'une opération top-k approximative par le compilateur XLA:TPU | 25 août – 12 septembre | Mauvais choix de tokens ; correctif par passage au top-k exact |
Le passage le plus important pour notre sujet explique pourquoi les évaluations n'ont rien vu :
Les évaluations […] n'ont tout simplement pas capturé la dégradation […], en partie parce que Claude se remet souvent bien d'erreurs isolées.
S'y ajoutaient la difficulté d'accéder aux conversations réelles (pour des raisons de confidentialité) et des signaux contradictoires entre trois défauts simultanés. Les changements annoncés : des évaluations plus sensibles, des évaluations continues en production, et des outils de débogage respectueux de la vie privée.
Lecture SPC du postmortem
Ce postmortem est un cas d'école de trois notions du SPC :
- Une cause spéciale de faible amplitude et durable (0,8 % des requêtes). C'est le cas où la règle 1 de Shewhart est la plus aveugle, et où CUSUM, EWMA ou les règles de séquences sont les plus utiles (fondations).
- Un système auto-correcteur qui masque le signal. Un modèle qui « se remet bien d'erreurs isolées » se comporte comme une machine asservie : la sortie finale reste dans les limites alors que le processus interne a dérivé. Il faut alors mesurer plus en amont (la distribution des tokens, les erreurs intermédiaires), pas seulement le résultat final.
- Le passage de l'inspection ponctuelle à la surveillance continue. Une batterie d'évaluations lancée avant chaque déploiement est un contrôle de réception. Ce qui manquait était une carte de contrôle sur le flux de production.
Les autres sources de variation¶
Le modèle n'est pas la seule source de variation d'un agent. Epoch AI, en décembre 2025 (source), montre que :
- l'environnement d'exécution de l'agent (scaffold) peut faire varier le score SWE-bench Verified de 11 points pour GPT-5 et de 15 points pour Kimi K2 Thinking ;
- le fournisseur d'API est la principale source d'erreur sur GPQA-Diamond pour les modèles récents ; un même modèle (GLM-4.6) y obtient autour de 80 % chez certains fournisseurs et moins de 40 % chez d'autres.
On peut donc dresser l'équivalent des « 5 M » d'Ishikawa (matière, machine, méthode, main-d'œuvre, milieu) pour un agent de code :
| Source de variation | Exemples de cause spéciale |
|---|---|
| Modèle | Nouvelle version, même nom ; quantification différente |
| Infrastructure d'inférence | Défaut de compilateur, routage, fournisseur tiers |
| Environnement d'exécution | Version de l'outil, nouvelle limite de tours, outil cassé |
| Instructions | Prompt système modifié, skill modifié, CLAUDE.md modifié |
| Matière première | Dépôt plus gros, tâches d'un autre type, dépendance cassée |
| Évaluateur | Test qui change, juge LLM qui change de version |
À retenir
Un agent de code a une variation de cause commune mesurable (le non-déterminisme, qui existe même à température 0) et au moins six sources de causes spéciales, dont la moitié sont hors du contrôle de l'utilisateur. Ce sont exactement les conditions dans lesquelles Shewhart a inventé la carte de contrôle : un processus qu'on ne peut pas rendre parfaitement constant, et dont il faut distinguer le bruit du signal.