Le financement de Fleuret AI soutient un défi européen aux tests d’intrusion ponctuels

Fleuret AI a levé 4 millions d’euros afin de remplacer les instantanés périodiques de sécurité par des agents IA qui testent les applications en continu. Ce tour de financement donne à la startup parisienne les moyens d’étendre une plateforme axée sur des preuves d’exploitation reproductibles, la remédiation et les nouveaux tests.

RAISE Ventures a mené ce tour de pré-amorçage. Auriga Cyber Ventures, Wind Capital, Better Angle et des dirigeants de la cybersécurité y ont également participé. Cette annonce place une entreprise européenne sur un marché qui attire déjà des acteurs bien financés comme XBOW, Horizon3.ai et Pentera.

L’enjeu ne se résume pas à Fleuret AI face à ces fournisseurs. Il oppose les tests continus menés par des agents à l’évaluation manuelle annuelle qui définit encore les tests d’intrusion pour de nombreuses organisations.

Fleuret affirme que ses agents peuvent cartographier les systèmes exposés, examiner les applications et les API, exploiter les faiblesses confirmées et vérifier les correctifs. Cette séquence promet davantage qu’une analyse de vulnérabilités. Elle autorise aussi un système autonome à se comporter comme un attaquant dans un périmètre approuvé.

Cette autorisation crée la tension centrale. Un agent utile doit être suffisamment offensif pour prouver une vulnérabilité, tout en restant assez prévisible pour éviter d’endommager les systèmes de production. Le financement peut accélérer le développement du produit, mais il ne peut pas résoudre seul cette question de confiance.

Le financement de Fleuret AI rapproche les tests continus de la couche applicative

Ce tour finance une remise en cause directe du test d’intrusion en tant que service planifié et centré sur les documents.

Fleuret a annoncé ce financement de pré-amorçage le 5 octobre 2026. Selon l’annonce de financement de l’entreprise, le capital soutiendra des recrutements dans l’IA, l’ingénierie logicielle et la sécurité offensive.

L’entreprise compte environ dix employés et cite Brevo, Stoïk et Yogosha parmi ses clients. Ses fondateurs, Yanis Grigy et Augustin Ponsin, avaient auparavant créé une activité de tests d’intrusion pendant leurs études.

Ce parcours est important, car les tests d’intrusion automatisés doivent reproduire davantage que la vitesse d’un scanner. Un scanner conventionnel identifie des schémas associés à des faiblesses. Un pentester cherche à déterminer si ces faiblesses peuvent aboutir à une compromission significative.

Fleuret utilise deux agents, Émile et Champollion, pour répartir ce travail. Les agents cartographient l’environnement d’un client, explorent les applications et les API, puis tentent d’exploiter les faiblesses découvertes dans un périmètre autorisé.

La plateforme joint ensuite une preuve de concept à chaque constat signalé. Une preuve de concept est une preuve reproductible montrant qu’une faiblesse peut être exploitée, plutôt qu’une simple correspondance avec une signature.

Fleuret indique également relier les constats aux processus de remédiation. Les équipes d’ingénierie peuvent attribuer un problème, appliquer un correctif et demander à la plateforme de tester à nouveau le même chemin d’attaque.

Cela crée une boucle fermée : découvrir, exploiter, corriger et vérifier. C’est un modèle opérationnel sensiblement différent de la réception d’un rapport après une mission planifiée.

Le produit met actuellement l’accent sur les applications web, les API et l’infrastructure externe. Ce périmètre place Fleuret près de la livraison logicielle, où les déploiements peuvent modifier la surface d’attaque plusieurs fois entre deux évaluations formelles.

Un test réalisé avant une mise en production ne peut pas évaluer le code ou la configuration introduits ensuite. Le rapport reste valable comme preuve de cette évaluation antérieure, mais sa représentation opérationnelle commence immédiatement à vieillir.

Les tests d’intrusion de Fleuret AI visent à réduire cet écart. La startup souhaite que les organisations exécutent des tests plus approfondis lorsque les systèmes évoluent, au lieu d’attendre la prochaine mission annuelle.

Le financement ne prouve pas que Fleuret puisse égaler une équipe d’experts sur chaque application ou chemin d’attaque. Il finance toutefois une tentative de transformer les tests d’intrusion en processus logiciel continu.

