Dépréciation des modèles LLM : plan de continuité en 10 points pour éviter la panne

Le scénario qui te met à l’arrêt “sans bug” chez toi

Tu as une automatisation qui tourne. Un agent qui lit des PDF et prépare des réponses. Un workflow qui rédige des devis. Un tri automatique de tickets support. Tout marche.

Puis un matin, “simple annonce” chez ton fournisseur : dépréciation d’un modèle. Quelques semaines plus tard, c’est le shutdown. Pas “un peu moins bien”. Pas “une légère baisse de qualité”. Un arrêt.

Concrètement, l’endpoint répond par des erreurs. Tes appels API échouent. Et tes process tombent. Google le décrit noir sur blanc : dépréciation = fin de support annoncée, puis “shutdown” et endpoint indisponible.

Le piège, c’est que cette panne arrive souvent là où tu ne regardes pas : un identifiant de modèle figé dans du code, un scénario Make/Zapier, un connecteur CRM, une app interne, un prompt “système” copié-collé il y a 6 mois. Le jour J, tu découvres que tu n’avais pas de plan B.

Pourquoi la dépréciation casse tes métiers (pas seulement “ton IA”)

Une dépréciation modèle OpenAI ou Azure ou Bedrock n’est pas un sujet “tech”. C’est un sujet opérationnel.

• Agents et RPA : l’agent n’arrive plus à lire un document, à classer, à répondre, à déclencher une action. Résultat : backlog, retards, clients mécontents.
• CRM et support : plus de résumé automatique, plus de suggestion de réponse, plus de qualification. Tes équipes reviennent en manuel en catastrophe.
• Devis, conformité, analyse documentaire : si l’IA est dans la boucle de validation, tu crées une file d’attente, ou pire : tu la bypasses “temporairement” et tu prends un risque.

Le vrai déclencheur de panne, c’est souvent le “pinning” : tu épingles une version pour stabiliser les résultats. Exemple classique : gpt-3.5-turbo-0613, gpt-4-32k-0613, ou des snapshots Azure. Tu as gagné de la stabilité… jusqu’au shutdown.

Ce qui rend le risque sournois : timelines hétérogènes et exceptions

Tu ne peux pas compter sur “12 mois de préavis”. Les règles varient selon :

• le fournisseur (OpenAI, Azure AI Foundry, Amazon Bedrock, Google Gemini, etc.)
• le statut (GA vs preview)
• le mode de déploiement (standard, provisioned, on-demand)
• des exceptions sécurité/compliance (accélération possible)

Quelques faits utiles pour ancrer la réalité :

• OpenAI publie une page officielle de dépréciations avec dates de shutdown et remplacements. Exemple : gpt-4-vision-preview shutdown au 6 décembre 2024, remplacement recommandé gpt-4o.
• OpenAI : gpt-3.5-turbo-0613 et gpt-3.5-turbo-16k-0613 shutdown au 13 septembre 2024.
• OpenAI : gpt-4-32k et variantes shutdown 6 juin 2025, remplacement recommandé gpt-4o. Et au passage, les tarifs affichés avant retrait (60 $ / 1M tokens input, 120 $ / 1M tokens output) te rappellent un point : migration = coût, même quand elle est “obligatoire”.
• Azure : même si tu dis “j’utilise gpt-4o”, si tu as épinglé un snapshot (ex 2024-08-06-ev3), il peut avoir une date de retraite (ex : 31 mars 2026).
• Azure : certains déploiements peuvent être auto-upgradés à date. Tu évites l’arrêt, mais tu risques une régression fonctionnelle si tu n’as pas de tests.
• Bedrock : cycle Active / Legacy / EOL. En Legacy, modèle “scheduled for retirement”, nouveaux clients bloqués. Et détail opérationnel violent : des clients existants peuvent perdre l’accès après 15 jours d’inactivité. À EOL, requêtes KO.

Moralité : ton risque dépendance API IA ne se gère pas avec de l’espoir. Il se gère avec une discipline de continuité.

Plan de continuité IA : la méthode en 10 points (applicable dès aujourd’hui)

