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

Un changement silencieux de modèle survient quand un fournisseur d’API remplace la version servie derrière un même identifiant, si bien que le système se comporte autrement sans qu’aucune ligne de code n’ait changé. C’est un scénario à préparer, dont voici un exemple générique.

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.

Certains fournisseurs proposent notamment deux façons d’appeler un modèle : un alias générique, qui peut être réaffecté à une nouvelle version, et un identifiant daté, qui désigne une version précise jusqu’à son retrait. Le choix entre les deux décide de qui contrôle le moment du changement.

Une version identifiée, des tests rejoués régulièrement et une validation explicite des sorties limitent les régressions, à condition de surveiller aussi les paramètres et les données de l’application.

• Épingler une version datée du modèle quand le fournisseur le permet, plutôt que l’alias générique. C’est la protection la plus efficace et la plus souvent négligée.
• Rejouer le jeu de tests automatiquement, chaque semaine, même sans changement de votre côté. C’est ce qui transforme une dérive invisible en alerte.
• Surveiller deux indicateurs simples : la longueur moyenne des réponses et le taux de conformité du format. Ils bougent avant que les utilisateurs ne se plaignent.

Un changement de comportement se détecte en comparant réponses, formats, refus et erreurs sur des cas stables, puis en recherchant les changements possibles de modèle, de données ou de paramètres. Aucun indicateur unique ne suffit.

Une baisse des refus peut refléter de meilleures réponses ou des affirmations non justifiées. Une hausse peut refléter une prudence accrue ou une nouvelle difficulté des questions reçues. Je confronte donc le signal aux cas concernés.

Les tests périodiques doivent garder prompts, documents, paramètres et règles d’évaluation identifiables. L’évaluation continue formalise ce suivi. Lecture complémentaire sur l’exploitation : ce qui occupe l’équipe la deuxième année.

La validation du format de sortie protège les programmes qui consomment une réponse, car une structure incorrecte peut casser la chaîne même lorsque le texte semble compréhensible. Le modèle se met à ajouter une phrase d’introduction, à 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 un nombre borné de reprises, une alerte et un repli sûr en cas d’échec. Lecture complémentaire sur la consigne : écrire un prompt système qui tient six mois.

Une équipe qui appelle une API contrôle son application, ses paramètres et les versions proposées au contrat, tandis que le fournisseur maîtrise l’infrastructure et certaines évolutions du service.

Vous ne contrôlez pas le modèle. C’est le prix d’une API, et c’est un prix raisonnable : à condition d’avoir la mesure qui vous dit quand quelque chose a bougé. Sans elle, vous découvrirez le changement par les utilisateurs, si aucune mesure ne signale les écarts.

Le jour où le modèle change sans prévenir, il faut d’abord confirmer le changement par le jeu de tests, puis revenir à la version précédente si elle reste disponible, et consigner l’événement. La séquence tient en cinq étapes.

1. Confirmer : rejouer le jeu de tests et comparer aux résultats de la semaine précédente, pour distinguer un changement de modèle d’un changement de données ou d’usage.
2. Identifier la version : vérifier dans les journaux et dans les annonces du fournisseur quelle version était servie avant et après.
3. Revenir en arrière si possible : épingler la version datée précédente tant qu’elle est disponible, pour rétablir le service.
4. Corriger pour la nouvelle version : ajuster le prompt et la validation de format, puis rejouer les tests jusqu’à retrouver le niveau antérieur.
5. Consigner : 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.

Je vérifie ces trois informations dès la reprise d’un système. 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, avec les éléments utiles à un contrôle des versions et de leur qualification. Lecture complémentaire sur la tenue du dossier : préparer un contrôle de conformité en deux semaines.

Le changement de modèle doit être prévu dans l’exploitation d’un service, sans supposer une cadence universelle ni un temps de migration identique pour toutes les équipes. Je cherche à réduire le risque, pas à promettre une durée.

Une couche d’abstraction isole le contrat d’appel et rend la comparaison plus facile, comme dans la couche qui rend le modèle remplaçable. Elle ne supprime pas le travail sur les prompts, les formats et les erreurs.

Il faut prévoir un responsable de veille, une fenêtre de recette et un moyen de revenir en arrière. Ces conditions font partie du passage du prototype au service.

Une formation IA peut partir d’un exercice de migration : mêmes cas, deux versions, comparaison des erreurs, puis décision écrite de maintien ou de bascule.

Un préavis chiffré avant le retrait d’une version et la possibilité d’épingler une version datée se négocient au contrat avec le fournisseur de modèle, pas au moment de l’incident. Ces deux points 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.

Lecture complémentaire pour qualifier le fournisseur : évaluer un fournisseur d’IA hors capacités.

Héberger un modèle donne davantage de contrôle sur ses poids et sa version, mais la stabilité dépend aussi des paramètres, du logiciel et des données qui l’entourent. L’exploitation d’un modèle interne a son propre coût.

Lecture complémentaire sur ce choix : modèles ouverts et souveraineté. Mais sur un système dont la sortie alimente un processus automatisé, cette stabilité vaut cher.

Le bon critère est donc la nature du consommateur de la sortie. Si c’est un humain qui lit, une version épinglée et un jeu de tests suffisent. Si c’est un programme qui enchaîne, la stabilité devient une exigence, et l’hébergement interne mérite d’être chiffré. Un audit IA de l’architecture existante permet de situer chaque système de part ou d’autre de cette ligne.

L’erreur qui rend un changement de modèle douloureux est d’appeler un alias générique sans jeu de tests, ce qui laisse les utilisateurs découvrir la régression à la place de l’équipe. Les autres erreurs aggravent ce point de départ.

• Ne pas lire les annonces de dépréciation du fournisseur, et apprendre le retrait d’une version le jour où elle disparaît.
• Tester seulement au déploiement, alors que le modèle peut changer entre deux déploiements.
• Laisser le format de sortie sans validation, ce qui transforme une variation de forme en panne de la chaîne aval.
• Ne rien consigner, et devoir reconstituer après coup ce qui a changé et quand.
• Optimiser le prompt pour une version précise en s’appuyant sur ses particularités, ce qui rend la migration suivante plus coûteuse.