La gestion des vulnérabilités est en train de changer d’échelle. Les scanners détectent toujours plus de failles, les équipes sécurité croulent sous les alertes et les attaquants, eux, s’appuient désormais sur l’IA pour aller beaucoup plus vite. Face à ce décalage, Konvu mise sur des agents IA capables d’investiguer, de trier et, à terme, de remédier automatiquement les vulnérabilités réellement exploitables. Entretien avec Lucas Masson, cofondateur et CEO de Konvu.
Code Confiance : Avant d’entrer dans la technologie, pouvez-vous présenter Konvu ? Est-ce une entreprise française ?
Lucas Masson – Je suis aujourd’hui basé à New York, mais la plupart des équipes sont en France. Nous ne sommes que trois à New York pour le moment. Konvu est donc une entreprise très liée à l’écosystème français, même si nous avons un tropisme américain dans notre développement commercial.
L’histoire vient de mon parcours dans la sécurité. Cela fait une dizaine d’années que je travaille sur ces sujets. Avant Konvu, j’étais chez Sqreen, une entreprise spécialisée dans la détection d’attaques au runtime. J’ai commencé en France, puis je suis parti à San Francisco en 2018. Sqreen a ensuite été rachetée par Datadog en 2021. Chez Datadog, j’ai travaillé sur des produits de sécurité et d’observabilité, notamment autour de la détection de vulnérabilités sur différentes couches de la stack : applicatif, cloud, systèmes d’exploitation.
Ce que nous avons vu chez de très gros clients, c’est que la quantité de vulnérabilités détectées devenait ingérable humainement. C’est ce problème précis que nous avons voulu résoudre avec Konvu.
Concrètement, quel problème cherchez-vous à traiter ?
Le problème, ce n’est plus seulement de détecter les vulnérabilités. Beaucoup d’entreprises savent déjà le faire. Elles ont des scanners, des outils de SAST (Static Application Security Testing), de SCA (Software Composition Analysis), de sécurité cloud, de détection applicative. Le vrai sujet, c’est ce qui se passe après la détection.
Il faut investiguer, comprendre si la vulnérabilité est réellement exploitable dans l’environnement du client, prioriser, décider quoi corriger, puis lancer la remédiation. Aujourd’hui, une grande partie de ce travail repose encore sur des analystes sécurité ou des équipes AppSec qui passent leurs journées à trier des alertes. Notre objectif est d’automatiser au maximum ces tâches post-détection.
Nous utilisons une approche entièrement agentique. Des agents IA spécialisés vont mener l’investigation, contextualiser les vulnérabilités et aider à réduire fortement le bruit. À terme, nous pensons que les systèmes pourront devenir partiellement auto-résilients. Pas à 100 %, mais peut-être à 80 ou 90 % sur certaines vulnérabilités, avec des investigations et des corrections largement automatisées.
À quels types d’entreprises vous adressez-vous aujourd’hui ?
Nous travaillons surtout avec des entreprises qui produisent beaucoup de code. Beaucoup sont des éditeurs de logiciels SaaS, de logiciels d’entreprise ou des plateformes financières. Nous avons par exemple des clients cotés, des éditeurs de logiciels de comptabilité ou encore des acteurs américains du logiciel d’entreprise.
Le point commun, c’est le volume. Ces entreprises ont déjà des scanners et des programmes de gestion des vulnérabilités. Mais elles sont confrontées à un flux massif de résultats, dont une partie importante n’est pas réellement exploitable dans leur contexte. Cela crée du bruit, de la charge opérationnelle et des tensions entre équipes sécurité et équipes d’ingénierie.
Où s’intègre Konvu dans l’environnement existant des clients ?
Nous avons deux grands points d’intégration. Le premier se situe au niveau des scanners. Nous ingérons les vulnérabilités détectées par les outils déjà utilisés par l’entreprise, comme Snyk, Semgrep, Qualys, Checkmarx, Veracode ou d’autres plateformes de détection. Ces outils peuvent faire de l’analyse de code statique, de l’analyse de composition logicielle ou de la détection de vulnérabilités dans les dépendances et bibliothèques tierces.
Le deuxième point d’intégration se fait dans l’environnement du client, notamment via l’accès au code source, avec des intégrations GitHub ou GitLab. Cela nous permet de lancer nos agents dans un contexte précis. Ils peuvent alors reproduire, autant que possible, le travail qu’un ingénieur sécurité ferait s’il disposait de beaucoup de temps et de ressources pour investiguer chaque vulnérabilité.
Vous dites que le problème principal est le bruit. Pourquoi les scanners génèrent-ils autant de faux positifs ou d’alertes peu utiles ?
Parce qu’un scanner signale souvent une vulnérabilité potentielle. Il identifie qu’un composant est vulnérable, qu’une règle de sécurité est violée ou qu’un pattern de code peut poser problème. Mais il ne sait pas toujours dire si cette vulnérabilité est réellement exploitable dans l’environnement précis du client.
Une bibliothèque vulnérable peut être présente, mais pas utilisée dans le chemin d’exécution concerné. Une faille peut exister théoriquement, mais être inaccessible depuis l’extérieur. Une vulnérabilité peut être classée critique dans l’absolu, mais ne pas représenter le même niveau de risque dans une architecture donnée.
Nos agents ajoutent cette couche de raisonnement contextuel. Ils analysent le code, les dépendances, l’environnement et les conditions d’exploitation. L’objectif est de distinguer ce qui mérite une action immédiate de ce qui relève du bruit.
Pourquoi ce sujet devient-il plus prégnant aujourd’hui ?
Parce que le délai entre la découverte d’une vulnérabilité et son exploitation se réduit très fortement. Il y a quelques années, les entreprises pouvaient encore raisonner avec des cycles de patching de plusieurs jours, voire de plusieurs semaines. Les normes de conformité demandent encore souvent de corriger les vulnérabilités critiques dans un délai de 14 jours.
Mais ce rythme n’est plus adapté. Les attaquants disposent eux aussi de modèles d’IA capables de faire un très bon travail offensif. Dès qu’une nouvelle vulnérabilité est publiée, ils peuvent l’analyser, produire des exploits, automatiser des recherches de cibles et passer à l’action beaucoup plus vite qu’avant.
On passe d’un monde où les équipes avaient parfois plusieurs semaines à un monde où la fenêtre d’exploitation peut se réduire à quelques heures. Cela met une pression énorme sur les programmes de vulnerability management.
Autrement dit, la détection progresse, mais le goulet d’étranglement se déplace vers le tri et la correction ?
Exactement. Les outils de détection deviennent meilleurs. Les modèles IA découvrent plus de vulnérabilités. Le volume de code explose. Les scanners sont plus largement déployés. Tout cela crée davantage d’alertes.
Mais si, derrière, les équipes humaines doivent continuer à tout qualifier manuellement, le système ne tient pas. Le goulot d’étranglement se déplace vers l’investigation, le triage et la remédiation. C’est là que Konvu intervient.
Notre conviction, c’est que les entreprises doivent pouvoir aller beaucoup plus vite, sans pour autant prendre des décisions aveugles. Il ne suffit pas de dire : “l’IA va corriger toute seule”. Il faut produire des résultats fiables, explicables, reproductibles, avec des preuves suffisantes pour que les équipes sécurité puissent leur faire confiance.
Vos agents IA sont-ils construits en interne ou reposent-ils sur des modèles existants ?
Nous construisons les agents, mais nous ne reconstruisons pas la couche LLM. Notre métier, c’est l’orchestration.
Nous combinons des modèles existants avec des outils déterministes que nous développons pour collecter du contexte dans l’environnement du client. Selon les tâches, nous utilisons différents modèles, notamment des modèles d’Anthropic ou d’OpenAI. Nous testons régulièrement les nouveaux modèles et nous choisissons ceux qui sont les plus performants selon la nature de la tâche, mais aussi selon leur efficacité économique.
Notre valeur n’est pas dans le fait de créer un nouveau grand modèle. Elle est dans la compréhension métier du vulnerability management, dans l’orchestration des agents, dans l’intégration aux workflows d’entreprise et dans la construction de confiance autour des résultats.
Comment construisez-vous cette confiance ?
C’est un point central. Les tâches de sécurité ne peuvent pas être traitées comme de simples tâches de productivité. Une mauvaise décision peut avoir des conséquences importantes. Il faut donc encadrer l’autonomie.
Nous travaillons beaucoup sur l’évaluation des résultats, sur la reproductibilité et sur l’usage d’outils déterministes. Les agents IA ne se contentent pas de “raisonner” dans le vide. Ils vont chercher du contexte, exécutent des vérifications, produisent des éléments de preuve et formulent des conclusions exploitables par les équipes sécurité.
L’enjeu est que les équipes puissent comprendre pourquoi une vulnérabilité est considérée comme exploitable ou non, pourquoi elle doit être priorisée, ou pourquoi une correction est proposée.
Le marché français vous intéresse-t-il vraiment ou reste-t-il secondaire par rapport aux États-Unis ?
Il nous intéresse, bien sûr. Nous avons des conversations avec des entreprises françaises et nous sommes déjà utilisés par quelques acteurs français. Mais aujourd’hui, notre go-to-market est davantage orienté vers les États-Unis, pour une raison simple : nous sommes une petite équipe et nous devons choisir où concentrer nos efforts.
Le marché américain avance plus vite sur ce type de sujet. Il y a moins d’éducation à faire. Les cycles d’adoption sont plus rapides. En France, les décisions sont souvent plus collégiales, les cycles de vente plus longs et la prise de risque plus prudente. Ce n’est pas forcément négatif, mais c’est culturellement différent.
On l’a déjà vu avec le cloud. Quand j’étais chez Sqreen en 2018, les grandes entreprises américaines avaient souvent deux ou trois ans d’avance dans l’adoption cloud par rapport à certains grands comptes français, encore très attachés à leurs infrastructures internes. Je pense que l’on retrouve une dynamique comparable avec l’IA agentique appliquée à la sécurité.
Cela dit, nous avons vocation à avoir des équipes go-to-market en France. Nos équipes d’ingénierie sont déjà largement en France, et il est logique qu’à terme, des équipes commerciales et terrain y soient aussi présentes.
Qui sont vos concurrents ?
Il y a plusieurs catégories de concurrents.
D’abord, des acteurs assez proches de nous, jeunes, qui repensent la gestion des vulnérabilités avec une approche agentique. Certains sont au Royaume-Uni, d’autres aux États-Unis. Nous sommes à peu près au même niveau de maturité.
Ensuite, il y a les acteurs historiques de la détection de vulnérabilités. Beaucoup ont construit leur activité sur la découverte de failles et ajoutent désormais des couches de priorisation ou de remédiation, parce que leurs clients leur demandent de résoudre ce problème.
Pour nous, l’existence de concurrents est plutôt un bon signal. Cela montre qu’il y a un vrai problème de marché. Si personne ne travaillait sur ce sujet, ce serait inquiétant. Là, on voit au contraire que tout l’écosystème comprend que l’ancien modèle atteint ses limites.
Konvu est-il une plateforme autonome ou une brique qui s’intègre dans des outils de cybersécurité plus larges ?
Nous nous intégrons fortement dans l’écosystème existant des entreprises. L’idée n’est pas de forcer les clients à adopter un nouveau dashboard de plus.
Nous nous connectons aux scanners, nous pouvons renvoyer les décisions d’investigation directement dans ces outils, et nous nous intégrons aussi à des solutions de ticketing ou de gestion de projet comme Jira. Dans beaucoup de cas, les clients utilisent peu notre interface au quotidien. Ils l’utilisent davantage pendant la phase de test, puis le produit fonctionne en arrière-plan, en mode presque headless.
L’objectif est que les décisions, les preuves et les actions remontent dans les outils que les équipes utilisent déjà.
Quelle est votre actualité à court terme ?
Nous avons récemment remporté le Cyber Startup Award à Infosecurity Europe, à Londres. C’était une compétition avec cinq finalistes qui présentaient leur solution sur scène devant un jury composé de profils très expérimentés, dont Shlomo Kramer, fondateur d’Imperva, de Check Point et de Cato Networks.
Nous serons également présents à Black Hat et DEF CON à Las Vegas début août. Côté technique, certains de nos ingénieurs interviennent aussi dans des conférences très spécialisées, notamment sur des sujets de sécurité offensive, de reverse engineering ou d’agents capables de valider l’exploitation de vulnérabilités.
C’est important pour nous de rester connectés à la communauté technique. Konvu n’est pas seulement un produit de gestion du risque. C’est aussi une approche très opérationnelle de la sécurité, au plus près de la manière dont les vulnérabilités sont découvertes, comprises, validées et corrigées.
En résumé, quelle est la promesse de Konvu ?
Notre promesse, c’est d’aider les entreprises à ne plus se noyer dans les vulnérabilités détectées. Les scanners produisent beaucoup de signal, mais aussi beaucoup de bruit. Les attaquants vont plus vite. Les équipes sécurité ne peuvent pas simplement travailler davantage ou recruter indéfiniment.
Il faut changer de modèle. Automatiser l’investigation, contextualiser les risques, prioriser ce qui est réellement exploitable et accélérer la remédiation. C’est ce que nous essayons de construire : une gestion des vulnérabilités capable de fonctionner à la vitesse du logiciel moderne, et surtout à la vitesse des attaquants.
