GitHub branche son scanner IA de failles sur les pull requests, pilotable par API

Si tu gères du code sur GitHub, un réglage qui demandait des clics dans dix dépôts différents se pilote désormais en une requête. Ce jeudi 10 septembre au soir, GitHub a ouvert en aperçu public deux API REST pour activer ou couper le scan IA des pull requests, la fonctionnalité qui utilise un moteur d'intelligence artificielle pour repérer des failles de sécurité dans les modifications de code. Fini la configuration manuelle dépôt par dépôt dans l'interface : les organisations peuvent désormais déployer ce balayage automatique à l'échelle, par script.

L'annonce figure sur le changelog officiel de GitHub. Concrètement, deux points d'entrée API apparaissent : un au niveau de l'organisation, un au niveau de chaque dépôt, pour lire et modifier l'état d'activation du scan IA. La fonctionnalité reste en aperçu public, donc susceptible d'évoluer, et concerne uniquement github.com : les serveurs GitHub Enterprise Server, auto-hébergés, ne sont pas concernés.

Pourquoi c'est utile : quand une équipe applique une règle de sécurité, elle veut l'appliquer partout d'un coup, pas cocher quarante cases à la main. C'est exactement le vide que ces API comblent.

Une fonction née en juillet, un pilotage qui restait manuel

Le scan IA des pull requests, ou AI Scan dans le vocabulaire de GitHub, complète le moteur historique CodeQL, l'analyse statique de GitHub qui traque les vulnérabilités connues dans un ensemble de langages précis. Là où CodeQL s'arrête, par exemple sur du PHP, du Shell, des fichiers Terraform ou des Dockerfiles, le scan IA prend le relais : il examine les modifications d'une pull request, la demande d'intégration de code qui attend une relecture, et y signale des problèmes comme des injections de chaînes, une cryptographie trop faible ou un contrôle d'accès mal verrouillé.

La documentation officielle précise le périmètre. Les résultats apparaissent directement dans la pull request, étiquetés d'un badge AI pour les distinguer des alertes CodeQL. Ils sont consultatifs : ils ne bloquent jamais la fusion du code, contrairement à une règle de protection stricte. Et comme tout jugement produit par une IA, ils peuvent contenir des faux positifs, ce que GitHub reconnaît explicitement en intégrant un bouton de retour au signalement.

Ce qui change aujourd'hui

Jusqu'ici, activer ce scan relevait du point et clic : un administrateur devait se rendre dans les réglages de sécurité de chaque dépôt, ou dans les réglages globaux de son organisation, et activer l'option à la main. Pour un garage numérique avec trois dépôts, la manip' passe. Pour une entreprise avec trois cents dépôts, elle devient un chantier.

GitHub avait annoncé la fonctionnalité elle-même en juillet sur son forum communautaire. Ce qui arrive aujourd'hui, c'est le pilotage programmatique : les deux nouvelles API permettent de lire et d'écrire l'état d'activation, au niveau organisation via /orgs/{org}/code-scanning/ai-scan, au niveau dépôt via /repos/{owner}/{repo}/code-scanning/ai-scan. Une équipe peut donc écrire un petit script qui active le scan IA partout d'un coup, l'inclure dans son outillage interne, ou l'intégrer à ses vérifications de conformité.

Règle importante à connaître avant de scripter quoi que ce soit : un dépôt ne peut pas réactiver ce que l'organisation a coupé. La hiérarchie des réglages reste strictement descendante.

La chaîne d'activation : entreprise d'abord

La documentation de GitHub détaille une chaîne d'autorisation à trois niveaux. Au sommet, l'administrateur d'entreprise doit d'abord autoriser la fonctionnalité : elle est interdite par défaut à ce niveau. Ensuite, l'administrateur d'organisation l'active pour l'ensemble de ses dépôts, ou la laisse disponible. Enfin, chaque dépôt hérite du réglage et peut l'ajuster, mais uniquement dans le sens de la restriction.

Schéma explicatif réalisé par la rédaction d'après la documentation officielle de GitHub.

Cette logique descendante ne surprendra personne : c'est le modèle classique des politiques de sécurité en entreprise. Elle évite qu'un projet isolé réactive tout seul un scan que la direction de la sécurité a volontairement désactivé, par exemple pour maîtriser la facturation.

Côté limites, rappelons que tout cela reste un aperçu public : les catégories de détection et les langages couverts peuvent évoluer, et les résultats ne peuvent pas encore servir de critère bloquant dans les règles de fusion.

Ce que ça coûte, et ce que ça ne fait pas

Il faut un abonnement GitHub Advanced Security pour y toucher. C'est la gamme payante de sécurité de GitHub, réservée aux organisations. La fonctionnalité exige en plus une licence GitHub Copilot, et chaque analyse consomme des crédits IA facturés à l'usage : le scan ne tourne que lorsqu'une pull request est créée ou reçoit un nouveau commit, sans coût caché en arrière-plan.

Autre point à garder en tête : ce scan analyse uniquement les modifications en cours dans une pull request, jamais un dépôt entier. Il ne remplace donc pas une revue de sécurité complète du code existant, et ses conclusions sont des suggestions, pas des verdicts. Les catégories couvertes vont de l'injection de chaînes à la falsification de requête côté serveur, en passant par l'exposition de données sensibles et les risques de chaîne d'approvisionnement.

Pour qui, vraiment ?

Si tu es développeur indépendant ou petite équipe sans abonnement Advanced Security, cette annonce ne change rien à ton quotidien : la porte reste payante. En revanche, si tu bosses dans une organisation déjà équipée, la nouveauté est bien réelle : ce qui demandait une campagne de clics devient une ligne de script, et la sécurité rattrape le rythme des dépôts qui se créent chaque semaine.

GitHub a déjà durci ses garde-fous cette semaine en bloquant les pull requests qui exposent tes secrets. Le balayage IA s'inscrit dans la même logique : déplacer la détection le plus tôt possible, avant que le code ne parte en production.

Pour les organisations françaises, l'angle est double : automatiser la détection de failles sans ajouter un outil externe, et garder la main sur les coûts puisque la facturation suit l'usage réel. L'aperçu public venant d'ouvrir, les retours des premières équipes façonneront la version finale. Si le sujet te concerne, le plus simple reste de demander à ton administrateur d'entreprise s'il a déjà activé l'option : la réponse est peut-être à une requête API près.

Sources

GitHub Changelog : l'annonce officielle des API REST de gestion du scan IA des pull requests, en aperçu public.

GitHub Docs : la documentation des détections de sécurité assistées par IA (langages, catégories, licences, facturation).

GitHub Community : la discussion d'annonce de juillet 2026, avec le détail du fonctionnement et des prérequis.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.