Dot.Blog

GitHub Code Quality est désormais disponible de manière générale. Le produit combine analyse CodeQL, détection assistée par IA, couverture de tests, quality gates et Copilot Autofix. L’ensemble paraît cohérent, mais ne prouve ni une meilleure maintenabilité ni un retour sur investissement. Pour décider, il faut mesurer le bruit, les défauts réellement évités, le temps de cycle et le coût complet.

Une annonce qui répond à un vrai problème

L’augmentation du volume de code produit avec assistance IA crée davantage de changements à relire. Cela ne signifie pas automatiquement que tout code généré est mauvais, mais la capacité de production peut augmenter plus vite que la capacité de revue.

Le risque dépend de plusieurs facteurs : qualité des tests, maturité de l’équipe, complexité du domaine, ancienneté du patrimoine, architecture du système et autonomie accordée aux agents. Une équipe dotée d’une excellente suite de tests et de règles de conception strictes n’a pas le même profil qu’un projet legacy faiblement couvert.

GitHub positionne Code Quality comme une chaîne intégrée : détecter un problème, proposer une correction, exposer des métriques et éventuellement bloquer la fusion. Cette approche est plus crédible qu’un simple reviewer LLM, car elle ne repose pas sur une seule technique.

Une architecture hybride plutôt qu’un reviewer magique

Le produit combine plusieurs couches distinctes.

La valeur vient de l’orchestration de ces briques. Une analyse sans règle de décision produit des commentaires que l’équipe peut ignorer. Un gate sans calibration bloque inutilement. Un Autofix sans tests peut déplacer le défaut au lieu de le supprimer.

L’approche hybride est donc la bonne direction : déterminisme pour les invariants exprimables, IA pour les signaux plus ambigus, validation humaine pour les décisions contextuelles et tests pour vérifier le comportement.

Le chiffre de 67,3 % ne démontre pas l’efficacité

GitHub affirme que ses propres équipes résolvent 67,3 % des findings avant fusion. Ce chiffre montre que les findings sont utilisés. Il ne démontre pas que le produit réduit les incidents ou la dette technique.

Plusieurs informations manquent :

• quelle proportion des findings était réellement importante ;
• combien auraient été détectés par une revue humaine classique ;
• combien étaient des préférences de style ;
• quel était le taux de faux positifs ;
• combien de correctifs ont introduit une autre régression ;
• quel impact a été observé en production.

Corriger un commentaire n’est pas nécessairement éviter un défaut. Une métrique pertinente doit relier le finding à un résultat : incident évité, temps de correction réduit, dette contenue ou régression empêchée.

Une tarification qui ne s’arrête pas à 10 USD

Le tarif de base annoncé est de 10 USD par committer actif et par mois. GitHub ajoute une facturation pour les fonctions IA et le calcul nécessaire aux analyses CodeQL dans GitHub Actions.

Le coût réel doit donc être calculé ainsi :

Coût mensuel total =
  licences par committer actif
  + consommation des fonctions IA
  + calcul GitHub Actions
  + temps humain de triage
  + coût de maintenance des règles
  - coût estimé des défauts évités

Le dernier terme est difficile à estimer, mais c’est précisément celui qui justifie l’investissement. Un outil qui trouve beaucoup d’anomalies mineures peut coûter plus cher qu’il ne rapporte.

La définition du committer actif mérite également une attention particulière. GitHub considère comme actif un contributeur ayant poussé un commit dans les 90 derniers jours sur un dépôt où Code Quality est activé. L’activation trop large peut donc augmenter rapidement le coût.

Comment l’évaluer sur un patrimoine .NET

Construire un corpus représentatif

Un test sur un dépôt de démonstration propre n’a presque aucune valeur. Il faut utiliser un corpus contenant :

• applications ASP.NET Core récentes ;
• bibliothèques partagées ;
• code legacy ;
• projets WPF ou .NET MAUI lorsque le patrimoine en contient ;
• pull requests ayant introduit des régressions connues ;
• zones à forte complexité cyclomatique ;
• code métier riche en invariants.

Le corpus doit permettre d’observer les catégories de problèmes que l’organisation rencontre réellement.

Classer les findings

Chaque finding devrait être classé dans une catégorie stable :

1. défaut réel et prioritaire ;
2. amélioration utile mais non bloquante ;
3. préférence de style ;
4. faux positif ;
5. impossible à trancher sans expertise métier.

Sans cette classification, le nombre de findings n’est qu’une métrique de volume.

Mesurer avant d’activer les gates

Le mode d’évaluation des rulesets doit précéder tout blocage. Il faut observer pendant plusieurs semaines :

• combien de pull requests auraient été bloquées ;
• pour quelles raisons ;
• combien de blocages auraient été justifiés ;
• combien auraient ralenti inutilement la livraison ;
• quels dépôts produisent le plus de bruit.

Un seuil de couverture doit également être contextualisé. Une couverture de 80 % peut masquer l’absence totale de tests sur les chemins critiques, tandis qu’une couverture plus faible peut être suffisante sur du code d’infrastructure simple.

Traiter les Autofix comme du code non fiable

Un correctif généré doit passer exactement les mêmes contrôles qu’un patch humain : compilation, tests unitaires, tests d’intégration, analyse statique et revue.

Lorsque les invariants sont complexes, il peut être utile d’ajouter des tests de propriétés ou des tests de mutation. L’origine IA du correctif ne change pas le contrat de qualité. Elle augmente plutôt le besoin de vérification, car un patch peut être syntaxiquement parfait tout en étant sémantiquement faux.

Une grille de décision utile

Ces seuils ne sont pas universels. Ils servent à forcer une décision fondée sur des observations plutôt que sur la démonstration commerciale.

Ce que GitHub Code Quality ne résout pas

Le produit ne connaît pas automatiquement les invariants métier. Il ne remplace pas une stratégie de test. Il ne prouve pas que la couverture mesure les bons comportements. Il ne corrige pas une architecture fortement couplée. Il ne garantit pas qu’un code fusionné plus vite soit plus maintenable.

Il ne faut pas davantage supposer que la détection assistée par IA est toujours supérieure aux règles déterministes. Les deux couches couvrent des classes de problèmes différentes. Une règle précise et reproductible reste préférable lorsqu’elle peut exprimer le défaut.

Prise de position

GitHub Code Quality est plus crédible qu’un simple « reviewer IA » précisément parce qu’il associe analyses déterministes, métriques, gates et suggestions. Mais il ne faut pas acheter la promesse avant d’avoir construit le protocole de mesure.

La bonne question n’est pas : « l’outil trouve-t-il des problèmes ? » Tous les analyseurs en trouvent. La question est : « trouve-t-il assez de problèmes importants, avec assez peu de bruit, pour réduire le coût et le risque du cycle de développement ? »

Pour un patrimoine .NET important, une expérimentation limitée à quelques dépôts représentatifs est rationnelle. Une activation globale immédiate ne l’est pas.

Conclusion

La disponibilité générale de GitHub Code Quality confirme une évolution durable : l’IA de développement ne sera plus évaluée uniquement sur la quantité de code produite, mais sur les mécanismes capables d’en contenir les effets indésirables.

L’approche hybride est techniquement saine. Son efficacité reste à démontrer organisation par organisation, avec des mesures sur la précision, le coût, le temps de cycle et les défauts réellement évités.

Que ferez-vous de ces nouveaux outils ? Votre entreprise est-elle prête à payer de plus en plus d'abonnements "IA" sans avoir d'outils de mesure de leur réelle efficacité sur la productivité et la qualité des produits ?

A vous de me le dire,

Stay Tuned !