Code généré par IA : mesurer la qualité et le coût total

GitHub Code Quality est disponible depuis le 20 juillet 2026 pour les organisations Enterprise Cloud et Team. Le produit combine des analyses déterministes issues de CodeQL, des détections assistées par IA, des suggestions de correction, des métriques de couverture et des règles de qualité avant fusion.

La tarification commence à 10 dollars par active committer et par mois. GitHub définit cet active committer comme une personne ayant poussé au moins un commit au cours des 90 derniers jours sur un dépôt où Code Quality est activé. Les fonctions assistées par IA sont facturées à l’usage. L’exécution des analyses CodeQL mobilise également du calcul. Pour les organisations qui utilisaient la version publique de test, la facturation a commencé automatiquement lors du passage en disponibilité générale.

Le signal important ne concerne pas seulement GitHub. Plus une équipe produit de code avec des assistants, plus elle doit rendre visibles les coûts de revue, de validation et de maintenance qui apparaissent après la génération.

GitHub expose désormais des métriques d’adoption, d’engagement, d’acceptation, de lignes de code et de cycle de vie des pull requests. Les rapports peuvent descendre au niveau du dépôt pour certaines activités de Copilot coding agent et de Copilot code review.

Ces données permettent de savoir où l’outil est utilisé. Elles ne suffisent pas à conclure que l’équipe livre mieux. Un taux d’acceptation élevé peut signaler des suggestions pertinentes. Il peut aussi refléter des changements faciles ou une revue insuffisante. Davantage de pull requests peut réduire la taille des lots ou créer plus de coordination. La métrique doit toujours être reliée à une conséquence de livraison.

La documentation GitHub recommande elle-même de chercher des tendances croisées plutôt que de piloter sur un seul nombre. Certaines mesures dépendent aussi de la télémétrie disponible dans les environnements de développement. L’absence de donnée n’est donc pas automatiquement une absence d’usage.

Le rapport DORA 2025 décrit l’IA comme un amplificateur des forces et des faiblesses d’une organisation. Une équipe dotée de tests rapides, de responsabilités claires et d’un flux de revue sain peut absorber davantage de changements. Une équipe déjà ralentie par une CI instable ou une dette diffuse risque surtout de produire plus vite le prochain goulot d’étranglement.

Avant de comparer des outils, il faut donc mesurer le système qui recevra leur production. Sans baseline, une hausse du volume ressemble à un gain alors qu’elle peut déplacer le travail vers la revue, la correction ou l’exploitation.

Le bon niveau d’analyse est le dépôt ou un groupe de dépôts comparables. Une moyenne globale mélange les produits, les langages, les niveaux de risque et la qualité des tests. Le tableau suivant relie chaque signal à une décision concrète.

Choisis quelques dépôts représentatifs plutôt que les plus simples. Relève les six métriques sur une période antérieure, puis documente les événements qui faussent la comparaison : migration, incident majeur, changement d’équipe ou refonte de la CI.

Le pilote doit préciser les outils autorisés, les données accessibles, les règles de revue et les critères d’arrêt. Il doit aussi conserver un groupe ou une période de comparaison crédible. Sans ce cadre, toute amélioration sera facilement attribuée à l’IA même si elle vient d’une formation, d’un changement de processus ou d’un lot exceptionnellement simple.

• Définir les dépôts, équipes et types de tâches inclus
• Capturer la baseline avant de modifier le workflow
• Fixer les contrôles qui restent obligatoires
• Séparer les métriques d’usage des métriques de livraison
• Documenter les coûts directs et le temps humain
• Écrire les critères pour étendre, corriger ou arrêter le pilote

Le nombre de lignes générées récompense le volume alors qu’un bon changement peut supprimer du code. Le nombre de pull requests ignore leur taille, leur utilité et le travail de revue. Le taux d’acceptation mesure une interaction avec l’outil, pas la valeur livrée au client.

Ces signaux restent utiles pour comprendre l’adoption. Ils deviennent trompeurs lorsqu’ils sont présentés seuls comme une preuve de productivité ou un retour sur investissement.

Le suivi doit montrer trois couches séparées. La première décrit l’adoption : utilisateurs actifs, fonctions utilisées et dépôts concernés. La deuxième décrit l’ingénierie : cycle, revue, CI, défauts et maintenabilité. La troisième décrit l’économie : licences, usages, calcul et temps humain.

À chaque revue, une décision est attendue par dépôt : continuer, étendre, corriger le workflow ou retirer l’outil. Un dashboard qui accumule des courbes sans changer une décision devient lui-même un coût de transformation.

Une transformation Dev IA ne commence pas par l’achat de sièges. Elle commence par une cartographie des dépôts, des workflows, des contrôles et des coûts. Le livrable utile contient la baseline, les cas d’usage prioritaires, les règles de sécurité, le plan de pilote et le tableau de décision.

Chez MAX, la mesure est définie avant le déploiement. Les outils viennent ensuite, lorsqu’un dépôt, une tâche et un critère de réussite sont suffisamment précis pour produire une comparaison exploitable.