Pour un développeur ou un indie hacker, le risque cyber se joue désormais en heures, pas en semaines. Une faille publiée dans un framework web peut être exploitée automatiquement le jour même. Un secret oublié dans un dépôt peut être revendu, puis utilisé à vos frais. Et si des données personnelles sont touchées, le RGPD fixe un délai de 72 heures pour notifier la CNIL. Ce guide vous aide à faire trois choses : réduire l’exposition technique, savoir qui doit notifier quoi, et vérifier ce que votre RC Pro, une assurance cyber et vos contrats prennent réellement en charge. Aucune assurance ne remplace les mises à jour, et chaque garantie dépend des conditions du contrat signé.
Ce qui a changé : des failles exploitées avant même d’être corrigées partout
L’épisode dit « React2Shell » résume bien la situation. Le 3 décembre 2025, l’équipe React a publié un avis sur une vulnérabilité critique des React Server Components (CVE-2025-55182), notée 10 sur 10 en gravité CVSS. Elle permettait d’exécuter du code à distance sur le serveur sans authentification. Next.js, qui embarque ces composants avec l’App Router, a publié le même jour son avis de sécurité. Il ne proposait aucun contournement : il fallait mettre à jour. L’identifiant propre à Next.js, CVE-2025-66478, a ensuite été rejeté comme doublon de CVE-2025-55182.
La suite montre la vitesse du marché criminel :
- AWS a observé des tentatives d’exploitation par des groupes liés à un État quelques heures après la divulgation publique ;
- la CISA, l’agence américaine de cybersécurité, a ajouté la faille à son catalogue des vulnérabilités activement exploitées (KEV) le 5 décembre 2025 ;
- le CERT-FR a émis l’alerte CERTFR-2025-ALE-014 et a recommandé de considérer comme compromis les serveurs vulnérables restés exposés après la publication des preuves de concept ;
- Next.js a ajouté une consigne souvent négligée : une application en ligne et non corrigée au 4 décembre 2025 devait aussi faire tourner (renouveler) l’ensemble de ses secrets.
Ce n’est pas un cas isolé. Selon VulnCheck (janvier 2026), 28,96 % des vulnérabilités ajoutées au catalogue KEV en 2025 ont été exploitées le jour de la publication de leur CVE, voire avant. Mandiant, dans son rapport M-Trends 2026 résumé par Help Net Security, estime que le délai moyen d’exploitation est devenu négatif : en moyenne, l’attaque précède désormais le correctif.
Ce que l’IA change concrètement côté attaquant
L’IA ne crée pas de nouvelles catégories d’attaques, mais elle réduit le coût de chaque étape. En novembre 2025, Anthropic a décrit une campagne d’espionnage où un agent d’IA aurait exécuté 80 à 90 % des opérations (reconnaissance, recherche de failles, collecte d’identifiants) contre une trentaine de cibles. Le même mois, le groupe de renseignement de Google a signalé les premières familles de logiciels malveillants qui interrogent un modèle de langage pendant leur exécution. Pour une petite équipe, la conséquence pratique est simple : un serveur exposé, un tableau de bord oublié ou un dépôt public est scanné, trié et attaqué sans qu’un humain ait besoin de s’y intéresser.
Les secrets volés : une facture, puis un problème de réputation
Une clé d’API, un jeton d’accès ou un identifiant cloud est un actif monnayable. Une fois récupéré, il est testé automatiquement, revendu ou utilisé directement. Les usages les plus documentés sont les suivants :
- la consommation de services payants : Sysdig a décrit le « LLMjacking », c’est-à-dire l’usage d’identifiants cloud volés pour interroger des modèles d’IA aux frais de la victime, avec un coût potentiel de plus de 46 000 dollars par jour ;
- la revente de l’accès ou son usage pour mener d’autres attaques ;
- l’accès aux données : base de données, stockage objet, outil de support client ou CRM.
Le volume progresse. GitGuardian, dans son rapport State of Secrets Sprawl 2026, recense environ 28,6 millions de nouveaux secrets exposés sur GitHub public en 2025, ainsi que 1,27 million de secrets de services d’IA exposés, et observe que les dépôts internes sont six fois plus susceptibles que les dépôts publics de contenir des secrets écrits en clair.
Le coût ne s’arrête pas à la facture du fournisseur. Un compte détourné peut être suspendu par le prestataire et servir à d’autres attaques qui ternissent votre image. Cette réputation se reconstruit lentement : elle doit figurer dans votre plan de réponse au même titre que la rotation des clés.
Dépendances et outils d’IA de code : la surface d’attaque que vous n’avez pas écrite
Le code que vous livrez contient surtout du code que vous n’avez pas écrit. Trois épisodes récents l’illustrent :
- le 8 septembre 2025, le compte d’un mainteneur npm a été pris par hameçonnage. Des versions piégées de paquets très utilisés, comme chalk et debug, ont été publiées. Selon StepSecurity, ces paquets cumulent plusieurs milliards de téléchargements par semaine ;
- quelques jours plus tard, le ver « Shai-Hulud » s’est propagé seul dans l’écosystème npm. La CISA a fait état de plus de 500 paquets compromis et a demandé de renouveler les identifiants des développeurs. Une seconde vague, en novembre 2025, s’exécutait dès l’installation des paquets, selon Wiz ;
- les assistants de code peuvent proposer des paquets qui n’existent pas. Une étude présentée à USENIX Security 2025 mesure au moins 5,2 % de dépendances inventées pour les modèles commerciaux testés et 21,7 % pour les modèles ouverts. Un attaquant peut enregistrer ces noms et attendre qu’on les installe (« slopsquatting »).
Les agents qui exécutent du code ajoutent un risque supplémentaire : l’injection de prompt. Un fichier, un ticket ou une page web contient des instructions que l’agent suit. La faille CVE-2025-54135 de l’éditeur Cursor, corrigée en version 1.3.9, permettait ainsi de modifier une configuration et d’exécuter des commandes. Le Top 10 OWASP pour les applications LLM classe l’injection de prompt en tête des risques. En pratique, un agent de code ne devrait jamais avoir accès aux secrets de production, ni le droit de publier ou de déployer sans relecture humaine.
Scénario pédagogique : les 72 premières heures d’une petite équipe
Ce scénario est fictif et composite. Il sert à ordonner les décisions, pas à décrire un cas réel.
Une petite équipe édite une application SaaS pour des professionnels. Un matin, l’équipe apprend qu’une dépendance installée la veille contenait un code malveillant ; des jetons d’accès présents sur la machine de build ont pu être copiés. L’équipe ne sait pas encore si des données de ses utilisateurs ont été consultées.
| Moment | Décision à prendre | Erreur fréquente |
|---|---|---|
| Première heure | Révoquer et remplacer les jetons exposés, puis tous les secrets présents sur la même machine. Retirer la version piégée et reconstruire depuis une source saine. | Effacer les journaux ou réinstaller le serveur avant d’avoir conservé les traces. |
| Premières heures | Ouvrir une main courante datée : faits constatés, actions, personnes informées. Conserver journaux, alertes et factures. | Tout gérer au téléphone sans écrit, ce qui empêche ensuite de justifier les délais. |
| Jour 1 | Qualifier : des données personnelles ont-elles été accessibles ? Lesquelles, combien de personnes, quel risque pour elles ? Prévenir l’assureur selon la procédure du contrat. | Conclure « aucune donnée touchée » sans l’avoir vérifié dans les journaux d’accès. |
| Avant 72 heures | Notifier la CNIL si la violation présente un risque pour les personnes, même avec des informations incomplètes. Si l’équipe est sous-traitante, prévenir d’abord le client responsable du traitement. Déposer plainte, condition de l’indemnisation par l’assurance. | Attendre la fin de l’enquête technique pour notifier. |
| Ensuite | Informer les personnes concernées si le risque est élevé. Corriger la cause et documenter les mesures. | Envoyer un message rassurant aux utilisateurs avant de connaître l’étendue réelle de l’incident. |
Perte de données : ce que le RGPD et la CNIL exigent vraiment
Une « violation de données personnelles » ne se limite pas à un vol. Le RGPD vise aussi une destruction, une perte, une altération ou un accès non autorisé, qu’il soit accidentel ou malveillant. Un secret exposé qui donnait accès à une base d’utilisateurs peut donc suffire, même sans preuve d’exfiltration.
Responsable de traitement ou sous-traitant : qui notifie ?
| Votre situation | Votre rôle probable | Votre obligation |
|---|---|---|
| Vous éditez et exploitez votre propre produit (SaaS, application, newsletter) | Responsable de traitement | Notifier la CNIL et, si le risque est élevé, informer les personnes ; tenir le registre des violations. |
| Vous développez et hébergez ou maintenez l’application d’un client qui détermine l’usage des données | Sous-traitant (article 28) | Prévenir votre client « dans les meilleurs délais » (article 33, paragraphe 2) et l’aider à remplir ses propres obligations. |
| Vous livrez un code sans accès aux données en production | Souvent ni l’un ni l’autre pour cette violation | Votre responsabilité contractuelle peut toutefois être recherchée si l’incident vient d’un défaut de votre livrable. |
La qualification dépend des faits et du contrat, pas du titre que vous vous donnez. En cas de doute, les lignes directrices 9/2022 du comité européen de la protection des données détaillent les cas de notification avec des exemples.
Le délai de 72 heures et le registre
- Article 33 du RGPD : le responsable de traitement notifie la violation à la CNIL « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance », sauf si elle n’est pas susceptible d’engendrer un risque pour les personnes. Passé ce délai, la notification doit expliquer le retard. Elle peut être faite en plusieurs temps si toutes les informations ne sont pas encore disponibles.
- Registre : toute violation, même non notifiée, doit être documentée (faits, effets, mesures prises). C’est ce registre qui permet de justifier, en cas de contrôle, une décision de ne pas notifier.
- Article 34 : si la violation est susceptible d’engendrer un risque élevé pour les personnes (données bancaires, identifiants réutilisables, données sensibles, usurpation d’identité possible), il faut les informer directement, en termes clairs, sauf exceptions prévues par le texte (données chiffrées et clés non compromises, par exemple).
La notification se fait en ligne sur le téléservice de la CNIL. La CNIL explique la démarche sur sa page « Notifier une violation de données personnelles ».
Pourquoi c’est un casse-tête pour une petite équipe
Le délai court à partir du moment où vous savez, pas à partir du moment où vous avez tout compris. Or, dans une petite structure, la même personne doit à la fois contenir l’incident, analyser les journaux, répondre au fournisseur et préparer la notification. Les difficultés les plus courantes sont prévisibles : absence de journaux d’accès suffisants pour exclure une consultation, contrat client muet sur le délai d’alerte, aucune trace écrite des décisions et des horaires. Préparer un modèle de notification et une liste de contacts avant l’incident fait gagner l’essentiel de ces heures.
Un autre délai de 72 heures concerne l’assurance. Depuis le 24 avril 2023 (loi LOPMI), l’article L12-10-1 du Code des assurances subordonne l’indemnisation des pertes et dommages causés par une atteinte à un système de traitement automatisé de données (articles 323-1 à 323-3-1 du Code pénal) au dépôt d’une plainte au plus tard 72 heures après que la victime en a eu connaissance. La règle s’applique aux personnes morales et aux personnes physiques dans le cadre de leur activité professionnelle.
RC Pro informatique et assurance cyber : qui paie quoi ?
Les deux contrats sont souvent confondus. Ils répondent pourtant à deux questions différentes. La RC Pro répond à la question : « mon client me reproche un dommage causé par mon travail, qui paie ? ». L’assurance cyber répond à la question : « mon système ou celui que j’exploite est attaqué, qui paie la gestion de crise et mes pertes ? ». Le tableau ci-dessous décrit les prises en charge que l’on rencontre généralement sur le marché. Chaque contrat a ses propres définitions, plafonds, franchises et exclusions : seules les conditions générales et particulières signées font foi.
| Situation | RC Pro informatique (en général) | Assurance cyber (en général) | Point à vérifier dans votre contrat |
|---|---|---|---|
| Un client subit un préjudice à cause d’une faille dans le code livré | Peut intervenir sur la réclamation du client (erreur, omission, négligence) | Volet responsabilité civile parfois inclus | Exclusion des failles connues non corrigées, plafond par sinistre |
| Frais d’expert pour enquêter et contenir l’attaque | Rarement | Garantie centrale des contrats cyber | Délai de déclaration, prestataires imposés ou agréés |
| Notification CNIL et information des personnes | Rarement | Fréquemment prévue (frais de notification, assistance juridique) | Plafond spécifique, prise en charge du conseil juridique |
| Facture d’un service détourné avec un secret volé | Non, en principe | Variable : certains contrats couvrent la fraude à l’usage, d’autres l’excluent | Définition de la « fraude » et des « frais d’utilisation frauduleuse » |
| Interruption de votre propre service | Non, en principe | Pertes d’exploitation, souvent après une franchise en heures | Mode de calcul de la perte, dépendance aux fournisseurs cloud |
| Amende administrative de la CNIL | Généralement exclue | Généralement exclue ou limitée à ce que la loi permet | Ne jamais considérer une amende comme assurée sans texte explicite |
Pour un indie hacker qui exploite son propre produit, la cyber répond aux premiers coûts de l’incident. Pour un développeur qui travaille pour des clients, la RC Pro est le socle, et le client peut lui-même avoir besoin de sa propre cyber. Les assureurs posent de plus en plus de questions sur l’authentification multifacteur, les sauvegardes et la gestion des mises à jour : une réponse inexacte au questionnaire peut fragiliser la garantie. Pour comparer les offres de RC Pro, notre comparatif RC Pro informatique détaille les critères de choix, et notre guide de l’assurance cyber décrit les garanties.
Les clauses de contrat qui protègent le développeur et son client
L’assurance n’absorbe que ce que le contrat met à votre charge. Un contrat de prestation bien rédigé limite donc l’exposition avant même l’incident. Points à faire relire par un juriste :
- Limitation de responsabilité : plafond (souvent lié au montant du contrat), exclusion des dommages indirects et articulation avec le plafond de votre RC Pro. Un plafond contractuel supérieur à votre plafond d’assurance laisse un écart à votre charge.
- Accord de sous-traitance RGPD (article 28) : objet et durée du traitement, mesures de sécurité, sous-traitants ultérieurs (hébergeur, services tiers, outils d’IA), délai d’alerte en cas de violation exprimé en heures, et assistance au client pour sa notification.
- Obligation de sécurité : préciser qu’il s’agit d’une obligation de moyens, décrire les mesures attendues (mises à jour, gestion des secrets, sauvegardes) et qui paie la veille et les correctifs après la livraison.
- Maintenance et correctifs : qui applique une mise à jour critique comme React2Shell, dans quel délai, et à quel prix si aucun contrat de maintenance n’a été signé.
- Accès et secrets : qui détient les comptes de production, les clés et les domaines ; comment ils sont restitués à la fin de la mission.
- Assurances : attestation de RC Pro à jour, éventuellement exigence d’une assurance cyber de part et d’autre.
Checklist : ce qu’un développeur peut faire cette semaine
- Inventorier vos applications en production, leurs frameworks et versions, ainsi que leurs dépendances directes.
- Abonner une adresse partagée aux alertes de sécurité de vos frameworks et activer les alertes de dépendances de votre forge (Dependabot ou équivalent).
- Corriger dans les 24 à 48 heures toute faille critique exploitée (présente dans le catalogue KEV ou signalée par le CERT-FR), y compris sur les projets « finis ».
- Sortir les secrets du code : gestionnaire de secrets ou variables d’environnement chiffrées, analyse automatique des commits (pre-commit et CI) et historique Git nettoyé.
- Limiter chaque clé : droits minimaux, restriction par domaine ou adresse IP quand le fournisseur le permet, plafond de dépenses et alertes de facturation.
- Faire tourner les secrets selon un calendrier, et immédiatement après un départ, une fuite ou une faille du framework.
- Verrouiller les dépendances (lockfile, versions épinglées), vérifier l’existence et l’ancienneté d’un paquet proposé par une IA avant de l’installer, désactiver les scripts d’installation quand c’est possible.
- Isoler les agents de code : aucun secret de production dans leur environnement, aucune publication ni aucun déploiement sans relecture.
- Surveiller : journaux d’accès conservés hors du serveur, alertes sur les connexions et les volumes inhabituels, authentification multifacteur sur la forge, l’hébergeur, le registre de domaines et le registre de paquets.
- Sauvegarder et tester la restauration, avec une copie hors ligne ou immuable.
- Écrire un plan de réponse d’une page : contacts (hébergeur, assureur, client, CNIL), modèle de main courante, modèle de notification, critères de qualification du risque.
- Relire vos contrats et vos attestations : délai d’alerte client, plafonds de responsabilité et d’assurance, garanties cyber disponibles.
Où suivre les failles récentes
- CERT-FR : alertes et avis de sécurité de l’ANSSI, en français ;
- catalogue CISA KEV : les vulnérabilités dont l’exploitation est avérée, à traiter en priorité ;
- NVD et CVE.org : fiches détaillées de chaque CVE ;
- GitHub Advisory Database : failles des paquets npm, PyPI, Composer et autres écosystèmes ;
- blog Next.js et bulletins Vercel pour l’écosystème React et Next.js ;
- Cybermalveillance.gouv.fr : assistance aux victimes et fiches réflexes ;
- guide d’hygiène informatique de l’ANSSI et son guide pour les TPE et PME en treize questions ;
- CNIL pour les démarches de notification.
Questions fréquentes
Si aucune donnée personnelle n’a fuité, dois-je notifier la CNIL ?
Non, si vous pouvez établir que la violation ne crée pas de risque pour les personnes, par exemple parce que l’accès a été bloqué avant toute lecture et que les journaux le montrent. Vous devez quand même inscrire l’incident et votre raisonnement dans le registre des violations.
Ma RC Pro paiera-t-elle la facture d’API générée par un secret volé ?
En principe non : la RC Pro couvre les dommages causés à des tiers, pas vos propres pertes. Certains contrats cyber prévoient une garantie de fraude à l’usage, d’autres l’excluent. La réponse se trouve dans les définitions de votre contrat.
Je travaille seul en micro-entreprise : une assurance cyber a-t-elle du sens ?
Cela dépend de ce que vous exploitez. Si vous hébergez un produit avec des utilisateurs, des paiements ou des données de clients, les frais d’expertise, de notification et d’interruption peuvent dépasser rapidement votre trésorerie. Si vous livrez du code sans rien exploiter, la RC Pro reste la priorité.
Faire le point sur votre couverture
MENELAS, courtier en assurances professionnelles, peut étudier votre exposition (produit exploité, clients, données traitées, contrats) et la présenter à des assureurs adaptés à votre profil. Décrivez votre activité sur la page assurance cyber risques pour les entreprises. L’étude ne vaut ni acceptation par un assureur ni promesse de garantie : la couverture résulte du contrat émis et de ses conditions.
Sources consultées en octobre 2026. Les versions corrigées et les recommandations évoluent : référez-vous toujours à l’avis de sécurité le plus récent de l’éditeur.
