Changer de modèle IA sans régression : protocole de migration

Changer de modèle IA n’est pas une modification de configuration anodine. Même lorsque l’API accepte les mêmes champs, le nouveau modèle peut interpréter une consigne différemment, appeler un outil à un autre moment, refuser davantage de cas, produire un JSON différent ou déplacer le compromis entre qualité, coût et latence. La bonne unité de migration est donc le système complet, pas le seul nom du modèle.

Une migration sûre compare deux baselines. La première décrit ce que l’application actuelle sait réellement faire, erreurs comprises. La seconde décrit le comportement acceptable après le changement. Entre les deux, on exécute les mêmes cas, on lit les écarts, on expose progressivement le nouveau chemin et on garde une voie de retour testée.

Réponse en bref

Pour changer de modèle IA sans régression :

1. recensez tous les endroits où le modèle, son alias, ses paramètres ou ses limites sont utilisés ;
2. figez une baseline de qualité, sécurité, coût, latence et exploitation sur le système actuel ;
3. écrivez un contrat de compatibilité qui couvre API, contexte, outils, sorties, refus et métriques ;
4. construisez un jeu d’évaluation représentatif à partir des tâches et incidents réels ;
5. exécutez ancien et nouveau chemins sur les mêmes entrées, sans effet externe ;
6. classez chaque écart comme amélioration, équivalence, régression, changement accepté ou résultat indécidable ;
7. corrigez le code, les paramètres et les consignes uniquement pour un écart observé ;
8. lancez un canary sur une faible part de trafic, avec des critères d’arrêt automatiques ;
9. vérifiez que le retour arrière restaure aussi l’état, les files et les versions de données ;
10. retirez l’ancien modèle seulement après la fenêtre d’observation et la fermeture des dépendances.

La prochaine action utile est de produire un inventaire des appels et un échantillon de vingt à cinquante cas. Tant que ces deux éléments n’existent pas, remplacer l’identifiant dans le code ne constitue pas une migration contrôlée.

Une migration est un changement de système

Les fournisseurs publient des cycles de vie, des avis de dépréciation et des remplacements. Ces informations disent qu’un modèle devient indisponible ou qu’un chemin est recommandé. Elles ne prouvent pas que le remplacement convient à votre application.

OpenAI précise que le comportement peut changer entre des versions de modèle et recommande des versions épinglées avec des évaluations. Anthropic demande de tester les applications bien avant la date de retrait et permet d’auditer l’usage par modèle. Google documente des versions stables, des dates de retrait et des chemins de migration. Le point commun est clair : le cycle du fournisseur crée une échéance, mais l’acceptation reste une responsabilité de l’application.

Le système à migrer comprend au moins :

• l’endpoint et le modèle ;
• les paramètres de génération ou de raisonnement ;
• la consigne système et les exemples ;
• la manière de construire le contexte ;
• les outils et leurs schémas ;
• le parseur de sortie ;
• les politiques de refus et de validation ;
• les reprises après erreur ;
• les seuils de coût et de latence ;
• l’interface qui présente le résultat.

Une réponse textuelle peut rester lisible tout en cassant un extracteur. Un outil peut conserver le même nom mais recevoir des arguments différents. Une amélioration moyenne peut masquer une régression sur les cas rares qui comptent le plus. C’est pourquoi l’évaluation d’un assistant avant déploiement reste utile, mais la migration ajoute une question particulière : qu’est-ce qui change par rapport au système déjà accepté ?

Recenser les dépendances au modèle

Commencez par chercher les identifiants, alias et paramètres dans le code, la configuration, les tâches planifiées, les notebooks, les files de traitement et les outils internes. L’inventaire doit relier chaque usage à un propriétaire et à une conséquence.

Champ	Exemple de question
composant	quel service effectue l’appel ?
tâche	quel résultat métier est attendu ?
modèle	version épinglée, alias ou routeur ?
endpoint	quelle interface et quel SDK ?
paramètres	quelles valeurs modifient le comportement ?
outils	quels appels sont possibles ?
sortie	texte, objet structuré, classement ou action ?
effet	lecture, proposition ou modification externe ?
volume	combien de requêtes et quels pics ?
propriétaire	qui accepte et qui peut revenir en arrière ?

