Les agents Cogent sous GPT-6.1 Sol réduisent de 75% le temps de correction des vulnérabilités

Quiconque a travaillé dans la sécurité le sait : détecter une vulnérabilité, c’est seulement la moitié du travail. Les scanners remontent chaque jour des centaines de résultats, puis commence la partie la plus fastidieuse : déterminer qui est responsable du service, ce qui en dépend, si une bibliothèque peut être mise à jour sans interruption et qui doit donner son accord. Selon Cogent, c’est précisément à cette étape que tout se bloque. La start-up construit pour les grandes entreprises des « usines de cyberdéfense » : des ensembles d’agents d’IA qui prennent en charge tout le parcours, de l’investigation à la correction vérifiée.

D’abord le contexte, ensuite les agents

Le système repose sur le Context Engine. Pour chaque client, celui-ci maintient un graphe de connaissances regroupant les actifs, les vulnérabilités, les comptes, les responsables et les dépendances. Des agents en arrière-plan recoupent en permanence les données des outils de sécurité pour que les agents chargés des investigations et des corrections disposent de la même vision de l’environnement. Le CTO Geng Sng parle de « memory harness pour l’entreprise » : un dispositif de mémoire qui évite de redécouvrir le fonctionnement de l’infrastructure à chaque nouvelle tâche. Avec, à la clé, moins de latence, moins de dépenses d’inférence et moins de divergences dans les réponses.

Un exemple simple : des failles critiques PHP2Shell sont divulguées dans PHP. Au lieu de rechercher manuellement où l’entreprise utilise PHP, les agents parcourent le graphe : ils repèrent les systèmes touchés, évaluent leur accessibilité pour un attaquant et établissent un plan tenant compte des dépendances applicatives et des contraintes opérationnelles. Ils appliquent ensuite les corrections selon le processus convenu avec le client et vérifient que la faille est effectivement corrigée. Pour l’investigation et la planification, Cogent utilise GPT-6.1 Sol et GPT-6 Astra.

Le droit d’agir dans une couche distincte

Pour les ingénieurs, le point le plus intéressant est la manière dont Cogent traite le risque qu’un agent provoque une panne. Les modifications autorisées et les exigences d’approbation sont décrites dans les Agent Policies. Le moteur TRACE vérifie chaque appel d’outil au regard de ces règles avant son exécution, au moyen de contrôles déterministes qui ne nécessitent aucun appel supplémentaire à un modèle. Au-dessus, l’Agent Gateway vérifie indépendamment les autorisations, tandis que les tâches risquées s’exécutent dans des bacs à sable isolés. Le client choisit son mode de fonctionnement : investigation seule, modifications soumises à une approbation humaine ou correction autonome limitée.

Le principe mérite d’être retenu : la sécurité d’un agent ne doit pas dépendre de la bonne compréhension d’une instruction par le modèle. Les règles résident dans le code, pas dans le prompt.

Économie : des modèles différents selon les tâches

Cogent répartit le travail selon sa complexité. GPT-6.1 Sol prend en charge l’exécution générale et les investigations exigeantes, tandis que GPT-5.6 s’occupe des tâches courantes de gestion des vulnérabilités qui ne demandent pas de raisonnement approfondi. Lorsqu’on déploie des « essaims » d’agents, le prix des tokens devient rapidement le premier poste de dépenses, et ce routage cesse d’être une simple optimisation pour devenir une nécessité.

Cogent affirme également avoir eu moins de code d’intégration à écrire grâce à l’API d’OpenAI : la plateforme prend largement en charge le routage des requêtes et l’orchestration des agents. La plupart des ingénieurs écrivent leur code dans Codex, car des outils prêts à l’emploi y sont déjà disponibles. Pour ses propres recherches, l’équipe utilise les programmes Trusted Access for Cyber et Daybreak, notamment le niveau Daybreak Red, qui propose des modèles spécialisés dans l’analyse offensive autorisée. L’objectif est de comprendre comment des vulnérabilités peuvent être enchaînées à travers les comptes, les ressources et les restrictions réseau.

Ce qu’il faut prendre avec du recul

Il s’agit d’un cas client publié sur le blog d’OpenAI, pas d’une étude indépendante. Les chiffres — une réduction de 75% du délai moyen de correction des vulnérabilités critiques chez un constructeur automobile du Fortune 1000 et une capacité de triage multipliée par 5 chez un intégrateur informatique du Fortune 500 — sont communiqués par Cogent, sans méthodologie ni données de référence. Les clients ne sont pas nommés, à l’exception de MarketAxess, qui évoque la hiérarchisation des risques sans fournir de métriques.

Les affirmations concernant la baisse des hallucinations et un coût plus avantageux que chez les autres fournisseurs ne sont pas non plus étayées par des benchmarks. La correction entièrement autonome reste au programme : il s’agit de passer de simples ajustements de configuration à des scénarios en plusieurs étapes touchant différents systèmes.

Ce qu’on peut appliquer en pratique

Si vous développez des agents pour l’infrastructure, le DevOps ou la sécurité, trois enseignements se dégagent de ce cas. Premier point : investissez dans la couche de contexte — un graphe des actifs, des responsables et des dépendances apporte davantage aux agents qu’un changement de modèle. Deuxième point : implémentez les politiques et les autorisations dans du code déterministe, en dehors du modèle, et isolez les actions risquées. Troisième point : prévoyez dès le départ le routage entre modèles, sous peine de voir la facture des agents vous réserver une mauvaise surprise. Quant aux chiffres d’efficacité sans vérification indépendante, mieux vaut pour l’instant les considérer comme du marketing.