Le prochain chapitre de Plexicus : bâtir l'avenir de la sécurité applicative fondée sur la preuve

Les logiciels sont développés plus vite que jamais. Les équipes de sécurité ont besoin de plus qu’une nouvelle liste de vulnérabilités potentielles. Elles ont besoin de preuves de ce qui peut réellement être exploité, du contexte de ce qui compte et d’un chemin concret vers un correctif relu. C’est le problème que Plexicus s’attache à résoudre, et c’est pourquoi notre prochain chapitre compte.

Le développement logiciel change. Les assistants de code IA, les workflows automatisés, les composants tiers complexes et l’infrastructure connectée aident les équipes à livrer à un rythme remarquable. Chaque nouvelle intégration, dépendance, API et fonctionnalité peut aussi soulever de nouvelles questions de sécurité.

Le défi n’est plus de savoir si un scanner peut signaler quelque chose de suspect. Il est de savoir si une entreprise peut établir ce qui est réel, pourquoi cela compte et ce qu’il faut faire ensuite, avant que l’exposition ne devienne un incident.

Chez Plexicus, nous pensons que la sécurité applicative doit être construite autour de la preuve. Notre mission : aider les équipes à valider le risque applicatif réel, à comprendre son impact et à le corriger grâce à un workflow appuyé sur des preuves.

Le problème : plus d’alertes ne veut pas dire plus de sécurité

Les équipes logicielles modernes s’appuient sur de nombreux types de tests de sécurité. L’analyse statique signale des schémas de code suspects. L’analyse des dépendances trouve des paquets vulnérables. Les tests dynamiques explorent le comportement de l’application. Les outils cloud ajoutent une couche de visibilité supplémentaire.

Ces capacités comptent. Mais elles vivent souvent dans des systèmes séparés, produisent des constats redondants et laissent les équipes de sécurité et d’ingénierie face à des questions difficiles :

• Cette vulnérabilité est-elle réellement exploitable dans notre environnement ?
• Quelle application, quelle API ou quel processus métier touche-t-elle ?
• S’agit-il d’une exposition urgente ou d’un problème théorique ?
• Quel changement la corrige sans casser le produit ?
• L’équipe peut-elle démontrer qu’elle a été corrigée ?

L’écart entre la détection et la remédiation vérifiée est un problème opérationnel. Plus d’alertes créent plus de travail de tri, sans gain de sécurité équivalent.

Le paysage des menaces ajoute de l’urgence. Dans son Data Breach Investigations Report 2026, Verizon identifie l’exploitation de vulnérabilités comme l’un des principaux vecteurs d’accès initial, à hauteur de 31 % des violations analysées dans ce jeu de données. Ce chiffre montre à quel point l’exposition logicielle porte à conséquence ; il ne dit rien de toutes les attaques et ne mesure pas les performances de Plexicus.

Qui nous sommes

Plexicus est une entreprise de sécurité applicative pilotée par l’IA, construite autour de Proof-Driven AppSec. Nous réunissons la validation de sécurité, la compréhension au niveau du code et une remédiation relisible dans un seul processus connecté, pour que les équipes décident mieux et agissent avec plus d’assurance.

La personne derrière Plexicus

Plexicus a été fondée en mai 2025 par José Ramón Palanco. Le produit est récent. L’habitude qui le sous-tend ne l’est pas. José travaille dans la cybersécurité depuis plus de vingt ans, presque toujours autour d’une seule question : est-ce vraiment cassé, et pouvez-vous me le montrer ?

José a été formé comme ingénieur en télécommunications à l’Université d’Alcalá, puis a obtenu un master en gouvernance des systèmes d’information à l’Université de Deusto. Les premières années de travail ont été consacrées à construire des systèmes, en R&D chez Ericsson et chez Optenet (aujourd’hui rattachée à Allot). Construire des systèmes apprend comment ils échouent.

Puis vint le côté offensif : des vulnérabilités publiées avec des identifiants CVE et des outils de sécurité open source que d’autres chercheurs utilisent encore, parmi lesquels nmap-scada, ProtocolDetector, escan, pma, EKanalyzer et un IDS SCADA. Les conférences ont suivi, à OWASP, RootedCON, ROOTCON, MALCON et FAQin.

Avant la sécurité