Ce changement compte, car les concurrents les plus solides avancent des promesses similaires. Fleuret doit désormais démontrer pourquoi une plateforme européenne axée sur les applications mérite sa place aux côtés de fournisseurs plus importants de tests autonomes.

Les règles européennes de sécurité renforcent la pression en faveur de preuves reproductibles

Fleuret arrive alors que les organisations européennes sont confrontées à des obligations de sécurité plus étendues et à des exigences accrues de contrôles documentés.

Le cadre NIS2 de l’Union européenne impose des exigences de gestion des risques de cybersécurité et de signalement dans 18 secteurs critiques. Il couvre notamment l’énergie, la santé, les transports, l’infrastructure numérique, l’industrie manufacturière et l’administration publique.

Ces règles ne demandent pas simplement à chaque organisation concernée d’acheter un produit automatisé de tests d’intrusion. Elles renforcent cependant la valeur de preuves reproductibles concernant les vulnérabilités, les contrôles, les incidents et la remédiation.

Les orientations NIS2 de la Commission européenne présentent la gestion des vulnérabilités et la sécurité de la chaîne d’approvisionnement comme des composantes du cadre. Elles rapprochent également la responsabilité des défaillances de gestion des risques de la direction générale.

Cet environnement favorise les systèmes de test qui préservent les preuves au fil du temps. Les équipes de sécurité doivent pouvoir montrer ce qu’elles ont testé, quelles faiblesses étaient exploitables, comment elles ont réagi et si la remédiation a fonctionné.

Les organisations financières sont soumises à une couche supplémentaire avec le règlement sur la résilience opérationnelle numérique, ou DORA. Cette réglementation établit des exigences de test pour les systèmes de technologies de l’information et de la communication utilisés par les entités financières concernées.

DORA définit également les tests d’intrusion fondés sur la menace pour certaines entités. Ces exercices reproduisent l’action de véritables acteurs malveillants et testent des systèmes de production critiques dans des conditions contrôlées.

Les règles de test de DORA imposent des exigences qu’une analyse automatisée ordinaire ne peut satisfaire à elle seule. La validation du périmètre, l’aptitude des testeurs, les contrôles des risques et les protections de production restent essentiels.

Fleuret dispose donc d’une opportunité, mais pas d’un raccourci réglementaire. Sa plateforme peut soutenir des tests fréquents et la collecte de preuves sans remplacer automatiquement chaque évaluation réglementée.

L’entreprise met en avant l’infrastructure européenne et la localisation des données comme autre élément de différenciation. Elle indique que ses constats sont hébergés à Paris chez le fournisseur cloud européen Scaleway.

Ce positionnement répond aux préoccupations des acheteurs quant au lieu où résident les preuves de sécurité sensibles. Un espace de travail de test d’intrusion peut contenir des détails d’architecture, des chemins exploitables, des identifiants et des preuves d’accès compromis.

Conserver ces éléments dans une juridiction privilégiée peut simplifier certaines discussions d’achat. Cela n’élimine pas la nécessité d’examiner les sous-traitants, les politiques de conservation, les contrôles d’accès, le chiffrement et les procédures de réponse aux incidents.

La même prudence s’applique aux affirmations de souveraineté. L’hébergement européen est un choix de conception utile, mais les acheteurs doivent examiner l’ensemble de la chaîne de service plutôt qu’un seul emplacement de centre de données.

La pression réglementaire renforce néanmoins l’argument de fond de Fleuret. Les preuves de sécurité perdent de leur utilité lorsqu’elles documentent un système qui a déjà changé.

Les tests continus offrent un moyen de créer un registre plus récent. Ils peuvent aussi aider les équipes à relier des déploiements précis à de nouveaux constats ou à vérifier qu’un correctif a fermé le chemin visé.

C’est là que les tests d’intrusion de Fleuret AI pourraient gagner du terrain auprès des entreprises européennes de logiciels. Le service peut se situer entre les missions périodiques menées par des experts et les scanners de vulnérabilités de routine.

Les équipes de conformité demanderont toutefois si ses rapports signés et ses preuves rejouables répondent aux attentes de leurs auditeurs. Les responsables de la sécurité demanderont si les agents restent dans les limites de leurs autorisations.

