Renaud Deraison, créateur de Nessus et ancien CTO de Tenable, intervenait pour la première fois au SSTIC depuis vingt et un ans. La conférence de clôture qu'il a donnée à Rennes le 5 juin 2026 s'articulait autour de deux axes : la présentation d'un projet open source qu'il a entièrement développé avec des LLM, et une réflexion sur les conséquences de cette nouvelle réalité pour l'industrie de la cybersécurité.
Avertissement: contenu généré à partir des sous-titres disponibles sur le gitlab du SSTIC.
Deraison ouvre sur une frustration personnelle accumulée au fil de sa carrière chez Tenable. À mesure que la société a grossi et qu'il est monté en responsabilités managériales, il est passé, selon ses propres mots, d'une compréhension viscérale de la technologie à une compréhension intellectuelle. Le delta entre les deux est immense, dit-il — et particulièrement critique en cybersécurité, où c'est précisément dans les détails que se trouvent les problèmes. Connaître le concept de Kubernetes et réellement opérer un cluster en production, voir les permissions, comprendre ce qui se passe réellement, ce sont deux expériences fondamentalement différentes.
Après avoir quitté Tenable il y a cinq ans, il a eu le temps de se remettre à bricoler. C'est dans ce contexte qu'il a découvert les LLM, d'abord avec ChatGPT, puis en migrant vers Claude. L'expérience l'a conduit à lancer, il y a trois mois, une expérimentation radicale : développer un projet open source complet en déléguant au maximum à des LLM — code, documentation, site web, marketing, blogs, localisation.
Le projet s'appelle Bromure. C'est un navigateur web sécurisé pour macOS, dont le nom est un clin d'œil à Bromium, une société fondée en 2010 qui avait eu l'idée visionnaire de faire tourner Internet Explorer dans une machine virtuelle de manière complètement transparente pour l'utilisateur. Bromium défendait alors une thèse provocatrice : inutile de patcher, il suffit de fermer la fenêtre du navigateur à la fin de chaque session. Deraison pense rétrospectivement qu'ils avaient raison — même en étant parfaitement à jour, un clic sur le mauvais lien soulève des doutes légitimes sur ce qui a pu être compromis.
Bromure reprend ce principe d'isolation mais repackagé pour macOS en 2026 : le navigateur tourne sous Linux dans une VM, mais l'intégration avec l'OS hôte est poussée au point d'être quasi-invisible. La barre de titre est native, les dialogues de fichiers sont ceux de macOS, le keychain et les passkeys sont intégrés, le drag-and-drop fonctionne. La communication entre la VM et le host passe par des vsockets. L'objectif de performance était de pouvoir regarder une vidéo YouTube en 1080p plein écran — ce qui avait justement coulé Bromium à l'époque.
Le navigateur expose un système de profils permettant de contrôler finement ce à quoi il a accès : accélération GPU, audio, webcam, transferts de fichiers, isolation réseau. Un plugin de détection de phishing analyse les métadonnées et le contenu des pages via un LLM pour détecter les incohérences — par exemple une page demandant de réinitialiser un mot de passe iCloud hébergée en dehors du domaine d'Apple.
Une fonctionnalité d'enregistrement de sessions permet également une visibilité totale sur le trafic web, y compris les données uploadées. Deraison présente cela comme un cas d'usage enterprise concret : lorsqu'un utilisateur a cliqué sur un lien de phishing, il affirme n'avoir rien fait, mais l'enregistrement montre qu'il a saisi ses credentials d'entreprise.
Il existe aussi une version enterprise (non encore open sourcée) permettant de déployer des profils centralisés, d'imposer une authentification mTLS, et de configurer Okta, Google Workspace ou Azure Entra pour n'accepter que les connexions issues de navigateurs Bromure. Le use case typique : un contracteur qui accède à Salesforce depuis sa propre machine.
Coût total de développement : 600 dollars d'abonnement Claude. Bromium, lui, avait levé 80 millions de dollars.
Deraison présente un second projet dans la même veine conceptuelle : Atlantic Coding, une VM pour développeurs conçue pour éviter le vol de credentials lors de l'exécution de code non fiable (packages NPM compromis, agents IA).
Le principe est le suivant : tous les tokens d'authentification — clés SSH, tokens AWS/GCP/Azure, kubeconfig — sont stockés sur la machine hôte, en dehors de la VM. La VM ne reçoit que de faux tokens. Quand le code tourne dans la VM et effectue une requête vers un service cloud, le host intercepte le trafic, détecte le faux token utilisé et le remplace à la volée par le vrai. De ce fait, si un package vérolé s'exécute dans la VM, il n'y a rien à voler.
SSH passe par un agent via vsocket — la clé n'est jamais présente dans la VM. Le kubeconfig est un fichier de configuration reconstruit. Le système peut en outre restreindre les droits : un compte Kubernetes avec accès admin peut être forcé en read-only au niveau du proxy, indépendamment de ce que pense la VM.
Le monitoring du trafic vers les LLM est également inclus, permettant de voir les requêtes, les réponses et les métadonnées que les API ajoutent — utile pour comprendre comment vos agents consomment réellement leurs tokens. Deraison cite l'anecdote d'une société qui a dépensé 500 millions de dollars en tokens parce qu'elle avait oublié de poser une limite de consommation.
La deuxième partie de la conférence abandonne la démo pour une réflexion de fond.
Deraison dresse un bilan sévère mais documenté. L'industrie de la cybersécurité a connu quelques vagues d'innovation dans les années 90-2000 (IDS, scanners, EDR), puis a massivement basculé vers le SaaS. Cette migration a absorbé l'essentiel des ressources R&D pendant des années — non pas pour innover, mais pour faire scaler les applications existantes. La décennie suivante a été dominée par l'expérience utilisateur, avec Wiz comme exemple emblématique d'un succès fondé sur la facilité de déploiement plutôt que sur une rupture technique.
La contrainte structurelle est financière : les investisseurs exigent 80% de marge brute. Sur un produit vendu 100 dollars, 20 dollars maximum peuvent aller à l'hébergement. Tout le reste paye les salariés, les commerciaux, le marketing. Dans ce contexte, chaque point de marge perdu fait plonger le cours en bourse. L'anecdote de Tenable est illustrative : une fonctionnalité permettant de comparer le niveau de sécurité de ses clients entre eux (un benchmark sectoriel) ne pouvait pas être offerte gratuitement parce qu'elle nécessitait du stockage supplémentaire, ce qui dégradait les marges. Elle a donc été monétisée séparément — et le fait de la facturer a immédiatement créé des attentes de ROI incompatibles avec une version 1.0 encore imparfaite.
Par ailleurs, les améliorations techniques profondes — refonte d'un moteur d'exécution, passage d'un arbre syntaxique à du bytecode comme l'a fait Nessus entre ses versions 2 et 3 — sont invisibles pour un client SaaS. Il n'y a pas de "nouvelle version" à livrer pour justifier l'effort.
Deux problèmes majeurs qui freinaient l'innovation sont en passe d'être résolus :
Le scale. Il existe aujourd'hui des dizaines de solutions matures pour faire scaler des applications. Elles étaient souvent complexes à mettre en œuvre — mais Claude sait configurer Kafka, choisir les bonnes librairies, gérer les détails. Le coût du scale s'effondre.
L'interface utilisateur. Pas encore l'expérience utilisateur au sens plein, mais la génération d'interfaces graphiques fonctionnelles est désormais accessible à n'importe quel ingénieur.
Ces deux capacités libérées permettent de revenir à ce qui compte : l'innovation fonctionnelle. Et de faire de la sécurité sur mesure, ce qui était jusque-là le privilège des grandes organisations.
Deraison propose une classification en trois catégories pour penser la valeur d'un produit de sécurité :
-
Rajouter un élément au workflow. Exemple : un outil de surveillance de votre réputation en ligne. Vous ignorez le problème avant, maintenant vous devez le gérer. Charge de travail supplémentaire, difficile à vendre dans la durée.
-
Remplacer un élément par un autre. Amélioration marginale de qualité ou d'ergonomie. Valeur limitée, différentiel de 5%.
-
Supprimer ou raccourcir un workflow. C'est ce que valorise le marché. L'exemple B2C canonique est Uber : obtenir un taxi est passé de vingt minutes d'incertitude à une pression sur un bouton.
Les LLM permettent désormais d'atteindre la troisième catégorie dans des domaines où c'était structurellement impossible pour un éditeur. Le cas de la priorisation des vulnérabilités en est l'illustration parfaite : aucun vendeur n'a réussi à résoudre ce problème de manière générique, précisément parce que chaque organisation a une logique métier propre. Goldman Sachs classe l'iPad en salle de conférence comme actif critique parce que sa compromission visible pourrait faire fuir un client lors d'une IPO. Un fabricant automobile considère son four industriel de cafétéria comme son équipement connecté le plus critique parce que sans cafétéria, il n'y a pas d'ouvriers, et donc pas de chaîne de production. Ces contextes ne peuvent pas être encodés dans un modèle générique — mais ils peuvent être exprimés à un LLM.
Deraison donne un autre exemple concret : le workflow d'audit de code source qu'Entro a sorti la veille. Ce n'est pas un simple "trouve-moi des failles", mais un pipeline complet : identification d'une faille, compilation du binaire, génération d'un proof of concept, vérification que l'exploitation est réelle, déduplication, reporting, patch. Un tel workflow supprime en grande partie le métier d'AppSec tel qu'il existe aujourd'hui.
Deraison ne tranche pas, mais pose les questions : les équipes de sécurité en 2030 seront-elles organisées différemment ? Sa vision pré-LLM était que les plateformes Ops (Microsoft, Datadog) absorberaient progressivement la sécurité, laissant aux équipes dédiées les rôles de compliance et de réponse à incident. Avec les LLM, une troisième option émerge : une division ingénierie sécurité capable de construire des outils sur mesure aussi vite que d'acheter des briques off-the-shelf.
La mise en garde est claire : ne pas adopter l'IA dans ses processus aujourd'hui, c'est se faire dépasser par ceux qui savent s'en servir. Il reconnaît que l'exercice requiert une discipline particulière pour les techniciens expérimentés : la tentation de rester dogmatique face à des technologies qu'on a vues échouer par le passé est réelle. Mais les modèles changent toutes les semaines — ce qui était nettement insuffisant il y a dix-huit mois peut être parfaitement utilisable aujourd'hui.
La session de questions a abordé plusieurs points d'accroche.
La sécurité de Bromure lui-même. Deraison reconnaît franchement qu'il n'a pas relu tout le code source, que l'audit a été confié à Claude et à ChatGPT, et que c'est un leap of faith. Il fait confiance à la qualité des modèles sur les problèmes de sécurité — qu'il qualifie de "problème assez facile" car la surface est finie : on prend du code source et on cherche des problèmes. On verra si en 2027 on parle du "gros hack de Bromure", dit-il.
L'avenir des développeurs juniors. Un professeur d'école d'ingénieurs exprime son inquiétude : les étudiants qui n'ont connu que les LLM ne sauront peut-être pas comment sont composés les blocs qu'ils assemblent. Deraison reconnaît le problème tout en ouvrant une piste : peut-être faut-il désapprendre certaines habitudes de pensée. Son exemple — construire un tableau de suivi de factures en saisissant manuellement chaque champ alors qu'un LLM peut extraire et structurer l'information directement — illustre une dissonance cognitive entre la logique de l'informatique traditionnelle et ce que les modèles permettent. Il reste ouvert sur l'issue : peut-être que les profils capables d'aller au-delà des limites des modèles deviendront plus rares et plus recherchés.
La souveraineté. Si la majorité de la programmation mondiale se concentre sur deux ou trois modèles contrôlés par des entreprises américaines, les nations qui les contrôlent auront une forme de mainmise sur la production logicielle mondiale. Deraison reconnaît la légitimité de la question, mise sur la confiance dans le marché et l'intérêt financier comme garde-fous, et espère que Mistral monte en puissance.
La valeur du code à terme zéro. Sa thèse de fond, répétée en conclusion : la valeur du code tend asymptotiquement vers zéro. Dans cinq à dix ans, ce qui fera la valeur d'une startup ne sera pas son code — ce sera son go-to-market, sa capacité à vendre, à maintenir ses infras, à parler de ce qu'elle fait. Ce qui devrait, mécaniquement, favoriser l'open source : si le code ne vaut plus rien, autant le partager.
Conférence de clôture du SSTIC 2026 — Renaud Deraison — 5 juin 2026, Couvent des Jacobins, Rennes. Vidéo disponible sur sstic.org.