Hackuity (Lyon) lève 19 M$ : 6 leçons pour industrialiser l’IA en gestion des vulnérabilités

Hackuity Lyon : 19 M$ qui valident un sujet dur, pas un effet de mode

La gestion des vulnérabilités, c’est rarement sexy. C’est surtout un puits sans fond. Des scanners partout, des alertes qui doublonnent, des équipes qui courent après des métriques, et au final un backlog qui gonfle.

Le 16 septembre 2026, Hackuity annonce une levée de 19 M$ (Series B) pour accélérer son approche de Vulnerability Operations Center piloté par IA. La société indique porter son financement total à 38 M$. Le tour est mené par Forgepoint Capital International, avec participation des investisseurs existants Bright Pixel Capital, Bpifrance et Seventure Partners. Sources : Hackuity et Bpifrance.

Point local, concret : Hackuity est basée à Lyon, avec un siège social à Lyon 9e, 55 avenue René Cassin (annuaire public). Quand une boîte lyonnaise lève sur un sujet aussi opérationnel, il y a une leçon simple : l’IA en cybersécurité n’apporte pas de magie, elle apporte du débit et de la discipline, si ton système est câblé pour.

Dans cet article, on déplie ce que veut dire un Vulnerability Operations Center (VOC) dopé à l’IA, où l’IA sert vraiment (triage, priorisation, enrichissement, workflows), quelles données et intégrations tu dois avoir, et quels garde-fous poser pour éviter de piloter à l’aveugle.

VOC : de quoi on parle, exactement (et pourquoi ce n’est pas un SOC bis)

Un Vulnerability Operations Center, ce n’est pas un nouveau buzzword pour dire “on scanne des CVE”. Opérationnellement, un VOC se présente comme une fonction (dans ou à côté du SOC) qui centralise l’ingestion, le triage, le suivi de remédiation, la vérification et le reporting pour tous les findings confirmés (guide VOC Hackuity).

SOC vs VOC : la confusion qui coûte cher

• SOC : détecter et répondre à des incidents en cours. Vous gérez du “maintenant”.
• VOC : réduire l’exposition avant exploitation, avec cadence, gouvernance, remédiation et preuve. Vous gérez du “avant que ça pète”.

Ça change tout. Le VOC est une usine. Son produit fini, ce n’est pas un tableau de bord. C’est une vulnérabilité fermée, vérifiée, tracée, avec un historique défendable.

Pourquoi l’IA arrive ici maintenant

La promesse “VOC” part d’un constat simple : le volume de signaux explose (scanners infra, cloud, AppSec, identités, endpoints, etc.). Le goulot d’étranglement, ce n’est pas la détection. C’est l’opérationnalisation : consolider, prioriser, orchestrer (Hackuity).

Et ce n’est pas qu’un sujet d’éditeurs. Même les approches institutionnelles poussent la priorisation basée sur le risque, avec monitoring continu et logique “risk-based” (exemple : directive CISA BOD 26-04).

Où l’IA apporte vraiment le plus dans un VOC

Si vous cherchez “un LLM qui résume des CVE”, vous allez être déçu. Le ROI est ailleurs : moins de bruit, plus de décisions utiles, plus vite. Dans un VOC, l’IA sert surtout quatre blocs.

1) Triage : transformer du bruit en unités de travail

Le triage, c’est décider ce qui est réel, ce qui est duplicat, ce qui est hors périmètre, ce qui est déjà compensé. L’IA peut aider à :

• Dédupliquer des findings multi-outils (même vulnérabilité, même actif, libellés différents).
• Normaliser les champs (CVE, package, version, preuve, chemin, image container, etc.).
• Regrouper par “problème remédiable” (un patch, une config, une mise à jour d’image, une règle WAF).

Le gain n’est pas “intelligent”. Il est industriel. Vous arrêtez de payer des humains pour faire du copier-coller entre outils.

2) Priorisation : arrêter le pilotage au CVSS seul

