Alexandre Logiciels
Mode automatique selon l’appareil.

Rechercher

Nouveautés

Retrouve ici les dernières publications. L’abonnement aux notifications sera proposé après validation du canal.

Recevoir la newsletter Flux RSS

Articles de blog

GitHub Code Quality : le nouveau chemin GitHub Actions à surveiller

GitHub sépare les exécutions Code Quality dans GitHub Actions. Voici les filtres, rapports et dashboards à vérifier dans ta stack SaaS.

Miniature violette montrant une interface abstraite de flux automatisés avec les voies Code Quality et code scanning.

Ce qui est confirmé

GitHub a séparé le chemin utilisé par GitHub Code Quality dans GitHub Actions. Cette évolution est disponible de façon générale, selon le changelog GitHub du 20 août 2026. Elle ne demande pas de reconfiguration de Code Quality. En revanche, elle peut modifier la lecture de tes rapports, de tes dashboards et de tes filtres automatisés.

Ce qui change dans GitHub Actions

Fait. GitHub indique qu’un chemin de workflow dédié pour les analyses CodeQL de GitHub Code Quality est désormais généralement disponible. Les exécutions d’analyse Code Quality passent par dynamic/github-code-quality/codeql. Elles ne partagent plus le chemin dynamic/github-code-scanning/codeql utilisé auparavant avec le code scanning. La note officielle précise aussi que l’acteur affiché devient github-code-quality.

Fait. Les historiques d’exécution et les rapports d’usage GitHub Actions distinguent maintenant les exécutions GitHub Code Quality de celles du code scanning. C’est le changement visible le plus important pour une équipe qui suit ses jobs dans l’interface GitHub ou dans un reporting exporté. La séparation porte sur l’identification des exécutions, pas sur une nouvelle analyse à activer. GitHub le confirme dans son annonce.

Le sujet paraît technique. Il touche pourtant une brique classique de la stack d’une équipe SaaS: les workflows qui transforment les données GitHub Actions en indicateurs de qualité, de consommation ou de coûts. Si ton équipe classe les runs à partir d’un chemin ou d’un acteur, elle doit vérifier ce classement.

Cette annonce complète les sujets que je suis déjà dans les actualités logiciels et marketing. Elle mérite surtout d’être lue comme une évolution de gouvernance des données de CI, pas comme une promesse de gain de performance ou de sécurité. GitHub ne chiffre ni amélioration de détection ni modification du moteur d’analyse dans cette note.

Les deux identifiants à connaître

Voici le résumé des valeurs citées par GitHub.

| Élément | Avant pour Code Quality | Désormais pour Code Quality | | — | — | — | | Chemin de workflow | dynamic/github-code-scanning/codeql | dynamic/github-code-quality/codeql | | Acteur | github-advanced-security | github-code-quality |

Fait. Ces correspondances sont documentées par GitHub. Le code scanning garde son propre périmètre dans la formulation de l’annonce. Je ne déduis pas de cette publication une modification de ses règles, de ses résultats ou de ses tarifs.

Analyse. Un dashboard qui filtre uniquement dynamic/github-code-scanning/codeql peut désormais séparer involontairement une partie des exécutions qui lui étaient auparavant rattachées. Le risque est un indicateur incomplet, pas nécessairement un échec du workflow. Le même raisonnement s’applique à un script qui repère Code Quality uniquement grâce à l’acteur github-advanced-security.

Ce point est proche d’un principe que j’applique à toute automation: un indicateur n’est utile que si son identifiant résiste aux changements de fournisseur. Quand un outil SaaS change une valeur de catégorisation, le job continue parfois à tourner alors que le reporting devient moins fiable. C’est précisément le type de dépendance qu’il faut documenter avant de conclure qu’une métrique baisse.

Ce que GitHub te demande de vérifier

Fait. GitHub indique que Code Quality ne nécessite pas de reconfiguration et que les dépôts déjà activés continuent d’être analysés. Il ne s’agit donc pas, selon cette source, d’une migration de configuration de Code Quality à lancer dans chaque dépôt. L’annonce officielle est explicite.

Fait. GitHub demande en revanche de mettre à jour les rapports d’usage et de facturation qui filtrent sur dynamic/github-code-scanning/codeql, afin qu’ils prennent également en compte dynamic/github-code-quality/codeql. La société demande aussi de revoir les scripts, dashboards et filtres d’historique qui reconnaissent Code Quality à travers l’acteur github-advanced-security. Ces consignes figurent dans le changelog GitHub.

