On croirait encore lire le scénario d'un nouveau Terminator, mais pour une fois, ce n'est pas de la science-fiction. Tenez vous bien, il y a actuellement ne résistance souterraine qui est réellement en train de s'organiser pour lutter contre les géants de l'IA.
Leur nom de code : "Poison Fountain".
Je suis tombé sur
cet article de Craig Smith chez Forbes
que je vous invite à lire et qui détaille ce mouvement d'un nouveau genre. Alors pour le moment, ça tient plus du manifeste un peu énervé que du logiciel de résistance clé en main, mais l'intention est claire. Ce que veut faire Poison Fountain c'est "miner" le web avec des données piégées pour que les prochaines générations d'IA s'intoxiquent en les ingérant.
Leur méthode repose sur des outils comme
Nightshade
, dont je vous ai déjà parlé, avec lequel vous prenez une image, disons une vache et l'outil modifie les pixels de façon invisible pour l'œil humain, de sorte que l'IA l'interprète ça comme... un camion. Alors que nous, avec nos petits yeux nous voyons toujours Marguerite.
Ainsi, si un modèle avale trop de ces données corrompues, il ne devient pas juste moins performant, mais commence également à faire des associations délirantes. C'est le principe du data poisoning et si Poison Fountain parvient à encourager massivement cette pratique, les crawlers d'OpenAI ou Google vont avoir des sueurs froides.
Bon, il ne faut pas s'emballer non plus car nettoyer un dataset contaminé est un enfer technique (il faut parfois tout réentraîner), mais les ingénieurs en face ont de la ressource. Ils finiront probablement par filtrer plus agressivement ou par se rabattre sur des données certifiées et sous licence. C'est plus cher, c'est moins frais, mais c'est la parade logique.
En tout cas, c'est le genre de dérive que craignait
Geoffrey Hinton
en quittant Google sauf que la perte de contrôle n'est pas accidentelle mais provoquée volontairement par des artistes et des activistes.
Alors est-ce du cyber-vandalisme comme l'a été le DDoS à une époque, ou est-ce de la légitime défense ?
Le débat est lancé, tout comme la guérilla de la data !
La gestion des vulnérabilités est souvent perçue comme un exercice purement technique : surveiller les failles, appliquer les correctifs, réduire l’exposition.
Sur le terrain, la réalité est bien différente. Avec plus de 130 nouvelles vulnérabilités publiées chaque jour, aucune organisation ne peut raisonnablement tout suivre, tout analyser et tout corriger. Pourtant, beaucoup continuent d’essayer.
Les organisations les plus matures ne sont pas celles qui traitent le plus d’alertes, mais celles qui ont structuré une méthode claire, reproductible et mesurable. Cette maturité repose généralement sur quatre étapes clés.
1. Accepter que tout surveiller est impossible, et définir ce qui compte vraiment
La première rupture consiste à abandonner l’illusion du “tout surveiller”. Surveiller l’intégralité des vulnérabilités publiées n’est pas seulement irréaliste, c’est contre-productif. Une organisation de taille moyenne utilise typiquement plusieurs dizaines d’éditeurs et parfois plus d’une centaine de produits différents. Sans périmètre clair, la veille devient rapidement ingérable.
Les organisations matures commencent par cartographier leurs éditeurs et produits réellement critiques : applications métier centrales, systèmes exposés sur Internet, environnements traitant des données sensibles. L’objectif n’est pas l’exhaustivité, mais la pertinence. Dans la pratique, 20 % des actifs concentrent souvent 80 % du risque. C’est sur ce périmètre assumé que la veille doit être prioritairement focalisée.
2. Structurer les sources et transformer le flux en information utile
Une fois le périmètre défini, encore faut-il s’informer efficacement. Les bulletins de sécurité des éditeurs restent les sources les plus fiables, complétées par les bases de données officielles comme les référentiels CVE. Mais s’appuyer uniquement sur ces bases expose à des angles morts : certaines vulnérabilités ne sont jamais cataloguées ou arrivent tardivement.
Sans filtrage ni centralisation, les équipes peuvent voir remonter des dizaines, voire des centaines d’alertes par jour, dont seule une minorité concerne réellement leur environnement. Les organisations matures cherchent donc à réduire le bruit : elles centralisent les sources, filtrent par éditeurs et produits suivis, et surtout qualifient l’information pour la rendre actionnable.
3. Prioriser au-delà du score CVSS et clarifier les responsabilités
Le score CVSS reste un indicateur utile, mais insuffisant. Une vulnérabilité très sévère sur un serveur de test isolé ne présente pas le même risque qu’une faille “moins critique” sur un service exposé et stratégique. Les organisations matures complètent donc l’évaluation technique par des critères contextuels : exposition réelle, exploitabilité connue, impact métier, sensibilité des données.
Cette priorisation n’a de valeur que si elle s’accompagne d’une organisation claire. Qui est responsable de la correction ? Dans quels délais ? Que fait-on lorsqu’un correctif n’est pas applicable ? Sans réponses explicites, les alertes s’accumulent et les décisions se diluent. La mise en place d’une matrice de gestion des correctifs (traitement immédiat, rapide, planifié ou mise en veille) devient alors un langage commun entre équipes techniques, sécurité et direction.
4. Mesurer pour piloter et faire évoluer le dispositif
La dernière étape distingue clairement les organisations réactives des organisations matures : la mesure. Traçabilité des décisions, délais de correction par niveau de criticité, taux de couverture des actifs critiques… Ces indicateurs transforment la gestion des vulnérabilités en levier de pilotage, et non plus en simple flux d’alertes.
Les retours d’expérience montrent qu’une veille structurée permet de réduire drastiquement le temps passé à trier l’information, souvent de plusieurs heures par jour à quelques dizaines de minutes, tout en améliorant la réactivité sur les vulnérabilités réellement critiques. À moyen terme, cette mesure gérée en continu permet d’optimiser les processus et d’anticiper les périodes de charge, plutôt que de subir l’urgence permanente.
La maturité en gestion des vulnérabilités ne repose ainsi ni sur la multiplication des outils ni sur la surveillance exhaustive. Elle repose sur des choix assumés, une priorisation contextualisée, une organisation claire et une capacité à mesurer dans le temps. Dans un contexte où le volume de vulnérabilités ne cesse d’augmenter, la capacité à décider devient aussi importante que la capacité à détecter.
* Marc Béhar est PDG Fondateur du cabinet de conseil en cybersécurité XMCO
« Et puis il y a eu ce post LinkedIn qui a attiré l’attention d’Octave Klaba […] »
Jérôme Masurel, président de 50 Partners, contextualise ainsi l’acquisition de SEALD par OVHcloud. L’accélérateur connaît bien cette entreprise francilienne : il avait participé, en 2018, à sa levée d’amorçage.
Depuis lors, SEALD est resté sur le même créneau : le chiffrement de bout en bout. Sa technologie se décline en logiciels bureautiques et sous forme de SDK. Elle avait obtenu le visa CSPN en décembre 2020 (trois ans de validité).
Les premières briques de SEALD posées en Californie
Créé en 2016, SEALD s’est d’abord appelé STASH. Ce pendant quelques semaines, le temps qu’une agence marketing française portant le même nom lui adresse une mise en demeure.
Les quatre fondateurs étaient alors dans leur vingtaine. Trois d’entre eux avaient convergé à UC Berkeley, dans le cadre d’un programme en partenariat avec l’École polytechnique. Les jalons de SEALD furent posés sur place par Timothée Rebours (32 ans aujourd’hui), qui prendrait la présidence de l’entreprise. Aux côtés de trois directeurs généraux : Mehdi Kouen (33 ans, CTO), Maxime Huber (34 ans, CPO) et Dan Lousqui (37 ans, directeur de la sécurité informatique).
Quelques semaines avant l’obtention de la CSPN, SEALD avait fait partie des finalistes du prix de l’innovation des Assises de la sécurité. Plus récemment (2023), il a figuré dans les lauréats de l’appel à projets « Suites bureautiques collaboratives cloud », en consortium avec Linagora, WaToo, Wimi et XWiki. Entre-temps, il y avait eu une alerte : une continuation d’activité malgré la perte de la moitié du capital.
Framatome et Stellantis comme références
La déclinaison « bureautique » de SEALD est basée sur une application desktop (Windows, Mac, Linux) qui permet de chiffrer des fichiers, d’assurer leur suivi et de contrôler les accès. La technologie couvre aussi les e-mails et leurs pièces jointes, en éventuelle conjonction avec les moteurs de DLP.
La version « bibliothèque logicielle » permet d’intégrer du chiffrement côté client dans des apps web, mobiles et de bureau. La promesse par rapport aux bibliothèques open source : supprimer les difficultés de gestion des clés, des appareils multiples, des droits d’accès sur les données, etc. Des SDK sont disponibles pour JavaScript, Android, iOS et Flutter.
Framatome y a fait appel pour sécuriser une application interne collectant des données sensibles. L’opérateur télécoms belge Proximus, pour une application de téléconsultation médicale (Doktr). Recare, pour son outil de bed management (orchestration des transferts interhospitaliers). Lovehoney Group, pour protéger une messagerie de couple basée sur CometChat. Stellantis et Lefebvre Sarrut font aussi partie des clients.
Le ticket d’entrée est à 250 €/mois pour 5000 utilisateurs protégés. Au-delà, SEALD facture un supplément dégressif par utilisateur (0,04 €jusqu’à 20 000 ; 0,03 € jusqu’à 50 000 ; 0,02 € au-delà).
« Ensemble, nous allors démocratiser [la] sécurité dans les services [collaboratifs] (et pas que…) », commente Octave Klaba.
Connexion
