Scénario illustratif. Un client demande deux fois dans la même matinée à l'agent de support s'il peut retourner une commande au bout de 40 jours. À 9 h 10, l'agent répond : « Oui, vous avez 60 jours. » À 11 h 30, avec les mêmes mots, il répond : « D'après votre commande, le délai est de 30 jours ; contactez un conseiller. » Les deux réponses semblent raisonnables, le même système a généré les deux, et l'une d'elles est sur le point de devenir une réclamation. Personne n'a rien touché entre les deux.
La thèse en une ligne : la variabilité d'un modèle n'est pas un défaut qu'on répare, c'est une propriété qu'on borne. On décide quelles parties du processus ne doivent jamais varier, lesquelles tolèrent la variation, et comment on la mesure avant qu'un client la voie.
Pourquoi l'IA répond-elle différemment à la même question ?
Parce qu'un modèle de langage ne va pas chercher une réponse stockée : il la calcule à chaque fois. À chaque étape, il répartit des probabilités entre les mots possibles et en choisit un, et ce choix contient une part de hasard voulue ; le paramètre qui la règle s'appelle la température. Voilà pourquoi la même question peut donner des formulations différentes et, quand la question laisse des trous, des conclusions différentes.
Trois autres sources de variation sont souvent oubliées. La première, c'est ce qui entoure la question : l'ordre dans lequel le système récupère les documents, la date, l'historique ou la mémoire changent le contexte et, avec lui, la réponse. La deuxième, c'est le serveur : même à température zéro, la plupart des services d'inférence ne garantissent pas des résultats identiques, car le calcul numérique dépend de la charge du serveur à cet instant (Thinking Machines, 2025). La troisième, c'est le fournisseur : un changement de version du modèle ou de ses réglages déplace le comportement sans que tu touches à rien, le même effet que nous expliquons dans pourquoi un agent d'IA se dégrade avec le temps alors que personne n'a rien changé.
Peut-on supprimer la variabilité en baissant la température ?
En partie, et on ne le voudrait pas tout à fait. Baisser la température réduit la dispersion de la formulation mais ne la supprime pas (la source ci-dessus explique pourquoi), et cela ne change ni ce que le modèle sait ni ce qui lui arrive. Cela ne corrige pas non plus l'erreur : à basse température, un modèle qui se trompe se trompe de façon plus constante. Nous développons ce point dans réduire les hallucinations de l'IA en production. Et une certaine variation, c'est justement ce que tu veux : elle permet à un résumé ou à une réponse de s'adapter au cas au lieu de sonner comme un modèle de lettre.
La bonne question n'est pas « comment faire pour qu'il réponde toujours pareil ? », mais « à quels endroits du processus ne peut-il pas répondre autrement ? ».
Quelles parties d'un processus doivent être déterministes et lesquelles tolèrent la variation ?
La règle : ce que le client peut citer, et ce qui engage de l'argent ou des promesses, ne sort pas de la génération libre. Cela sort d'une règle, d'une donnée ou d'un modèle ; le modèle, au mieux, le met en mots.
| Partie du processus | Tolère la variation ? | Où cela doit vivre |
|---|---|---|
| Délais, montants, conditions, dates | Non | Dans une donnée de ton système ou une règle de code ; le modèle la cite, il ne la calcule pas |
| Décision d'aiguillage ou de classification | Peu | Sortie fermée (une liste de catégories), seuil de confiance et relecture des cas douteux |
| Rédaction, ton, résumé | Oui | Dans les instructions et les exemples ; le modèle a de la marge à l'intérieur |
| Actions avec effet (envoyer, encaisser, supprimer) | Non | Dans une validation déterministe avant exécution et des permissions restreintes |
Si presque tout ton processus tombe dans les lignes « Non », tu n'as peut-être pas besoin d'un agent : un flux classique coûte moins cher et s'audite plus facilement, comme nous l'expliquons dans comment automatiser des processus avec des agents, pas avec des chatbots. Et ce que tu laisses au modèle se définit dans ses instructions : ce qu'il doit citer, ce qu'il ne peut pas affirmer et ce qu'il fait quand il n'a pas la donnée.
Comment mesure-t-on la variabilité d'un agent avant la mise en production ?
Avec un test ennuyeux et répétable. C'est une méthode, pas un chiffre magique :
- Rassemble des cas réels. Un ensemble d'entrées issues de ton activité, avec les ambiguës et les rares, pas celles de la démo.
- Répète-les. Fais passer chaque entrée plusieurs fois dans le système complet (avec sa récupération de documents, pas seulement le modèle) et garde chaque sortie.
- Compare ce qui compte. Sur les champs de décision (catégorie, montant, oui ou non), exige une correspondance exacte. Sur le texte, compare avec une grille : dit-il la même chose sur le fond ?
- Fixe un seuil par champ. Un champ qui engage de l'argent tolère zéro écart ; un résumé interne en tolère plus. Décide les seuils avant de regarder les résultats.
- Refais le test à chaque changement. Nouveau modèle, nouvelles instructions, nouvelle source de documents : on repasse.
Ce test est une éval, et la concevoir et la maintenir fait partie de l'évaluation de la qualité des agents d'IA. Une fois l'agent en service, l'étape suivante est de mesurer la performance de tes automatisations, pour que la variation ne s'infiltre pas pendant la nuit.
Que faire si deux réponses contradictoires sont déjà parvenues à un client ?
D'abord, reconstitue ce qui s'est passé : sans trace de l'entrée, du contexte récupéré, de la version du modèle et de la sortie, tu ne peux pas savoir laquelle des deux était la bonne. Ensuite, referme la brèche :
- Sors la donnée du texte libre. Si la contradiction portait sur un délai ou une condition, arrête de la générer : fais-la lire dans une source unique.
- Fais en sorte que le système se recoupe lui-même. Pour les réponses à risque, génère deux fois et, si elles ne concordent pas sur le fond, ne les envoie pas : passe la main à une personne. Cela coûte plus cher par réponse, donc réserve-le aux endroits où l'erreur coûte cher.
- Ajuste l'autonomie au risque. Ce qui ne peut pas varier et que tu ne peux pas valider automatiquement, un humain le relit avant l'envoi. C'est à cela que servent les niveaux d'autonomie d'un agent et l'humain dans la boucle.
Quand ne vaut-il pas la peine de chercher la cohérence ?
Quand la sortie est un brouillon qu'une personne va relire et retoucher, quand l'erreur est peu coûteuse et réversible, ou quand la variation est la valeur (idées, variantes d'un texte). Exiger zéro variation là rend le système plus cher sans protéger personne. Mets la rigueur là où une réponse différente coûte de l'argent ou de la confiance, et laisse respirer le reste.
La ligne à retenir : ne demande pas au modèle d'être toujours identique ; conçois le processus pour que ce qui ne peut pas changer ne dépende pas de lui.
Sources (consultées le 29 octobre 2026) : « Defeating Nondeterminism in LLM Inference », Thinking Machines Lab (10 septembre 2025), utilisée de façon qualitative. Le scénario d'ouverture est illustratif.