Votre IA n'a pas de numéro de version

Aug 17, 2026 min read
Votre IA n'a pas de numéro de version

Posez deux fois exactement la même question à un modèle, avec la température à zéro, sur la même version, à la même heure. Vous pouvez obtenir deux réponses différentes.

Pas parce que quelqu’un a mal configuré quelque chose. Parce que c’est comme ça que ça marche.

Et si vous faites le même métier que moi, cette phrase devrait vous faire un drôle d’effet. J’ai passé quinze ans à me battre pour exactement l’inverse.

Ce qu’on a mis quinze ans à obtenir

Repensez à tout ce qu’on a construit, et pourquoi.

  • la gestion de versions, pour savoir exactement quel code tourne ;
  • l’infrastructure as code, pour que la production soit décrite quelque part et pas dans une tête ;
  • les fichiers de verrouillage, pour que npm install d’aujourd’hui donne la même chose que celui d’il y a six mois ;
  • les images immuables, pour arrêter de réparer les serveurs à la main ;
  • les tests de non-régression, pour détecter qu’un comportement a changé sans qu’on le veuille.

Tout ça sert une seule idée : la même entrée doit produire la même sortie. C’est ce qui rend un incident analysable, un correctif vérifiable et un audit possible. J’écrivais il y a quelques jours que le vrai sujet de l’infrastructure as code, c’est que le dépôt décrive la production.

Puis on a branché un LLM en production, et on a jeté tout ça par la fenêtre sans qu’une seule réunion soit organisée à ce sujet. Vous vous souvenez d’avoir eu cette discussion, vous ? Moi non plus.

Deux fois la même question, deux réponses

Commençons par le plus troublant, parce que même des gens du métier l’ignorent.

L’explication qu’on entend d’habitude, c’est la virgule flottante : sur un GPU, l’addition n’est pas associative, les threads s’exécutent dans un ordre variable, donc le résultat bouge. C’est séduisant, et c’est largement faux. Les travaux de Thinking Machines sur le sujet montrent qu’un noyau de calcul pris isolément est en général déterministe au bit près, à matériel et entrées fixés.

La vraie cause est ailleurs, et elle est bien pire pour nous : la dépendance à la taille du lot.

Votre requête n’est pas traitée seule. Elle est regroupée avec celles des autres clients dans un lot dont la taille varie selon la charge du moment. Or les noyaux de réduction — ceux qui font les sommes dans la normalisation, l’attention, les multiplications de matrices — changent de stratégie d’accumulation selon la taille du lot. Une infime dérive numérique apparaît, se propage de couche en couche, et finit par changer un jeton.

Relisez ça tranquillement, parce que la première fois je l’ai lu deux fois. La réponse que vous obtenez dépend du nombre de gens qui interrogeaient le modèle au même instant que vous.

Il existe des noyaux invariants à la taille du lot, qui restaurent le déterminisme au bit près. C’est une vraie solution, et elle prouve que le problème est réparable. Simplement, ce n’est pas ce que vous avez au bout de votre appel d’API aujourd’hui.

« Il suffit d’épingler une version »

C’est la réponse réflexe, et elle est légitime : on sait faire, on fait ça depuis toujours. Les fournisseurs proposent d’ailleurs des versions datées, du type gpt-5-2025-08-07. Vous épinglez, vous êtes tranquille.

Sauf que ces épingles ont une date de péremption.

Le 11 juin 2026, OpenAI a prévenu ses développeurs que six versions figées de génération courante seraient retirées de l’API le 11 décembre 2026. Parmi elles, gpt-5-2025-08-07 et o3-2025-04-16. La politique annoncée, c’est au moins six mois de préavis pour les modèles en disponibilité générale, trois mois pour les variantes spécialisées, et deux semaines pour les préversions.

Et le basculement est sec, sans période de grâce : la veille, votre requête fonctionne ; le lendemain, elle renvoie une erreur.

Comparez avec ce que vous avez l’habitude de manipuler. Une version de bibliothèque épinglée dans un fichier de verrouillage reste installable des années. Une image de conteneur avec son empreinte reste tirable indéfiniment tant que vous gardez votre registre. Là, vous avez un fichier de verrouillage avec une date limite de consommation, et ce n’est pas vous qui la fixez.