Ces questions mettent sous pression à la fois les cabinets de conseil traditionnels et les startups de tests automatisés. Les cabinets doivent justifier de longs intervalles, tandis que les plateformes doivent démontrer leur profondeur, leur contrôle et la crédibilité de leurs preuves.

Le financement de Fleuret AI soutient deux agents, pas un scanner de vulnérabilités supplémentaire

Le pari technique central de Fleuret est que des agents coordonnés peuvent examiner et prouver des chemins d’attaque que les scanners ordinaires se contentent de signaler.

Un agent IA associe un modèle de langage à des outils, de la mémoire et une logique de décision. Il peut choisir des actions, interpréter les résultats et ajuster son plan tout en poursuivant un objectif défini.

En sécurité offensive, cet objectif peut consister à cartographier des points de terminaison, tester des limites d’authentification ou enchaîner plusieurs faiblesses. Chaque action doit rester dans le cadre de l’autorisation explicite du client.

Fleuret indique qu’Émile cartographie les applications et les API comme le ferait un attaquant. Champollion aide à transformer les constats en preuves et en processus de remédiation, bien que l’annonce publique fournisse peu de détails architecturaux.

La distinction importante est comportementale. Un scanner suit généralement des vérifications prédéfinies et rapporte des correspondances. Un agent peut interpréter une réponse inattendue, choisir une autre voie et construire un chemin d’attaque en plusieurs étapes.

Prenons une application présentant un contrôle d’autorisation d’objet insuffisant. L’accès à un point de terminaison peut exposer le dossier d’un autre client, mais seulement après que le testeur a modifié des identifiants et compris la structure des comptes de l’application.

Une signature peut manquer cette relation métier. Un agent disposant d’un contexte suffisant peut examiner si l’application applique correctement la propriété des données.

Fleuret affirme ne pas signaler de constat sans preuve d’exploitation reproductible. Cette politique cible l’un des problèmes les plus anciens des tests de sécurité automatisés : de longues files de faiblesses présumées que les ingénieurs doivent valider manuellement.

La preuve est précieuse parce qu’elle modifie la priorisation. Une faiblesse théorique est en concurrence avec de nombreuses autres alertes. Une compromission rejouable indique précisément à l’équipe quel chemin a fonctionné et ce qui exige son attention.

Les nouveaux tests complètent le processus. Après le déploiement d’un correctif par les ingénieurs, la plateforme peut répéter l’action antérieure et enregistrer si le comportement vulnérable reste accessible.

Ce mécanisme explique pourquoi les tests d’intrusion automatisés attirent des capitaux. Leur valeur ne réside pas seulement dans l’exécution plus rapide de tests traditionnels. Elle consiste à préserver la logique d’attaque afin que les organisations puissent la réutiliser après chaque changement significatif.

L’approche crée également une occasion d’apprentissage. Des tests répétés révèlent si les mêmes catégories de vulnérabilités réapparaissent entre les services, les équipes ou les versions.

Les organisations peuvent relier ces preuves aux processus de développement. Une faille d’autorisation récurrente peut révéler des faiblesses dans un middleware partagé, la revue de code ou les normes d’architecture.

Toutefois, Fleuret n’a pas publié suffisamment de données d’évaluation indépendantes pour établir une couverture étendue. L’annonce cite des clients et décrit le processus, mais elle ne publie pas de résultats comparatifs de détection.

Elle ne précise pas non plus à quelle fréquence des humains examinent les décisions des agents. C’est important, car l’autonomie existe sur un continuum, de l’automatisation guidée à une exécution largement indépendante.

Les documents publics de l’entreprise mettent l’accent sur la preuve, l’hébergement européen et les nouveaux tests continus. Ce sont des priorités produit raisonnables, mais les acheteurs ont toujours besoin de réponses techniques lors de l’évaluation.

Ils devraient demander comment le système gère l’authentification, les limites de débit, les actions destructrices, les données inattendues et les changements d’état des applications. Ils devraient également examiner les contrôles d’autorisation et les journaux de test.

La démonstration la plus convaincante utiliserait un environnement de préproduction contrôlé par le client et proche de la production. Les équipes pourraient comparer les résultats à une évaluation récente menée par des humains et examiner chaque action.

Ce test révélerait davantage qu’un score de benchmark. Il montrerait si les agents comprennent les applications de l’organisation, respectent le périmètre et produisent des éléments de preuve exploitables par les développeurs.

Le principal adversaire est l’instantané annuel de sécurité

L’argument commercial de Fleuret ne tient que si les agents continus étendent la couverture sans écarter le jugement apporté par les pentesteurs humains.

Les tests d’intrusion traditionnels concentrent l’attention d’experts dans le cadre d’une mission définie. Les testeurs qualifiés explorent la logique métier, remettent en question les hypothèses et reconnaissent lorsqu’une réponse inhabituelle a une signification opérationnelle.

Ce modèle peut produire des résultats approfondis. Il présente aussi un problème de calendrier inévitable, car la plupart des organisations ne peuvent pas commander une évaluation manuelle complète après chaque déploiement.

Les plateformes continues ciblent cet intervalle. Elles peuvent répéter des vérifications connues, explorer les surfaces modifiées et valider les correctifs sans devoir reconstruire l’intégralité de la mission à chaque fois.

Horizon3.ai poursuit ce modèle dans les infrastructures d’entreprise. Le produit NodeZero de l’entreprise teste les réseaux, les environnements cloud et d’autres systèmes au moyen de parcours d’attaque autonomes.

En août 2026, Horizon3.ai a annoncé un important tour de financement et déclaré avoir exécuté des centaines de milliers de tests en production. Son échelle déclarée offre aux acheteurs en entreprise un point de référence mature pour les tests autonomes.

Un rapport sur l’expansion du marché a également décrit la croissance internationale de Horizon3.ai et l’accent qu’elle met sur des tests de production prévisibles. Ces capacités relèvent le niveau que Fleuret doit atteindre.

XBOW est un autre comparatif proche, notamment pour la sécurité offensive centrée sur les applications. L’entreprise commercialise un hacker autonome qui identifie et valide les vulnérabilités logicielles.

L’entreprise a annoncé un important financement de série C en mars 2026. Son expansion des tests autonomes illustre la rapidité avec laquelle les capitaux et les talents expérimentés en sécurité entrent dans cette catégorie.

Pentera aborde le problème via la validation automatisée de la sécurité. Son empreinte couvre les surfaces d’attaque internes et externes, ce qui le rend pertinent pour les organisations cherchant à tester largement leurs contrôles.

L’opportunité de Fleuret est plus spécifique. L’entreprise peut devenir une option européenne axée sur les applications, les API, les preuves d’audit et les boucles de remédiation.

Une entreprise plus petite peut aussi travailler au plus près de ses premiers clients. Cela peut l’aider à adapter ses flux de travail aux achats européens, à la résidence des données et aux attentes de conformité propres à chaque secteur.

Cependant, Fleuret ne concurrence pas uniquement par sa géographie. Les clients européens peuvent déjà acheter des produits auprès de fournisseurs internationaux établis.

La startup doit démontrer une meilleure adéquation avec leurs applications et leurs contraintes opérationnelles. Elle a aussi besoin d’intégrations permettant aux conclusions de sécurité d’entrer dans le travail d’ingénierie sans perdre leur contexte.

Cette dimension liée aux flux de travail compte. Un rapport devient moins utile lorsque ses preuves sont séparées du ticket, de la modification de code et du résultat du nouveau test.

Une plateforme efficace devrait préserver toute la chaîne. Les équipes ont besoin de la requête d’origine, du comportement observé, de la preuve d’exploitation, du service concerné, du responsable désigné, de la remédiation et de l’enregistrement de validation.

Cela rappelle le défi plus général consistant à construire une base de connaissances consultable à partir de preuves techniques. Les informations doivent rester reliées, à jour et accessibles aux bonnes personnes.

Les tests continus modifient également le rôle des cabinets de conseil. Ils ne les retirent pas nécessairement du processus.

Les spécialistes humains peuvent se concentrer sur la logique métier complexe, les modèles de menace inhabituels, l’ingénierie sociale, les contrôles physiques et les chaînes d’attaque créatives. Les agents peuvent couvrir les tests répétables entre ces missions.

Ce modèle hybride constitue une perspective à court terme plus crédible qu’un remplacement complet. Il met aussi les cabinets de conseil sous pression pour proposer une validation continue au lieu de considérer chaque rapport comme le produit final.

Le produit gagnant pourrait donc compléter le travail d’experts tout en réduisant les efforts répétitifs. Le défi de Fleuret est de prouver que ses agents occupent cette zone intermédiaire utile.

La preuve de compromission n’élimine pas le risque lié à l’autonomie

Des preuves rejouables peuvent réduire les faux positifs, mais elles ne garantissent ni une couverture complète, ni une exécution sûre, ni un jugement métier solide.

Les tests d’intrusion autonomes opèrent dans un contexte particulièrement sensible. L’agent reçoit des outils conçus pour découvrir des faiblesses et les exploiter contre des systèmes réels.

Un faux positif gaspille le temps des équipes d’ingénierie. Un faux négatif crée une confiance mal placée. Une action non sûre peut interrompre un service, corrompre des données ou atteindre un système en dehors du périmètre autorisé.

L’exigence de preuve de concept de Fleuret répond au premier problème. Si chaque vulnérabilité signalée inclut un exploit rejouable, les développeurs peuvent examiner le comportement exact.

Cette politique ne résout pas entièrement les faux négatifs. Un agent peut produire des preuves exactes pour les failles qu’il trouve tout en manquant un échec d’autorisation plus profond ou une chaîne d’attaque inconnue.

Elle ne répond pas non plus à la question du comportement du système lorsqu’un test rencontre des conditions de production inattendues. La sécurité de l’exploitation dépend de l’application du périmètre, des contrôles d’action, des identifiants, des limites de débit, de la surveillance et des arrêts d’urgence.

La recherche universitaire justifie cette prudence. Une étude récente sur les tests autonomes de réseaux d’entreprise a constaté que les agents peuvent suivre des pistes non pertinentes et perdre des informations entre la planification et l’exécution.

La recherche a également relevé des préoccupations de sécurité nécessitant une supervision humaine. Ces résultats figurent dans une étude sur les tests en entreprise publiée par l’Association for Computing Machinery.

D’autres évaluations ont signalé des difficultés avec les interfaces graphiques, la logique métier complexe et des taux de faux positifs plus élevés. Les performances peuvent aussi varier selon le modèle, le prompt, la configuration des outils et l’environnement cible.

Les benchmarks introduisent une autre incertitude. Les environnements d’entraînement contiennent souvent des vulnérabilités connues, des objectifs clairs ou des modèles d’application représentés dans les données d’entraînement du modèle.

Les systèmes de production sont plus désordonnés. Ils comportent des flux de travail personnalisés, une documentation incohérente, des autorisations partielles, des services tiers et des règles métier propres à une organisation.

Un succès de benchmark démontre donc une capacité dans des conditions définies. Il n’établit pas qu’un agent reproduira l’évaluation d’un expert sur chaque application en production.

Il existe également un problème de gouvernance. Les organisations doivent décider quelles actions un système autonome peut effectuer et lesquelles nécessitent une approbation humaine.

Lire un endpoint est différent de modifier un enregistrement de base de données. Tester le contrôle d’accès est différent de créer un accès persistant. Démontrer une faiblesse est différent d’en maximiser l’impact.

Une plateforme crédible devrait expliciter ces limites et les appliquer techniquement. Le seul langage contractuel ne peut empêcher un agent d’entreprendre une action non sûre.

Les clients devraient exiger des journaux détaillés montrant ce que le système a tenté, quel outil a exécuté chaque étape et quelles preuves étayaient le résultat. Les journaux devraient également identifier les actions bloquées.

L’accent mis par Fleuret sur la preuve et les nouveaux tests est prometteur, car il se concentre sur un comportement observable. Pourtant, l’entreprise n’a pas publié d’évaluation indépendante de la sécurité ni de benchmark comparatif à grande échelle.

Cette absence est compréhensible pour une jeune startup, mais elle reste importante. La confiance des investisseurs et les clients nommés sont des signaux utiles, pas des substituts à une validation technique.