Concrètement, je ferais une vérification ciblée plutôt qu’une refonte. Commence par rechercher les deux anciennes chaînes dans ton dépôt d’infrastructure, tes scripts de reporting et ta solution de visualisation. Examine aussi les filtres enregistrés dans GitHub Actions, si ton organisation les utilise pour distinguer les runs. Enfin, compare les catégories retenues par ton rapport avec les valeurs de la table ci-dessus.

Analyse. Le bon résultat n’est pas d’obtenir deux lignes partout. Le bon résultat est de décider si tu veux les agréger ou les suivre séparément. Si ton indicateur répond à « combien de ressources attribuons-nous à la qualité du code? », l’agrégation peut être cohérente. Si ton indicateur compare la qualité du code et le code scanning, la séparation peut rendre l’analyse plus lisible.

Pourquoi c’est important

Je te conseille de noter cette décision dans le dépôt qui porte le reporting. Cela évite qu’un futur changement de filtre soit interprété comme une baisse des usages. Pour structurer cette démarche dans un environnement plus large, mon guide pour automatiser son business peut aider à poser un workflow, une source et un contrôle humain, même si le cas présent reste spécifique à GitHub Actions.

Disponibilité annoncée et périmètre connu

Fait. GitHub annonce la disponibilité de GitHub Code Quality sur GitHub Enterprise Cloud et GitHub Team. L’annonce cite également GitHub Enterprise Cloud avec résidence des données. La liste des environnements figure dans la publication GitHub.

Fait. La note renvoie vers la documentation de facturation de GitHub Code Quality. Elle ne donne pas, dans son texte, de montant, de nouvelle grille tarifaire, de quotas, ni de date d’arrêt d’un ancien identifiant. Je préfère donc ne pas transformer cette annonce technique en comparaison de prix. Pour une décision de budget, il faut consulter la documentation de facturation liée par GitHub au moment où tu fais le contrôle.

Ce qui reste inconnu dans la source. GitHub ne précise pas ici la durée de coexistence éventuelle des deux chemins dans les données historiques. La publication ne décrit pas non plus de méthode d’export, de format d’API ou de règle prête à copier. Elle ne permet pas d’affirmer que tous les outils tiers de reporting reconnaîtront automatiquement le nouvel acteur.

Cette limite est importante. Une source officielle confirme le changement annoncé par GitHub. Elle ne valide pas le comportement de ton stack, de tes connecteurs ou de tes règles internes. La vérification doit donc porter sur tes propres filtres et sur la continuité de tes chiffres, sans inventer une anomalie avant de l’avoir observée.

Ce que ça change pour toi

Si tu gères un produit SaaS, un site no-code ou une équipe marketing qui dépend d’un dépôt GitHub, l’impact le plus probable se situe dans l’observabilité. Beaucoup d’équipes utilisent GitHub Actions comme une source de données parmi d’autres. Elles alimentent ensuite un dashboard, un tableur, une alerte ou une automation. La modification d’un libellé technique peut casser le regroupement sans interrompre l’exécution du job.

Analyse. Je séparerais le contrôle en trois questions simples. Première question: ton rapport lit-il le chemin dynamic/github-code-scanning/codeql? Deuxième question: utilise-t-il github-advanced-security pour identifier Code Quality? Troisième question: dois-tu afficher Code Quality et le code scanning dans le même indicateur ou dans deux indicateurs distincts? Les réponses guident le correctif, si un correctif est nécessaire.

Cette méthode évite deux erreurs. La première consiste à modifier un workflow alors que GitHub dit qu’aucune reconfiguration de Code Quality n’est requise. La seconde consiste à ne rien vérifier parce que l’analyse continue dans les dépôts. Dans les deux cas, tu risques de confondre fonctionnement opérationnel et qualité du reporting.

Pour les organisations où GitHub participe au pipeline commercial ou produit, je recommande aussi de relier chaque métrique à sa définition. Ce n’est pas du luxe administratif. C’est la condition pour pouvoir dire d’où vient un chiffre. Le même réflexe s’applique à un CRM, à un outil d’email marketing ou à une automation no-code: une donnée existe, mais son interprétation dépend de la règle qui l’a sélectionnée.