Ce n’est pas un scandale, d’ailleurs. Garder en ligne des dizaines de générations de modèles coûte une fortune en matériel immobilisé. C’est parfaitement compréhensible. Mais il faut en tirer la conséquence : vous n’avez pas une dépendance, vous avez un abonnement à quelque chose qui bougera.

Ce que ça casse, concrètement

Bon, et alors ? Est-ce que ça change quelque chose pour vous, honnêtement, si la réponse varie de temps en temps ?

Alors oui. Vous allez reconnaître au moins un point de la liste :

  • vous ne pouvez pas reproduire un incident. Un client se plaint d’une réponse aberrante datée de mars. Le modèle de mars n’existe plus, et même s’il existait, la même entrée ne redonnerait pas la même sortie ;
  • vous ne pouvez pas faire de test de non-régression au sens strict. Comparer octet à octet n’a aucun sens. Il faut passer à des comparaisons statistiques sur un jeu d’exemples, ce qui est un autre métier et que presque personne n’a mis en place ;
  • votre journalisation ment par omission. Si vous n’avez enregistré que le prompt et la réponse, sans le nom exact de la version ni les paramètres, vous ne pouvez rien reconstituer ;
  • votre migration est forcée et datée. Vous ne choisissez pas quand vous changez de modèle. On vous donne six mois, et parfois deux semaines.

Le dernier point est celui qui devrait remonter au comité de direction, parce que c’est un risque d’exploitation, pas un sujet de laboratoire.

Alors on fait quoi

Je n’ai pas de solution magique — la reproductibilité au sens où on l’entendait est perdue, et il faut l’accepter. En revanche on peut arrêter de faire semblant, et quatre choses fonctionnent.

Enregistrez la version exacte à chaque appel. C’est la première chose que je demande en arrivant sur une plateforme, et c’est presque toujours absent. Dans les journaux, à côté de la réponse. Pas « GPT », pas « le modèle » : la chaîne complète avec sa date. C’est trois lignes de code, et c’est ce qui vous permettra de dire « le comportement a changé le 14 » au lieu de « les utilisateurs trouvent que c’est moins bien depuis quelque temps ».

Constituez un jeu d’évaluation, et versionnez-le comme du code. Trente à cent cas réels, avec ce qu’on attend en sortie. C’est la seule chose qui vous dira si le prochain modèle fait aussi bien, et c’est aussi ce qui vous rend capable de changer de fournisseur. J’en parlais dans l’article sur la souveraineté : sans jeu d’évaluation, vous êtes captif par votre propre faute.

Traitez un changement de modèle comme une migration de base de données. Avec une recette, une bascule progressive, une comparaison des deux versions en parallèle sur du trafic réel, et un plan de retour arrière tant que l’ancienne version existe encore. Pas comme une mise à jour de dépendance mineure.

Et acceptez le non-déterminisme au lieu de le combattre. J’ai mis du temps à m’y résoudre, je l’avoue. Si votre chaîne exige une sortie identique, le problème n’est pas le modèle, c’est votre conception. Contraignez le format, validez la sortie contre un schéma, rendez l’opération idempotente en aval. On sait faire des systèmes fiables avec des composants non fiables : c’est même à peu près toute l’histoire de notre métier.

En conclusion

Ce qui me frappe, ce n’est pas que l’IA soit non déterministe. C’est qu’on l’ait mise en production sans jamais poser la question.

On a passé quinze ans à traquer la moindre dérive de configuration, à s’interdire de modifier un serveur à la main, à exiger qu’un terraform plan sorte vide. Et le même mois, on a branché sur le chemin critique un composant dont on ne maîtrise ni la version, ni la durée de vie, ni la sortie exacte. Sans revue, sans discussion, souvent sans même une ligne dans le registre des risques.

Ce n’est pas une raison pour ne pas s’en servir. J’en utilise tous les jours. C’est une raison pour arrêter de le traiter comme une bibliothèque de plus.

Vous n'avez pas ajouté une dépendance. Vous avez ajouté un fournisseur qui a le droit de changer d'avis.

Sources

-|