Un agent IA qui répond une fois sur deux de façon différente à la même question pose un problème que la plupart des équipes découvrent trop tard : on ne peut ni le tester, ni le corriger, ni le déployer proprement. Ce problème a un nom, la reproductibilité, et il est au cœur de l’industrialisation.
La reproductibilité signifie que le même système, relancé avec les mêmes entrées, produit le même résultat. C’est une évidence pour un logiciel classique, et c’est précisément ce que les agents perdent dès lors qu’ils reposent sur des modèles non déterministes.
Cet article explique pourquoi cette perte est un obstacle, et ce que l’on peut mettre en place pour la maîtriser : versionner ce qui change le résultat, épingler les modèles, et s’appuyer sur un jeu d’évaluation stable. Ce sont les fondations d’un agent exploitable en production.
Un agent n’est jamais deux fois le même
Le non-déterminisme vient de plusieurs sources. La première est le modèle lui-même : un grand modèle de langage échantillonne une réponse parmi des possibles, et deux appels identiques donnent souvent deux réponses différentes. La seconde est la chaîne de dépendances : version du modèle, du prompt, des outils, des données, qui changent indépendamment.
Les conséquences sont concrètes. Un utilisateur signale une mauvaise réponse, et vous ne pouvez pas la reproduire pour la corriger. Un test passe aujourd’hui et échoue demain, sans que rien n’ait changé dans le code. Un déploiement qui a fonctionné en préproduction se comporte autrement en production.
On peut tolérer une part de variation dans la formulation d’une réponse. Ce qu’on ne peut pas tolérer, c’est l’incapacité à savoir pourquoi une réponse a été produite et à la reproduire pour la juger. C’est cette capacité que la reproductibilité vise à restaurer.
Versionner tout ce qui change le résultat
La première mesure est le versionnage de tout ce qui influence la sortie d’un agent : le code, le prompt, la configuration, la version du modèle, les outils et leurs paramètres. Si l’un de ces éléments change sans être tracé, le comportement change sans explication, et toute comparaison dans le temps devient impossible.
Ce versionnage doit être conjoint, pas séparé. Ce qui importe n’est pas la version de chaque pièce, mais la combinaison exacte qui a produit un comportement donné. C’est cette combinaison qu’il faut pouvoir reconstituer, à tout moment, pour rejouer un cas ou auditer une décision.
Concrètement, cela passe par des pratiques ordinaires : tout dans le dépôt de code, les prompts traités comme du code, les versions de modèle explicites dans la configuration, et un identifiant de version global qui regroupe le tout. Rien de spectaculaire, mais c’est ce qui permet de savoir ce qui tourne réellement en production.
Le jeu d’évaluation comme référence stable
La reproductibilité ne sert pas qu’à rejouer, elle sert à juger. Pour savoir si un changement améliore ou dégrade un agent, il faut une référence stable : un jeu de cas d’évaluation, fixe, avec pour chacun les critères de réussite.
Sans ce jeu, chaque changement est un pari. On modifie le prompt, on a l’impression que c’est mieux, et on découvre deux semaines plus tard qu’on a cassé dix cas qu’on ne testait pas. Avec un jeu d’évaluation stable, chaque changement se juge sur les mêmes cas, et la régression se voit immédiatement.
Le jeu d’évaluation doit lui-même être versionné et préservé. C’est lui qui donne son sens à toutes les autres mesures. Le construire demande du temps au départ, mais c’est l’investissement qui transforme un agent en système qu’on peut faire évoluer sans peur.
Épingler les modèles et les paramètres
Une source majeure de dérive est le modèle lui-même. Les fournisseurs mettent à jour leurs modèles en continu, et le même nom de modèle ne désigne pas toujours le même comportement d’un mois à l’autre. Épingler un modèle, c’est verrouiller une version précise et ne la changer que délibérément.
Il faut également verrouiller les paramètres qui influencent le hasard : la température, et tout ce qui contrôle l’échantillonnage. Une température élevée augmente la variabilité, ce qui est utile pour la créativité mais nuisible pour la fiabilité. Sur un agent de production, on la réduit, et on la fixe.
Ces réglages ne garantissent pas un résultat identique à chaque appel, mais ils réduisent la variabilité et, surtout, ils la rendent stable et prévisible. Le reste de la variabilité est alors assumé, pas subi.
La reproductibilité comme condition du déploiement
Beaucoup d’équipes considèrent la reproductibilité comme un luxe d’ingénierie, à traiter une fois que le produit marche. C’est l’inverse : c’est une condition pour pouvoir déployer et itérer sans casser. Un agent non reproductible est un agent qu’on ne peut ni tester ni auditer, donc qu’on ne peut pas exploiter sérieusement.
Le seuil minimal pour industrialiser tient en trois points : un versionnage conjoint de tout ce qui influence la sortie, un jeu d’évaluation stable, et des modèles épinglés. Ces trois points posés, on peut tester, déployer, corriger et mesurer, c’est-à-dire faire tout ce qu’on attend d’un logiciel.
Ce qui rend la chose abordable, c’est qu’il ne s’agit pas d’une refonte, mais d’une discipline. Les outils existent, les pratiques sont connues. Ce qui manque le plus souvent, c’est la décision de les appliquer avant que le système ne devienne trop gros pour être repris.
L’accompagnement Agenticiel pour rendre vos agents reproductibles
Mettre en place la reproductibilité demande de structurer ce qui est souvent resté informel : le versionnage, le jeu d’évaluation, les réglages de modèle. C’est un travail d’industrialisation que nous menons pour des équipes qui passent un agent du prototype à la production.
Agenticiel intervient comme sous-traitant de développement : mise en place du versionnage, constitution du jeu d’évaluation, verrouillage des modèles et des paramètres. L’équipe est composée de développeurs offshore francophones basés à Madagascar, ce qui réduit le coût de ce chantier tout en conservant une communication directe, dans votre langue et sur votre fuseau.
Notre approche consiste à faire de la reproductibilité un préalable, pas un raffinement : on versionne ce qui change le résultat, on fige la référence d’évaluation, et on ne déploie que ce que l’on sait rejouer et juger.