L’IA code plus vite que vos équipes ne savent relire : le nouveau goulot d’étranglement des DSI

Nous avons peut-être posé la mauvaise question sur l’intelligence artificielle appliquée au développement logiciel. Depuis deux ans, les directions informatiques cherchent à mesurer combien de code un développeur peut produire avec Copilot, Codex, Claude Code ou d’autres agents. Le sujet qui apparaît maintenant est presque inverse : que faire lorsque l’IA produit davantage de code que l’organisation n’est capable d’en vérifier correctement ?

Le signal est devenu suffisamment fort pour que GitHub lui-même s’y attaque. Le 4 août 2026, l’entreprise a publié une méthode destinée précisément à éviter les gigantesques pull requests générées par les agents de programmation. Son exemple part d’un cas devenu banal : un agent reçoit une fonctionnalité complète à développer et revient quelques minutes plus tard avec plus de 1 000 lignes de modifications portant simultanément sur les données, l’API, l’interface et les tests. Techniquement impressionnant. Humainement pénible à contrôler. 

Voilà probablement le prochain problème sérieux des DSI : nous avons accéléré la fabrication du logiciel sans accélérer au même rythme notre capacité à décider si ce logiciel mérite d’entrer en production.

Plus de code ne signifie pas forcément plus de logiciel livré

Les études commencent d’ailleurs à montrer un paradoxe assez dérangeant.

Le programme de recherche DORA de Google observe que les développeurs utilisant largement l’IA déclarent davantage de productivité individuelle et de satisfaction. Pourtant, au niveau du système de production logiciel, les résultats ne progressent pas automatiquement. Selon son étude publiée en 2026, une hausse de 25 % de l’adoption de l’IA était associée à une baisse de 1,5 % du throughput de livraison et à une dégradation de 7,2 % de la stabilité. L’une des explications avancées est très concrète : l’IA permet de produire rapidement des changements plus volumineux, donc plus difficiles à relire et à intégrer. 

C’est essentiel pour un comité de direction.

Un développeur peut avoir l’impression d’être deux fois plus rapide alors que l’entreprise ne met pas davantage de fonctionnalités fiables en production.

Le travail n’a pas disparu. Il s’est déplacé.

L’IA écrit. Quelqu’un doit ensuite comprendre, tester, vérifier, challenger puis assumer ce qu’elle a écrit.

La pull request de 2 000 lignes devient le nouveau fichier Excel monstrueux

Pendant longtemps, un bon principe de développement consistait à effectuer des changements relativement petits et compréhensibles.

Les agents peuvent casser cette discipline extrêmement facilement.

Demandez à un agent « ajoute la recherche produit à cette application » et il peut naturellement modifier le modèle de données, créer une API, ajouter les validations, construire l’interface, gérer les erreurs et écrire les tests dans une seule branche.

GitHub décrit précisément ce comportement dans son billet du 4 août et recommande désormais de décomposer le travail en une série de pull requests empilées, chacune correspondant à une responsabilité claire. La donnée peut ainsi être vérifiée par l’équipe concernée, l’API par les spécialistes backend et l’interface par les responsables frontend. 

Cela paraît presque banal.

Mais ce principe change complètement la manière de piloter un agent.

Nous ne devons plus seulement lui apprendre à produire du bon code. Nous devons lui apprendre à produire du code vérifiable par des humains.

C’est une nuance considérable.

Les recherches sur les agents commencent à confirmer le problème

Une étude acceptée à la conférence MSR 2026 a analysé environ 33 000 pull requests produites par cinq agents de programmation. Les chercheurs constatent que les contributions non fusionnées ont tendance à modifier davantage de fichiers, à comporter des changements plus importants et à échouer plus souvent dans les chaînes CI/CD. Les tâches documentaires et de maintenance obtiennent de meilleurs résultats que certains travaux de performance ou de correction de bugs. 

Une autre étude portant sur 567 pull requests utilisant Claude Code aboutit à une conclusion plus encourageante, mais elle confirme également le rôle essentiel du contrôle humain. Environ 83,8 % des contributions agentiques étudiées ont été acceptées, contre 91 % pour l’échantillon humain comparable ; environ 55 % des PR agentiques fusionnées l’ont été sans modification supplémentaire. Les auteurs recommandent notamment de conserver des pull requests de petite taille et de fournir aux agents les règles spécifiques d’architecture du projet. 

Autrement dit, l’agent peut parfaitement devenir un excellent développeur junior extrêmement rapide.

Mais le laisser construire seul une cathédrale de 15 000 lignes avant de demander à quelqu’un de vérifier le bâtiment est une mauvaise idée.

Et si l’IA relisait l’IA ?

La tentation suivante est évidemment prévisible.

Si un agent produit trop de code pour les humains, donnons le code à relire à un second agent.

Cela fonctionne en partie.

GitHub a d’ailleurs généralisé le 7 août 2026 différents niveaux d’effort pour Copilot Code Review. Une entreprise peut désormais choisir une revue « Lite » pour un changement simple ou « Balanced » pour une modification plus complexe ou sensible, et définir une politique par défaut au niveau de l’organisation. 

L’idée est excellente : toutes les modifications ne nécessitent pas la même puissance de contrôle.

Mais supprimer entièrement l’humain serait beaucoup plus hasardeux.