Ne vous limitez pas au dépôt principal. Un modèle retiré peut rester dans une tâche nocturne, un outil d’administration ou un notebook exécuté chaque trimestre. Les pages officielles de dépréciation donnent une date ; votre inventaire indique ce qui cassera à cette date.

Les plateformes intermédiaires ajoutent une nuance. Anthropic indique par exemple que les calendriers peuvent différer entre sa propre plateforme et les plateformes partenaires. Ne copiez donc pas une date sans vérifier le fournisseur qui sert réellement l’appel.

Figer la baseline actuelle

Une baseline ne signifie pas que l’ancien modèle est bon. Elle décrit son comportement observé afin de distinguer une régression d’un défaut déjà présent.

Mesurez sur une période et un lot définis :

• taux de tâches acceptées selon vos critères ;
• erreurs graves et familles de refus ;
• respect du schéma de sortie ;
• exactitude ou fidélité sur les champs vérifiables ;
• appels d’outils réussis, inutiles ou interdits ;
• latence médiane et au 95e percentile ;
• coût moyen et dispersion par tâche acceptée ;
• longueur du contexte et de la sortie ;
• interventions humaines nécessaires ;
• incidents, reprises et abandons.

Conservez deux colonnes : « comportement observé » et « comportement acceptable ». Si l’ancien système réussit 87 % d’un lot mais que le seuil métier est 95 %, le nouveau modèle ne doit pas simplement dépasser 87 %. Il doit atteindre le contrat ou déclencher une décision explicite sur le seuil.

Cette distinction empêche aussi de bloquer une amélioration parce qu’elle produit une forme différente mais acceptable. Le but n’est pas de reproduire chaque phrase de l’ancien modèle. Il est de préserver les propriétés nécessaires au produit.

Écrire le contrat de compatibilité

Le contrat décrit ce qui doit rester vrai après le changement. Utilisez dix dimensions :

1. Interface

Quels endpoints, SDK, champs, événements de streaming et codes d’erreur sont attendus ? Une compatibilité annoncée au niveau de l’API ne couvre pas toutes les hypothèses du code client.

2. Contexte

Quelle taille de contexte est réellement utilisée ? Comment les messages, fichiers, images, historiques ou éléments de raisonnement sont-ils transmis ? Un contexte maximal plus grand n’aide pas si la construction du contexte devient moins pertinente.

3. Consignes

Quelles règles sont obligatoires, quelles préférences sont stylistiques et quels exemples encodent une exigence produit ? Ne réécrivez pas tout le prompt avant d’avoir observé l’écart.

4. Outils

Quels outils peuvent être appelés, avec quels paramètres et dans quel ordre ? Le modèle choisit, mais le code valide toujours les arguments et l’autorisation.

5. Sorties

Quels champs sont requis ? Comment représenter une absence, un refus, une incertitude ou une valeur invalide ? Le contrat de sorties structurées doit rester validé localement après chaque génération.

6. Qualité

Quels critères définissent une tâche acceptée ? Utilisez des faits, des règles et des rubriques liées au cas, pas une impression générale de style.

7. Sécurité

Quels contenus doivent être refusés, quelles données ne doivent jamais apparaître et quelles actions nécessitent une validation ? Une variation du taux de refus doit être lue par catégorie, pas seulement comme un total.

8. Performance

Quels seuils de latence, débit, erreur fournisseur et saturation sont acceptables ? Le nouveau modèle peut déplacer le temps entre génération, outils et contrôles.

9. Économie

Quel coût par tâche acceptée est soutenable ? Recalculez avec les entrées et sorties réelles, les retries et le travail humain. Un prix unitaire plus faible peut coûter plus si la sortie devient longue ou doit être reprise.

10. Exploitation

Qui surveille, qui arrête, comment reprendre une file et combien de temps l’ancien chemin reste disponible ? Une migration sans propriétaire n’est qu’une modification retardée.

Construire un jeu d’évaluation représentatif

Le jeu de test doit contenir davantage que les exemples réussis de la démonstration. Prenez des cas dans cinq familles :

