← Journal
Cadre de décision·mai 2026·Journal

Non-déterminisme : pourquoi l'IA change de réponse

Le non-déterminisme n'est pas un bug à corriger — c'est une décision d'architecture. Ce que ça impose à un système en production.

Le principe

Un LLM échantillonne, il ne calcule pas : à entrée identique, il peut produire des sorties différentes — par conception. Ce n'est pas un défaut à corriger, c'est une propriété à cadrer.

Thinking Machines Lab — « Defeating Nondeterminism in LLM Inference » (sept. 2025)

La cause n'est ni le hasard « pur » ni le calcul flottant : c'est la variabilité du batch côté serveur. Le non-déterminisme se maîtrise quand on contrôle la pile d'inférence — mais derrière une API tierce, vous ne la contrôlez pas.

La règle

Pour chaque tâche, avant d'y mettre une IA, une seule question :

La question qui tranche

Le résultat doit-il être reproductible et auditable ?

Les deux cas

  • Oui → déterministe. Calculs, règles métier, conformité, montants, décisions traçables. Ça se câble en dur — code, automatisation. L'IA prépare, elle ne tranche jamais seule.
  • Non → non-déterministe assumé. Rédaction, exploration, synthèse, jugement sous incertitude. La variabilité devient un atout — à condition de la contenir.
Le piège

Placer un LLM sur une tâche déterministe est l'erreur d'architecture n°1.

Contenir le non-déterminisme (quand on le garde)

  • Sortie contrainte — imposer un schéma ou un format de réponse strict.
  • Garde-fous déterministes — validation, bornes, vérifications autour de l'appel.
  • Évaluation systématique — une IA-juge qui note les sorties sur une grille, pour détecter la dérive avant la production, pas en production.

À retenir

À retenir

La bonne question n'est pas « quel modèle ? » mais « cette tâche doit-elle être reproductible ? ». C'est cette ligne de partage — pas la puissance du modèle — qui sépare un POC qui impressionne d'un système qui tient.

← Le guideSuivant : Un serveur à soi