Le VOC n'existe pas.

Après avoir écrit que le SOC était mort, j'aurais pu m'arrêter là.

Mais il y a un autre sujet qui mérite qu'on lui dise la vérité en face, un sujet sur lequel l'industrie de la cybersécurité s'est collectivement raconté une belle histoire depuis quelques années. Et moi parmi les premiers, sans doute.

Le VOC.

Le Vulnerability Operations Center.

Pour certains, c'est le grand successeur annoncé du SOC. Pour d'autres, c'est le nouveau standard de la gestion des vulnérabilités, la réponse moderne à une surface d'attaque qui explose, c'est le nouveau service cyber indispensable qu'il faut avoir, avant toute autre chose.

Mais le VOC n'est en fait qu'un service de vulnerability assessment avec un beau logo et une plaquette commerciale réécrite.

Ce n'est évidemment pas un jugement sur les équipes qui font ce travail. C'est un constat sur un concept qui promet ce qu'il ne tient presque jamais.

Le "O" de VOC ne veut rien dire.

Commençons par les fondamentaux. Un Operations Center, qu'il soit dédié à la sécurité, au réseau, ou à la production industrielle, implique une boucle opérationnelle complète. On observe, on analyse, on décide, on agit, on vérifie. C'est le cycle. C'est ce qui distingue un opérateur d'un observateur.

Dans cette logique, un Vulnerability Operations Center devrait couvrir l'intégralité du cycle de vie d'une vulnérabilité : la découverte, l'évaluation, la priorisation, la remédiation, le patch management, et la vérification que la vulnérabilité est effectivement corrigée.

Posons-nous une question simple : combien de services qui se revendiquent VOC font réellement du patch management ?

La réponse, dans l'écrasante majorité des cas, est : aucun.

Ce que font ces services, c'est scanner. Collecter. Scorer. Puis, produire des rapports, souvent volumineux, toujours en retard sur la réalité de la production. Ils livrent une liste de vulnérabilités, priorisée selon un score CVSS ou une heuristique propriétaire, et s'arrêtent là. La remédiation ? C'est l'affaire du client. Les équipes IT internes. L'intégrateur. Quelqu'un d'autre.

Un service qui observe les risques sans les traiter n'est pas un opérateur. C'est un cabinet de diagnostic qui refuse de prescrire.

Comment le marché s'est laissé embarquer

Pour comprendre comment on en est arrivé là, il faut retracer la mécanique de ce rebaptême collectif.

D'un côté, les MSSP ont, légitimement et naturellement, cherché à élargir leur portfolio au-delà du SOC, perçu à juste titre comme de plus en plus commoditisé. La gestion des vulnérabilités était un terrain adjacent, avec des marges potentiellement meilleures et une demande réglementaire croissante portée par des référentiels comme NIS, DORA, PCI-DSS, etc. Ils ont pris leurs services de VA existants, ajouté une couche de reporting contextualisé, et sont allés au marché avec un nouveau nom.

De l'autre côté, les éditeurs de scanners de vulnérabilités, qui avaient construit des produits solides sur la découverte et le scoring, ont cherché à monter en valeur. Ils ont développé des portails de suivi, des tableaux de bord d'exposition, des intégrations ITSM. Et ils ont commencé à parler de VOC. Après tout, si un client peut piloter ses vulnérabilités depuis leur console, n'est-ce pas un Operations Center ?

Non. Ce n'est pas un Operations Center. C'est un outil de pilotage. La nuance est fondamentale.

Enfin, les intégrateurs et cabinets de conseil ont suivi le mouvement, en vendant des missions de "mise en place de VOC" qui consistaient, dans les faits, à déployer un scanner, définir une gouvernance de traitement, et former les équipes internes à consommer les rapports. Utile. Mais toujours pas un VOC.

Le résultat ? Un marché où tout le monde parle de VOC, où les appels d'offres utilisent le terme, où les RSSI demandent à leurs équipes d'en construire un, sans que personne ne s'accorde sur ce que cela signifie réellement.

Et surtout, sans que le problème fondamental soit résolu : les vulnérabilités s'accumulent plus vite qu'elles ne sont corrigées.

La vulnérabilité sans remédiation : l'illusion du risque maîtrisé

Il y a un phénomène pervers dans les organisations qui se sont dotées d'un "VOC" : elles pensent avoir maîtrisé leur exposition aux vulnérabilités. Elles ont un tableau de bord. Elles ont des métriques. Elles peuvent montrer à leur COMEX une courbe de réduction du backlog.

Mais si les vulnérabilités critiques identifiées en semaine 1 ne sont toujours pas corrigées en semaine 8, parce que la remédiation n'est pas dans le scope du service, alors le VOC n'a fait que produire de la visibilité sur un risque qu'il n'a pas réduit.

La visibilité sans action, c'est de la conformité documentaire. C'est cocher une case dans un audit. C'est très bien. Mais ce n'est pas de la sécurité opérationnelle.

Les équipes IT qui reçoivent les rapports du VOC ont d'autres priorités. Les correctifs cassent des applications en production. Les fenêtres de maintenance sont rares. Les dépendances sont complexes. La remédiation est un problème organisationnel autant que technique ; un service qui ne prend pas en charge cette dimension ne peut pas s'appeler Operations Center.

Nommer quelque chose "Operations" ne le rend pas opérationnel.

Et puis Mythos est arrivé

Jusqu'ici, on pourrait objecter que le VOC, même imparfait, même limité au diagnostic, a une valeur. Et il en a une ! C'est évident.

