Hackuity lève 19 M$ : l’IA en cybersécurité change quoi pour les RSSI à Lyon

19 M$ à Lyon, et un vrai signal pour les RSSI

Quand une boîte cybersécurité basée à Lyon lève gros, ça ne dit pas juste “bravo”. Ça dit surtout: le marché paie pour un problème très concret. Le tien.

Hackuity (siège à Lyon, bureau à Paris) se présente comme une plateforme de “Vulnerability Operations” (VOC): agrégation, déduplication, enrichissement, priorisation, puis orchestration de la remédiation. Source: hackuity.ai.

La société a réalisé une levée de fonds de 19 M$ (Series B) le 16 septembre 2026, selon CB Insights. Forgepoint Capital indique mener ce tour de table de 19 M$, avec participation de Bright Pixel, Bpifrance et Seventure, et relie explicitement le financement à l’accélération des capacités de priorisation et de remédiation. Source: Forgepoint Capital.

Pourquoi ça compte pour un RSSI à Lyon et sa métropole? Parce que la “priorisation des vulnérabilités par IA” n’est plus un gadget. C’est une tentative de répondre à une équation devenue intenable: trop de vulnérabilités, trop peu de temps, trop de bruit, et des équipes qui n’ont pas vocation à patcher “tout, tout de suite”.

Pourquoi la priorisation explose maintenant (et pourquoi CVSS seul ne suffit plus)

Le contexte 2026 est brutal côté volume. Google Threat Intelligence Group observe une accélération forte des divulgations: 5 045 vulnérabilités divulguées en janvier 2026 contre 10 740 en août 2026 (plus du double). Source: Google Cloud, Threat Intelligence.

Mais le point le plus important pour éviter de piloter à l’aveugle est ailleurs. Google indique aussi que seules 0,23% des vulnérabilités divulguées en 2026 auraient été observées en exploitation active, environ 1 sur 431. Même source.

Donc oui, le volume explose. Non, tout n’est pas exploité. Le RSSI qui continue à faire “scanner, export, backlog, patch au fil de l’eau” se condamne à:

• patcher beaucoup de choses peu probables,
• rater quelques vulnérabilités réellement utilisées,
• et perdre la confiance du COMEX à force de demander des moyens “pour réduire un backlog”.

En parallèle, l’exploitation de vulnérabilités reste un vecteur d’entrée majeur. Le DBIR 2026 de Verizon met en avant 31% des intrusions analysées liées à l’exploitation de vulnérabilités. Source reprise par TechRepublic: TechRepublic.

C’est exactement là que les démarches d’exposure management et de priorisation contextualisée prennent le dessus, plutôt qu’une gestion “volume + CVSS”. Gartner formalise cette évolution via CTEM/exposure management. Source: Gartner.

“Priorisation des vulnérabilités par IA”: ce que ça recouvre vraiment

On va faire simple. Une plateforme de gestion des vulnérabilités “nouvelle génération” vise à transformer un tas de listes hétérogènes en une file de remédiation exploitable.

Le résultat attendu n’est pas “un dashboard de plus”. C’est:

• moins de bruit (doublons, findings redondants, faux positifs),
• une unité de travail claire (un finding, un owner, un système, une action),
• un ordre de traitement défendable (probabilité + impact + contexte),
• un bouclage exécution via ITSM et, si pertinent, via les outils SOC.

Les ingrédients classiques d’une priorisation “IA”

Ce type de plateforme combine généralement plusieurs familles de signaux:

• Sévérité: CVSS (y compris CVSS v4.0, publié en novembre 2023). Source: Common Vulnerability Scoring System.
• Probabilité: par exemple EPSS (FIRST), qui estime une probabilité d’exploitation sous 30 jours, mise à jour quotidiennement. Attention: EPSS n’est pas “le risque”, c’est un ingrédient. Source: FIRST EPSS.
• Exploitation avérée: listes “known exploited” (type KEV côté CISA) ou threat intel privée.
• Contexte SI: exposition Internet, criticité métier, présence réelle dans l’environnement, contrôles compensatoires, calendrier de patch, contraintes d’exploitation, etc.

La partie “IA” intervient souvent à plusieurs endroits: corrélation et déduplication multi-sources, enrichissement, scoring contextualisé, et parfois suggestion de remédiation ou routage automatique des tickets. Et oui, selon les vendeurs, “IA” peut aller de règles avancées jusqu’à des modèles ML. Ton job, c’est d’exiger de la traçabilité, pas une promesse.

Ce que revendique Hackuity dans cette logique

Hackuity met en avant:

• l’agrégation agentless via API,
• la déduplication,
• un score propriétaire (“True Risk Score”) combinant sévérité, threat intel et contexte,
• et une approche “explainable”, “no black box”. Source: hackuity.ai.

Dans sa communication produit, Hackuity a aussi mis en avant une réduction du bruit CVSS (“96% CVSS noise reduction”). Source: Hackuity 2.0 release.

