--- service: "Publicasta" schema_version: "1.0" article_id: 524 title: "GitHub Copilot retire quatre modèles : préparer la migration avant le 2 octobre" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=fr" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice" channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-06T10:50:19+00:00" updated_at: "2026-09-06T10:50:19+00:00" translations: - language: "ar" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ar" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ar" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ar" - language: "de" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=de" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=de" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=de" - language: "en" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=en" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=en" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=en" - language: "es" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=es" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=es" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=es" - language: "fr" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=fr" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=fr" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=pl" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ru" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ru" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=zh" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=zh" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=zh" --- # GitHub Copilot retire quatre modèles : préparer la migration avant le 2 octobre > Inventaire des dépendances, règles d’accès, essais sur des tâches réelles, coûts et déploiement pilote : une méthode concrète pour changer de modèle Copilot sans confondre recommandation et équivalence. ![Une équipe d’ingénierie organise la migration de quatre anciens modèles d’IA vers trois nouveaux à travers des étapes d’inventaire, d’essai, de déploiement pilote et de repli.](https://publicasta.com/storage/projects/8/pages/524/2026/09/36618231-a8a7-4cc0-b021-44ed5452d883.webp) Le 2 octobre 2026, GitHub prévoit de retirer de Copilot Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code et Claude Opus 4.7. L’échéance concerne l’ensemble des usages expressément cités par GitHub : le chat, les modifications dans l’éditeur, le mode question, le mode agent et la complétion de code. Il reste donc moins d’un mois aux équipes pour repérer leurs dépendances, autoriser les modèles de remplacement et vérifier que leurs méthodes de travail résistent au changement. Ce calendrier ne justifie ni une migration précipitée ni une simple modification de nom dans un fichier de configuration. GitHub propose Gemini 3.8 Flash à la place des deux versions Flash retirées, Kimi K3 à la place de Kimi K2.7 Code et Claude Opus 5 à la place de Claude Opus 4.7. Il s’agit de pistes de transition, pas d’une promesse d’équivalence. Le comportement, le délai de réponse, la qualité des résultats et le coût réel peuvent différer selon la tâche, le client et l’abonnement. ## Commencer par l’inventaire des dépendances Le premier risque est de ne regarder que le sélecteur de modèle visible dans l’interface. Une équipe peut avoir choisi un modèle explicitement dans certaines conversations, tout en l’utilisant ailleurs par l’intermédiaire d’un réglage par défaut, d’une intégration ou d’un processus automatisé. L’inventaire doit donc couvrir les choix explicites, les valeurs par défaut et les dépendances implicites. Pour chaque usage, il est utile de consigner le modèle actuel, la fonction Copilot concernée, le client et sa version, le propriétaire du réglage, ainsi que la solution de repli prévue. Cette cartographie doit inclure les parcours ordinaires : produire une complétion, modifier un bloc de code, interroger le dépôt, confier une tâche au mode agent ou lancer une conversation depuis un outil intégré. Elle ne doit pas extrapoler à des interfaces que GitHub n’a pas citées dans son avis. Dans les organisations Copilot Business et Enterprise, la vérification comporte deux niveaux. Il faut examiner les règles d’accès aux modèles dans l’administration, puis contrôler ce que voit réellement un utilisateur représentatif dans son sélecteur. Le choix peut être imposé par le propriétaire de l’entreprise, délégué à l’organisation ou hérité de la disponibilité par défaut. Une configuration apparemment correcte au niveau central ne prouve donc pas, à elle seule, que le modèle cible est utilisable sur le poste de travail. Kimi K3 mérite une attention particulière. GitHub le classe parmi les modèles à poids ouverts, désactivés par défaut pour Business et Enterprise indépendamment du réglage général de disponibilité. Il peut être autorisé explicitement lorsqu’aucune autre restriction ne s’y oppose. Une équipe qui se contente de remplacer Kimi K2.7 Code par Kimi K3 risque ainsi de découvrir trop tard que ses utilisateurs n’y ont pas accès. ## Vérifier la disponibilité avant de comparer la qualité La mention « disponibilité générale » ne signifie pas qu’un modèle fonctionne dans toutes les interfaces. Son accès dépend encore de l’abonnement, du client utilisé et des règles de l’organisation. Certaines nouveautés exigent aussi une version récente de l’environnement de développement ou de son extension. La documentation consultée le 6 septembre indique VS Code 1.131 pour Kimi K3 et VS Code 1.128.0 pour Claude Opus 5. Pour Gemini 3.8 Flash, plusieurs versions minimales restent à déterminer dans un tableau que GitHub qualifie lui-même de provisoire. Avant tout essai comparatif, il faut donc valider une chaîne simple de prérequis : le modèle est autorisé, il apparaît pour l’utilisateur choisi, le client satisfait aux exigences publiées et la fonction à tester le prend effectivement en charge. Cette étape évite de confondre une restriction administrative ou un logiciel trop ancien avec une défaillance du modèle. Depuis le 2 septembre, les réglages administrés par l’entreprise permettent aussi de définir n’importe quel modèle disponible comme choix par défaut pour les nouvelles conversations, avec un réglage distinct selon l’équipe. GitHub annonce cette fonction pour Business et Enterprise dans l’application Copilot, l’interface en ligne de commande et VS Code. Ce réglage par défaut ne doit pas être confondu avec un choix explicite ni avec le mode Auto, et rien ne permet d’en déduire sa présence dans d’autres interfaces. ## Rejouer des tâches réelles plutôt que comparer des réputations Une migration sérieuse se mesure sur le travail de l’équipe. Il convient de constituer un petit échantillon de tâches déjà résolues et suffisamment variées : expliquer un module, corriger un défaut, écrire un test, transformer plusieurs fichiers ou proposer une modification ponctuelle. Les mêmes consignes et le même contexte doivent être soumis à l’ancien modèle et au candidat retenu tant que l’ancien reste disponible. La comparaison doit porter sur des résultats observables : exactitude technique, pertinence des changements, délai de réponse, effort de relecture et coût par tâche acceptée. GitHub rappelle que les modèles diffèrent notamment par leur latence, leur propension aux hallucinations et leur adéquation aux différentes tâches. Cette indication aide à construire un protocole, mais elle ne remplace ni une évaluation indépendante ni un essai sur le dépôt concerné. Il faut également conserver les échecs. Un modèle qui répond vite mais oblige à reprendre une modification risquée peut coûter davantage en temps d’ingénierie. À l’inverse, une réponse plus lente peut être acceptable si elle réduit nettement la relecture. Sans essais propres à l’équipe, aucune conclusion chiffrée n’est défendable et les modèles suggérés par GitHub ne doivent pas être présentés comme des remplaçants identiques. Le mode Auto peut faire partie de l’évaluation. Il sélectionne un modèle selon sa disponibilité, l’état des systèmes et la complexité de la tâche, tout en respectant l’abonnement et les règles applicables. Les interfaces compatibles permettent de voir quel modèle a réellement été utilisé. Auto constitue donc une solution de repli à tester, mais pas la garantie qu’un processus jusque-là attaché à un modèle conservera le même comportement : la sélection accessible à Auto peut évoluer. ## Lire les tarifs comme un instantané, pas comme une facture Au 6 septembre, GitHub affiche pour un million de jetons trois tarifs — entrée, entrée mise en cache et sortie — de 1,50 $, 0,15 $ et 9 $ pour Gemini 3.5 Flash. Gemini 3.6 Flash et Gemini 3.8 Flash sont tous deux annoncés à 0,75 $, 0,075 $ et 3,75 $. Kimi K2.7 est affiché à 0,95 $, 0,19 $ et 4 $, contre 3 $, 0,30 $ et 15 $ pour Kimi K3. Claude Opus 4.7 et Claude Opus 5 partagent les mêmes montants publiés : 5 $ en entrée, 0,50 $ pour l’entrée mise en cache, 6,25 $ pour l’écriture en cache et 25 $ en sortie. Ces chiffres sont un relevé daté, non une estimation de facture. La consommation dépend du volume de jetons, de l’utilisation du cache, de la fonction et de l’abonnement. Des tarifs identiques ne prouvent pas que deux modèles consommeront autant pour accomplir une tâche, pas plus qu’un prix unitaire supérieur n’établit à lui seul un coût final plus élevé. GitHub valorise par ailleurs un crédit d’IA à 0,01 $, tandis que les complétions de code et les suggestions de prochaine modification ne consomment pas ces crédits. L’indicateur le plus utile reste donc le coût d’un résultat effectivement accepté, replacé dans les conditions du contrat de l’organisation. ## Déployer progressivement et conserver une issue de secours Une fois les essais terminés, mieux vaut commencer par un groupe restreint couvrant plusieurs métiers et plusieurs interfaces. Pendant cette phase pilote, l’équipe peut suivre les erreurs, le temps de réponse, les corrections demandées par les relecteurs et les dépenses observées. Les résultats doivent être ventilés par type de tâche : une moyenne globale masquerait facilement une régression du mode agent compensée par de bonnes réponses dans le chat. La solution de repli doit être décidée avant le déploiement. Elle peut être un autre modèle explicitement autorisé ou, après validation, le mode Auto. Il faut aussi désigner la personne capable de modifier rapidement les règles d’entreprise ou d’organisation. Sans cette préparation, un incident banal d’accès risque de devenir une interruption prolongée pour tous les utilisateurs. Le passage général peut ensuite être planifié avant le 2 octobre, avec un contrôle après bascule : modèle par défaut des nouvelles conversations, choix disponibles pour les utilisateurs, fonctionnement des intégrations et version des clients. GitHub précise qu’il ne sera pas nécessaire de supprimer manuellement les anciens modèles après leur retrait. L’effort doit donc porter sur les dépendances encore actives et sur la vérification des nouveaux parcours, plutôt que sur un nettoyage symbolique. Cette échéance révèle surtout une réalité durable des outils d’IA : le modèle fait désormais partie des dépendances opérationnelles. Il faut connaître son propriétaire, ses règles d’accès, ses surfaces prises en charge, son coût et sa solution de remplacement. Les équipes qui transforment ce retrait en exercice reproductible — inventaire, vérification des prérequis, comparaison sur des cas réels, déploiement pilote et contrôle final — seront mieux préparées aux prochaines évolutions de Copilot que celles qui se limitent à sélectionner le nom recommandé.