Depuis le 26 août 2026, il n’y a plus besoin de s’inscrire sur une liste d’attente pour faire relire ses pull requests par une IA sur Azure Repos. GitHub Copilot Code Review est passé en preview publique, ouvert à tous les organisations Azure DevOps sans demande d’accès préalable. Concrètement : Copilot rejoint la liste des reviewers de ta pull request, lit le diff, et pose des commentaires ligne par ligne — exactement comme le ferait un collègue, sauf qu’il ne dort jamais et ne prend pas de café avant 9h.
Ce n’est pas un gadget marketing greffé sur Azure Boards. C’est une brique qui s’active en quelques clics, se facture au token, et s’intègre directement dans tes policies de branche existantes. Voici ce qu’il faut savoir avant de l’activer sur un vrai projet.
Ce que fait réellement Copilot Code Review
Une fois activé, GitHub Copilot apparaît comme reviewer disponible sur chaque pull request d’un dépôt Git (les dépôts TFVC ne sont pas supportés — encore une raison de migrer si tu es encore dessus). Tu peux le solliciter manuellement à la demande, ou laisser une policy de branche le déclencher automatiquement à chaque nouvelle PR.
Il pose ses commentaires directement sur les lignes concernées, et ces commentaires se comportent comme ceux d’un humain : tu peux y répondre, les résoudre, les masquer, réagir avec un emoji. Ce qu’il ne fait jamais en revanche, c’est bloquer une fusion ou approuver formellement une PR — sa review reste toujours au statut « Commentaire ». Et il ne relit pas automatiquement après un nouveau commit : si tu pousses un correctif, il faut redemander une review à la main. Pas de veille passive façon humain qui laisse traîner un onglet ouvert.
Trois niveaux d’effort, trois facturations différentes
Tu choisis entre Low, Medium et High au moment de la demande de review (ou tu fixes un niveau par défaut au niveau du projet ou du repo). Plus l’effort est élevé, plus Copilot consomme de tokens — et plus la facture grimpe. Pas de mystère marketing ici : Microsoft facture en GitHub AI credits, à 0,01 $ le crédit, calculés sur les tokens d’entrée, de sortie et les tokens mis en cache. La taille de la PR, tes instructions personnalisées et les mises à jour de modèle jouent aussi sur la note finale.
Pour une équipe qui traite des dizaines de PR par jour, le choix du niveau d’effort par défaut n’est pas un détail cosmétique — c’est une ligne de budget. Autant commencer en Low sur les repos à fort volume et réserver High aux PR touchant du code sensible (auth, paiement, infra), plutôt que de l’activer partout en mode maximal dès le premier jour.
Activer la fonctionnalité : organisation, projet, ou dépôt
L’activation se fait à trois niveaux, du plus large au plus ciblé :
- Organisation : Organization settings → Repos → Repositories, bascule « Allow repositories in this organization to use Copilot code review ». L’option « Enable all » active la fonctionnalité pour tous les projets et dépôts d’un coup.
- Projet : Project settings → Repos → Repositories, bascule équivalente qui s’applique à tous les dépôts du projet, sauf override au niveau dépôt. Cette étape est facultative si l’organisation a déjà tout activé.
- Dépôt : même chemin, sélectionne le repo concerné, onglet Settings, bascule « Enable Copilot code review for pull requests in this repository ». Une fois actif, GitHub Copilot doit apparaître dans la liste des reviewers disponibles sur une PR.
Pour l’exécution des reviews, tu peux garder le pool Azure Pipelines hébergé par défaut, ou pointer vers un Managed DevOps Pool que tu contrôles déjà — utile si tu veux garder la main sur l’image et le dimensionnement des agents. Une contrainte à connaître avant de t’y engager : seules les images Ubuntu Server récentes sont supportées, les images Windows sont exclues, et il ne faut pas mélanger agents Ubuntu et Windows dans le même pool. Les pools self-hosted classiques, eux, ne sont pas éligibles du tout.
Les limites concrètes à connaître avant de généraliser
Avant de brancher ça sur ton repo monolithique de 8 Go avec des PR de 300 fichiers, quelques plafonds à vérifier :
- Taille du dépôt : 10 Go maximum
- Fichiers modifiés par PR : 100 maximum
- Changements totaux : 100 maximum
- Reviews simultanées par organisation : 5
- Reviews simultanées par utilisateur : 2
- Une seule review complétée par commit de fusion
Autre point qui a son importance dans un vrai workflow : les pull requests en brouillon ne sont pas prises en charge. La PR doit être active, sans conflit de fusion, pour que Copilot accepte de la relire. Si ton équipe a l’habitude de solliciter des retours dès le brouillon, il faudra soit changer cette habitude, soit accepter que Copilot n’intervienne qu’une fois la PR passée en revue « officielle ».
Suivre la facture sans surprise
Les coûts remontent dans Azure Cost Management avec un délai de 48 heures après la fin d’une review — pas en temps réel, donc pas de tableau de bord pour surveiller la dépense minute par minute. Filtre sur la catégorie de compteur GitHub et la sous-catégorie GitHub Copilot for AzDO, puis regroupe par tag Organization ou Project pour savoir quelle équipe consomme quoi. Si plusieurs équipes se partagent le même abonnement Azure, configurer une alerte de budget (seuils à 75 % et 90 % par exemple, sur le produit « GitHub Copilot for AzDO ») évite la mauvaise surprise en fin de mois — un réflexe qui rejoint ce qu’on évoquait récemment sur le pilotage FinOps des charges liées à l’IA.
Faut-il l’activer dès maintenant ?
Pour une équipe qui fait déjà de la revue de code sérieuse (branch policies, reviewers obligatoires, checks CI bloquants), oui — activer Copilot en complément d’une review humaine, pas à sa place, a du sens dès la preview publique : le risque est faible (il ne peut jamais fusionner ni bloquer), le coût est maîtrisable en Low, et le gain (attraper les fautes d’attention avant l’œil humain) est réel. Pour une petite équipe sans process de review formalisé, en revanche, poser d’abord des branch policies et des reviewers humains obligatoires rapporte plus, tout de suite, que d’ajouter un reviewer IA à un processus qui n’existe pas encore.
FAQ
Copilot Code Review peut-il bloquer une fusion ?
Non. Sa review reste toujours au statut « Commentaire », jamais « Approuvé » ni « Rejeté ». Il ne peut donc pas empêcher une fusion à lui seul — il faut une policy de branche distincte pour ça.
Ça fonctionne sur des dépôts TFVC ?
Non, uniquement sur des dépôts Git. Si ton équipe est encore sur TFVC, c’est une raison de plus d’envisager la migration.
Faut-il une licence GitHub Copilot séparée ?
La fonctionnalité est disponible en preview publique pour tous les clients Azure DevOps, sans inscription préalable, mais la consommation se facture en crédits IA GitHub via ton abonnement Azure — vérifie la documentation officielle Microsoft Learn pour le détail exact de la facturation selon ton contrat.
Peut-on désactiver la fonctionnalité si les retours ne conviennent pas ?
Oui, à trois niveaux : pour un utilisateur (désactiver les « Preview features » dans ses réglages personnels), pour un dépôt (bascule au niveau repo), ou pour toute l’organisation (bascule au niveau organisation, qui coupe la fonctionnalité pour tous les projets).
Si tu gères plusieurs projets Azure DevOps, le plus simple reste de tester d’abord sur un seul dépôt à faible enjeu, de calibrer le niveau d’effort par défaut sur quelques semaines de PR réelles, puis de généraliser une fois que le rapport signal/bruit des commentaires de Copilot te convient. Et surtout : configure l’alerte de budget avant, pas après avoir découvert la facture.
Laisser un commentaire