1. nominaux, fréquents et clairement définis ;
2. limites, avec documents longs, champs absents ou demandes ambiguës ;
3. erreurs historiques, issues d’incidents ou de corrections réelles ;
4. sécurité, avec donnée interdite, permission absente ou instruction hostile ;
5. abstention, où le bon résultat consiste à demander une précision, refuser ou ne pas agir.

Chaque cas possède : entrée autorisée, résultat attendu, critères de notation, gravité d’une erreur, règle sur les outils, données à ne pas exposer et décision en cas d’échec. Gardez une partie des cas hors du travail de réglage pour éviter d’optimiser uniquement le lot connu.

Les évaluations officielles OpenAI illustrent l’usage d’un échantillon représentatif. Cette idée reste indépendante du fournisseur : la représentativité vient de votre contexte métier. Un benchmark public aide à comprendre une capacité générale ; il ne remplace pas une facture atypique, une procédure interne ou une demande d’utilisateur qui a déjà fait échouer votre système.

Commencez avec vingt à cinquante cas si le périmètre est étroit. Ajoutez ensuite les cas qui changent une décision. Un lot de mille exemples mal relus crée une précision apparente sans garantie sur les situations critiques.

Exécuter ancien et nouveau chemins en parallèle

La première comparaison se fait hors effet externe. Dupliquez l’entrée vers les deux chemins et interdisez l’envoi, l’écriture, la réservation ou toute autre conséquence. Les outils peuvent être simulés ou limités à la lecture.

Enregistrez pour chaque cas :

Dimension	Ancien	Nouveau	Verdict
tâche acceptée	oui/non	oui/non	amélioration, équivalence ou régression
schéma	erreurs	erreurs	compatible ou à corriger
faits clés	présents/faux/absents	présents/faux/absents	comparaison ciblée
outils	appels et arguments	appels et arguments	permis, inutile ou interdit
refus	motif et forme	motif et forme	attendu ou régression
latence	médiane et p95	médiane et p95	seuil respecté ou non
coût	par cas accepté	par cas accepté	soutenable ou non

Ne comparez pas les textes par égalité exacte. Utilisez des contrôles déterministes lorsque le résultat possède une structure, une règle ou un calcul. Ajoutez une revue humaine pour les critères qui nécessitent un jugement. Un modèle juge peut aider sur une rubrique bornée, mais il doit être calibré sur des exemples relus et ne devient pas l’autorité finale.

Lire les écarts cas par cas

Classez chaque différence :

• amélioration : le nouveau chemin corrige un défaut sans perdre une propriété requise ;
• équivalence : la forme change, mais le contrat reste satisfait ;
• régression : une propriété nécessaire disparaît ou passe sous le seuil ;
• changement accepté : le produit choisit explicitement un autre compromis ;
• indécidable : les preuves ou critères ne permettent pas encore de conclure.

Cette taxonomie évite deux erreurs. La première consiste à rejeter toute différence. La seconde consiste à accepter une moyenne supérieure alors qu’un cas grave régresse.

Pour chaque régression, cherchez la couche responsable : paramètre invalide, contexte tronqué, schéma d’outil, consigne devenue ambiguë, parseur fragile, contrôle absent ou capacité du modèle. Corrigez la plus petite couche possible, puis rejouez tout le lot. Une succession de correctifs de prompt peut masquer un problème d’interface ou d’autorisation.

Tester les caractéristiques non éditoriales

Une migration peut réussir les réponses et échouer l’exploitation. Testez séparément :

• limites de débit et comportement sous charge ;
• délais, annulations et timeouts ;
• streaming interrompu ;
• comptage des jetons et troncature ;
• variation des arguments d’outil ;
• nouveaux motifs de refus ;
• reprise après erreur temporaire ;
• compatibilité des logs et identifiants de requête ;
• quotas, région et conservation des données ;
• coût aux percentiles élevés.

Les documentations de migration fournisseur signalent parfois des changements de paramètres, de tokenizer, d’outils ou de format. Ces listes sont nécessaires, mais elles ne remplacent pas un test du chemin réel. Un parseur écrit à partir d’une chaîne exacte peut casser alors qu’un parseur JSON standard continue de fonctionner.

Lancer un canary à faible exposition

