// LOGICIEL
Coder en dur les invites : une nouvelle dette technique
6 min de lecturenijitech
Quand les invites de modèle se dispersent dans le code source, chaque changement de texte devient une mise en production. C’est exactement ce qui est arrivé au SQL.
Article complet
Dans une application qui gagne une fonction d’IA, les invites vont généralement à l’endroit le plus pratique : à l’intérieur de la fonction qui fait l’appel. La première semaine, c’est le bon choix — c’est rapide et ça marche. Au sixième mois, la même décision a produit la partie du produit la plus lente à changer.
Une histoire connue. Il y a dix ans, les requêtes SQL étaient elles aussi enfouies dans le code applicatif, et tout changement de requête exigeait un déploiement. Le résultat est le même : un changement de texte devient une tâche d’ingénierie.
Quatre coûts d’une invite codée en dur
Ce qui se passe réellement
- Une correction d’un mot exige de sortir une version
- La même consigne est copiée dans plusieurs fichiers ; l’un est mis à jour, l’autre oublié
- On ne voit pas quelle invite a changé quand — la cause d’un changement de comportement reste introuvable
- La personne qui devrait écrire le texte (l’expert métier) ne peut pas atteindre le fichier
Le quatrième est le plus insidieux. Une invite est en réalité du contenu produit : son ton, sa portée et ses limites demandent une connaissance métier. Enfouie dans le code, le droit d’écrire ce contenu a été retiré à celui qui devrait l’écrire.
Une invite est de la configuration
Le remède n’est pas compliqué : les invites vivent à part du code, sous contrôle de version, et l’application les appelle par un identifiant. Dès lors, changer une invite est une tâche de configuration plutôt qu’un déploiement.
Le versionnage rend un changement réversible
Quand une invite change, le comportement change, et parfois il empire. Sans versions il n’y a nulle part où revenir ; il ne vous reste que le constat qu’hier c’était mieux.
C’est là qu’apparaît le lien avec le jeu d’évaluation. Avec une invite versionnée et un jeu d’évaluation exécutable ensemble, vous pouvez mesurer à chaque changement quelle catégorie a régressé. S’il en manque un des deux, la mesure reste incomplète.
Ce qui arrive quand le modèle change
Les modèles vieillissent, et quand une version moins chère ou plus puissante sort, vous voulez bouger. Si les invites sont dispersées dans le code, la migration devient une opération de rechercher-remplacer et chaque invite doit être essayée une par une contre le nouveau modèle.
Avec les invites au même endroit, la même migration est un changement de configuration et un passage du jeu d’évaluation. La différence se compte en heures contre des jours.
Par où commencer
Les trois premières étapes
- Rassembler au même endroit toutes les invites du dépôt — juste les déplacer, rien d’autre
- Donner à chaque invite un identifiant et un numéro de version
- Écrire le prochain changement comme une nouvelle version ; ne pas supprimer l’ancienne
Aucune des trois ne demande un changement d’architecture. Le bénéfice arrive le premier jour où vous devez revenir en arrière.
Du glossaire : Orchestration de modèles · Jeu d'évaluation (eval)