Une photo d’enfance tirée des archives familiales de José : deux garçons, deux tortues et un chien très patient.

Dinoflux

Présentation de Dinoflux, l’entreprise de threat intelligence que José a fondée en 2014, à The Cube Madrid.

APIAddicts

Sur la scène d’APIAddicts, avec la frise de parcours qui va de 2005 à Plexicus en 2025.

API · MCP · Agentic

La même conférence : là où la sécurité se brise entre les API, MCP et l’IA agentique.

CMICE

La table ronde « L’impact de l’IA dans la rue », lors de la journée technique du CMICE sur l’IA à Madrid, le 10 novembre 2026. José faisait partie du panel.

Aujourd’hui

José Ramón Palanco, fondateur et CEO/CTO de Plexicus.

En 2014, José a fondé Dinoflux, une société de renseignement sur les menaces rachetée plus tard par Telefónica, et travaille aussi avec 11Paths depuis 2018. Créer une entreprise, la vendre et travailler au sein d’une grande organisation a montré le même problème sous trois angles : le fournisseur qui produit des alertes, l’acheteur qui les reçoit et l’équipe qui doit agir dessus.

Plexicus est conçue pour cette troisième équipe. Pendant vingt ans, le travail a consisté à montrer aux gens que quelque chose en quoi ils avaient confiance était cassé. Avec Plexicus, la phrase trouve sa fin : voici la preuve, et voici le correctif, prêt à fusionner.

Vous pouvez écouter José l’expliquer sur la chaîne YouTube @jpalanco, où la démo complète ci-dessous a été publiée, et en savoir plus sur jpalanco.com.

Ce parcours façonne notre approche. Les outils de sécurité ne devraient pas se contenter de produire des résultats convaincants. Ils devraient aider les équipes techniques à établir ce qui peut être démontré, relu et corrigé.

Notre approche : Valider. Comprendre. Remédier.

Plexicus repose sur trois questions liées.

1. Valider : le risque peut-il réellement être démontré ?

AI Swarm Pentest, propulsé par notre moteur Nexus, coordonne un essaim d’agents IA contre une application autorisée et explicitement délimitée. Les agents explorent des chemins d’attaque, testent des hypothèses et produisent des preuves reproductibles pour chaque constat qu’ils peuvent confirmer. Un vérificateur distinct rejoue les preuves avant qu’un constat ne compte. No PoC, no finding.

Les évaluations exigent que vous déteniez les cibles ou y soyez autorisé, respectent les limites convenues et laissent les décisions aux humains. Lire la documentation AI Pentest.

2. Comprendre : qu’est-ce que le constat touche ?

Une faiblesse confirmée est plus utile quand les ingénieurs savent où elle se trouve et ce qu’elle peut atteindre. Deep Code Analysis relie un constat à ses chemins de code, ses flux de données, son accessibilité et son contexte environnant. Il devient plus simple de comprendre pourquoi une faiblesse compte, de choisir la bonne réponse d’ingénierie et de cesser de gaspiller des efforts sur des alertes sans contexte.

3. Remédier : comment l’équipe peut-elle corriger en confiance ?

Trouver des problèmes n’est qu’un début. Le résultat qui compte est une application plus sûre. Remediation de Plexicus prépare une modification de code proposée et ses preuves à l’appui sous forme de pull request. Vos ingénieurs la relisent, la testent et la fusionnent. Un nouveau test vérifie ensuite que le problème démontré a disparu, selon le workflow configuré.

Notre philosophie est simple : l’IA aide les équipes à aller plus vite sans retirer la responsabilité humaine.

À quoi cela ressemble en pratique

Prenons une plateforme en ligne hypothétique qui reçoit une alerte sur un endpoint d’API potentiellement dangereux. Le schéma de code semble suspect, mais un rapport classique ne peut pas, à lui seul, dire si un attaquant peut atteindre l’endpoint ou l’exploiter en conditions réelles.

Dans un workflow fondé sur la preuve :

1. L’équipe définit un périmètre de test autorisé.
2. Les agents étudient le comportement de l’application et collectent des preuves reproductibles lorsqu’ils le peuvent.
3. L’analyse de code relie le constat aux fonctions concernées, aux flux de données et au contexte métier.
4. Un correctif proposé est préparé sous forme de pull request pour relecture par l’ingénierie.
5. Les relecteurs décident de la fusionner ou non, et un nouveau test vérifie le résultat.

