Changer de modèle LLM sans casser un workflow agentique

Un workflow agentique peut fonctionner correctement pendant des semaines, puis devenir fragile le jour où le modèle change. La syntaxe des réponses reste proche, mais le comportement se déplace : un agent découpe moins bien une tâche, appelle un outil plus tôt, justifie moins ses choix, reformule un JSON autrement ou propose un diff plus large que prévu. Dans un système LLMOps, la migration de modèle doit donc être traitée comme une modification applicative, pas comme un simple réglage dans une interface.

Le sujet est concret depuis que les éditeurs font évoluer leurs catalogues. GitHub a par exemple annoncé le 18 septembre 2026 la dépréciation de plusieurs modèles Copilot au 19 octobre 2026 dans les expériences Copilot, avec des alternatives suggérées dans son changelog officiel. Ce type d’annonce ne prouve pas qu’un modèle est meilleur ou moins bon pour votre dépôt. Il impose surtout une question d’exploitation : comment basculer sans découvrir les dérives au moment du merge ?

Étape 1 : isoler les workflows réellement dépendants du modèle

La première erreur consiste à lister les modèles utilisés sans lier chaque usage à une décision technique. Un assistant conversationnel interne, une revue de pull request, un agent de correction de tests et un extracteur de sortie structurée ne cassent pas de la même façon. La fiche de migration doit partir du workflow, puis remonter vers le modèle.

• Workflow concerné : revue IA, génération de tests, tri de ticket, correction automatisée ou extraction structurée.
• Point de décision : suggestion libre, modification de fichiers, appel d’outil, blocage CI ou demande d’escalade.
• Sortie attendue : diff, commentaire de revue, objet JSON, statut de validation ou rapport synthétique.
• Critère d’échec : format invalide, oubli d’un risque, action trop large, coût excessif, latence bloquante ou absence de justification exploitable.

Cette étape complète naturellement les approches de sorties structurées IA et de journalisation des interventions IA : la migration ne doit pas seulement dire quel modèle est appelé, mais quelle responsabilité lui est confiée.

Étape 2 : classer les risques avant de lancer un essai

Une migration de modèle n’a pas besoin d’un benchmark global pour commencer. Elle a besoin d’une carte des risques. Le changement le plus dangereux n’est pas toujours une mauvaise réponse visible. C’est souvent une réponse plausible qui passe les contrôles existants tout en modifiant le niveau d’autonomie de l’agent.

Étape 3 : construire un jeu de migration court

Le jeu d’essai ne doit pas chercher à couvrir tout le dépôt. Il doit représenter les décisions que l’équipe ne veut pas voir dériver. Pour un agent de développement, cinq à dix cas bien choisis valent mieux qu’une grande suite décorative. Chaque cas doit contenir un état initial, une consigne, le résultat attendu, les erreurs acceptables et les erreurs bloquantes.

Les cas utiles viennent souvent des incidents passés : une revue IA qui a raté une faille évidente, un prompt qui a produit un JSON valide mais faux, un agent qui a modifié un fichier hors périmètre, ou une correction de test qui a figé l’implémentation au lieu de vérifier le comportement. Cette logique rejoint les tests de régression pour prompts IA, mais avec une différence : ici, le changement testé est le modèle ou sa politique de sélection, pas seulement le texte du prompt.

Étape 4 : exécuter la migration comme une chronologie contrôlée

1. Jour 0 : inventorier les workflows, modèles, prompts, outils appelés et seuils actuels.
2. Jour 1 : sélectionner un jeu court de cas représentatifs, avec au moins un cas négatif par workflow critique.
3. Jour 2 : exécuter l’ancien modèle et conserver les sorties brutes, les traces d’outils et les décisions humaines.
4. Jour 3 : exécuter le modèle cible dans le même environnement, sans changer les prompts ni les permissions.
5. Jour 4 : comparer les sorties sur les critères métier, pas seulement sur la réussite technique.
6. Jour 5 : activer la bascule sur un périmètre réduit, avec journalisation renforcée et retour arrière documenté.
7. Jour 6 à 10 : surveiller les écarts réels, puis décider si la bascule devient le comportement par défaut.

La chronologie évite deux raccourcis fréquents : modifier le prompt en même temps que le modèle, puis attribuer au modèle une amélioration qui vient en réalité du cadrage ; ou basculer tout le workflow sans point de retour. Dans un dispositif LLMOps, une migration réussie doit pouvoir être expliquée après coup.

Étape 5 : séparer compatibilité, qualité et coût

Trois décisions sont souvent mélangées. La compatibilité répond à une question binaire : le workflow continue-t-il à fonctionner sans rupture de contrat ? La qualité demande si le résultat reste utile, relisible et suffisamment prudent. Le coût mesure si l’exécution reste acceptable dans le volume réel de l’équipe. Une bascule peut être compatible mais trop chère, moins chère mais trop instable, ou qualitativement meilleure mais nécessiter une validation humaine plus lourde.

Les annonces éditeur doivent donc être lues comme des contraintes de calendrier et de disponibilité, pas comme des preuves de performance locale. Le billet GitHub sur la migration du runtime Copilot vers Rust, publié le 16 septembre 2026, montre aussi que les agents peuvent intervenir sur des chantiers logiciels importants, mais un retour d’expérience éditeur ne remplace pas une vérification sur votre architecture et vos règles de livraison.

Étape 6 : définir les critères de bascule

Avant d’activer le nouveau modèle par défaut, l’équipe doit écrire une décision courte. Elle peut tenir dans une pull request de configuration ou dans un document d’exploitation. Le format compte moins que sa capacité à être relu pendant un incident.

• Le modèle cible est autorisé uniquement sur les workflows listés.
• Les cas de migration bloquants ont été rejoués dans le même environnement.
• Les sorties brutes et les écarts notables sont conservés.
• Les permissions d’outils ne changent pas pendant la bascule.
• Le retour arrière est possible sans migration de données irréversible.
• Un seuil d’arrêt est défini : taux d’échec, coût, latence, volume de corrections humaines ou nombre de PR rejetées.

Cette décision doit être reliée aux traces existantes. Si l’équipe instrumente déjà ses agents avec une approche d’observabilité agentique, la migration devient un événement explicite dans les traces : ancien modèle, modèle cible, version de prompt, cas rejoué, décision humaine et statut final.

Étape 7 : documenter ce qui n’a pas été prouvé

Une migration honnête garde une colonne pour les limites. Si le test n’a pas été exécuté sur un gros module legacy, il ne faut pas prétendre que le modèle est validé pour ce cas. Si les cas ne couvrent que des tickets simples, l’autonomie maximale doit rester basse. Si les données de production ne sont pas exposées à l’agent, la migration ne dit rien sur son comportement face à un contexte réel plus bruyant.

Le bon résultat n’est pas un classement de modèles. C’est une bascule dont les hypothèses sont visibles : ce qui a été rejoué, ce qui a échoué, ce qui reste sous validation humaine et ce qui déclenchera un retour arrière. Dans une équipe de développement, cette discipline transforme le changement de modèle en opération maîtrisée plutôt qu’en pari silencieux.