L'informatique classique repose sur le déterminisme : même entrée, même sortie, à chaque fois. Les moteurs de recherche ont commencé à flouter ce principe. Les LLM l'ont totalement abandonné. Quelles sont les implications pour les développeurs ?
Depuis les origines de l'informatique, le déterminisme est un axiome fondateur : à entrée identique, un programme produit toujours la même sortie. C'est ce qui rend les logiciels testables, déboguables, prévisibles. Un bug est reproductible, une régression est détectable, un test peut échouer ou réussir de façon binaire. Ce contrat implicite est en train d'être rompu.
Une érosion progressive : du déterminisme au flou
Le glissement n'a pas commencé avec les LLM. Les moteurs de recherche ont été les premiers à introduire de l'opacité dans leurs résultats : PageRank, puis les algorithmes de personnalisation, font varier les résultats selon l'heure, la localisation, l'historique de navigation. Deux utilisateurs tapant la même requête obtiennent des réponses différentes. La sortie n'est plus universelle — elle est contextuelle. Les systèmes de recommandation ont franchi une étape supplémentaire : leurs sorties dépendent d'un modèle entraîné sur des milliards de données, dont le comportement est difficile à prédire même pour leurs concepteurs.
Les LLM : le non-déterminisme assumé
Les grands modèles de langage ont fait du non-déterminisme une fonctionnalité. Le paramètre temperature contrôle
l'aléatoire de la génération : à 0, le modèle est quasi-déterministe (il choisit toujours le token le plus probable) ; à
1 ou plus, il explore des chemins moins probables. Deux appels identiques à temperature=0.7 produiront deux réponses
différentes. Ce n'est pas un bug — c'est un choix de conception pour rendre les réponses moins répétitives et plus
créatives. Mais pour un développeur qui intègre un LLM dans un système, c'est une rupture paradigmatique.
L'art de flouter le processus
Ce qui rend les LLM particulièrement délicats à manipuler, c'est l'absence de signal d'erreur. Un programme déterministe qui échoue lance une exception, retourne un code d'erreur, produit une sortie manifement incorrecte. Un LLM qui « se trompe » produit une réponse convaincante, bien rédigée, grammaticalement correcte — et factuellement fausse. Pas de stack trace. Pas de warning. Le processus de raisonnement est opaque par construction : on obtient une réponse, pas une explication auditée de comment elle a été produite.
Implications pour les développeurs
Intégrer un LLM dans une chaîne logicielle impose de repenser plusieurs pratiques :
- Les tests unitaires classiques ne suffisent plus : on ne peut pas asserter une valeur exacte sur une sortie LLM. On teste des propriétés (la réponse contient un JSON valide, la réponse mentionne le bon nom de produit) plutôt que des valeurs.
- Temperature=0 pour les usages critiques : classification, extraction de données structurées, code generation — réduire l'aléatoire au minimum.
- Validation de sortie systématique : parser et valider le format de retour, ne jamais faire confiance à la structure sans la vérifier.
- Human-in-the-loop : pour tout ce qui a des conséquences réelles (envoi d'email, modification de données, décision métier), garder un humain dans la boucle de validation.
- Traçabilité et logging : stocker les inputs et outputs pour pouvoir analyser les comportements aberrants a posteriori.
L'IA générative est un outil puissant — mais il oblige à un changement de posture : passer d'une ingénierie du contrôle total à une ingénierie de la probabilité gérée. Ce n'est pas une régression, c'est une nouvelle compétence à développer.