Une étude publiée en avril et acceptée à MSR 2026 a comparé plus de 3 000 pull requests examinées par des humains ou par des agents de revue. Dans cet échantillon, les PR relues uniquement par des agents avaient un taux de fusion de 45,2 %, contre 68,37 % pour celles contrôlées uniquement par des humains. Les chercheurs constatent également beaucoup de commentaires automatisés à faible valeur et concluent que les agents de revue sont aujourd’hui plus efficaces comme complément que comme remplacement des reviewers humains. 

Faire relire aveuglément une IA par une autre IA ne constitue donc pas une gouvernance.

Cela peut simplement produire deux machines extrêmement rapides qui se donnent mutuellement raison.

Le KPI « lignes de code » devient définitivement absurde

Cette transformation doit aussi faire évoluer les indicateurs des DSI.

Le nombre de prompts, de lignes générées ou même de pull requests créées ne prouve presque rien.

GitHub commence d’ailleurs à confronter coût et production dans son tableau de bord Copilot : depuis le 7 août, il peut rapprocher la consommation de crédits IA, le coût estimé par développeur et le nombre de pull requests produites. GitHub précise lui-même que ces mesures restent directionnelles. 

Il faut aller plus loin.

Je mesurerais désormais la taille moyenne des changements, le temps d’attente avant revue, le temps entre création et fusion, le taux de modifications demandées, les échecs CI, les retours arrière après production et surtout le temps humain consacré à contrôler les productions des agents.

Car c’est là que le coût caché apparaîtra.

Un agent capable de générer une fonctionnalité en vingt minutes n’est pas réellement vingt fois plus productif si trois ingénieurs doivent ensuite passer deux jours à comprendre ce qu’il a fait.

Il faut désormais concevoir le travail pour la revue

La bonne approche consiste à modifier le processus avant de multiplier les agents.

Dans une DSI utilisant sérieusement le développement agentique, j’imposerais quelques principes simples : un agent doit recevoir une tâche limitée et explicite ; une modification complexe doit être automatiquement décomposée ; les tests doivent être exécutés avant ouverture de la pull request ; la taille ou le nombre de fichiers modifiés doit pouvoir déclencher un niveau de revue supérieur ; les changements de sécurité, d’identité, de paiement ou d’architecture doivent conserver un reviewer humain identifié ; enfin, le code produit par un agent doit rester traçable jusqu’à son origine.

Ce n’est pas ralentir l’IA.

C’est construire la chaîne industrielle qui permet enfin de profiter de sa vitesse.

Le métier de développeur va monter d’un étage

Cette évolution annonce également un changement intéressant du travail des équipes.

Une partie croissante de leur valeur ne viendra plus de leur capacité à taper du code. Elle viendra de leur capacité à décomposer un problème, définir une architecture, imposer des contraintes, concevoir les tests et juger le résultat d’un agent.

Pour le DSI, cela change même la question stratégique.

Il ne faudra bientôt plus demander : « Combien de développeurs puis-je remplacer par l’IA ? »

La question utile sera : « Combien de changements supplémentaires mon organisation peut-elle vérifier et mettre en production sans augmenter son risque ? »

C’est beaucoup moins spectaculaire qu’une démonstration d’agent codant une application en dix minutes.

Mais c’est là que se trouve la véritable productivité.

L’IA vient de résoudre une partie du problème de production du code. Elle nous révèle maintenant le suivant : la capacité humaine et organisationnelle à distinguer très rapidement le code impressionnant du code réellement bon.

Et dans beaucoup de DSI, le prochain investissement ne devra donc pas être un agent capable d’écrire encore plus vite.

Il devra être une chaîne capable de comprendre, tester et approuver ce qu’il produit.

Sources vérifiées au 11 août 2026 : GitHub Engineering et GitHub Changelog des 4 et 7 août 2026, recherche DORA/Google Cloud, travaux empiriques acceptés à MSR 2026 et ACM TOSEM. 

#IntelligenceArtificielle, #DSI, #IAAgentique, #DeveloppementLogiciel, #CodingAgents, #DevOps, #DevSecOps, #GitHub, #CodeReview, #Automatisation, #TransformationNumerique, #GouvernanceIA, #SoftwareEngineering, #CI_CD, #Productivite, #QualiteLogicielle, #DirectionIT

Prompt d’illustration : illustration éditoriale moderne, professionnelle et légèrement satirique, immense usine logicielle futuriste où plusieurs robots intelligents extrêmement rapides produisent à toute vitesse des montagnes de blocs de code lumineux sur un tapis roulant, tandis qu’à l’autre extrémité quelques ingénieurs humains débordés doivent examiner chaque bloc avec loupes, scanners et instruments de contrôle qualité, accumulation spectaculaire devant le poste de validation créant un gigantesque embouteillage, un DSI observe la scène depuis une passerelle et comprend que le goulot d’étranglement n’est plus la production mais le contrôle, quelques petits lots de code soigneusement séparés passent facilement sur une deuxième ligne mieux organisée, ambiance réaliste cinématographique haut de gamme, humour visuel discret, métaphore industrielle claire, lumière froide et élégante, grande profondeur, format horizontal 16:9, aucun texte, aucune lettre, aucun chiffre, aucun logo, aucune marque identifiable.