Le 19 octobre, GitHub a retiré six modèles de Copilot du jour au lendemain : GPT-5.5, GPT-5.4, GPT-5.4 mini, Gemini 3.7 Flash, Grok 4.5. La bascule vers les remplaçants est automatique. Quatre jours avant la coupure, le 15 octobre, GitHub annonçait déjà la vague suivante : Claude Opus 5 et GPT-5.6 Terra sortent le 16 novembre.
Ce n'est pas un incident. C'est un rythme. Et ton équipe vit dessus sans filet.
Un modèle, c'est une dépendance. Personne ne la gère.
Ton agent de code dépend d'un modèle tiers. L'enquête Stack Overflow 2026 (plus de 30 000 répondants) mesure à quel point : 73% des utilisateurs d'outils IA s'en servent tous les jours, et 66% des devs travaillent désormais dans des agents de code (Claude Code 66%, Copilot 59%).
En face, l'hygiène classique d'une dépendance : un semver, un lockfile, un changelog, une date de fin de vie annoncée. Pour un modèle de code, il n'y a rien de tout ça.
Une version npm est immuable : le package que tu as installé en mars est celui que tu relances aujourd'hui. Un modèle de code est renommé, remplacé, retiré. GPT-5.5 remplacé par GPT-5.6 Sol, ce n'est pas une version suivante. C'est un autre produit, avec un autre comportement, sous un nom voisin.
GitHub donne un mois de préavis, dans un changelog. La doc des modèles supportés porte même l'avertissement noir sur blanc : "Model availability is subject to change". Ton agent, lui, ne lit pas les changelogs.
Ce qui casse, et ce qui dérive en silence
Ce qui casse bruyamment : la config ou la CI épinglée sur un nom de modèle. Une erreur, un build rouge, on corrige en dix minutes.
Ce qui casse en silence : la bascule automatique. Sous Copilot Business et Enterprise, les modèles de remplacement sont activés d'office. Ton équipe se met à écrire du code avec un modèle qu'elle n'a pas choisi. La longueur des réponses change, le style change, la précision sur tes patterns internes change. Personne ne l'a demandé, personne ne l'a remarqué.
Les équipes jonglent déjà. La même enquête Stack Overflow : 27% des organisations utilisent différents modèles pour différents travaux, 38% posent des limites d'usage, 25% limitent qui peut utiliser l'IA. Le multi-modèles est une pratique installée. Sa gouvernance ne l'est pas.
Le risque le plus cher n'est pas la 404. C'est la dérive : tout continue de fonctionner, et les outputs glissent semaine après semaine, jusqu'au jour où un dev dit "l'agent ne code plus comme avant".
Les 4 règles : l'hygiène npm appliquée aux modèles
Les 4 règles : alias, lockfile, smoke test, fallback.
Règle 1 : l'alias, jamais le nom en dur. Un seul endroit du repo définit quel modèle l'équipe utilise (une variable d'env, une ligne de config centrale). Tout le reste référence l'alias. Quand le modèle change, on édite une ligne, pas quinze fichiers.
Règle 2 : le lockfile du modèle. Une ligne consigne le modèle actif et la date d'adoption, dans un models.lock ou une section de ton fichier de conventions d'agents. Le changement de modèle devient une décision relue en PR, pas une bascule subie côté éditeur.
Règle 3 : le smoke test en CI. Un prompt fixe, des assertions sur la sortie. Il tourne avant chaque changement de modèle, et il détecte la dérive de comportement que les yeux ne voient pas au premier coup.
Objection légitime : un LLM ne répond jamais deux fois pareil. Le test ne compare donc pas une réponse littérale, il vérifie des invariants. La température est bloquée à 0, les assertions portent sur le contrat (JSON valide, instruction suivie, bornes de longueur), et un échec isolé ne bloque pas : c'est la récurrence qui alarme. La réponse exacte rejouée, ça n'existe pas. Le contrat tenu ou cassé, si.
// smoke-model.mjs : on teste le contrat, pas la réponse littérale
const MODEL = process.env.LLM_MODEL; // l'alias, un seul endroit
const out = await call(MODEL, {
messages: [{ role: "user", content: 'Réponds uniquement en JSON : {"ok":true,"n":42}' }],
temperature: 0,
});
const parsed = JSON.parse(out); // invariant 1 : le format tient
assert(parsed.ok === true, "instruction non suivie");
assert(parsed.n === 42, "valeur demandée non rendue");
assert(out.length < 200, "bavardage = le modèle a changé de caractère");Règle 4 : le fallback explicite. Un deuxième modèle désigné, testé par le même smoke test, consigné à côté du premier. Tu choisis ton plan B. La bascule par défaut de l'éditeur, elle, ne le demande à personne.
Cas vécu. Dans mon propre stack d'agents, le modèle est une variable, jamais un nom écrit en dur. Quand un forfait de crédits a brûlé en septembre, la bascule de fournisseur a tenu en une commande. Un seul endroit à changer, grep le confirme.
Le contre-point : ne pas sur-ingénierer
Pas de registry privé de modèles, pas de dashboard de drift, pas de comité. L'alias et le lockfile se posent en 20 minutes et couvrent l'essentiel du risque. Le smoke test ne sert que si des scripts d'agents tournent en CI ou en job planifié. Le reste est du confort.
Et l'éditeur fournit déjà des repères : la doc Copilot désigne un modèle de long terme (GPT-5.3-Codex) et documente la sélection auto. Les repères existent. Les choisir pour ton équipe, ça reste ton travail.
Ce que ça change pour le lead
Vingt minutes : l'alias, la ligne de lockfile, le smoke test branché. Et l'argument à porter en équipe tient en une phrase : on applique à un modèle ce qu'on applique à une dépendance npm depuis quinze ans.
La prochaine vague GitHub, c'est le 16 novembre. Treize jours après cet email. Le temps de vérifier ce que ton équipe a épinglé, tu l'as.
Liens sélectionnés
Upcoming deprecation of selected GitHub Copilot models in mid-October (GitHub Changelog, 18/09/2026). La vague 1 : six modèles retirés le 19/10, bascule automatique en Business/Enterprise.
Upcoming deprecation of selected GitHub Copilot models in mid-November (GitHub Changelog, 15/10/2026). La vague 2, annoncée 27 jours après la première : Claude Opus 5 et GPT-5.6 Terra sortent le 16/11. La cadence, pas l'incident.
Supported AI models in GitHub Copilot (GitHub Docs, 2026). 35 modèles listés, "Model availability is subject to change", un modèle de long terme désigné (GPT-5.3-Codex). Les repères que l'éditeur donne déjà.
The results of the 2026 Developer Survey are here (Stack Overflow, 06/10/2026). 66% des devs dans les agents de code, 73% d'usage quotidien, 27% des orgs en multi-modèles. La dépendance, mesurée.
Outil de la semaine
Le models.lock décrit plus haut, en version minimale : un fichier texte de cinq lignes (modèle actif, date, fallback, où est défini l'alias), versionné avec le repo, relu comme n'importe quelle PR. Pas un outil nouveau, pas un budget : une règle de npm appliquée aux modèles. Et le smoke test de 15 lignes en cron hebdo si tes agents tournent sans humain dans la boucle.
Ton repo, aujourd'hui : combien de noms de modèles écrits en dur ?
Compte-les et dis-moi le chiffre. Je parie que la plupart des repos en ont au moins un. Et si tu as déjà vécu une bascule de modèle subie, raconte-la : c'est exactement le cas d'école que je cherche pour la suite.
La semaine prochaine : la file de review, le nouveau goulot des équipes qui produisent avec l'IA.
