GitHub Models arrive aujourd'hui au bout de sa trajectoire. Depuis ce 30 juillet 2026, GitHub retire entièrement le service, y compris son playground, son catalogue de modèles, son API d'inférence et la possibilité d'utiliser ses propres clés avec BYOK. Les nouveaux clients ne pouvaient déjà plus y accéder depuis le 16 juin. Pour les équipes qui s'en servaient comme laboratoire ou comme dépendance d'une application, la période d'observation est donc terminée : il faut désormais avoir migré.

La fermeture est un rappel utile. Une API d'IA ressemble parfois à une simple brique interchangeable parce que la plupart des fournisseurs acceptent des messages, un nom de modèle et quelques paramètres. Dans la pratique, une plateforme embarque aussi l'authentification, les quotas, les formats d'erreur, les filtres, la disponibilité régionale, les journaux, le catalogue et les règles de cycle de vie. Changer d'endpoint sans revoir ces contrats déplace le risque au lieu de le supprimer.

GitHub recommande Microsoft Foundry pour les nouveaux projets qui cherchent un catalogue de modèles. Cette piste est naturelle dans l'écosystème Microsoft, mais elle ne dispense pas d'un travail de migration structuré.

Commencer par savoir ce qui dépend réellement du service

La première étape consiste à inventorier les usages. Certaines équipes n'ont utilisé GitHub Models que dans le navigateur pour comparer des prompts. D'autres ont intégré l'API dans un prototype, un test automatisé, un outil interne ou une fonction visible par les clients. Le niveau de risque n'est pas le même.

Il faut rechercher les URLs d'API, les noms de variables d'environnement, les secrets, les packages SDK et les références au service dans les workflows GitHub Actions. Les notebooks et les scripts ponctuels sont faciles à oublier, alors qu'ils peuvent encore servir à produire un rapport ou à préparer une démonstration. Les tableaux de bord de coûts et les alertes doivent aussi être vérifiés, car une migration peut déplacer la consommation vers un autre compte sans déplacer les garde-fous.

L'inventaire doit distinguer les appels synchrones, les traitements en lot et les expériences manuelles. Il doit également identifier les propriétaires. Une dépendance sans équipe responsable devient rapidement un incident silencieux.

Le modèle n'est pas le seul contrat

Remplacer un modèle par un autre portant un nom proche ne garantit pas le même comportement. Les limites de contexte, le support du JSON structuré, les appels d'outils, le streaming et les politiques de filtrage peuvent changer. Même lorsque l'interface HTTP reste compatible, la qualité des réponses et les cas d'échec évoluent.

Une migration sérieuse doit donc partir des comportements attendus. Pour une extraction, il faut vérifier la validité du schéma, le taux de champs manquants et le traitement des entrées ambiguës. Pour un assistant, il faut mesurer la pertinence, les refus, les temps de réponse et la stabilité des appels d'outils. Pour de la génération de code, les tests doivent porter sur l'exécution, la sécurité et la maintenance du résultat, pas uniquement sur son apparence.

Les paramètres par défaut méritent la même attention. Température, nombre maximal de tokens, délai d'expiration et stratégie de nouvelle tentative peuvent produire des écarts de coût ou de latence importants. La migration est terminée lorsque le service rendu est à nouveau prévisible, pas lorsque le premier appel renvoie un statut 200.

Construire une couche fournisseur raisonnable

La disparition de GitHub Models peut encourager une réaction excessive : créer immédiatement une abstraction universelle capable de parler à tous les modèles du marché. Cette approche devient souvent plus complexe que le problème initial. Chaque fournisseur expose des fonctions spécifiques, et vouloir tout réduire au plus petit dénominateur commun peut empêcher d'utiliser les capacités réellement utiles.

Une couche légère suffit généralement. Elle doit isoler l'URL, l'authentification, le nom du modèle, les délais, les tentatives et la normalisation des erreurs. Le code métier doit recevoir une réponse validée plutôt qu'un objet brut propre à un SDK. Les fonctions particulières, comme les outils ou les sorties structurées, peuvent rester des capacités explicites au lieu d'être cachées derrière une interface artificiellement uniforme.

Cette séparation rend le prochain changement moins coûteux. Elle permet aussi de tester un second fournisseur sur une petite partie du trafic sans réécrire tout le produit.

Les données et les secrets changent de frontière

Migrer vers Microsoft Foundry ou un autre service modifie la destination des prompts, des fichiers et des métadonnées. Les équipes doivent confirmer la région utilisée, la rétention, les journaux disponibles et les responsabilités d'accès. Un prototype qui ne manipulait que des textes publics peut devenir un outil métier alimenté par des documents confidentiels ; la même configuration n'est alors plus acceptable.

Les clés doivent être recréées dans le nouveau système de secrets plutôt que copiées dans des variables locales permanentes. Les anciennes clés et intégrations doivent être supprimées lorsque le service n'en a plus besoin. Même si une plateforme ferme, conserver des secrets inutilisés entretient une confusion opérationnelle et complique les audits.

Les rôles doivent rester minimaux. Une application d'inférence n'a pas besoin des mêmes permissions qu'un administrateur capable de déployer des modèles ou de modifier les quotas. Cette distinction devient particulièrement importante quand plusieurs environnements partagent un abonnement cloud.

Prévoir le cycle de vie dès le départ

Le calendrier de retrait de GitHub Models est visible et daté, mais tous les changements ne donnent pas autant de temps. Les catalogues d'IA évoluent vite : versions remplacées, modèles retirés, routes d'API unifiées et conditions commerciales modifiées. Une application qui inscrit directement un modèle dans des dizaines de fichiers rend chaque évolution plus risquée.

Le nom du modèle et l'endpoint doivent être configurables par environnement. Une alerte doit signaler les annonces de dépréciation assez tôt pour lancer les évaluations. Les tests de référence doivent pouvoir être rejoués contre une nouvelle version. Enfin, un chemin de retour doit exister tant que la migration n'est pas stabilisée.

Ce travail n'exige pas nécessairement une plateforme complexe. Un petit jeu de cas représentatifs, une configuration centralisée et un tableau comparant qualité, coût et latence apportent déjà beaucoup plus qu'une confiance fondée sur quelques essais manuels.

La fermeture transforme un prototype en décision d'architecture

GitHub Models avait rendu l'exploration accessible depuis un environnement familier aux développeurs. Sa disparition ne signifie pas que les expériences menées étaient inutiles. Elle montre simplement qu'un outil d'exploration et une dépendance de production n'obéissent pas aux mêmes attentes.

Les équipes qui ont conservé des prompts versionnés, des tests et une séparation claire entre le métier et le fournisseur migreront sans drame. Celles qui ont laissé l'expérience devenir progressivement un service critique devront découvrir leurs dépendances dans l'urgence.

Le bon enseignement n'est pas d'éviter les plateformes en préversion. Elles permettent d'apprendre vite. Il est de savoir à quel moment un prototype devient un système, puis d'ajouter à ce moment-là les contrôles que suppose sa durée de vie. La date du 30 juillet ferme GitHub Models ; elle devrait aussi ouvrir une discussion plus mature sur la portabilité réelle des applications d'IA.