Prends ces chiffres comme des hypothèses à vérifier chez toi. Pas comme une vérité universelle.

Les trois pièges classiques pour un RSSI (et comment les éviter)

Piège 1: croire que la priorisation commence après le scan

Non. Elle commence par tes données d’entrée. Sinon tu fais de l’IA sur du désordre, et tu obtiens du désordre plus vite.

Questions à poser (et à te poser):

• As-tu un inventaire fiable des assets (on-prem, cloud, endpoints, workloads, SaaS critiques)?
• Ton CMDB est-elle à jour, ou est-ce un tableau mort?
• Peux-tu rattacher chaque asset à un owner (équipe, produit, responsable run)?
• As-tu des tags métiers (criticité, données sensibles, production vs préprod)?

Sans owner, tu n’as pas une vulnérabilité. Tu as un problème sans responsable, donc un problème non traité.

Piège 2: acheter un score “magique” non explicable

Si un outil te dit “c’est top 1” mais ne te dit pas “pourquoi”, tu ne peux pas:

• défendre tes arbitrages face à la DSI et aux métiers,
• auditer les décisions,
• corriger les biais,
• industrialiser un process.

Exige une explication lisible, du type: exploitation observée + EPSS élevé + asset exposé Internet + application critique + absence de contrôle compensatoire. Et exige l’historisation des raisons: le contexte change, donc les priorités changent.

Piège 3: rester au niveau “tableau de bord” (sans exécution)

Sans ITSM, la priorisation reste une vitrine. Tu veux des tickets. Tu veux des délais. Tu veux du contrôle.

Concrètement, une plateforme de gestion vulnérabilités utile doit:

• créer des tickets dans ton outil (ServiceNow, Jira, Azure DevOps, etc.),
• éviter de créer 12 tickets pour la même CVE sur le même actif,
• récupérer les statuts (en cours, résolu, accepté, compensé),
• gérer les exceptions de manière propre (acceptation de risque, dérogations, fenêtre de maintenance).

Et côté SOC? Intégrer au SIEM peut avoir du sens si tu veux rapprocher vulnérabilités, exposition et signaux de compromission. Mais ne mélange pas tout. Beaucoup d’équipes lyonnaises ont une réalité simple: ITSM d’abord, SIEM ensuite si tu as déjà la maturité et les ressources.

Évaluer le ROI sans te raconter d’histoires (métriques avant-après)

La priorisation par IA se vend souvent sur “moins de bruit” et “plus vite”. OK. Mesure-le. Sinon tu ne sauras jamais si tu as amélioré la sécurité, ou juste changé d’interface.

Avant: prends une photo de ta situation actuelle

Sur 30 jours, capture:

• Volume: nombre de findings entrants par source (scanner infra, cloud, SAST, pentest, etc.).
• Doublons: estimation du pourcentage de CVE répétées (mêmes CVE vues par plusieurs outils).
• Temps humain: temps hebdo passé à trier, qualifier, assigner (RSSI, SOC, vuln mgmt, run, produit).
• Backlog: nombre de vulnérabilités ouvertes par criticité, et leur âge médian.
• SLA: temps moyen de remédiation par niveau (critique, high, medium).
• Réalité terrain: combien de tickets “critiques” finissent reclassés, repoussés, ou contournés.

Après: des métriques qui prouvent un gain, pas juste une activité

• Taux de réduction du bruit: combien de findings aboutissent réellement à un ticket actionnable.
• MTTR vulnérabilités prioritaires: pas le MTTR global, celui du top prioritaire (le 1% ou 5% le plus risqué).
• Part de vulnérabilités avec owner: si tu passes de 60% à 95%, tu as gagné en exécution.
• Stabilité du backlog: backlog total peut rester stable, mais backlog “à risque réel” doit baisser.
• Ratio faux positifs: nombre de tickets fermés comme “non applicable” ou “faux positif”. S’il explose, ton scoring est mal calibré.

Si tu veux une méthode simple pour cadrer un vrai avant-après (sans t’auto-convaincre), tu peux t’appuyer sur cette approche: https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia.

Faux positifs, biais, et “effet tunnel”: les risques spécifiques de l’IA

On parle beaucoup des faux positifs des scanners. Mais la priorisation “IA” crée ses propres risques.

Risque 1: surpondérer ce qui est bien documenté

Les actifs cloud bien tagués, les applis modernes, les environnements où l’inventaire est propre seront mieux scorés. Les zones legacy, industrielles, ou mal inventoriées (et à Lyon il y en a, industrie incluse) risquent de passer sous le radar.

Parade: impose un minimum de couverture et des contrôles de cohérence. Exemple: “liste des actifs sans owner”, “actifs exposés Internet sans tags métiers”, “sources non connectées”.

Risque 2: confondre probabilité globale et risque local

EPSS te dit “probabilité d’exploitation sous 30 jours” de manière générale. Ça ne sait pas si toi, à Lyon, tu as:

