Onze modèles en onze jours : aucune de ces sorties ne vous oblige à requalifier
Entre le 1er et le 11 septembre 2026, onze modèles sont sortis chez sept fournisseurs. Anthropic a ouvert le bal avec Claude Fable 5.1 le 1er, Google a publié Gemini 3.8 Flash le 2, Meta Muse Spark 1.3 le même jour, OpenAI GPT-6 Astra le 3, puis deux modèles d'image le 8, DeepSeek V4.1 Flash le 10 et Sakana AI deux variantes de Fugu le 11. Le décompte vient du registre de sorties tenu par LLM Gateway, mis à jour le 11 septembre. Le 6 septembre, CNBC a donné un nom à l'effet produit sur les acheteurs, model fatigue, et rapporté que Sam Altman reconnaissait un passage général à des cadences plus rapides.
La lecture réflexe est qu'il faut une meilleure méthode pour choisir dans ce flux. C'est passer à côté du point. Aucune de ces onze sorties ne crée d'obligation. Rien ne casse en production parce qu'un modèle a été annoncé, et un identifiant épinglé continue de répondre exactement comme la veille. Ce qui crée une obligation, c'est une date de retrait posée sur le modèle que vous exécutez déjà. Le 1er septembre, jour de la sortie de Fable 5.1, GitHub Copilot a retiré six modèles. L'annonce datait du 31 juillet.
Deux calendriers tournent donc en parallèle. Celui des sorties est bruyant, permanent et sans échéance. Celui des retraits est discret, daté et opposable. L'essentiel du budget d'évaluation des équipes part dans le premier. L'article du 1er septembre sur le préavis de retrait devenu le calendrier réel du fournisseur traitait la sortie forcée d'un modèle. Celui-ci traite l'entrée volontaire dans le suivant, c'est-à-dire le droit de ne pas requalifier.

Onze sorties en onze jours, et zéro obligation
Le registre de LLM Gateway compte 385 modèles suivis chez 55 fournisseurs depuis 2022, dont 141 pour la seule année 2026. La concentration de début septembre n'est donc pas une anomalie de volume, c'est une anomalie de synchronisation : quatre laboratoires frontière en trois jours ouvrables, chacun avec son billet, sa page de benchmarks et sa comparaison avec la génération précédente.
Ce que cette concentration produit chez un acheteur est un coût d'attention, pas un coût de production. Aucun contrat n'est rompu, aucune interface ne change, aucune facture ne bouge. Le seul effet mécanique d'une sortie est qu'un fournisseur dispose désormais d'un modèle plus récent à recommander quand il retirera l'ancien, ce qui est une conséquence, pas une cause.
Le piège tient à la manière dont l'information arrive. Une sortie est poussée : billet, courriel, fil social, couverture presse dans les heures qui suivent. Un retrait est tiré : une ligne dans un changelog, une entrée dans un tableau de documentation, parfois un courriel adressé à l'adresse de facturation. La première catégorie sature l'attention d'équipes qui n'ont aucune décision à prendre. La seconde arrive chez des gens qui ont une décision à prendre et une échéance pour la prendre.
La date qui vous oblige n'est dans aucune annonce de sortie
Le 31 juillet 2026, GitHub a publié au changelog la dépréciation de six modèles au 1er septembre sur l'ensemble des surfaces Copilot, chat, éditions en ligne, modes ask et agent, complétions : Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6 et Raptor Mini. Trente-deux jours de préavis. Le billet précise que les administrateurs Copilot Enterprise doivent activer eux-mêmes l'accès au modèle de remplacement dans les politiques de modèle, ce qui veut dire que lire l'annonce ne suffit pas : il faut agir avant la date, sinon les développeurs se retrouvent devant un sélecteur qui ne propose plus rien d'équivalent.
Du côté des fournisseurs de modèles, l'information est encore plus disponible et encore moins lue. La page de dépréciation d'Anthropic publie, pour chaque modèle actif, une date plancher de retrait formulée « pas avant ». Au 13 septembre 2026, l'instantané claude-sonnet-4-5-20250929 porte un plancher au 29 septembre 2026 et claude-haiku-4-5-20251001 un plancher au 15 octobre 2026, soit seize et trente-deux jours. La même page engage un préavis minimum de soixante jours avant tout retrait de modèle publié, et documente l'export CSV de la console qui liste l'usage par clé d'API et par modèle.
Ces trois éléments suffisent à construire l'horizon complet de votre parc sans attendre la moindre annonce : la liste des identifiants réellement appelés, le plancher publié en face de chacun, le préavis contractuel par-dessus. C'est une donnée disponible aujourd'hui, gratuite, et qui ne dépend d'aucune veille.
Les mots du cycle de vie
Requalification : refaire passer à un modèle la batterie d'évaluations qui avait autorisé sa mise en production, parce que le modèle ou son contexte d'usage a changé. Distincte de la qualification initiale, qui portait sur un modèle inconnu.
Dépréciation : le modèle fonctionne encore mais n'est plus recommandé, une date de retrait lui est assignée. Retrait : les appels échouent. Entre les deux, il reste du temps ouvré, et c'est le seul temps dont vous disposez.
Instantané et alias : un instantané est un identifiant daté, reproductible, avec sa propre date de retrait publiée. Un alias pointe vers la version la plus récente de la famille et change donc sous vos pieds sans que votre code bouge.
Durée de vie résiduelle : le temps restant entre aujourd'hui et la date plancher de retrait d'un modèle. S'applique aussi, et surtout, au modèle vers lequel vous envisagez de migrer.