Le CVSS donne une sévérité théorique. Ton entreprise, elle a un risque réel, contextualisé. Hackuity met en avant une logique de score de risque contextualisé (par exemple True Risk Score (TRS)) et cite aussi des approches type SSVC pour classer et décider.

Une priorisation utile combine typiquement :

• Criticité de l’actif (métier, disponibilité, données sensibles).
• Exposition (internet-facing, accessible VPN, segment interne).
• Exploitabilité (signaux type KEV/EPSS, menace active, contexte APT).
• Chemin d’attaque (l’actif est-il un pivot crédible).

Le vrai test : quand tu vas en comité (RSSI, DSI, owners applicatifs), tu dois pouvoir répondre à “pourquoi celle-là avant celle-là” sans baratin.

3) Enrichissement : injecter du contexte métier, pas des phrases

Le différenciateur opérationnel, c’est l’enrichissement automatique : relier un finding à des infos que vos outils de sécurité n’ont pas nativement. Typiquement :

• Owner (équipe, produit, responsable applicatif).
• Environnement (prod, préprod, dev, lab).
• Service supporté (process critique ou non).
• Contraintes (fenêtres de maintenance, freeze, exceptions).
• État de remédiation (ticket ouvert, patch planifié, compensations).

Sans ça, votre “priorisation IA” est juste un score de plus. Avec ça, vous obtenez une action assignable, avec un responsable clair.

4) Workflows : si ça ne pousse pas dans l’ITSM, ça ne se ferme pas

La plupart des programmes vulnérabilités meurent ici : les tickets ne sont pas créés, ou mal routés, ou sans preuve, ou jamais retestés. L’automatisation utile, c’est :

• Créer et router des tickets (avec les bons champs, la bonne équipe, le bon SLA).
• Relancer selon la criticité et l’échéance.
• Gérer la boucle retest (re-scan, validation, fermeture).
• Conserver la preuve (scan avant/après, change, décision d’acceptation de risque).

Hackuity décrit l’orchestration et l’auto-création de tickets ITSM comme un axe clé de sa plateforme. C’est logique : le VOC est une chaîne de production, pas un dashboard.

Les données et intégrations nécessaires (sinon ton VOC est un faux centre)

Un VOC piloté par IA ne commence pas par un modèle. Il commence par des connecteurs et une hygiène de données. Hackuity indique connecter 130+ outils et gérer des volumes massifs de findings (métriques déclaratives éditeur). Peu importe les chiffres exacts dans ta boîte : la structure du problème est la même.

Le socle minimum : inventaire actifs + identité

• CMDB ou inventaire : qui est l’actif, où il vit, à quoi il sert.
• Cloud inventory : comptes, projets, ressources, tags.
• IAM : pour relier l’actif à des équipes, des owners, des groupes.

Sans inventaire propre, vous allez “prioriser” des actifs fantômes. Et vous allez perdre la confiance du run.

Les sources vulnérabilités : il faut accepter la réalité multi-outils

• Scanners infra (réseau, OS, VM).
• Cloud security (CSPM, CWPP, posture, configs).
• AppSec (SAST, DAST, SCA, secrets, IaC).
• Containers (images, registries, SBOM si vous en avez).
• Endpoints (selon les organisations, certaines vulnérabilités remontent aussi là).

Le VOC ne remplace pas ces outils. Il les met d’accord. C’est une différence énorme.

Les intégrations “qui font fermer” : ITSM et change

• ITSM : ServiceNow, Jira Service Management, GLPI, ou autre. Peu importe le nom, il faut le flux.
• Change management : liens vers les changements planifiés, validations, CAB si vous en avez.
• Patch management : pour mesurer l’exécution réelle, pas l’intention.

Si le VOC ne parle pas ITSM, vous construisez un système parallèle. Et les équipes ops vont le contourner.

SIEM : utile, mais pas pour les raisons que tu crois

Le SIEM est rarement la “source de vérité vulnérabilités”. Par contre, il peut aider à :

• Corréler risque et activité (ex : asset vulnérable + logs de scanning externe).
• Documenter (preuves temporelles, contexte d’exposition).
• Déclencher des escalades (si menace active détectée).