Tu peux aussi consulter l’article sur le suivi des tendances GitHub Code Quality pour replacer ce changement dans un suivi de qualité par dépôt. Pour le contexte technique récent, l’actualité sur CodeQL 2.26.3 et GitHub Actions complète utilement la lecture. Ces liens internes proposent du contexte éditorial. Ils ne remplacent pas la confirmation officielle du changement décrite ici.

Une checklist courte avant de modifier un dashboard

Je garderais cette checklist volontairement limitée:

  • Vérifie si tes filtres contiennent l’ancien chemin dynamic/github-code-scanning/codeql.
  • Vérifie si tes requêtes utilisent l’ancien acteur github-advanced-security pour Code Quality.
  • Ajoute le chemin dynamic/github-code-quality/codeql lorsque ton rapport doit inclure Code Quality, conformément à la consigne de GitHub.
  • Décide et documente si tes rapports doivent agréger ou séparer Code Quality et code scanning.
  • Contrôle la période de comparaison avant et après la modification du filtre.

Fait. Seule la troisième étape découle directement de la demande de mise à jour formulée par GitHub. Les autres étapes sont mon analyse de méthode. Elles servent à éviter de tirer une conclusion sur des données dont la logique de regroupement a changé.

Si tu relies GitHub à des agents IA, regarde aussi mon article sur les plugins d’agents GitHub. Le sujet n’est pas le même. Il rappelle toutefois qu’un pipeline devient plus difficile à auditer quand plusieurs outils modifient, analysent ou résument les mêmes données.

Ce que cela change

Mon avis

Opinion. À mon avis, GitHub fait ici un changement utile pour la lisibilité des historiques et des rapports d’usage. Je ne le traiterais pas comme une actualité à déployer en urgence dans le code. Je le traiterais comme une alerte de maintenance sur les métriques. Si ton équipe facture, pilote ou arbitre à partir de ces dashboards, quelques minutes de vérification valent mieux qu’une interprétation erronée le mois suivant.

Sur les sujets de stack, d’automation et de mesure, je partage aussi des ressources sur mon agence AskOptimize. L’objectif reste le même: relier un outil, une règle de données et une décision opérationnelle, sans confondre signal technique et résultat business.

FAQ

Faut-il reconfigurer GitHub Code Quality après ce changement?

Fait. Non, GitHub indique que Code Quality ne nécessite pas de reconfiguration et que les dépôts activés continuent d’être analysés. Vérifie toutefois tes rapports ou scripts s’ils reposent sur les anciens identifiants. Source: changelog GitHub.

Quel est le nouveau chemin GitHub Actions pour Code Quality?

Fait. GitHub indique dynamic/github-code-quality/codeql pour les analyses CodeQL de GitHub Code Quality. L’ancien chemin cité dans l’annonce est dynamic/github-code-scanning/codeql. Source: GitHub.

Quel acteur apparaît désormais pour GitHub Code Quality?

Fait. L’acteur affiché devient github-code-quality, selon GitHub. L’annonce explique qu’il remplace l’identification de ces runs par github-advanced-security. Source: publication officielle.

Mes rapports de facturation GitHub doivent-ils être mis à jour?

Fait. GitHub demande de mettre à jour les rapports d’usage et de facturation qui filtrent sur l’ancien chemin, afin de prendre aussi en compte le nouveau chemin Code Quality. La nécessité exacte dépend de tes filtres actuels. Source: changelog GitHub.

GitHub Code Quality est-il disponible sur GitHub Team?

Fait. Oui. GitHub cite GitHub Team, GitHub Enterprise Cloud et GitHub Enterprise Cloud avec résidence des données parmi les environnements où GitHub Code Quality est disponible. Source: annonce GitHub.

Information & avertissement

Cet article présente une annonce technique à partir d’une source officielle GitHub datée du 20 août 2026. Il ne remplace pas la documentation de ton environnement, ni une vérification de tes workflows, scripts, dashboards ou rapports de facturation. Aucun lien affilié ni aucune offre commerciale ne sont intégrés dans cet article.

Sources et méthode

Les informations ont été vérifiées à partir des sources ci-dessous.

Les faits confirmés sont distingués des analyses et des limites encore ouvertes.

Sources

  1. github.blog