Un modèle d’intelligence artificielle peut être excellent aujourd’hui et indisponible quelques mois plus tard.
Ce risque paraît abstrait tant que l’IA sert à reformuler un email ou à résumer un document. Il devient opérationnel lorsqu’un modèle qualifie des prospects, extrait des informations depuis des contrats, prépare des mises à jour CRM ou déclenche une chaîne de travail entre plusieurs outils.
Dans ce cas, remplacer le nom du modèle dans un fichier de configuration ne suffit pas. Le remplaçant peut répondre dans un autre format, interpréter différemment les consignes, utiliser davantage de tokens, refuser certains cas ou appeler les outils avec une logique différente.
Le 3 septembre 2026, GitHub a annoncé le retrait de plusieurs modèles de ses expériences Copilot au 2 octobre, avec des alternatives recommandées. L’annonce concerne notamment Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code et Claude Opus 4.7.[2] Ce type de calendrier rappelle une contrainte simple : un workflow IA construit sur un modèle tiers n’est jamais figé.
La continuité d’un employé IA dépend donc moins du nom du modèle que de la qualité du système qui l’entoure.
Un modèle n’est pas le workflow
Une équipe finit facilement par confondre les deux.
Elle teste un modèle sur quelques exemples. Les résultats sont bons. Elle ajuste ses prompts, ajoute des connecteurs et construit des automatisations. Quelques semaines plus tard, le nom du modèle apparaît partout : dans le code, les scénarios d’automatisation, les tableaux de bord, les procédures et parfois même les supports commerciaux.
Le système fonctionne, mais il est devenu dépendant d’un composant qu’il ne contrôle pas.
Cette dépendance ne pose pas uniquement un problème de disponibilité. Elle touche aussi le comportement. Deux modèles capables de produire un résumé correct ne classent pas forcément les priorités de la même manière. Ils ne détectent pas les mêmes ambiguïtés. Ils peuvent choisir des outils différents ou structurer leurs réponses selon des schémas incompatibles.
Anthropic distingue quatre états dans le cycle de vie de ses modèles : actif, ancien, déprécié et retiré. Lorsqu’un modèle est retiré, les requêtes échouent. L’éditeur annonce au moins 60 jours de préavis pour les modèles publics concernés, mais précise que les plateformes partenaires peuvent appliquer leur propre calendrier.[1]
Soixante jours peuvent sembler confortables. Ils passent vite lorsqu’il faut retrouver tous les usages, comparer les résultats, corriger les écarts et faire valider les nouveaux comportements par les équipes métier.
Le premier risque est silencieux
Une panne franche se voit immédiatement. Une requête renvoie une erreur, une alerte se déclenche et le workflow s’arrête.
Une migration réussie techniquement peut être plus dangereuse.
Le nouveau modèle répond bien en HTTP 200. Le JSON reste valide. Les tâches continuent de circuler. Pourtant, le système commence à extraire une date de clôture à la place d’une date de relance, à résumer trop fortement une objection ou à classer comme certain un besoin seulement évoqué.
Aucun composant n’est en panne. Le sens du résultat a changé.
Pour une tâche de rédaction, l’écart peut rester acceptable. Pour une mise à jour CRM, une analyse de contrat ou une décision financière, il doit être détecté avant la mise en production.
C’est pourquoi le test d’un modèle de remplacement ne doit pas se limiter à la qualité apparente de quelques réponses. Il faut vérifier le résultat métier attendu.
Un bon test pose des questions concrètes :
- le même champ CRM est-il rempli avec la même preuve ?
- les informations absentes restent-elles signalées comme absentes ?
- le modèle sait-il demander une validation lorsque le contexte est ambigu ?
- les appels d’outils respectent-ils toujours l’ordre et les permissions prévus ?
- le coût et le temps de traitement restent-ils compatibles avec l’usage ?
Anthropic recommande de tester les applications avec le modèle de remplacement bien avant la date de retrait, puis d’auditer les usages pour retrouver les appels encore liés aux modèles dépréciés.[1]
Cartographier la dépendance avant l’urgence
Une entreprise ne peut pas migrer ce qu’elle ne voit pas.
La première étape consiste à établir un registre des modèles utilisés. Ce registre n’a pas besoin d’être complexe. Il doit répondre à sept questions :
- Quel workflow utilise ce modèle ?
- Quelle tâche lui est confiée ?
- Quelles données reçoit-il ?
- Quels outils peut-il appeler ?
- Quel format doit-il produire ?
- Quel humain valide le résultat ?
- Que se passe-t-il si le modèle devient indisponible ?
Le registre doit aussi identifier la plateforme réelle. Un même modèle peut être proposé directement par son éditeur, puis via Amazon Bedrock, Google Cloud ou une autre couche intermédiaire. Les dates de retrait peuvent différer selon l’hébergeur.[1]
Cette cartographie évite une mauvaise surprise fréquente : découvrir au dernier moment qu’un ancien identifiant de modèle se cache dans un script oublié, un scénario de test ou une automatisation utilisée une fois par mois.
Construire une couche de remplacement
Le modèle ne devrait pas être appelé directement depuis chaque étape du processus.
Une couche d’orchestration peut centraliser :
- l’identifiant du modèle actif ;
- les paramètres autorisés ;
- le format de sortie attendu ;
- les règles de nouvelle tentative ;
- le modèle de secours ;
- les journaux de coût, de latence et d’erreur.
Cette architecture ne rend pas tous les modèles interchangeables. Elle réduit le nombre d’endroits à modifier et rend les différences visibles.
Le contrat de sortie est particulièrement important. Au lieu de demander une réponse libre, le workflow attend une structure précise : faits observés, niveau de confiance, sources, champs proposés et éléments à valider. Si le nouveau modèle ne respecte pas ce contrat, le système bloque la suite au lieu de transmettre une donnée ambiguë.
Le même principe vaut pour les permissions. Le modèle de remplacement ne doit pas hériter automatiquement de tous les droits du précédent. On commence en lecture seule, puis on réactive progressivement les actions après vérification.
Préparer un jeu de tests métier
Les benchmarks publics comparent les modèles sur des tâches générales. Ils ne savent pas ce qu’est une opportunité qualifiée dans votre entreprise, comment vous nommez vos étapes commerciales ou quelles pièces rendent un dossier complet.
Le jeu de tests doit donc venir du travail réel.
Pour un workflow commercial, on peut conserver cinquante situations anonymisées : appels clairs, objections contradictoires, dates imprécises, interlocuteurs multiples, absence de budget, doublons et changement de décideur. Chaque cas possède un résultat attendu validé par un humain.
Lors d’une migration, l’ancien et le nouveau modèle traitent les mêmes cas. La comparaison porte sur :
- l’exactitude des faits extraits ;
- le respect du schéma attendu ;
- la détection des informations manquantes ;
- le nombre de corrections humaines ;
- les appels d’outils proposés ;
- le coût par résultat validé ;
- la stabilité sur plusieurs exécutions.
Ce protocole complète notre méthode pour tester un employé IA avant de le mettre en production. Il permet aussi d’appliquer une règle déjà abordée dans l’Insight sur l’adaptation des modèles au coût et à la complexité des missions : le modèle le plus récent n’est pas automatiquement le meilleur choix pour chaque tâche.
Organiser une migration progressive
Changer tous les workflows le même jour transforme une mise à niveau en pari.
Une migration plus sûre suit quatre étapes.
D’abord, le nouveau modèle fonctionne en mode miroir. Il reçoit une copie des entrées mais ses résultats ne déclenchent aucune action. L’équipe compare ses sorties à celles du système actif.
Ensuite, il traite une petite part des cas à faible risque. Les résultats restent soumis à validation humaine renforcée.
Puis, son périmètre augmente lorsque les mesures restent acceptables : taux de correction, erreurs de format, latence, coût et incidents métier.
Enfin, l’ancien modèle reste disponible pendant une période définie, lorsque le fournisseur le permet. Le retour arrière doit être documenté et testé avant le basculement, pas improvisé après un incident.
Cette progression évite de confondre disponibilité technique et fiabilité opérationnelle.
Le modèle de secours doit être testé lui aussi
Afficher « fallback activé » dans une configuration ne constitue pas un plan de continuité.
Le modèle de secours peut avoir un contexte plus court, ignorer un paramètre, refuser un type de fichier ou produire un format différent. Certains paramètres autrefois acceptés peuvent même provoquer une erreur avec des modèles plus récents. La documentation Anthropic indique par exemple que temperature, top_p et top_k sont dépréciés pour certains modèles et peuvent entraîner une erreur 400 lorsqu’ils reçoivent une valeur non standard.[1]
Un fallback utile doit donc être exécuté régulièrement sur le même jeu de tests que le modèle principal. Il faut connaître à l’avance les fonctions qu’il sait reprendre et celles qui doivent être suspendues.
Pour une mission sensible, le meilleur secours n’est pas toujours un autre modèle. Le workflow peut basculer vers une file d’attente, conserver les données sans les modifier et demander une reprise humaine. La continuité ne signifie pas que l’automatisation doit continuer à tout prix.
Ce que l’annonce ne permet pas de conclure
Le retrait annoncé par GitHub ne signifie pas que les modèles concernés sont mauvais ou dangereux. Il ne prouve pas non plus que les remplaçants recommandés produiront de meilleurs résultats dans chaque organisation.[2]
De même, le calendrier Anthropic décrit les engagements et pratiques de cet éditeur. Il ne représente pas une règle universelle applicable à tous les fournisseurs.[1]
Ces sources prouvent cependant que les modèles, leurs identifiants, leurs paramètres et leurs dates de disponibilité changent. Une organisation qui délègue un travail réel à l’IA doit intégrer cette évolution dans sa gouvernance.
À retenir
Un workflow ne devrait jamais dépendre d’un modèle sans disposer d’un inventaire, d’un contrat de sortie, d’un jeu de tests métier et d’une procédure de remplacement.
La bonne question n’est pas « quel modèle allons-nous utiliser pour toujours ? ». Aucun fournisseur ne peut garantir cette stabilité. Il faut plutôt déterminer ce que la mission doit produire, quels écarts sont acceptables et comment le système réagit lorsque son moteur change.
Pour une PME, le plan minimal tient en cinq actions : recenser les modèles utilisés, conserver des cas de test anonymisés, centraliser la configuration, tester un secours en lecture seule et documenter le retour au traitement humain.
Le modèle peut changer. Le niveau de contrôle, lui, ne doit pas changer avec lui.
Sources
[1] https://platform.claude.com/docs/en/about-claude/model-deprecations — Anthropic — Model deprecations [2] https://github.blog/changelog/2026-09-03-upcoming-deprecation-of-selected-github-copilot-models/ — GitHub — Upcoming deprecation of selected GitHub Copilot models