Cloudflare laisse l’IA chercher les failles, sans lui confier le correctif

10 septembre 2026 à 22:30|Auteur: Équipe éditoriale de QUASA|5 min de lecture| 3

Cloudflare a ouvert le 3 septembre 2026 l’accès anticipé à Vulnerability Discovery and Remediation, un service sur invitation intégré à Managed Defense pour certains clients Enterprise, selon son communiqué du 3 septembre. Le dispositif associe les modèles Daybreak d’OpenAI au contexte de trafic et de sécurité de Cloudflare, sans leur donner le pouvoir d’appliquer un correctif logiciel ou une règle de filtrage.

GPT-5.6 Cyber intervient dans la reconnaissance, la recherche et la validation sur les bases de code dont l’examen a été autorisé. Le modèle peut contribuer à préparer un patch et une mesure de protection, mais le workflow automatise surtout l’enquête, la vérification et la présentation des propositions : la modification durable de l’application reste entre les mains du client.

Le moteur reste chez Cloudflare, l’inférence part chez OpenAI

Le code autorisé est traité chez Cloudflare, tandis que l’inférence a lieu sur les serveurs d’OpenAI avant le retour de la réponse.

La chaîne commence sur l’infrastructure de Cloudflare. Pour une application Workers, le service récupère la version source la plus récente et les routes configurées ; il constitue aussi un instantané des routes actives, du trafic, des événements de sécurité et des protections WAF concernées. Dans le cas d’une application mandataire, l’analyse demeure limitée au code que le client a expressément autorisé.

Le flux peut être résumé ainsi :

Cloudflare rassemble le code autorisé et le contexte pertinent provenant de Web Assets, du WAF et, lorsqu’ils sont disponibles, des événements Workers Trace accessibles par Logpush.
Le moteur d’enquête exécuté chez Cloudflare relie les chemins des requêtes aux portions du code qui les traitent.
Le contexte nécessaire à chaque requête de modèle part de Workers, traverse Cloudflare AI Gateway et atteint les modèles Daybreak sur les serveurs d’OpenAI.
Les réponses reviennent au moteur de Cloudflare, où le workflow poursuit la corroboration et les contrôles extérieurs au modèle.
Les propositions validées sont préparées pour examen, sans modifier directement l’environnement du client.

La description technique du flux précise qu’aucune inférence ne s’exécute à la périphérie de Cloudflare. Avant que le contexte nécessaire atteigne OpenAI, le service écarte les éléments inutiles et applique les contrôles de masquage configurés pour l’engagement ; le code source, les journaux et les métadonnées de requêtes sont traités comme des éléments à examiner, non comme des instructions.

Le trafic sert à classer les failles, pas à les prouver

Cloudflare relie une route active aux lignes de code concernées et exige une preuve dans le code avant de classer la faille.

Le processus commence par une cartographie entre les routes et le code, puis dirige les agents de recherche vers les sections concernées. La validation examine ensuite les découvertes et les mesures proposées. GPT-5.6 Cyber participe à chacune de ces étapes, mais ses sorties restent intégrées à un moteur d’enquête plus large.

Le contexte réseau sert à orienter et à hiérarchiser la recherche. Une route très fréquentée ou récemment visée par des requêtes suspectes peut recevoir davantage d’attention, mais ces signaux ne suffisent pas à établir qu’une vulnérabilité existe. Chaque signalement doit être corroboré par un élément présent dans le code source.

L’évaluation initiale du risque repose donc sur le code. Elle peut être relevée lorsque le point d’entrée concerné reçoit beaucoup de trafic ou montre des signes de sondage hostile. Par rapport à une analyse statique isolée, le service cherche ainsi à déterminer si le code vulnérable est accessible en production et si une protection déjà active réduit son exposition.

Le patch et la règle WAF répondent à deux problèmes distincts

Une règle WAF réduit temporairement l’exposition, tandis que le correctif de code reste soumis à la décision des ingénieurs.

Le terme « remédiation » recouvre d’abord un correctif du code source, généré sous forme de proposition. Chaque patch doit passer des contrôles exécutés hors du modèle, puis être validé par l’équipe de Cloudflare avant sa présentation au client. Si un contrôle échoue ou si le résultat demeure ambigu, le workflow s’interrompt avant cette présentation et réserve la sortie au diagnostic.

Le second résultat possible est une règle WAF personnalisée, destinée à réduire temporairement l’exposition. Elle est délimitée autour de la méthode HTTP, du chemin et des autres caractéristiques nécessaires pour atteindre le code vulnérable. Aucune règle n’est proposée lorsque le motif de route ne contient que des variables et des jokers, car le lien avec les requêtes à bloquer ne peut alors être circonscrit assez prudemment.

Lorsque le client a préalablement autorisé Vulnerability Discovery and Remediation à défendre la zone concernée, Cloudflare peut déployer la règle validée à sa périphérie. Cette autorisation ne donne aucun pouvoir d’exécution au modèle et ne transforme pas le filtrage en correction logicielle : la règle intercepte certaines requêtes, tandis que la faiblesse demeure dans le code jusqu’à ce que l’équipe du client teste, accepte et déploie le patch.

L’accès reste limité et son efficacité globale n’est pas documentée

Le service n’est pas disponible de manière générale. Chaque engagement d’accès anticipé débute avec une application choisie par le client, et l’enquête est qualifiée de semi-automatisée. Le client examine chaque résultat avant de décider de tester ou de déployer un changement.

Le compte rendu de SiliconANGLE relève qu’aucun tarif ni calendrier de disponibilité générale n’a été communiqué. Cloudflare n’a pas davantage publié de résultats agrégés permettant d’évaluer le taux de faux positifs, la part des patchs acceptés ou le nombre de corrections finalement déployées.

À ce stade, la capacité documentée est donc plus étroite qu’une réparation autonome. L’IA explore le périmètre autorisé et formule des propositions ; Cloudflare fournit le contexte réseau, contrôle les sorties et peut activer une protection WAF préautorisée ; le propriétaire de l’application conserve la décision sur le correctif durable. Les prochaines informations attendues concernent l’élargissement de l’accès et des données mesurables sur les résultats du service.