Les équipes de sécurité devraient considérer les premiers déploiements comme des évaluations contrôlées. Elles peuvent commencer par des systèmes de préproduction, des périmètres restreints, des identifiants surveillés et des conditions d’arrêt bien définies.

Elles devraient comparer les conclusions des agents à une revue humaine, en particulier concernant l’autorisation et la logique métier. Elles devraient également mesurer le temps consacré à la validation des résultats, et pas seulement le nombre de conclusions.

La mesure la plus utile n’est pas le nombre de vulnérabilités signalées par un agent. C’est le nombre de problèmes vérifiés et conséquents qui atteignent la remédiation sans ajouter un risque opérationnel inacceptable.

Fleuret doit prouver cette équation dans des environnements clients variés. D’ici là, les affirmations concernant le remplacement des tests manuels approfondis méritent d’être soigneusement nuancées.

Ce qu’il faut surveiller après le tour de financement de Fleuret AI

Les prochaines preuves devront provenir des déploiements, des contrôles de sécurité et de résultats reproductibles, plutôt que d’une nouvelle annonce de financement.

Le premier signal est une validation technique indépendante. Fleuret a besoin d’évaluations comparant ses agents à des pentesteurs expérimentés sur des applications réalistes.

Des résultats utiles distingueraient la découverte, la validation d’exploitation, la couverture de la logique métier, les faux positifs et les faux négatifs. Ils décriraient également la complexité des cibles et le niveau d’assistance humaine.

De solides résultats étayeraient l’affirmation de Fleuret selon laquelle son système offre davantage qu’un scan rapide. Des résultats faibles ou définis de manière étroite favoriseraient un rôle hybride entre les missions humaines planifiées.

Le deuxième signal est l’expansion auprès des clients dans les secteurs européens réglementés. Fleuret cite déjà des entreprises numériques, mais les services financiers, la santé et les infrastructures critiques imposent des exigences plus strictes en matière d’achats et d’exploitation.

L’adoption sur ces marchés mettrait à l’épreuve la résidence des données, les preuves d’audit, les contrôles d’identité et la sécurité en production. Elle révélerait également si les acheteurs acceptent des rapports générés par des agents dans leurs programmes d’assurance existants.

Une liste croissante de clients ne suffira pas à trancher la question. Les études de cas devraient expliquer le périmètre des tests, les résultats de remédiation et la relation entre les évaluations automatisées et humaines.

Le troisième signal est la manière dont les concurrents réagissent. XBOW, Horizon3.ai, Pentera, les cabinets de conseil et les plateformes de tests de sécurité disposent tous de voies vers la validation continue.

Ils peuvent ajouter un hébergement européen, une couverture des applications, des flux de travail basés sur des agents ou des intégrations de remédiation plus approfondies. Fleuret doit établir un avantage défendable avant que ces capacités ne convergent.

Son ouverture la plus claire est une plateforme européenne étroitement intégrée pour les applications et les API. Cette position se renforce si les clients peuvent relier chaque exploit à un correctif et à un nouveau test vérifié.

Cette position s’affaiblit si les utilisateurs ont encore besoin d’une validation manuelle importante ou d’outils distincts pour obtenir une couverture significative. Elle s’affaiblit également si l’exécution autonome crée des retards d’approvisionnement qui effacent la rapidité promise.

Le tour de financement de Fleuret AI est donc important sans être concluant. Il donne à une jeune entreprise les ressources nécessaires pour vérifier si la sécurité offensive continue peut devenir une infrastructure d’ingénierie ordinaire.

Pour les développeurs, la pertinence immédiate réside dans un retour plus rapide entre une modification de code et la preuve de son exploitabilité. Pour les responsables de la sécurité, c’est la possibilité de tester davantage de systèmes entre les missions menées par des experts.

Les acheteurs en entreprise devraient désormais demander un essai surveillé utilisant leurs propres modèles d’application. Comparez les preuves de l’agent aux résultats humains, inspectez chaque action et mesurez le temps de remédiation.

Cette évaluation révélera si les tests d’intrusion automatisés réduisent le retard accumulé en matière de sécurité ou n’en changent que la forme. La réponse déterminera si Fleuret devient un leader européen de la catégorie ou une autre couche prometteuse dans une pile déjà encombrée.