• cet asset réellement déployé,
• exposé,
• protégé par un contrôle compensatoire,
• ou déjà patché mais mal détecté.

Parade: exige que le score final combine probabilité et contexte, et qu’il soit explicable.

Risque 3: automatiser trop tôt (et créer des tickets toxiques)

Si tu lances la création automatique de tickets dès le jour 1, tu vas spammer la DSI, perdre la confiance, et tuer le projet. Classique.

Parade: démarre en mode recommandation, puis passe en “ticketing contrôlé” sur un périmètre limité, puis seulement ensuite industrialise.

Checklist de déploiement en 30 jours (adaptée à une équipe sécu lyonnaise)

Objectif: obtenir un résultat visible en un mois, sans vendre du rêve. Périmètre réaliste: un domaine (ex: périmètre bureautique M365, ou une BU applicative, ou un segment infra exposé), pas tout le SI.

Jours 1 à 3: cadrage sec, décisions rapides

• Définis le périmètre: 1 environnement, 1 owner côté run, 1 sponsor DSI.
• Fixe la définition d’un “ticket actionnable”: un actif identifié, un owner, une preuve, une action, une échéance.
• Choisis 3 objectifs mesurables: ex: diviser par 2 le temps de tri, réduire de 30% le backlog “prioritaire”, améliorer le MTTR du top 5%.

Jours 4 à 7: données, connecteurs, hygiène

• Connecte les sources (minimum viable): scanner infra + cloud + inventaire (CMDB/EDR) + ITSM.
• Normalise les identifiants: noms d’assets, environnements, applications. Sans ça, déduplication bancale.
• Règles d’ownership: mapping “asset ou appli -> équipe responsable”. Même si c’est imparfait, il faut un début.

Jours 8 à 12: déduplication et vérité terrain

• Mesure le taux de doublons sur ton périmètre.
• Échantillonne 30 findings: combien sont exploitables, combien sont du bruit, combien sont mal contextualisés.
• Liste des trous: actifs sans owner, sans criticité, sans exposition connue.

Jours 13 à 18: calibration du scoring (pas de religion)

• Définis tes facteurs de contexte: Internet-facing, prod, données sensibles, criticité métier, contrôle compensatoire.
• Impose l’explicabilité: pour chaque top finding, tu veux 3 à 5 raisons lisibles.
• Teste un cas “piège”: vuln CVSS critique mais non exploité et non exposé. Vérifie qu’elle ne remonte pas artificiellement.

Jours 19 à 23: boucle ITSM, mais en mode maîtrisé

• Crée un workflow ticket avec statuts clairs: ouvert, en cours, corrigé, faux positif, accepté (avec justification), compensé.
• Commence petit: tickets auto uniquement sur le top 20, ou top 50, pas plus.
• Ajoute les champs qui évitent les ping-pong: preuve, système, owner, fenêtre de patch, recommandation.

Jours 24 à 27: mesure avant-après, et arbitrages

• Compare: temps de tri, nombre de tickets utiles, MTTR des priorités.
• Regarde les faux positifs: combien de tickets fermés “non applicable”. Pourquoi?
• Ajuste: pondération exposition Internet, criticité, exploitation avérée, etc.

Jours 28 à 30: décider si tu industrialises (ou si tu coupes)

• Décide sur preuves: est-ce que le process remplace vraiment du travail manuel?
• Fixe un plan 90 jours: extension de périmètre, durcissement des données, automatisations supplémentaires.
• Documente: qui change les règles, qui valide une acceptation de risque, qui audite.

Ce que ça change concrètement pour un RSSI à Lyon

La montée de l’IA en cybersécurité, côté vulnérabilités, ne remplace pas ton équipe. Elle change le centre de gravité:

• Tu passes de “combien de vulnérabilités” à “lesquelles comptent vraiment ici”.
• Tu passes de “un dashboard sécurité” à “un flux de remédiation branché sur l’IT”.
• Tu passes de “priorisation à la main” à “priorisation auditable”, donc défendable face au COMEX.

La levée de fonds Hackuity est un signal local: des investisseurs financent l’industrialisation de cette approche depuis Lyon. Pour toi, RSSI, la question n’est pas “est-ce que c’est tendance?”. La question c’est “est-ce que ça réduit mon risque et mon temps perdu, mesuré, sur mon SI?”.

Actions à lancer dès cette semaine

• Fais l’inventaire des sources vulnérabilités réellement utilisées dans ta boîte (pas celles “qu’on a payées”).
• Choisis un périmètre pilote qui a un owner clair et une capacité de patch réelle.
• Définis 3 métriques avant-après et collecte déjà la baseline sur 30 jours glissants.
• Verrouille l’intégration ITSM dès le départ, sinon tu auras un reporting, pas un résultat.
• Exige l’explication des priorités et l’historisation, sinon tu achètes une boîte noire.

Si tu veux garder le bon réflexe “métriques, pas storytelling” sur tes projets IA en général, cette méthode avant-après te donnera un cadre simple: https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia.