Pourquoi Google a conçu PageBreak
La recherche de failles avec l’IA se heurte à un problème concret : un modèle peut expliquer de façon convaincante pourquoi un extrait de code lui paraît dangereux sans prouver qu’un attaquant pourrait en tirer parti. Une équipe de sécurité doit ensuite vérifier manuellement chaque piste. Si les signalements sont nombreux et peu fiables, le gain promis par l’automatisation disparaît.
Google dit avoir lancé un pilote PageBreak en novembre 2025, puis transformé le projet en programme plus complet en janvier 2026. L’outil est utilisé par son équipe Product Security sur les applications Web appartenant à l’entreprise. Il bénéficie donc d’un accès au code et à des environnements de test que n’aurait pas un chercheur extérieur. Sa présentation publique date du 24 septembre 2026 : il ne s’agit pas d’un lancement commercial ce jour-là. Source : Google.
Ce contexte est essentiel pour comprendre les résultats. PageBreak n’est pas simplement un chatbot auquel on demande de relire un dépôt. C’est un agent placé dans un ensemble de scanners, de signaux de sécurité et d’outils d’exécution déjà utilisés chez Google. L’entreprise précise que la majorité de ses usages reposent sur des modèles Gemini, tout en indiquant que l’architecture peut accueillir d’autres modèles.
Comment une suspicion devient une preuve
Le modèle explore une surface d’attaque et formule une hypothèse. PageBreak transmet ensuite cette hypothèse à un validateur spécialisé, dont la logique de contrôle n’est pas écrite par l’IA. Ce validateur exécute un test concret sur l’application en fonctionnement. La conclusion dépend du comportement observé, plutôt que de la seule formulation du modèle. Source : architecture décrite par Google.
Pour une faille XSS, par exemple, un test peut injecter un contenu JavaScript spécifique, charger la page dans un environnement contrôlé et observer si ce code s’exécute réellement. Cela distingue un champ qui accepte du texte suspect d’un scénario où le navigateur exécute ce texte dans le contexte du site. La distinction est décisive : le premier cas est une piste, le second peut devenir une vulnérabilité exploitable.
Google décrit aussi des validateurs pour l’injection SQL, la traversée de chemins, l’exécution de code à distance et les requêtes déclenchées vers des services internes. Chaque famille exige un test différent : observer une réponse ou un délai de base de données, vérifier la lecture d’un fichier, constater la création d’une ressource ou détecter une requête réseau. Ces exemples décrivent les capacités de vérification de l’outil ; Google ne donne pas un total de failles confirmées pour chacune de ces catégories.
Ce que signifie le chiffre de 500 failles XSS
Google affirme que PageBreak a trouvé plus de 500 vulnérabilités XSS sur ses propres applications Web, y compris sur des domaines sensibles. Une XSS permet, dans certaines conditions, de faire exécuter du code contrôlé par un tiers dans le navigateur d’une personne visitant un site de confiance. Son impact dépend de la page concernée, des protections en place et des droits de la victime. Le nombre de failles ne renseigne donc pas, à lui seul, sur leur gravité individuelle. Source : Google.
Le taux de faux positifs « proche de zéro » annoncé par Google concerne les alertes que PageBreak a pu vérifier. Il ne signifie pas que le système trouve toutes les failles, ni que toutes ses hypothèses initiales sont exactes. Google reconnaît au contraire un risque de faux négatifs : si aucun validateur n’est capable de confirmer un scénario complexe, celui-ci peut rester sans preuve automatique.
L’équipe conserve les pistes non vérifiées pour améliorer les recherches ultérieures ou développer de nouveaux validateurs, mais indique ne pas les transmettre telles quelles aux équipes produit. Cette séparation protège les développeurs contre le bruit des hypothèses incertaines. Elle réduit aussi la visibilité immédiate sur les failles pour lesquelles l’outil manque encore de moyens de test.
Un autre résultat à lire avec précaution
Google a confronté PageBreak à des applications construites avec ses cadres Web dits « à haute assurance », conçus pour limiter les erreurs de sécurité par défaut. Au 4 septembre 2026, l’agent n’y avait trouvé que deux XSS parmi des centaines d’applications, selon l’entreprise. Google précise qu’elles concernaient des applications internes ou des points d’accès de débogage présentant des lacunes de protection. Source : Google.
Ce résultat suggère qu’une architecture sécurisée dès la conception peut réduire les occasions de trouver des failles, même face à un agent offensif. Il ne prouve pas que ces applications soient invulnérables : PageBreak n’a testé que les scénarios accessibles à ses méthodes et validateurs. L’intérêt de cette comparaison est moins d’opposer l’agent au développement sécurisé que de montrer leur complémentarité.
Pourquoi les résultats de Google ne se transposent pas partout
Le contexte de Google offre à PageBreak plusieurs avantages particuliers. L’entreprise possède un vaste dépôt de code où l’agent peut suivre un chemin d’exécution entre services. Elle exploite des signaux tirés du trafic HTTP pour relier des requêtes à des portions de code. Elle dispose enfin de scanners capables d’accéder à des applications internes ou protégées par une authentification. Source : Google.
Une entreprise qui n’a ni ces données, ni ces droits, ni cette infrastructure ne peut pas supposer qu’un agent équivalent obtiendrait les mêmes résultats. Il faudrait connaître la durée des analyses, le coût du calcul, la part des alertes confirmées manuellement et le nombre de failles manquées pour comparer PageBreak à d’autres approches. Google ne publie pas, dans cette présentation, un protocole permettant de reproduire indépendamment l’ensemble de ses chiffres.
Autre limite : la vérification automatique doit être sûre pour l’environnement testé. Déclencher un scénario d’attaque contre une application en production exige des autorisations, des garde-fous et une méthode qui évite de modifier des données réelles. La publication de Google montre des exemples de validateurs, mais elle ne constitue pas un mode d’emploi universel pour tester n’importe quel site.
Ce que cette annonce change pour les équipes de sécurité
Le principe le plus utile est simple : ne pas confondre une hypothèse crédible avec une faille démontrée. Un agent peut aider à explorer beaucoup de pistes ; un système de validation peut réserver l’attention humaine aux cas les plus solides. Cela peut accélérer la correction et rendre les rapports plus utiles aux développeurs, à condition que les tests couvrent réellement les risques prioritaires.
Google évoque aussi une coopération avec d’autres initiatives internes, dont CodeMender, pour proposer à terme des correctifs. Cette perspective va au-delà de la détection : trouver, vérifier, proposer une réparation puis faire valider celle-ci. À la date de l’article, la présentation de PageBreak ne démontre toutefois pas qu’une telle chaîne corrige automatiquement toutes les failles découvertes.
Prix, disponibilité et points à suivre
PageBreak reste un projet interne de Google. Aucune interface publique, aucun tarif et aucune date d’ouverture aux entreprises ne sont annoncés. Pour un lecteur français, l’information concerne donc surtout l’évolution des méthodes de cybersécurité, pas l’arrivée d’un nouvel outil à acheter ou à installer.
Les prochaines données utiles seraient une mesure externe du taux de détection, une répartition par gravité des failles confirmées, les coûts d’exploitation et des exemples montrant où les validateurs échouent. Elles permettraient de juger plus précisément la portée du projet au-delà des applications de Google.
Notre analyse
PageBreak illustre une étape intéressante dans l’usage des agents IA : la valeur ne réside pas seulement dans leur capacité à imaginer une faille, mais dans leur capacité à chercher une preuve observable. L’annonce est crédible comme retour d’expérience d’une grande équipe de sécurité, avec des détails techniques sur la validation. Elle reste aussi une communication de l’entreprise sur son propre système. Le bon niveau de lecture consiste à retenir la méthode, tout en attribuant à Google ses chiffres et ses performances annoncées.