Deux modèles arrivent dans Copilot, mais leur disponibilité ne répond pas à la question essentielle : lequel aide réellement votre équipe à livrer un changement correct ? Voici comment préparer une comparaison reproductible sur vos propres tâches, sans fabriquer de benchmark.
Ce que les annonces changent — et ce qu'elles ne prouvent pas
Deux dates, un accès à constater
GitHub a annoncé Gemini 3.8 Flash dans Copilot le 3 septembre 2026, puis la disponibilité générale de GPT-6 Astra le 4 septembre 2026. Dans les deux cas, GitHub décrit un déploiement progressif, des offres éligibles et des réglages d'administration propres au service. Ce sont des faits d'annonce, consultés le 9 septembre 2026 ; ils ne permettent pas d'affirmer qu'un modèle est déjà activé pour chaque compte.
| Modèle | Annonce GitHub | Accès dans votre environnement |
|---|---|---|
| Gemini 3.8 Flash | 3 septembre 2026 | Non vérifié |
| GPT-6 Astra | 4 septembre 2026 | Non vérifié |
La première action est donc sobre : relever l'offre, les politiques applicables, le client utilisé et le modèle réellement sélectionnable. Un relevé daté évite de confondre une annonce, une activation administrative et une expérience de développement observable.
Une disponibilité n'est pas une victoire au benchmark
GitHub présente ses propres évaluations dans ces annonces. Elles renseignent sur la manière dont l'éditeur positionne le service ; elles ne remplacent pas une comparaison indépendante sur un dépôt, des règles de revue et une chaîne d'intégration continue donnés. L'analyse de Partitech est donc la suivante : le choix doit porter sur un changement accepté par l'équipe, pas sur la fluidité d'une conversation ou une démonstration isolée.
Construire un jeu de tâches qui ressemble au travail réel
Des changements courts avec des critères d'acceptation
Préparez des tâches assez petites pour être revues, mais assez réalistes pour exposer les contraintes du projet. Par exemple : corriger une validation PHP qui accepte une valeur invalide ; ajouter un champ documenté à une réponse d'API sans rompre les clients existants ; réparer un test JavaScript devenu instable. Ces exemples sont fictifs : ils décrivent un protocole, aucun résultat observé.
Chaque tâche doit partir d'un commit connu, fournir le contexte strictement nécessaire, désigner les tests ciblés et définir le résultat attendu. « Le test passe », « aucun fichier hors périmètre n'est modifié » et « la réponse reste compatible » sont des critères vérifiables. Une demande vague, telle que « améliorer ce module », ne produit pas une unité de comparaison utilisable.
Rendre les conditions comparables
Figez le commit, les dépendances, les droits des outils, le contexte transmis et le budget de génération. Séparez les tâches déjà connues de celles qui seront réservées à l'évaluation, afin que l'équipe n'adapte pas involontairement le protocole à une réponse antérieure. Prévoyez plusieurs passages lorsque c'est pertinent, sans transformer cette intention en résultat avant d'avoir réellement exécuté les essais.
Mesurer le résultat accepté, pas seulement la réponse produite
Une grille vide est plus honnête qu'un tableau rempli de chiffres décoratifs. Elle enregistre ce qui a été constaté après exécution, avec les conventions retenues par l'équipe.
| Tâche | Tests ciblés | Défauts de revue | Reprises | Temps humain | Coût constaté | Résultat |
|---|---|---|---|---|---|---|
| À renseigner | Non mesuré | Non mesuré | Non mesuré | Non mesuré | Non mesuré | Non mesuré |
Le coût par changement validé peut être suivi ainsi : (génération + revue + reprises) / changements acceptés. Il faut fixer ce que recouvrent « revue » et « reprises » : temps d'ingénierie, exécutions facturées, attente de CI, ou seulement temps actif. Si aucun changement n’est accepté, le coût unitaire reste non calculable : conserver les dépenses et les échecs séparément. La formule aide à comparer des essais documentés ; elle ne prédit aucun rendement.
Interpréter les écarts sans surconclure
Classez les échecs avant de les attribuer : erreur fonctionnelle, régression, modification hors périmètre, contexte incomplet ou outillage indisponible. Une sortie rejetée parce qu'un test n'a pas été lancé n'a pas la même signification qu'un correctif qui casse une règle métier. Si des essais sont publiés, indiquez la taille du jeu, les exclusions et les limites de représentativité.
La décision peut alors être conditionnelle. Conservez un modèle pour une famille de tâches si les changements sont régulièrement acceptés et si la revue reste soutenable. Testez davantage si les résultats dépendent fortement du contexte ou varient d'un essai à l'autre. Limitez son emploi à un périmètre précis si les reprises ou les modifications hors sujet deviennent trop fréquentes. Cette matrice est une recommandation éditoriale, pas un classement de GPT-6 Astra ou de Gemini 3.8 Flash.
Passer de l'essai au suivi de version
Conservez les identifiants de version, les prompts, les sorties, les commandes de test et les arbitrages de revue, en excluant secrets et données client. Rejouez un sous-ensemble représentatif après une évolution substantielle du service, d'un modèle, de vos dépendances ou de vos politiques. Cette trace rend une décision révisable au lieu de la transformer en préférence durable.
Le protocole ne répondra pas à toutes les questions : il ne mesure pas seul la qualité architecturale à long terme ni la valeur métier d'une évolution. Il permet toutefois de décider quoi autoriser, quoi observer et quoi suspendre sur la base de preuves locales. Pour replacer cette discipline dans le contexte plus large des agents, voir aussi notre analyse des agents cyber critiques.
Choisir un modèle dans Copilot revient ainsi à acheter une preuve locale, pas une promesse générale. Vérifiez l'accès, figez les conditions, mesurez les changements acceptés et gardez les éléments qui permettront de refaire la décision.