On pourrait objecter qu'il structure une démarche. Qu'il sensibilise les organisations. Qu'il est un premier pas. Admettons-le. Parce que c'était effectivement le cas.

Mais ce premier pas vient de se faire rattraper par quelque chose de fondamentalement différent.

L'émergence des agents IA autonomes, et en particulier ce que représente une annonce comme Claude Mythos d'Anthropic, pose une question que personne dans l'industrie du VOC ne peut plus esquiver : si une IA peut scanner en continu, prioriser en contexte, corréler les vulnérabilités avec la topologie réseau réelle, l'exposition effective et les tactiques adversariales connues, et orchestrer la remédiation sans intervention humaine... quelle est la valeur d'un service humain qui ne fait que produire des rapports ?

Ce n'est pas une question rhétorique. C'est la question opérationnelle de la prochaine décennie.

Les agents IA de nouvelle génération ne se contentent pas de scanner plus vite. Ils raisonnent. Ils priorisent non pas selon un score CVSS figé, mais selon le contexte : cette vulnérabilité est-elle exploitable dans mon environnement spécifique ? Existe-t-il un exploit public actif ? Cet asset est-il exposé à Internet ? Est-il critique pour les processus métier ? L'acteur de menace qui cible mon secteur l'utilise-t-il ?

C'est exactement ce qu'un bon analyste VOC devrait faire ; la majorité des services actuels ne le font pas, faute de temps, de contexte, ou de données suffisantes.

L'IA n'a pas ces contraintes.

Et demain, ces mêmes agents pourront, dans des environnements préparés pour cela, déclencher automatiquement les workflows de remédiation, vérifier l'application des correctifs, et boucler le cycle sans attendre qu'un humain lise un rapport PDF de 200 pages.

Le VOC tel qu'il existe aujourd'hui ne sera pas transformé par l'IA. Il sera contourné.

Les gens dans la boucle : la même résistance qu'au SOC

J'ai parlé dans mon article précédent des équipes SOC accrochées à leurs rochers. Le phénomène est identique dans l'écosystème VOC, avec une nuance tout de même.

Dans le SOC, la résistance est culturelle : des analystes formés à des outils et des processus spécifiques, réticents à évoluer.

Dans le VOC, la résistance est aussi contractuelle : des services définis sur des périmètres étroits, des engagements qui excluent délibérément la remédiation pour limiter le risque opérationnel côté prestataire.

Ce n'est pas de la mauvaise foi. C'est de la prudence commerciale.

Mais cette prudence a un coût : elle crée une industrie de la vulnérabilité qui vit de la persistance du problème qu'elle est censée résoudre.

Et certains pourraient même ajouter qu'un service qui détecte sans corriger a, structurellement, intérêt à ce que les vulnérabilités continuent d'exister.

Ce que le VOC devrait vraiment être

Je ne crois pas plus à la disparition du VOC qu'à celle du SOC. Et comme pour le SOC, je crois à une transformation radicale, et à la nécessité de nommer les choses pour ce qu'elles sont.

Si on veut conserver l'acronyme VOC, alors il faut le redéfinir de fond en comble.

Le VOC doit devenir un Vulnerability Orchestration & Closure Center.

J'ai encore ajouté un C, effectivement.

Et chaque mot compte, une fois encore.

Vulnerability : pas seulement les CVE connues et scorées, mais aussi les mauvaises configurations, les expositions cloud, les dépendances tierces, les chemins d'attaque qui n'ont pas de CVE associée mais qui représentent un risque réel.

Orchestration : la coordination active entre la détection, la priorisation contextuelle, les équipes IT responsables de la remédiation, et les outils qui permettent d'automatiser ce qui peut l'être. L'orchestration, ce n'est pas produire un rapport. C'est piloter un processus de bout en bout.

Closure : le mot le plus important. Une vulnérabilité sans clôture confirmée n'est pas traitée. Elle est enregistrée. Le VOC de demain doit avoir une obsession : fermer la boucle. Vérifier. Valider. Mesurer non pas le nombre de vulnérabilités identifiées, mais le taux et le délai de remédiation effective.

Center : un lieu de convergence entre les équipes sécurité, IT, et métier ; pas un silo de scanning qui envoie des alertes dans le vide.

Conclusion : le choix entre l'étiquette et la réalité

L'industrie de la cybersécurité a une tendance chronique à rebrander ses problèmes plutôt qu'à les résoudre.

• Le SOC devient une commodité, alors émergent les MSSP.
• Les MSSP se banalisent, alors apparaît le SOC “nouvelle génération”.
• Et lorsque le SOC "Next Gen" atteint ses limites, il se réinvente sous une nouvelle appellation, comme le VOC.

Les étiquettes ne réduisent pas le risque.

Les processus qui bouclent, les outils qui automatisent ce que l'humain ne peut pas faire à l'échelle, et les équipes qui assument la remédiation et pas seulement le diagnostic : voilà ce qui réduit le risque.

L'IA autonome n'est pas une menace pour les équipes qui font un travail réellement opérationnel. Elle est une opportunité d'amplification massive.

Et elle est une menace existentielle pour les services qui se cachent derrière un acronyme.

La question que chaque RSSI devrait poser à son prestataire VOC est simple : la dernière vulnérabilité critique que vous avez identifiée chez moi, qui l'a corrigée, et en combien de temps ?

Si la réponse commence par "ce n'est pas dans notre périmètre", vous n'avez pas un VOC. Vous avez un scanner avec un account manager.