Applications mobiles, sites web, SAAS…
Je m'abonne à la newsletter 💌
Le 21 octobre 2026, le CERT-FR, centre d’alerte de l’ANSSI, a signalé deux failles de sécurité critiques dans PHP, le langage sur lequel reposent WordPress et une grande partie des sites et applications web. Des tentatives d’attaque avaient été observées quatre jours avant même la publication du correctif.
Une question simple, alors : vos sites et vos applications sont-ils concernés ?
Si vous êtes dirigeant ou manager, il y a de fortes chances que vous ne puissiez pas répondre seul. Pas par négligence : cette information ne remonte tout simplement jamais jusqu’à vous. Elle vit dans les outils de vos développeurs, dans la tête de votre DSI ou chez un prestataire. Chez I SEE U, nous avons conçu Libwatch pour changer cela.
Vos logiciels sont assemblés avec des centaines de briques que vous n'avez jamais vues
Un site ou une application n’est presque jamais écrit de A à Z. Vos développeurs assemblent des composants open source, que l’on appelle des dépendances : un module de paiement, un outil d’envoi d’emails, une bibliothèque de gestion des dates. C’est une bonne pratique : on ne réinvente pas ce qui existe et qui a fait ses preuves.
Selon le rapport OSSRA 2026 de Black Duck, 98 % des logiciels analysés contiennent de l’open source, avec en moyenne 1 180 composants par application.
Pensez à un immeuble de bureaux. Vous ne fabriquez ni l’ascenseur, ni la chaudière, ni les serrures. Mais si le fabricant d’un modèle de serrure annonce un défaut, vous devez savoir très vite si vos portes en sont équipées. Pour vos logiciels, c’est exactement pareil, sauf que personne ne vous envoie le courrier de rappel.
Il y a aussi les fondations : la version du langage (PHP, Ruby, Python, Node.js…). Chaque version a une date de fin de support, après laquelle plus aucun correctif de sécurité n’est publié. Un site WordPress parfaitement à jour qui tourne encore sur PHP 8.1 reste exposé : cette version n’est plus corrigée depuis fin 2025.
Pourquoi les failles de sécurité restent invisibles pour les dirigeants
Le problème n’est pas que les failles existent : c’est inévitable. Le même rapport OSSRA relève en moyenne 581 vulnérabilités par base de code, un chiffre qui a plus que doublé en un an. La vraie question est ailleurs : lesquelles vous concernent, et lesquelles sont réellement exploitées par des attaquants ?
Or cette information se heurte à trois obstacles :
- elle est technique : bulletins en anglais, numéros CVE, scores de gravité. Rien qui ne remonte naturellement en comité de direction ;
- elle est éparpillée : un dépôt de code par projet, des sites WordPress chez différents hébergeurs, des applications livrées par plusieurs prestataires au fil des années ;
- elle n’a pas de propriétaire : vos développeurs sont mobilisés sur les nouvelles fonctionnalités. Le site vitrine refait il y a quatre ans ou l’outil interne que plus personne ne touche ne sont surveillés par personne.
Résultat : la personne qui signe les budgets et porte la responsabilité finale est souvent la dernière informée.
Ce que vous risquez concrètement
Une faille de sécurité non corrigée n’est pas un sujet technique. C’est un risque d’entreprise, au même titre qu’un risque juridique ou financier :
- l’arrêt de service : un site e-commerce piraté ou une application bloquée, ce sont des ventes perdues chaque heure. ;
- la fuite de données : en cas de violation de données personnelles, le RGPD vous impose de notifier la CNIL sous 72 heures, et parfois d’informer chaque personne concernée ;
- la confiance de vos clients : les grands comptes envoient de plus en plus de questionnaires de sécurité à leurs fournisseurs, et « comment suivez-vous les vulnérabilités de vos logiciels ? » en fait presque toujours partie.
- la conformité : depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants et éditeurs de produits numériques de signaler toute vulnérabilité activement exploitée. La directive NIS2, en cours de transposition en France avec la loi Résilience, fait de la cybersécurité une responsabilité de la direction.
Et le temps joue contre vous. Dans le cas de la faille PHP d’octobre, les attaques ont précédé le correctif de quatre jours. Une entreprise qui découvre le problème trois semaines plus tard, par hasard, a déjà perdu la course.
Libwatch : la veille de sécurité qui parle enfin aux dirigeants
Libwatch est une plateforme SaaS éditée par I SEE U. Son rôle : surveiller en permanence les composants et les versions de langage de tous vos projets, et vous prévenir quand une faille vous concerne vraiment.
Une mise en place en quelques minutes
Votre développeur, votre DSI ou votre prestataire connecte vos projets : dépôts GitHub ou GitLab, et sites WordPress. Libwatch dresse alors l’inventaire de tout ce qui compose vos logiciels. Aucune modification de vos outils n’est nécessaire, et le premier projet est analysé en quelques minutes.
Chaque nuit, tous vos projets revérifiés
À 2 h du matin, Libwatch recroise votre inventaire avec les nouvelles failles publiées, y compris pour les projets auxquels personne n’a touché depuis des mois. Il intègre bien sur les alertes du CERT-FR sur PHP mais également les autres technologies : une version touchée est signalée au plus tard la nuit suivante.
Les urgences d'abord
Toutes les failles ne se valent pas. Libwatch place en tête celles qui sont activement exploitées par des attaquants (recensées dans le catalogue KEV de l’agence américaine de cybersécurité), puis les plus graves. Il signale aussi les fins de support de vos langages et frameworks, pour anticiper les migrations au lieu de les subir. Vous savez quoi corriger en premier, et pourquoi.
Une alerte qui arrive au bon endroit
Les alertes partent par e-mail, Slack, ou webhook, avec un résumé hebdomadaire. Toute l’équipe voit les mêmes informations, y compris la direction.
Votre code reste chez vous
Libwatch ne copie pas votre code et ne l’exécute pas : il lit uniquement la liste des composants et de leurs versions. La plateforme est hébergée en France chez OVHcloud, un point qui compte pour votre DPO comme pour vos clients.
Des preuves pour vos clients et vos auditeurs
Libwatch exporte une nomenclature logicielle (SBOM), autrement dit la liste des ingrédients de vos logiciels, aux formats standards CycloneDX et SPDX. Un journal d’audit trace qui a connecté, modifié ou supprimé quoi. De quoi répondre sereinement à un questionnaire de sécurité ou préparer vos obligations réglementaires.
Avant et après Libwatch : un exemple concret
Mardi matin, la presse spécialisée relaie une faille critique dans PHP. Votre principal client vous écrit : « Êtes-vous concernés ? »
Sans Libwatch, vous transférez la question à votre équipe technique. Il faut retrouver la liste des projets, identifier qui les maintient, vérifier chaque version. La réponse arrive dans plusieurs jours, à condition que les personnes qui connaissent les anciens projets soient encore là.
Avec Libwatch, l’alerte vous attendait déjà dans votre boîte mail. Vous savez que deux projets sur douze sont concernés, que l’un tourne sur une version qui n’est plus maintenue, et lequel traiter en premier. Vous répondez à votre client avant midi.
Libwatch ne remplace pas votre équipe : il lui donne la bonne priorité, et il vous donne la visibilité.
Combien coûte Libwatch ?
Libwatch se paie au projet (un dépôt de code ou un site WordPress compte pour un projet), avec des utilisateurs inclus.
Toutes les offres comprennent la veille nocturne, les alertes, le suivi des fins de support et l’hébergement en France. Chacune peut être testée 14 jours, sans prélèvement avant la fin de l’essai (détail des tarifs). Comparé au coût d’une journée d’arrêt de votre site ou d’une fuite de données, le calcul est vite fait.
FAQ
Une question avant de vous lancer ?
Je ne suis pas technicien : Libwatch est-il fait pour moi ?
Oui. La connexion des projets demande quelques minutes à votre équipe technique ou à votre prestataire. Ensuite, Libwatch vous dit clairement ce qui est urgent, ce qui peut attendre et ce qui arrive en fin de support.
Faut-il donner accès à notre code source ?
Libwatch lit uniquement les fichiers qui listent vos composants, via les accès GitHub ou GitLab que vous autorisez. Aucun dépôt n'est copié, aucun code n'est exécuté, et les données sont hébergées en France.
Mon site est sous WordPress : est-il couvert ?
Oui. Un site WordPress compte comme un projet, au même titre qu'un dépôt de code. Vous suivez vos sites et vos applications dans un seul outil.
Libwatch corrige-t-il les failles ?
Non, et c'est volontaire : la correction reste entre les mains de votre équipe ou de votre prestataire. Libwatch leur dit quoi corriger en premier. Si vous manquez de ressources pour traiter les mises à jour, l'équipe I SEE U peut prendre le relais.
Quelles technologies sont couvertes ?
PHP, JavaScript, Python, Ruby, Java, Kotlin, Go, .NET, Rust, Swift, Dart et Flutter, ainsi que les sites WordPress : 14 gestionnaires de paquets au total.
Reprenez la main sur la sécurité de vos logiciels
Depuis 2009, nous avons livré plus de 300 projets web et mobiles. Nous savons qu’un logiciel ne s’arrête pas le jour de sa mise en ligne : il vieillit, et ses failles avec lui. Libwatch vous permet de suivre ce vieillissement sans devenir technicien.
Deux façons de démarrer :
- vous avez une équipe technique ou un prestataire : demandez-lui de connecter un premier projet et essayez Libwatch gratuitement pendant 14 jours.
- vous n’avez personne en interne, ou vous voulez un regard extérieur : contactez l’équipe I SEE U, nous regardons ensemble où en sont vos sites et applications.