Objectif : si un modèle est retiré, tu veux basculer sans panique, sans arrêt, et sans exploser les coûts. C’est une migration modèle LLM maîtrisée, pas un firefighting.

1) Mets un propriétaire business sur chaque usage IA

Pas “c’est l’IT”. Pas “c’est le stagiaire”. Pour chaque workflow IA, tu veux un owner côté métier : support, sales, ops, juridique, finance.

• Il valide ce que “bon résultat” veut dire.
• Il décide si on dégrade temporairement (mode fallback) ou si on coupe.
• Il porte l’impact client quand ça casse.

2) Fais l’inventaire des dépendances (API, apps, prompts, identifiants figés)

C’est le point le plus rentable. Tu listes tout ce qui appelle un LLM :

• code interne (API calls)
• outils no-code (Make, Zapier, n8n, Power Automate)
• CRM/helpdesk (connecteurs, plugins)
• agents et orchestrateurs
• prompts “système” et templates (là où tu as souvent copié un nom de modèle)

Et tu captures, pour chaque item :

• fournisseur (OpenAI, Azure, Bedrock, Gemini…)
• identifiant exact du modèle (y compris version/snapshot)
• fonction dans le process (résumer, extraire, classer, rédiger, décider)
• criticité (bloquant, dégradé acceptable, confort)
• données manipulées (sensibles ou non)

Tu viens de créer ton tableau de bord de risque.

3) Classe tes usages en 3 niveaux de continuité

• Niveau A : arrêt = arrêt d’exploitation (facturation, support, production, conformité).
• Niveau B : arrêt = grosse perte de productivité mais contournable (assistants internes, rédaction).
• Niveau C : nice-to-have (veille, expérimentation).

Tu ne mets pas le même effort de continuité partout. Sinon tu ne fais rien.

4) Standardise une couche d’abstraction “modèle” (même en no-code)

Règle simple : jamais le nom du modèle en dur partout.

• Dans le code : une config centrale (par environnement) qui mappe “MODELE_PRINCIPAL” et “MODELE_SECOURS”.
• En no-code : un variable store, un champ de config, ou au minimum un scénario unique “LLM Gateway” que les autres appellent.

Le jour où tu changes, tu changes un endroit.

5) Prévois 2 modèles de secours, pas 1

Une stratégie simple :

• Modèle principal : le meilleur coût/qualité pour le cas.
• Fallback 1 : même fournisseur, modèle plus récent ou plus stable.
• Fallback 2 : autre fournisseur (option “multi-vendeur”) pour les usages Niveau A.

Oui, ça demande un peu d’effort. Mais c’est le seul moyen d’éviter d’être coincé quand un fournisseur change ses règles, ses quotas, ou son catalogue.

6) Mets en place des tests de non-régression orientés métier

Sans tests, tu ne “migres” pas. Tu “pries”.

Tu construis un petit jeu de tests par workflow :

• 20 à 50 cas réels (tickets, emails, docs, demandes) anonymisés si nécessaire
• des critères de réussite clairs : format, champs obligatoires, ton, absence d’invention, citations, délais
• un score simple : OK / KO / à revoir

Tu n’as pas besoin d’un framework énorme. Tu as besoin d’un rituel. Si tu bosses des données sensibles, fais les choses proprement côté partage et RGPD (référence utile : https://jimmymanin.com/blog/anonymisation-et-ia-en-entreprise-plan-terrain-en-6-etapes-pour-partager-utile-sans-risque-rgpd).

7) Sépare “prompt” et “politique d’exécution”

Quand tu migres, les comportements changent : longueur, refus, style, sensibilité aux consignes. Si ton prompt est mélangé avec :

• les paramètres (température, top_p)
• les contraintes de sortie (JSON strict, schema)
• les règles de sécurité

… tu vas passer ta vie à débugger.

Fais deux blocs :

• Prompt métier : ce qu’on veut produire.
• Policy : format, garde-fous, validation, niveau d’autonomie, escalade humain.

