Migrer un agent d'un modèle à l'autre sans régression

Un système en production change de modèle deux à trois fois par an : parce que le fournisseur déprécie une version, parce qu'un modèle moins cher fait aussi bien, ou parce qu'une nouvelle génération sort.

Cette opération est traitée comme une mise à jour de dépendance. Elle n'en est pas une : le comportement change de façon diffuse, sur des cas qu'aucun test technique ne couvre.

Ce que je vois régulièrement : on profite du changement de modèle pour retoucher les prompts, parce qu'on sait que le nouveau modèle « préfère » d'autres formulations.

Résultat : quand la qualité bouge, on ne sait pas si c'est le modèle ou le prompt. Et comme la mesure porte sur l'ensemble, on ne peut pas revenir en arrière partiellement.

La règle est donc stricte : d'abord le modèle seul, à prompt identique, mesuré. Ensuite seulement, l'optimisation du prompt pour le nouveau modèle, mesurée à son tour.

C'est le point qui casse le plus souvent en production, et le moins souvent en test.

Un système qui attend une sortie structurée fonctionne parfaitement sur les trente cas du jeu de tests, puis échoue sur deux pour cent du trafic réel parce que le nouveau modèle ajoute une phrase d'introduction, ou change une casse. Ces deux pour cent suffisent à faire remonter des incidents.

La parade n'est pas dans le prompt : c'est une validation stricte de la sortie, avec reprise automatique en cas de non-conformité, et une alerte si le taux de reprise dépasse un seuil.

Rien de ce qui précède n'est réalisable sans deux prérequis posés bien avant : une couche d'abstraction qui isole l'appel au modèle, et un jeu de tests métier maintenu.

C'est pour cela que je les installe dès la première semaine d'une mission, même quand le système ne compte que trois cas d'usage. Ce sont les deux investissements dont le rendement se manifeste au douzième mois, et qu'on ne peut pas faire rétroactivement sans tout rouvrir.

Avec un rythme de remplacement de six mois, la migration n'est plus un événement mais une routine trimestrielle. La question n'est plus de l'éviter mais de la rendre indolore.

Une équipe qui dispose d'une couche d'abstraction et d'un jeu de tests traite l'opération en deux heures : on change l'identifiant, on relance, on compare, on bascule par paliers.

Une équipe qui n'a ni l'un ni l'autre subit chaque génération comme une perturbation de plusieurs jours. L'écart d'effort initial se compte en heures, l'écart sur trois ans en mois, comme détaillé dans la couche qui rend le modèle remplaçable.

Un modèle plus capable peut respecter moins strictement un format de sortie contraint, et cette régression ne se voit pas sur un test de qualité. C'est le défaut le plus coûteux d'une bascule.

Une sortie invalide une fois sur vingt casse une chaîne automatisée, alors même que les dix-neuf autres réponses sont meilleures qu'avant. Le jeu de tests doit donc mesurer la validité du format séparément de la justesse du contenu.

Les capacités de sortie structurée garantie ont supprimé une bonne part de ce risque, et il subsiste sur tout ce qui n'est pas contraint par un schéma, le raisonnement de sorties structurées.

Quelle version était en service, quelle version l'a remplacée, et ce que le jeu de tests a mesuré avant et après. Trois lignes, et elles manquent presque toujours.

Leur absence produit une situation fréquente en reprise : un système qui fonctionne moins bien qu'avant, sans que personne ne puisse dater le changement ni identifier ce qui l'a causé.

Cette consignation sert aussi en conformité, où elle démontre que les changements de modèle sont suivis et évalués. Elle se tient au rythme trimestriel décrit dans préparer un contrôle de conformité en deux semaines.