Mais attention à ne pas confondre : VOC = réduction d’exposition, SIEM = détection d’événements.

6 leçons concrètes “copiables” pour industrialiser l’IA en cybersécurité à Lyon

On revient au pratico-pratique. Si tu es RSSI, DSI, responsable vulnérabilités ou sécurité produit dans une entreprise lyonnaise, voilà ce que tu peux reprendre, même sans acheter le même outil.

Leçon 1 : consolider avant d’“intelligenter”

Ton premier sprint, ce n’est pas de “mettre de l’IA”. C’est de rassembler et dédupliquer. Une vue, un identifiant d’actif, un identifiant de finding, un statut.

• Définis un schéma commun (actif, vulnérabilité, preuve, owner, échéance).
• Décide qui est “source de vérité” pour chaque champ (CMDB pour l’owner, scanner pour la preuve, ITSM pour le statut de remédiation).

Si tu sautes cette étape, l’IA va amplifier ton chaos. Pas le réduire.

Leçon 2 : prioriser par risque contextualisé, pas par score unique

Tu dois sortir du réflexe “CVSS 9 = urgence”. Ce qui compte : “est-ce exploitable chez nous, maintenant, et sur un actif critique”.

• Ajoute la notion d’exposition (internet-facing, segments).
• Ajoute la notion d’valeur métier (criticité service).
• Ajoute des signaux de menace (KEV/EPSS ou équivalents).

Ensuite seulement, laisse l’IA aider à classer, regrouper, proposer des seuils. Mais garde une règle simple : chaque décision doit être explicable en 30 secondes.

Leçon 3 : enrichir avec des données de run, pas des commentaires

L’enrichissement utile vient des systèmes existants :

• Tags cloud (environnement, produit).
• Référentiels internes (applications, owners, criticités).
• Calendriers de maintenance.
• Exceptions de sécurité (acceptation de risque, compensations).

Objectif : quand un ticket part, il part complet. Pas “à investiguer”.

Leçon 4 : industrialiser les workflows via ITSM, avec des boucles fermées

Le VOC doit produire des tickets propres, avec une boucle de fermeture. Sinon tu vas “traiter” sans jamais fermer.

• Un finding priorisé crée un ticket avec SLA.
• Le ticket déclenche patch ou change.
• Le retest valide, puis fermeture automatique si OK.
• Si KO, réouverture, pas création d’un nouveau ticket.

Ça ressemble à de l’usine. C’est le but.

Leçon 5 : utiliser l’IA pour du reporting récurrent, mais traçable

Oui, l’IA peut aider à faire des rapports “board-ready”. Mais seulement si les chiffres sont auditables.

• Un KPI doit pointer vers une liste d’actifs et de findings derrière.
• Chaque “fermeture” doit avoir une preuve (retest, changement, justification).
• Chaque exception doit être datée, signée, expirée.

Sur ce volet, tu peux aussi t’inspirer de notre logique “POC vers run” côté industrialisation, même si le sujet ici est cyber : https://lyon-ia.com/blog/industrialiser-lia-en-dsi-a-lyon-1310-la-checklist-poc-vers-run-mlops-couts-risques

Leçon 6 : mesurer l’impact en réduction d’exposition, pas en “alertes traitées”

La métrique “on a traité 10 000 vulnérabilités” ne veut rien dire. Les bons indicateurs :

• Backlog critical : combien de critiques ouvertes, et depuis quand.
• Temps de cycle : détection vers ticket, ticket vers correction, correction vers validation.
• Couverture : % d’actifs critiques sous monitoring continu.
• Rework : taux de réouverture après retest.

Un VOC mature réduit le stock et accélère le flux. Pas l’inverse.

Garde-fous : l’IA en VOC, oui, mais pas en pilote automatique

Dans un contexte cybersécurité, l’IA doit être utile et contrôlable. Sinon vous allez gagner du débit, et perdre en maîtrise. Trois garde-fous sont non négociables.

