GitHub a retiré Gemini 2.5 Pro et Gemini 3 Flash de toutes les expériences Copilot vendredi. Les remplaçants sont Gemini 3.1 Pro et Gemini 3.6 Flash.
L’échange n’est pas symétrique
Gemini 2.5 Pro était un modèle stable, généralement disponible. Son successeur désigné, Gemini 3.1 Pro, est étiqueté Preview. Les équipes qui s’étaient standardisées sur un modèle stable sont basculées vers un modèle portant une étiquette de préversion, ce qui, dans la propre taxonomie de GitHub, signifie qu’il peut changer ou disparaître sans l’avis qu’un modèle GA reçoit.
Ce que « aucune action requise » couvre réellement
Le changelog indique qu’aucune action n’est requise, et pour la suppression, c’est exact — rien ne casse, les modèles cessent simplement d’apparaître. La même entrée précise ensuite que les administrateurs Copilot Enterprise peuvent devoir activer l’accès aux modèles alternatifs via leurs politiques de modèle. Ces deux phrases ne décrivent pas la même situation. Dans une organisation soumise à une politique de modèle restrictive, les anciens modèles Gemini disparaissent et les nouveaux ne sont pas automatiquement autorisés, ce qui laisse les développeurs sans aucune option Gemini jusqu’à ce qu’une personne disposant des droits d’administration s’en aperçoive.
L’autre changement publié le même jour
GitHub a également rendu public en préversion le ciblage des politiques de modèle pour les équipes d’entreprise : une entreprise peut définir un ensemble de modèles de référence et accorder des modèles supplémentaires à des équipes individuelles, la résolution se faisant selon la règle la moins restrictive. La plupart des clients obtiennent l’opt-in le 3 août, de sorte que l’annonce précède la disponibilité. En creux, une conséquence mérite d’être lue deux fois : une fois le ciblage d’entreprise activé, les paramètres de modèle au niveau de l’organisation ne s’appliquent plus. Les restrictions existantes d’un administrateur d’organisation sont silencieusement supplantées par la politique d’entreprise.
Pourquoi une entrée de changelog mérite d’être lue
La disponibilité des modèles dans un outil de codage relève désormais d’une décision d’approvisionnement prise par l’éditeur de l’outil, et non par le développeur. Les modèles accessibles à une équipe, et à quel niveau de stabilité, sont déterminés deux niveaux plus haut — par la plateforme, puis par un administrateur d’entreprise — et cela évolue au gré d’entrées de changelog que personne n’est tenu de lire.