L’exemple est illustratif, ce n’est ni un cas client ni un benchmark du produit. Il montre la direction du workflow : du risque possible à la preuve, le contexte et une prochaine action responsable. Pour l’entreprise, les décisions sont plus faciles à expliquer. Pour les équipes de sécurité, les constats peuvent être défendus avec des preuves techniques. Pour les ingénieurs, le chemin du rapport au code relu est plus court.

L’histoire complète du produit, en moins de deux minutes :

La démo complète, du tableau de bord au correctif fusionné

Pourquoi maintenant ?

Plusieurs tendances convergent.

L’IA change la vitesse de livraison des logiciels. L’IA générative aide les ingénieurs à écrire, transformer et relire du code, mais une production plus rapide ne supprime pas le besoin de conception sécurisée, de validation et de relecture humaine. Un rapport d’eu-LISA de juillet 2026 sur l’IA générative dans le développement logiciel souligne les questions de sécurité et de qualité que soulèvent les assistants de code IA. Les workflows de sécurité doivent suivre le rythme.

La gestion des vulnérabilités est un problème opérationnel. Une organisation peut posséder de nombreuses applications, services cloud, dépôts et chaînes d’approvisionnement. Les équipes de sécurité ne manquent pas d’informations ; elles ont besoin de priorisation et de contexte exploitable, et d’un chemin rapide d’un constat confirmé à un correctif relu.

Les exigences européennes de sécurité des produits évoluent. Le Cyber Resilience Act renforce les obligations de sécurité des produits et de gestion des vulnérabilités pour les produits relevant de son champ. Certaines obligations de notification ont débuté le 11 septembre 2026 ; les principales obligations s’appliquent généralement à partir du 11 décembre 2027. Voir la présentation de la CRA par la Commission européenne. Aucune plateforme ne rend une entreprise conforme à elle seule, mais des processus documentés et des preuves défendables comptent plus que jamais.

Les équipes de sécurité demandent des résultats mesurables. Le nombre de constats est un piètre indicateur de sécurité. Les organisations doivent savoir quels risques ont été validés, qui a agi, quels changements ont été relus et quelles preuves subsistent ensuite.

Ce qui distingue Plexicus

Notre différence n’est pas la promesse que l’automatisation remplacera chaque spécialiste de la sécurité, ni que chaque vulnérabilité peut être trouvée automatiquement. C’est la façon dont le travail de sécurité est organisé et étayé.

• Des preuves avant les conclusions. Les constats s’appuient sur des preuves techniques reproductibles, pas sur un score de confiance ni sur une explication plausible d’une IA.
• Un workflow connecté. Validation, compréhension au niveau du code et remédiation forment une seule séquence, et non des passages de relais entre outils déconnectés.
• La sécurité dans les contraintes réelles de l’ingénierie. Les évaluations restent dans le périmètre approuvé, et chaque changement proposé passe par une relecture humaine et des contrôles de fusion.
• Conçu pour les développeurs et les équipes de sécurité ensemble. Le même constat est compréhensible pour un relecteur sécurité, exploitable pour un ingénieur et explicable à un responsable métier.

Comme toute entreprise technologique, nous devons continuer à le prouver par l’usage du produit, les retours clients, des résultats mesurables et la comparaison avec les alternatives.

De la vision au produit : les progrès réalisés

Plexicus ne part pas d’une simple idée. Nous avons construit le produit, documenté le workflow et l’avons présenté à des publics techniques.

Sources : annonce des crédits Azure · sortie de promotion Startup Wise Guys · programme NEOTEC 2026 du CDTI · résolution provisoire du CDTI, 6 novembre 2026.

Construire la preuve de la traction

La reconnaissance externe est utile, mais ce n’est pas de la traction commerciale. Le vrai test d’une entreprise de produit est de savoir si elle obtient de l’adoption, sert bien ses clients et transforme sa capacité technique en valeur répétable.

Nous nous concentrons sur la transformation de la validation du produit et des premiers engagements commerciaux en adoption durable. Nos priorités à court terme : approfondir les relations clients, établir des processus de déploiement répétables et mesurer les résultats que les équipes de sécurité et d’ingénierie valorisent le plus.

Notre activité : transformer la capacité de sécurité en valeur répétable