1) Explicabilité opérationnelle (pas académique)

“Pourquoi c’est prioritaire” doit être traçable. Concrètement :

• Quels signaux ont déclenché la priorité (exposition, actif critique, menace active).
• Quelles sources ont été utilisées (scanner X, CMDB Y, ITSM Z).
• Quelle règle ou quel seuil a été appliqué.

Si tu ne peux pas l’expliquer à une équipe infra en 2 minutes, tu perds.

2) Gestion des faux positifs et du bruit

Les faux positifs tuent la confiance. Donc :

• Met en place un statut “contesté” avec motif.
• Crée une boucle d’apprentissage sur les causes (mauvais mapping actif, signature scanner, version mal détectée).
• Ne laisse pas l’IA auto-fermer sans preuve technique.

3) Audit et traçabilité des décisions

Vous devez pouvoir rejouer l’histoire : qui a décidé quoi, quand, avec quelles infos. Pour ce point, tu peux t’appuyer sur une règle générale utile au-delà de la cyber : tracer les décisions prises avec l’aide d’une IA. https://lyon-ia.com/blog/tracabilite-decisions-ia

Garde aussi en tête la base : vérifier une information produite par une IA, surtout quand elle influence une décision de risque. https://lyon-ia.com/blog/verifier-information-generee-par-ia

Checklist : si tu veux copier l’approche “Vulnerability Operations Center” pilotée par IA

Tu veux passer de “on scanne” à “on réduit l’exposition” ? Copie ça, et coche franchement.

• Périmètre : vos actifs critiques sont listés, propriétaires identifiés, et l’inventaire est à jour.
• Sources : vos findings viennent de plusieurs outils, mais vous avez une stratégie de consolidation et déduplication.
• Modèle de données : un finding a un identifiant stable, un actif a un identifiant stable, et les statuts sont normalisés.
• Priorisation : vous combinez sévérité + criticité actif + exposition + signaux de menace. Le CVSS seul ne décide plus.
• Contexte métier : owner, environnement, service, contraintes de maintenance, exceptions sont injectés automatiquement.
• ITSM : chaque vulnérabilité prioritaire crée un ticket routé, avec SLA, et une boucle retest vers fermeture.
• Preuves : chaque fermeture s’appuie sur un retest ou une preuve de correction, archivée et consultable.
• Règles IA : toute recommandation IA est expliquée (sources, signaux, seuils). Pas de “score magique”.
• Faux positifs : un processus simple existe pour contester, corriger la cause, et éviter la récidive.
• KPIs : vous mesurez réduction de backlog critique, temps de cycle, couverture des actifs critiques, taux de réouverture.
• Audit : les décisions, exceptions et acceptations de risque sont tracées, datées, et revues périodiquement.
• Rituel : un comité VOC existe (sécurité + ops + produits), avec arbitrages clairs et responsabilités.

Ce que la levée dit aux équipes sécurité lyonnaises

La levée de Hackuity Lyon rappelle un truc basique : industrialiser l’IA en cybersécurité, ce n’est pas “ajouter un LLM”. C’est mettre de l’ordre, brancher les systèmes qui comptent (inventaire, scanners, ITSM, parfois SIEM), et utiliser l’IA là où elle accélère vraiment : triage, priorisation contextualisée, enrichissement, orchestration.

Si tu fais ça, ton VOC devient une machine à réduire l’exposition. Si tu ne fais pas ça, tu ajoutes juste un outil de plus dans une pile déjà illisible. Et tu payes deux fois : en licences, puis en confiance perdue.

Sources : annonce Hackuity (16 septembre 2026, Series B 19 M$, financement total 38 M$, métriques déclaratives, connecteurs), communiqué Bpifrance (lead Forgepoint Capital International, participation Bright Pixel Capital, Bpifrance, Seventure Partners), annuaire public (siège Lyon 9e, 55 avenue René Cassin), guide VOC Hackuity (définition opérationnelle), FAQ Hackuity (SOC vs VOC), directive CISA BOD 26-04 (priorisation based on risk).