GitHub fait relire par Copilot le code produit par ses propres agents : l’humain devient-il l’arbitre final ?
GitHub franchit une nouvelle étape dans le développement logiciel agentique. Depuis le 27 août 2026, Copilot code review peut effectuer une revue agentique complète sur les Pull Requests créées par des bots, y compris celles ouvertes par Copilot cloud agent.
GitHub supprime également l’ancienne limite de 300 fichiers ou 20 000 lignes de code par Pull Request et introduit trois raisons permettant aux développeurs de qualifier les remarques de l’IA : Addressed, Won’t fix et Incorrect.
Derrière cette mise à jour apparemment technique se dessine une évolution plus importante : un agent IA peut désormais produire du code, un autre système agentique peut le relire, puis l’humain intervient pour accepter, refuser ou signaler une erreur dans la review.
La vraie question n’est donc plus seulement de savoir si l’IA peut coder. Elle devient : peut-on faire confiance à une IA pour contrôler le travail produit par une autre IA ?
Qu’annonce exactement GitHub pour Copilot code review ?
La mise à jour du 27 août concerne trois changements principaux.
Premier changement : Copilot code review peut désormais analyser automatiquement les Pull Requests écrites par des bots. Cela inclut notamment les PR générées par Copilot cloud agent. Jusqu’ici, lorsqu’une review automatique était déclenchée sur une Pull Request créée par cet agent, GitHub utilisait une expérience limitée. Désormais, la PR peut recevoir la revue agentique complète.
Deuxième changement : l’ancienne limite de 300 fichiers ou 20 000 lignes de code ne s’applique plus. GitHub peut donc lancer Copilot code review sur des modifications beaucoup plus importantes. Il vaut toutefois mieux parler de suppression de cette limite précise que de review « illimitée » : GitHub ne garantit pas qu’une Pull Request de n’importe quelle taille obtiendra une analyse de qualité identique.
Troisième changement : lorsqu’un développeur résout un commentaire Copilot, il peut maintenant préciser pourquoi avec Addressed, Won’t fix ou Incorrect. GitHub explique que ces informations constituent un feedback utile pour améliorer le produit.
Le détail paraît mineur. Il est pourtant central pour comprendre la stratégie de GitHub.
Pourquoi Copilot code review devient-il une vraie brique agentique ?
Copilot code review n’est plus un simple LLM qui lit un diff et génère quelques commentaires.
Depuis mars 2026, GitHub indique que le service repose sur une architecture agentique avec appels d’outils. Le système peut explorer davantage de contexte dans le dépôt, examiner la structure du projet et rechercher les références nécessaires pour comprendre les modifications dans leur environnement global.
GitHub a depuis étendu cette architecture avec des fichiers AGENTS.md, des agent skills et des connexions MCP permettant d’apporter du contexte provenant d’outils, de standards internes ou de services tiers. Les appels MCP utilisés pendant la review restent en lecture seule.
Autrement dit, le workflow commence à ressembler à ceci :
ticket → agent de code → Pull Request → agent de review → corrections → validation humaine.
Cette logique prolonge directement ce que GitHub faisait déjà avec son intégration entre Copilot cloud agent et Linear, où un ticket peut être attribué à Copilot afin que l’agent prépare une Pull Request. CritiquePlus avait analysé cette évolution comme le passage progressif du copilote à la délégation de tâches complètes. GitHub Copilot dans Linear : du ticket à la Pull Request
La nouveauté du 27 août ferme une partie supplémentaire de la boucle : le code écrit par l’agent peut désormais être revu automatiquement par Copilot code review avec les mêmes capacités agentiques que le code humain.
L’IA peut-elle vraiment relire correctement le code produit par une autre IA ?
C’est la question la plus importante.
Sur le principe, utiliser deux étapes automatisées est logique. Un générateur peut produire une solution, tandis qu’un système de review cherche des bugs, incohérences, vulnérabilités ou problèmes d’architecture.
Mais deux IA ne garantissent pas deux raisonnements indépendants.
GitHub explique que Copilot code review utilise un mélange spécialement configuré de modèles, prompts et comportements système. L’entreprise ne permet pas à l’utilisateur de sélectionner le modèle de review et ne divulgue pas précisément quel modèle intervient dans chaque analyse.
Il devient donc difficile pour une équipe externe d’évaluer l’indépendance entre le système qui produit le code et celui qui le contrôle.
Si deux étapes reposent sur des modèles proches, sur le même fournisseur ou sur des hypothèses similaires, elles pourraient théoriquement partager certains angles morts. Une erreur logique que le premier agent juge acceptable pourrait également paraître correcte au second.
À ce stade, CritiquePlus n’a trouvé aucune preuve officielle démontrant que ce problème se produit systématiquement dans Copilot. Il s’agit d’un risque méthodologique à mesurer, pas d’une vulnérabilité établie.
Le test réellement intéressant serait de comparer trois situations : code créé par un humain puis revu par Copilot, code produit par Copilot cloud agent puis revu par Copilot, et code généré par un modèle A puis contrôlé par un modèle indépendant B.
GitHub ne publie pas, dans l’annonce du 27 août, ce type de comparaison.
GitHub dispose-t-il déjà de données sur la qualité de Copilot code review ?
Oui, et c’est une nuance importante.
Dire que GitHub ne publie aucune donnée serait incorrect.
En mars 2026, GitHub indiquait que Copilot code review avait dépassé 60 millions de reviews et représentait alors plus d’une review sur cinq sur GitHub. L’entreprise disait également suivre la qualité grâce aux réactions positives ou négatives des développeurs et au fait qu’un problème signalé soit corrigé avant le merge.
GitHub indiquait alors que 71 % des reviews produisaient un feedback jugé actionnable, tandis que 29 % ne généraient volontairement aucun commentaire. Le service produisait environ 5,1 commentaires par review en moyenne. GitHub affirme également que le passage à son architecture agentique avait amélioré de 8,1 % le taux de feedback positif.
Ce sont des signaux intéressants, mais ils ne remplacent pas un benchmark classique de precision, recall, taux de faux positifs ou bugs réellement détectés.
Surtout, ils ne répondent pas encore à la question spécifique de cette nouvelle architecture : Copilot code review est-il aussi performant lorsque le code contrôlé a lui-même été généré par Copilot ou un autre agent ?
Pourquoi les boutons Addressed, Won’t fix et Incorrect sont-ils stratégiques ?
Parce qu’ils donnent à GitHub un signal humain plus explicite.
Un commentaire marqué Addressed indique qu’une remarque a conduit à une correction. Won’t fix signifie que le développeur reconnaît éventuellement le point mais choisit de ne pas intervenir. Incorrect identifie directement une remarque que l’utilisateur considère comme erronée.
GitHub disposait déjà de signaux comme les pouces positifs ou négatifs et observait si les problèmes signalés étaient résolus avant fusion. Les nouvelles raisons de résolution enrichissent donc une boucle de feedback déjà existante plutôt qu’elles ne la créent.
Ce système peut devenir particulièrement précieux dans un environnement où la quantité de code produit par des agents augmente.
L’humain n’écrit alors plus nécessairement chaque ligne. Son rôle se déplace vers la validation, l’arbitrage et l’évaluation de la qualité des agents.
C’est précisément l’une des transformations décrites dans notre dossier sur l’IA agentique, où l’enjeu n’est plus uniquement de générer une réponse mais d’encadrer une chaîne d’actions automatisées. Comprendre l’IA agentique et ses boucles de contrôle
Combien coûte Copilot code review lorsqu’un bot crée la Pull Request ?
C’est l’autre changement important.
Une Pull Request créée automatiquement par un bot ne dispose pas nécessairement d’un utilisateur humain titulaire d’une licence GitHub Copilot auquel attribuer la consommation.
GitHub permet désormais aux organisations d’activer une politique autorisant Copilot code review pour les utilisateurs ou bots sans licence Copilot. Dans ces situations, l’utilisation peut être facturée directement à l’organisation ou à l’entreprise.
On voit donc apparaître une forme de consommation machine-to-machine : un agent génère une PR, un second processus IA la révise et l’entreprise paie la consommation informatique correspondante.
Une review comporte actuellement deux composantes de coût : les GitHub AI Credits consommés par le modèle et les minutes GitHub Actions nécessaires aux capacités agentiques comme la collecte de contexte.
Contrairement à ce que pourrait laisser penser une lecture rapide de l’annonce, GitHub publie désormais des estimations.
Une review Lite consomme typiquement entre 0,05 et 1 dollar d’AI Credits, tandis qu’une review Balanced est estimée entre 0,25 et 5 dollars. Ces montants n’incluent pas les minutes GitHub Actions et peuvent augmenter avec la taille de la Pull Request ou les instructions personnalisées du dépôt.
GitHub ne fournit toutefois pas un coût moyen observé par PR agentique, encore moins pour des dépôts utilisant massivement des agents.
Pour une entreprise qui automatise des milliers de Pull Requests, ce détail peut devenir un véritable sujet FinOps/AgentOps.
La suppression de la limite de 20 000 lignes garantit-elle une meilleure review ?
Non.
GitHub confirme seulement que l’ancienne restriction de 20 000 lignes ou 300 fichiers ne s’applique plus.
Cela ne démontre pas que la qualité reste constante lorsqu’une Pull Request passe de 2 000 à 20 000, 50 000 ou 100 000 lignes.
GitHub travaille déjà sur plusieurs niveaux d’effort. Le mode Lite privilégie une analyse rapide tandis que Balanced utilise un modèle à raisonnement plus poussé pour les modifications complexes, sensibles ou multi-services.
L’entreprise a également montré en juillet que modifier les outils d’exploration de code pouvait paradoxalement faire augmenter le coût tout en réduisant le nombre de problèmes détectés, avant optimisation. C’est un rappel utile : donner davantage d’outils ou de contexte à un agent ne garantit pas automatiquement une meilleure review.
Pour les très grosses PR, la question de la profondeur réelle d’analyse reste donc ouverte.
Que ne dit pas clairement GitHub sur cette nouvelle boucle d’agents ?
Le premier manque concerne la precision et le recall spécifiquement sur des Pull Requests générées par des agents.
GitHub publie des indicateurs internes et des métriques d’usage, mais pas un benchmark permettant de savoir combien de bugs introduits par Copilot cloud agent sont ensuite détectés ou ratés par Copilot code review.
Le deuxième angle mort concerne l’indépendance des modèles. GitHub ne permet pas de choisir le modèle utilisé pour la review et décrit son système comme un mélange optimisé de modèles et de comportements.
Le troisième concerne les très grandes Pull Requests. La disparition de la limite technique est utile, mais elle ne constitue pas une preuve de qualité constante à grande échelle.
Enfin, la consommation peut devenir difficile à prévoir lorsqu’une organisation combine coding agents, reviews automatiques, re-reviews, niveaux Balanced, GitHub Actions et autres fonctionnalités Copilot.
L’humain reste-t-il obligatoire dans Copilot code review ?
Dans le workflow de validation GitHub, oui.
Copilot code review ne peut pas approuver une Pull Request ni demander officiellement des changements. Ses reviews sont publiées sous la forme de commentaires. Elles ne comptent pas parmi les approbations obligatoires et ne bloquent pas directement le merge.
Cette limitation est importante.
GitHub construit donc pour l’instant une boucle dans laquelle les agents peuvent produire et analyser une quantité croissante de travail, mais où l’organisation peut conserver des quality gates, règles de branches et validations humaines.
Pour les équipes qui pilotent déjà plusieurs agents dans VS Code, cette évolution renforce une tendance visible depuis plusieurs mois : l’environnement de développement devient progressivement un poste d’orchestration plutôt qu’un simple éditeur de code. VS Code, Copilot, Claude et Codex : vers un poste de pilotage multi-agents
Qui peut vraiment profiter de GitHub Copilot code review pour les agents ?
Les équipes de développement utilisant Copilot cloud agent sont évidemment les premières concernées. Elles peuvent désormais automatiser une première couche de contrôle sans attendre immédiatement un reviewer humain.
Les grandes entreprises peuvent aussi utiliser Copilot code review comme filtre systématique sur un grand nombre de dépôts, à condition de surveiller les coûts et les faux positifs.
Les petites équipes peuvent gagner du temps sur les bugs simples, les incohérences ou les vérifications répétitives, mais elles doivent éviter de considérer une review IA comme une preuve que le code est correct.
Les utilisateurs de Claude Code, Cursor, Codex ou d’autres agents ont également intérêt à suivre cette évolution. Le marché ne se joue plus uniquement sur « qui écrit le meilleur code », mais sur la capacité à orchestrer génération, tests, review, correction et validation.
CritiquePlus compare déjà cette transformation dans son test de Claude Code et son analyse de Cursor AI, deux outils qui illustrent la transition de l’assistant de code vers l’agent logiciel. Test complet de Claude Code en 2026 Cursor AI : test, prix et alternatives
Quel est l’avis CritiquePlus sur Copilot code review ?
Cette mise à jour est plus stratégique qu’elle n’en a l’air.
La suppression de la limite de 20 000 lignes est utile. Les nouvelles raisons de résolution sont intelligentes. La prise en charge des PR créées par des bots améliore la cohérence du produit.
Mais le signal majeur est ailleurs : GitHub construit progressivement une chaîne de production logicielle dans laquelle plusieurs étapes peuvent être exécutées par des agents.
Un agent reçoit le ticket. Il modifie le dépôt. Il ouvre une Pull Request. Copilot code review analyse cette Pull Request. Un agent peut ensuite appliquer certaines corrections. L’humain contrôle ce qui mérite d’être conservé.
C’est probablement l’une des directions les plus importantes du développement logiciel en 2026.
CritiquePlus recommande néanmoins de tester plutôt que d’automatiser aveuglément. Une équipe sérieuse devrait mesurer séparément le taux de commentaires utiles, les faux positifs, les bugs ratés, le coût par PR et surtout les performances sur du code lui-même produit par une IA.
Le scénario le plus intéressant à tester serait même d’utiliser un reviewer indépendant du générateur.
Si un agent écrit et qu’un autre agent réellement indépendant contrôle, la diversité des modèles pourrait devenir l’équivalent logiciel du principe « quatre yeux ». Si le générateur et le reviewer partagent les mêmes angles morts, l’automatisation risque au contraire de produire une illusion de contrôle.
FAQ
Copilot code review peut-il relire une Pull Request créée par Copilot ?
Oui. Depuis le 27 août 2026, une Pull Request ouverte par Copilot cloud agent peut recevoir une review agentique complète lorsqu’une review automatique est configurée.
Copilot code review fonctionne-t-il sur les PR de plus de 20 000 lignes ?
Oui. GitHub indique que l’ancienne limite de 300 fichiers ou 20 000 lignes ne s’applique plus. Cela ne signifie toutefois pas que la qualité est garantie pour n’importe quelle taille de PR.
Copilot code review peut-il bloquer un merge ?
Non directement. Ses reviews restent des commentaires et ne valent ni « Approve » ni « Request changes ». Elles ne satisfont pas les approbations obligatoires et ne bloquent pas seules la fusion.
Combien coûte une Copilot code review ?
GitHub estime actuellement la consommation en AI Credits à environ 0,05 à 1 dollar pour Lite et 0,25 à 5 dollars pour Balanced, hors GitHub Actions. Le coût réel dépend notamment de la taille et du contexte de la PR.
GitHub mesure-t-il les faux positifs de Copilot code review ?
GitHub utilise déjà plusieurs signaux de production, dont les réactions des développeurs et la résolution des problèmes signalés. Le nouveau choix Incorrect fournit un feedback supplémentaire. En revanche, GitHub ne publie pas dans cette annonce de taux standardisé de precision ou de recall pour les PR créées par des agents.
Ce qu’il faut retenir
Copilot code review peut désormais effectuer une review agentique complète du code produit par Copilot cloud agent.
L’ancienne limite de 300 fichiers ou 20 000 lignes disparaît.
Les développeurs peuvent classer les remarques en Addressed, Won’t fix ou Incorrect, créant un signal humain plus précis pour améliorer le système.
La facturation peut désormais s’effectuer directement au niveau de l’organisation lorsqu’une PR provient d’un bot sans licence associée.
Mais la grande question reste sans réponse publique : un agent IA est-il aussi efficace pour détecter les erreurs lorsque le code a été produit par un autre agent de la même plateforme ?
Pour CritiquePlus, cette annonce ne signifie pas que la review humaine devient inutile. Elle montre plutôt que son rôle évolue : l’IA écrit, l’IA contrôle, mais l’humain doit encore décider à quel moment la boucle mérite réellement sa confiance.
Sources officielles consultées
GitHub Changelog — “Copilot code review: Resolution reasons and expanded capabilities”, 27 août 2026. Consulter l’annonce officielle GitHub
GitHub Docs — About GitHub Copilot code review. Documentation sur l’architecture agentique, les niveaux Lite et Balanced, les coûts, la facturation et les modèles utilisés.
GitHub Blog — “60 million Copilot code reviews and counting”, 5 mars 2026. Données officielles sur l’adoption, les signaux qualité et l’architecture agentique.
GitHub Changelog — Copilot code review now runs on an agentic architecture, 5 mars 2026.
GitHub Changelog — Agent skills and MCP now generally available, 29 juillet 2026.