Une entreprise de cybersécurité solide a besoin de plus qu’une démonstration impressionnante. Il lui faut un produit que les clients veulent adopter, un workflow auquel ils peuvent se fier et un modèle économique capable de financer sur la durée l’ingénierie, l’infrastructure et le service.

Notre plateforme s’adresse aux organisations qui construisent ou exploitent des logiciels et ont besoin d’une meilleure visibilité sur le risque applicatif, des développeurs et praticiens AppSec aux responsables de l’ingénierie et de la sécurité. Notre priorité commerciale : un déploiement initial concret, des évaluations délimitées, des preuves exploitables, des workflows de remédiation clairs et une livraison adaptée aux entreprises.

L’enjeu n’est pas de vendre le plus grand nombre d’alertes. C’est d’aider les clients à prendre de meilleures décisions de sécurité et à agir en conséquence.

Pourquoi nous nous préparons à notre prochaine étape de croissance

Bâtir une plateforme de sécurité ambitieuse demande une exécution soutenue. La recherche produit doit devenir des workflows fiables. Les clients exigeants ont besoin d’une infrastructure sûre, d’intégrations solides, de documentation et de support. La distribution demande des relations, de la pédagogie et une compréhension de la façon dont les équipes d’ingénierie achètent et adoptent les logiciels de sécurité.

Alors que Plexicus se tourne vers son prochain chapitre, nous ouvrons des discussions avec des investisseurs qui partagent notre vision à long terme. Nous voyons le capital externe, structuré de façon appropriée, comme un moyen d’accélérer des domaines précis d’exécution, et non comme un substitut à de solides fondamentaux produit. Nos priorités pour la prochaine étape :

• Approfondir le produit et la recherche en IA : des constats mieux validés, une couverture plus large des chemins d’attaque pertinents, un raisonnement au niveau du code et une remédiation plus solides, avec supervision humaine et preuves claires au centre.
• Étendre l’adoption et la distribution : aider davantage d’équipes de développement et de sécurité à passer de l’évaluation à l’usage quotidien de Proof-Driven AppSec.
• Renforcer l’infrastructure et la préparation clients : fiabilité, options de déploiement, intégrations, support et les contrôles opérationnels que les organisations attendent d’une plateforme de sécurité.
• Constituer l’équipe d’une exécution soutenue : compétences produit, recherche en sécurité, ingénierie et go-to-market.

Ce sont des domaines d’attention stratégiques, pas un budget approuvé, une allocation de capital ni des jalons garantis.

Si vous souhaitez suivre cette prochaine étape, vous pouvez manifester votre intérêt sur notre page investisseurs. L’inscription n’engage à rien. Elle ne constitue pas une offre de titres, et toute opportunité d’investissement sera communiquée par des canaux et une documentation approuvés.

Manifester votre intérêt

Notre vision à plus long terme

Nous croyons que l’avenir de la sécurité applicative n’est ni un tableau de bord rempli de constats non triés, ni une boîte noire qui demande aux utilisateurs de croire la réponse d’une IA. C’est un workflow où le risque pertinent est démontré, son contexte compris, et le bon correctif relu et vérifié.

L’opportunité est réelle, mais bâtir une entreprise de cybersécurité est difficile. Le marché est concurrentiel, l’adoption en entreprise prend du temps, les systèmes d’IA demandent des tests rigoureux, et ni les produits de sécurité ni les investissements dans des entreprises en phase de démarrage ne sont exempts de risque. Notre responsabilité est de continuer à transformer la promesse technique en une exécution fiable et mesurable.

Nous avons créé Plexicus parce que la sécurité doit produire des preuves sur lesquelles les ingénieurs peuvent agir. Voici le prochain chapitre de Plexicus : moins de conclusions sans fondement, des décisions de sécurité plus claires et un chemin plus direct du risque à la résolution.

Découvrez la plateforme Proof-Driven AppSec, consultez la documentation technique ou parlez à notre équipe.

Actualité de l’entreprise. Cet article décrit le produit, la stratégie et les ambitions de Plexicus. Il ne constitue ni une offre de vente de titres, ni une sollicitation d’investissement, ni un substitut à la documentation d’investissement officielle. Toute communication future relative à un investissement sera soumise aux autorisations, informations et exigences légales applicables.