Le remplaçant recommandé le 31 juillet est déprécié le 2 octobre
Le billet du 31 juillet ne se contentait pas d'annoncer six retraits, il recommandait des cibles. Gemini 3.1 Pro devait céder la place à Gemini 3.6 Flash. Claude Opus 4.5 et Opus 4.6 renvoyaient vers Opus 4.7, Opus 4.8 ou Opus 5. Raptor Mini renvoyait vers MAI-Code-1-Flash.
Le 3 septembre, soit deux jours après l'échéance, GitHub a publié une seconde vague de dépréciations au 2 octobre. Elle emporte Gemini 3.6 Flash et Claude Opus 4.7, c'est-à-dire deux des cibles recommandées cinq semaines plus tôt. Le 10 septembre, MAI-Code-1-Flash a reçu à son tour son avis de dépréciation. Sur les quatre cibles nommées dans le billet du 31 juillet, trois ont été dépréciées avant que le mois de septembre ne se termine.
Une équipe qui a suivi la recommandation officielle à la lettre a donc fait le travail deux fois en cinq semaines, et se retrouve au 13 septembre avec une migration à refaire dans les dix-neuf jours. Une équipe qui avait déjà choisi une cible à horizon long, Claude Opus 5 ou Claude Sonnet 5 par exemple, ne l'a fait qu'une fois. La différence entre les deux n'est pas la qualité de l'évaluation technique, c'est un critère que presque aucune politique de modèle n'écrit : la durée de vie résiduelle de la cible.
Sur le terrain, ce critère manque pour une raison structurelle. Dans les organisations qui ont une politique de modèle écrite, elle décrit comment choisir un modèle et ne dit rien des conditions dans lesquelles on a le droit de ne pas en changer. Et la personne qui reçoit l'avis de dépréciation, souvent un administrateur de plateforme ou l'adresse de facturation, n'est pas celle qui a signé la mise en production ni celle qui tiendra le calendrier. L'échéance arrive par un canal qui n'a pas de propriétaire nommé.
Cinq déclencheurs, et un défaut à non
Une politique de requalification utile commence par sa valeur par défaut. Par défaut, on ne requalifie pas. Une sortie de modèle, un score de benchmark public, une couverture presse ou la demande d'un commercial ne sont pas des déclencheurs. Cinq situations, et cinq seulement, ouvrent le droit de dépenser du budget d'évaluation.
Le premier est une dépréciation annoncée, ou une date plancher de retrait à moins d'un seuil que vous fixez une fois pour toutes, sur un modèle réellement appelé en production. C'est le seul déclencheur qui produit une obligation datée, et il se surveille dans un tableau, pas dans un flux d'actualité.
Le deuxième est une rupture d'interface sur le chemin que vous utilisez, pas sur l'API en général : un paramètre qui renvoie désormais une erreur, un format d'appel d'outil modifié, un bloc de raisonnement devenu illisible par les versions antérieures. Anthropic a par exemple rendu temperature, top_p et top_k refusés au-delà de leur valeur par défaut sur Claude Opus 4.7 et les modèles suivants, avec une erreur 400 à la clé. Ce genre de changement se qualifie en lisant la note de migration, pas en relançant une campagne d'évaluation complète.
Le troisième est un gain mesuré au-dessus d'un seuil que vous avez écrit avant de regarder les résultats, et mesuré sur votre propre jeu d'évaluation. Un seuil décidé après coup n'est pas un seuil, c'est une justification. C'est le prolongement direct de la grille de qualification d'un modèle inconnu posée le 28 août, appliquée cette fois à un modèle dont vous connaissez déjà l'auteur.
Le quatrième est une variation de prix au-delà d'un seuil, calculée sur votre mix de jetons réel et non sur le tarif affiché. Fable 5.1 illustre pourquoi la distinction compte : le prix liste est resté à dix dollars en entrée et cinquante en sortie par million de jetons, identique à Fable 5, pendant que la lecture de cache passait à un quart de son prix antérieur. Anthropic estime la baisse à environ 25 % sur une charge classique et jusqu'à 45 % sur une charge fortement agentique, d'après la synthèse publiée par VentureBeat le 2 septembre. Une charge qui ne relit jamais de cache ne verra rien de cette baisse. Une charge agentique en verra l'essentiel. Le tarif affiché, seul, ne permet pas de trancher.
Le cinquième est une exigence de conformité nouvelle, propre à votre secteur ou à votre juridiction, qui rend le modèle en place inadapté indépendamment de ses performances.
À ces cinq déclencheurs, ajoutez deux règles de procédure. La cible de migration doit avoir une durée de vie résiduelle publiée supérieure à la durée de votre cycle de requalification, faute de quoi vous payez deux fois. Et chaque déclenchement doit avoir un budget chiffré à l'avance, en jours-homme et en jetons d'évaluation, pour que le coût de la décision soit visible au moment où on la prend.
Ce que la requalification coûte quand le système est classé à haut risque
Dans un contexte régulé, changer de modèle n'est pas neutre juridiquement. L'article 43, paragraphe 4 du règlement européen sur l'intelligence artificielle prévoit qu'un système à haut risque déjà passé par une procédure d'évaluation de la conformité doit repasser une nouvelle procédure en cas de modification substantielle, que le système modifié soit destiné à être distribué ou qu'il reste utilisé par le déployeur actuel.
Le même paragraphe ouvre une porte que peu d'équipes utilisent. Les changements prédéterminés par le fournisseur au moment de l'évaluation initiale, et intégrés à la documentation technique, ne constituent pas une modification substantielle. Autrement dit, une politique de requalification écrite à l'avance et versée au dossier technique n'est pas seulement de l'hygiène interne : c'est l'artefact qui peut faire passer un changement de version de modèle du statut de modification substantielle à celui de changement prédéterminé. L'écrire après coup ne produit pas cet effet.
Deux précautions. Cette obligation pèse sur le fournisseur du système à haut risque, pas sur tout utilisateur d'un modèle, et la qualification exacte de votre système est une question juridique qui se traite avec un conseil. Par ailleurs, la page de la Commission qui publie cet article porte un avertissement indiquant que la disposition a été amendée par le Digital Omnibus sur l'IA et que le texte affiché n'intègre pas encore ces amendements. Le raisonnement reste valable, la formulation exacte est à vérifier avant de l'inscrire dans un dossier.
À mettre en route cette semaine
Sortez la liste des identifiants de modèle réellement appelés en production, pas la liste des modèles autorisés dans vos politiques. Chez Anthropic, l'export CSV de la page Usage de la console donne l'usage ventilé par clé d'API et par modèle. L'écart entre les deux listes est souvent le premier résultat utile de l'exercice.
Mettez en face de chaque identifiant sa date plancher de retrait publiée, et triez par échéance croissante. Si un instantané que vous appelez encore porte un plancher à moins de quatre-vingt-dix jours, vous avez une migration à planifier, et elle n'a rien à voir avec les onze sorties de la semaine dernière.
Écrivez la politique de déclenchement sur une page, avec la valeur par défaut affirmée en première ligne et les cinq déclencheurs en dessous, chacun avec son seuil chiffré. Datez-la et faites-la approuver par la même instance qui approuve les mises en production, pas par l'équipe qui suit la facture.
Avant d'engager la moindre migration, vérifiez la durée de vie résiduelle publiée de la cible. Une cible qui expire avant la fin de votre cycle de requalification n'est pas une cible, c'est une étape intermédiaire qu'il faut refuser explicitement.
Nommez un propriétaire du canal de dépréciation, avec une adresse de réception qui n'est pas une boîte de facturation, et une revue mensuelle de quinze minutes sur le tableau des échéances. C'est le poste le moins coûteux de toute cette liste, et celui dont l'absence explique la plupart des migrations faites dans l'urgence.
Conclusion
La cadence de sortie des laboratoires n'est pas votre problème, et elle ne le deviendra pas en accélérant vos évaluations. Votre problème est que le calendrier qui vous engage réellement est déjà publié, modèle par modèle, dans des tableaux que personne n'a mandat pour surveiller, pendant que l'attention de vos équipes est captée par un flux qui ne porte aucune échéance. Écrire le droit de ne pas requalifier, avec des déclencheurs chiffrés et une valeur par défaut à non, coûte une page et libère le budget d'évaluation pour les quelques dates qui, elles, ne se négocient pas.
Sources : As of : Septembre 2026
- [Primary] Model deprecations, cycle de vie, préavis de soixante jours et tableau des dates plancher de retrait — Anthropic — consultée le 13 septembre 2026 — https://platform.claude.com/docs/en/about-claude/model-deprecations
- [Primary] Upcoming August 2026 model deprecations in GitHub Copilot — GitHub Changelog — 31 juillet 2026 — https://github.blog/changelog/2026-07-31-upcoming-august-2026-model-deprecations-in-github-copilot/
- [Primary] Upcoming deprecation of selected GitHub Copilot models — GitHub Changelog — 3 septembre 2026 — https://github.blog/changelog/2026-09-03-upcoming-deprecation-of-selected-github-copilot-models/
- [Primary] MAI-Code-1-Flash deprecated — GitHub Changelog — 10 septembre 2026 — https://github.blog/changelog/2026-09-10-mai-code-1-flash-deprecated
- [Primary] GPT-6 Astra is generally available in GitHub Copilot — GitHub Changelog — 4 septembre 2026 — https://github.blog/changelog/2026-09-04-gpt-6-astra-is-generally-available-in-github-copilot
- [Primary] Gemini 3.8 Flash is now available in GitHub Copilot — GitHub Changelog — 3 septembre 2026 — https://github.blog/changelog/2026-09-03-gemini-3-8-flash-is-now-available-in-github-copilot
- [Primary] Article 43 : évaluation de la conformité, paragraphe 4 sur la modification substantielle — AI Act Service Desk, Commission européenne, règlement (UE) 2024/1689 — version officielle du 13 juin 2024 — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-43
- [Secondary] When every LLM was released, registre des dates de sortie — LLM Gateway — mis à jour le 11 septembre 2026 — https://llmgateway.io/timeline
- [Secondary] Model fatigue sets in as AI labs roll out new versions at a frenetic pace — CNBC — 6 septembre 2026 — https://www.cnbc.com/2026/09/06/meta-google-openai-anthropic-ai-model-fatigue.html
- [Secondary] Anthropic's Claude Fable 5.1 and Mythos 5.1 arrive with a 75% cost reduction for Fable cache reads — VentureBeat — 2 septembre 2026 — https://venturebeat.com/technology/anthropics-claude-fable-5-1-and-mythos-5-1-arrive-with-a-75-cost-reduction-for-fable-cache-reads
Comments ()