Le jour où le modèle a changé sans prévenir

Un lundi, le système fonctionne. Le mardi, les utilisateurs signalent que les réponses sont plus longues, moins directes, et qu'une consigne de format n'est plus respectée. Aucun déploiement n'a eu lieu. Le code est identique.

Le fournisseur a mis à jour la version du modèle servie derrière le même identifiant. C'est prévu dans ses conditions, c'est annoncé quelque part, et personne dans l'équipe ne l'avait vu passer.

C'est la régression la plus fréquente lors d'un changement de version : le modèle se met à ajouter une phrase d'introduction, ou à modifier une casse, ou à entourer sa réponse de guillemets.

Sur un système où la sortie est lue par un humain, c'est mineur. Sur un système où elle est consommée par un autre programme, c'est une panne, et une panne qui ne se manifeste que sur une fraction du trafic, donc difficile à reproduire.

Je valide donc systématiquement la structure de la sortie, avec reprise automatique en cas d'échec et alerte au-delà d'un seuil de reprises.

C'est le seul argument technique sérieux en faveur d'un modèle hébergé : le comportement ne change que si vous le décidez.

Il ne suffit pas à trancher, l'exploitation d'un modèle interne a son propre coût, détaillé dans modèles ouverts et souveraineté. Mais sur un système dont la sortie alimente un processus automatisé, cette stabilité vaut cher.

Avec un rythme de génération de six mois, ce n'est plus un incident mais une routine, et il doit être traité comme tel. La question n'est plus de l'éviter mais de le rendre indolore.

Une équipe qui a isolé l'appel derrière une couche d'abstraction et qui dispose d'un jeu de tests traite l'événement en deux heures. Une équipe qui n'a ni l'un ni l'autre le subit comme une panne dont l'origine reste obscure pendant des jours.

L'écart d'effort initial entre les deux se compte en heures. L'écart sur trois ans se compte en mois, comme détaillé dans la couche qui rend le modèle remplaçable.

Un préavis chiffré avant le retrait d'une version, et la possibilité d'épingler une version datée : ces deux points se négocient au contrat, pas au moment de l'incident. Ils déterminent la charge d'exploitation.

La question à poser tient en une phrase : combien de temps une version reste-t-elle disponible après l'annonce de son remplacement. Un fournisseur qui répond précisément a pensé à ses clients en production ; un fournisseur qui esquive vous fera migrer dans l'urgence.

Ce critère et les trois autres qui décident réellement d'un fournisseur sont détaillés dans évaluer un fournisseur d'IA hors capacités.

Le taux de réponses « je ne sais pas », suivi dans le temps, est le signal le plus fiable d'un changement de comportement du modèle. Il bouge avant que quiconque ne se plaigne.

Une baisse soudaine signale que le système s'est mis à répondre là où il refusait, ce qui est une dégradation, pas un progrès. Une hausse signale l'inverse : le modèle est devenu plus prudent, et une partie des questions légitimes reçoit désormais un refus.

Dans les deux cas, l'alerte arrive plusieurs jours avant les signalements utilisateurs. Le tableau de bord correspondant est décrit dans ce qui occupe l'équipe la deuxième année.

Une ligne datée indiquant 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 informations, et elles manquent presque toujours.

Leur absence produit une situation que je rencontre régulièrement en reprise : un système qui fonctionne moins bien qu'avant, sans que personne ne puisse dater le moment ni identifier ce qui a changé. Le diagnostic devient alors une enquête de plusieurs jours, pour une information qui aurait tenu en une ligne.

Cette consignation a une seconde utilité, en conformité cette fois : elle démontre que les changements de modèle sont suivis et évalués, ce qui est précisément ce qu'un contrôle cherche à établir.

Le registre correspondant se tient en même temps que les fiches de systèmes, au rythme trimestriel décrit dans préparer un contrôle de conformité en deux semaines.