8) Ajoute du monitoring d’erreurs et des alertes “dépréciation”

Tu veux voir venir le problème avant les users.

• Surveille les erreurs API (4xx/5xx), timeouts, hausse de latence.
• Loggue : modèle, version, endpoint, taille des prompts, taux d’échec, coût.
• Crée une alerte spécifique : erreur “model not found”, “deprecated”, “shutdown”.

Si tu ne regardes pas, tu découvriras la panne via un client. Mauvais plan.

9) Prépare un runbook “jour J” (bascule en 15 minutes)

Ton plan doit tenir sur une page :

• où changer le modèle (config centrale)
• quel fallback activer (1 ou 2)
• quels workflows couper si ça part en vrille (liste Niveau A/B/C)
• qui décide (owner métier + IT)
• comment informer l’équipe (message prêt)

Fais un exercice une fois : tu simules “modèle retiré”. Si tu ne peux pas basculer vite, tu n’as pas de plan.

10) Mets une clause contractuelle minimale (et réaliste) côté fournisseur

Tu n’auras pas “zéro retrait”. Personne ne va te promettre ça. Mais tu peux cadrer le minimum, surtout si tu passes par un contrat enterprise, ou via un intégrateur :

• Préavis de dépréciation avec date de shutdown.
• Remplaçant recommandé quand il existe.
• Accès aux changelogs et à une page de lifecycle officielle.
• Engagement de notification (email, dashboard) pas “va checker le blog”.
• Réversibilité : export logs, prompts, configs, et possibilité de migrer sans blocage.

Et point dirigeant : négocie aussi la capacité à tester (environnement, quota) avant migration. Sinon tu payes la migration en prod. Ce n’est pas sérieux.

Les coûts cachés que tu vas payer si tu ignores le sujet

• Coût d’urgence : dev en panique, interruptions, consultants “en astreinte”.
• Coût de non-qualité : réponses support moins bonnes, devis incohérents, erreurs de classification.
• Coût de gouvernance : sans inventaire, tu oublies des intégrations et tu recasses ailleurs.
• Coût conformité : si la panne force des contournements (copier-coller de données sensibles dans un outil non cadré), tu crées un risque RGPD et un risque contractuel.

Tu peux aussi te faire piéger par un auto-upgrade (ex Azure) : pas de panne franche, mais un changement de comportement qui introduit des erreurs silencieuses. D’où l’intérêt des tests de non-régression.

Gouvernance des changements : le rythme à tenir (simple, mais non négociable)

Si tu veux que ça tienne dans le temps :

• Revue mensuelle : pages lifecycle des fournisseurs + inventaire dépendances.
• Revue trimestrielle : exécution des tests de non-régression sur les workflows Niveau A.
• À chaque nouveau cas d’usage : obligation d’enregistrer modèle, version, owner, fallback, et tests minimum.

Ce n’est pas “du process pour le plaisir”. C’est ton assurance anti-panne.

Ce que tu fais cette semaine (checklist exécutable)

• 1. Tu identifies 5 usages IA réels en prod (même petits).
• 2. Tu notes pour chacun : outil, modèle exact, criticité, owner.
• 3. Tu centralises le nom du modèle dans une config unique (ou un scénario gateway en no-code).
• 4. Tu définis un fallback 1 pour chaque usage, et un fallback 2 pour les usages bloquants.
• 5. Tu écris 20 cas de test sur l’usage le plus critique, avec un “OK/KO” clair.
• 6. Tu actives un monitoring basique des erreurs et une alerte “model not found/deprecated”.

Si tu fais juste ça, tu passes d’une dépendance fragile à un plan de continuité IA crédible. Le jour où un fournisseur retire un modèle, tu ne subis pas. Tu bascules.

Et si tu veux pousser plus loin sur la logique “panne fournisseur”, tu peux aussi cadrer le plan global de secours quand un outil IA tombe, pas seulement quand un modèle est retiré : https://jimmymanin.com/blog/chatgpt-en-panne-le-plan-de-secours-ia-entreprise-a-monter-avant-la-prochaine-coupure