Après la comparaison hors ligne, routez une faible part du trafic éligible vers le nouveau modèle. Commencez par des tâches réversibles, surveillées et sans population particulièrement exposée. Excluez les cas dont le contrôle n’est pas prêt.

Le plan de canary précise :

• pourcentage ou liste d’utilisateurs concernés ;
• durée minimale et volume attendu ;
• critères de succès ;
• seuils d’arrêt immédiat ;
• métriques comparées à la baseline ;
• personne capable de désactiver la route ;
• traitement des exécutions en cours ;
• heure de revue.

N’augmentez pas l’exposition uniquement parce qu’aucune alerte n’est apparue. Vérifiez que le volume permet d’observer les familles importantes. Un canary de cent cas nominaux ne dit rien sur une erreur mensuelle critique.

Une progression simple peut utiliser 1 %, 5 %, 20 %, 50 % puis 100 %, mais ces chiffres ne sont pas universels. Un traitement par lots peut migrer une file définie plutôt qu’un pourcentage. Une application interne peut sélectionner un groupe pilote. L’important est de limiter l’effet et de conserver une comparaison lisible.

Préparer un retour arrière vérifié

Un rollback ne consiste pas seulement à remettre l’ancien identifiant. Posez cinq questions :

1. l’ancien modèle est-il encore disponible et autorisé ?
2. le code précédent accepte-t-il les données produites pendant le canary ?
3. les opérations en cours peuvent-elles être reprises sans doublon ?
4. les prompts, schémas et paramètres sont-ils versionnés ensemble ?
5. la bascule arrière a-t-elle été testée avant l’exposition ?

Si le fournisseur retire définitivement l’ancien modèle, préparez un mode dégradé : file en attente, traitement manuel, modèle secondaire déjà évalué ou réduction du périmètre. Un alias qui pointe vers une nouvelle version ne constitue pas une sauvegarde.

Pour les workflows avec effet externe, combinez le retour arrière avec une clé d’idempotence, un état d’opération et une réconciliation. Sinon, la reprise peut doubler une action qui avait réussi avant la coupure.

Fermer la migration

La migration est terminée lorsque :

• les seuils du contrat sont respectés ;
• les régressions critiques sont fermées ou explicitement refusées ;
• la fenêtre de canary couvre le volume attendu ;
• l’exploitation sait surveiller et arrêter ;
• les identifiants obsolètes ont disparu de l’inventaire ;
• les tâches planifiées et outils secondaires ont été vérifiés ;
• les baselines, coûts et limites sont mis à jour ;
• le retour arrière ou le mode dégradé est documenté ;
• la date de prochaine réévaluation est fixée.

Retirez ensuite les chemins morts. Garder deux implémentations indéfiniment augmente le risque de divergence. Conservez les résultats d’évaluation, les décisions et les versions nécessaires pour comprendre le changement, sans stocker des données sensibles inutilement.

Une journalisation d’agent IA peut relier la version du modèle, la configuration, les outils et le verdict sans copier chaque prompt. Les objectifs de fiabilité d’un agent permettent ensuite de vérifier que le comportement accepté tient dans le temps.

Limites

Ce protocole ne garantit pas une absence totale de régression. Les sorties restent variables, les fournisseurs peuvent modifier des services et un jeu d’évaluation ne couvre jamais toutes les situations futures. La méthode réduit l’incertitude en rendant le changement observable, borné et réversible.

Les calendriers, modèles, paramètres, prix et fonctions des fournisseurs évoluent. Vérifiez les pages officielles le jour de la migration et la plateforme qui sert effectivement votre trafic. Les dates d’un fournisseur direct peuvent différer de celles d’une plateforme partenaire.

Enfin, un changement de modèle peut entraîner un changement d’endpoint, de SDK, de politique de données ou d’architecture qui dépasse le simple remplacement technique. Dans ce cas, ouvrez un projet de migration distinct avec ses propres risques, responsables et tests. La page automatisation IA et Python présente l’accompagnement possible pour un workflow qui doit être rendu testable et maintenable.

Articles liés

• Évaluer un assistant IA avant déploiement : protocole sur 50 cas
• Sorties structurées IA : fiabiliser un JSON avec un schéma
• SLO d’un agent IA : piloter la fiabilité