Début 2026, la France a connu une série de cyberattaques d’une ampleur inédite. Données de santé, comptes bancaires, fédérations sportives : des dizaines de millions de Français sont concernés. Ces incidents révèlent des failles structurelles que l’ISO 27001 permet précisément d’adresser.

Cegedim : 15 millions de dossiers patients dans la nature

Fin 2025, un attaquant a exploité des comptes utilisateurs du logiciel médical MLM, édité par Cegedim Santé. Les données de près de 15 millions de patients ont été exfiltrées et mises en vente sur le dark web. Pour environ 164 000 personnes, des données potentiellement sensibles ont été compromises : les « zones de commentaires libres » des médecins contenaient parfois des annotations intimes — antécédents psychiatriques, orientation sexuelle, addictions — bien loin du caractère « administratif » revendiqué par l’éditeur.

L’incident n’a été rendu public que le 26 février 2026 par France 2, plus de deux mois après sa détection.

Sources : Communiqué Cegedim (26/02/2026) · France Info (27/02/2026) · France Assos Santé · DSIH – analyse des zones de commentaires

FICOBA : 1,2 million de comptes bancaires exposés

Le 18 février 2026, la DGFiP a révélé qu’un acteur malveillant avait accédé au fichier national des comptes bancaires en usurpant les identifiants d’un fonctionnaire. Pendant 16 jours (du 28 janvier au 13 février), l’attaquant a extrait les données de 1,2 million de comptes : coordonnées bancaires, identités et adresses des titulaires.

Sources : Communiqué DGFiP / impots.gouv.fr · economie.gouv.fr · Fédération Bancaire Française

Fédérations sportives : une hémorragie en série

Depuis fin 2025, une vingtaine de fédérations sportives ont été piratées via la compromission de comptes clubs sur leurs outils de gestion des licences. Le bilan : 11 millions de lignes pour l’athlétisme, 2,9 millions pour la gymnastique (historique depuis 2004), 1,2 million pour le tennis, 2,4 millions pour le judo, et des dizaines de millions de données au total — incluant des informations sur des mineurs.

Sources : FFGym – communiqué officiel · France Info – FF Athlétisme (21/02/2026) · Décideurs du Sport (27/02/2026) · ZATAZ

Ces trois cas partagent des failles communes, toutes adressées par la norme ISO 27001:2022. Voyons un peu.

La gestion des accès reste le maillon faible.

Un seul identifiant usurpé a suffi pour FICOBA. Des comptes clubs compromis par phishing ont ouvert les portes des fédérations. Pas de MFA, des droits trop larges, une détection tardive.

→ Mesures A.5.15 à A.5.18 et A.8.2 à A.8.5 (contrôle d’accès, gestion des identités, droits à privilèges).

La chaîne de sous-traitance démultiplie les risques

Cegedim est un prestataire ; les outils des fédérations proviennent souvent d’un même éditeur tiers. Une vulnérabilité chez le sous-traitant expose l’ensemble de ses clients.

→ Mesures A.5.19 à A.5.23 (sécurité dans les relations fournisseurs).

La conservation excessive aggrave l’impact

Des données remontant à 1999 pour la FF Ski, à 2004 pour la FFGym. Plus la surface de données est grande, plus une fuite est dévastatrice.

→ Mesure A.5.33 (protection des enregistrements) et principe de minimisation du RGPD.

La détection et la réponse restent trop lentes

Deux mois avant la révélation chez Cegedim, 16 jours d’intrusion pour FICOBA, des fédérations alertées par la publication de leurs données sur des forums.

→ Mesures A.5.24 à A.5.28 (gestion des incidents) et A.8.15 à A.8.16 (journalisation/surveillance).

Notre cabinet recommande cinq chantiers immédiats :

1. Déployer le MFA sur tous les accès critiques, sans exception. Vérifiez également la légitimité des comptes actifs.
2. Auditer la sécurité de vos prestataires : clauses contractuelles, droit d’audit, suivi régulier. L’affaire Cegedim rappelle que la confiance n’exclut pas le contrôle.
3. Purger les données obsolètes : moins de données stockées = moins d’impact en cas de fuite.
4. Tester votre capacité de réponse aux incidents : un plan de crise qui n’a jamais été exercé n’est qu’un document de conformité.
5. Sensibiliser, encore et toujours : le phishing reste le vecteur d’entrée numéro un.

Quoi qu’il en soit, ces actions nécessitent de s’y préparer. Elles ne se règlent pas en quelques tâches simples et doivent être incluses dans une gestion plus globale de la sécurité de l’information.

Consultez notre série INDISEC, ensemble d’articles ayant pour objectifs de vous aider à prioriser les actions utiles et incontournables de sécurité à mettre en oeuvre au sein d’une organisation ! 
Le premier épisode est disponible ici !

La société Akamai, acteur international de la cybersécurité, établit dans son dernier rapport State of the Internet (SOTI) que le nombre d’attaques sur des application web et API a dépassé les 311 milliards en 2024. C’est une augmentation de 33% par rapport à 2023, et cela n’est pas près de diminuer en 2025 avec notamment une utilisation massive de l’intelligence artificielle dans les attaques (création, développement, automatisation, etc.).

Dans ce paysage, la question n’est plus de savoir si vos applications seront mises à l’épreuve par un attaquant, mais quand. Auditer le code de ses applications devient donc une priorité, c’est pourquoi dans cet article nous allons étudier deux manières de tester la sécurité d’une application.

SAST (Static Application Security Testing)
Inspecte le code source, octet ou binaire pour identifier des vulnérabilités sans exécuter l’application, offrant ainsi une approche de test dîte en « boîte blanche ». L’analyse se fait par la reconnaissance de schéma de code indiquant un type connu de vulnérabilité.

DAST (Dynamic Application Security Testing)
Consiste à tester une application en cours d’exécution sans nécessairement accéder au code (approche dîte en “boîte noire”). L’analyse se fait via l’injection de charges malveillantes (XSS, SQLi…) et observe les comportements pour identifier des failles réellement exploitables. Ainsi, son intégration offre des indicateurs uniques sur des comportements au runtime et les vulnérabilités spécifiques à l’environnement, que l’analyse statique pourrait négliger.

IAST (Interactive Application Security Testing)
Combine les tests SAST et DAST. En effet, les outils analysent le code et surveillent les applications en temps réel.

SAST

• Avantages : Apparition précoce dans le SDLC, détection de vulnérabilités connues (OWASP Top Ten ou CWE), coûts et temps nécessaire à la correction des vulnérabilités identifiées réduits.
• Limites : Nombreux faux positifs possibles si les outils ne sont pas configurés avec des règles personnalisées. L’outil doit prendre en charge les langages de programmation utilisés.

DAST

• Avantages : Détection de problèmes et vulnérabilités qui ne se produisent que lorsque l’application est en cours d’exécution, validation réelle d’erreurs de configuration et de vulnérabilités vraiment exploitables.
• Limites : La détection des vulnérabilités s’effectue à un stade avancé du processus de développement. Exhaustivité dépendante de la couverture de l’application par l’outil.

IAST

• Avantages : Couverture plus complète, détecte en temps réel et génère moins de faux positifs.
• Limites : Mise en œuvre complexe, peut impacter les performances de l’application pendant les tests en cas de surveillance en continue.

En intégrant la méthode SAST dès le début du cycle de développement, idéalement juste après la validation du code, les développeurs reçoivent un retour d’information immédiat sur les problèmes de sécurité potentiels, ce qui permet d’apporter des corrections rapides.

Le DAST doit être exécuté à chaque fois que vous allez apporter une modification à votre application en production, idéalement lorsqu’elle est déployée dans un environnement de test afin que vous puissiez détecter les problèmes avant leur mise en production.

Gouvernance interne

Les entreprises qui développent des applications se doivent de mettre en place une stratégie relative à la sécurité des développements applicatifs. Cette pratique est d’autant plus importante qu’elle fait l’objet de projets de réglementations.

• Dans un premier temps, il faut rédiger et diffuser une politique sur le cycle de développement des applications dans laquelle sont décrites toutes les exigences de sécurité à respecter et les mesures de sécurité à mettre en place (dont l’audit de la sécurité du code fait partie).
• Ensuite, il faut mettre en place et documenter des processus pour les tests de sécurité (dont les SAST et DAST font partie) à effectuer au cours du cycle de vie de développement des applications.
• Enfin, les procédures décrivant aux équipes opérationnelles les fonctionnalités des outils choisis, de leurs intégrations (dans l’IDE par exemple) à leurs utilisations. Chaque procédure doit également contenir les méthodes de lecture des réponses générées (via des tableaux de bord par exemple) pour les acteurs de la chaîne de développement.

Outillage

Voici à titre informatif quelques outils clés du marché :

• SAST : Synopsys Coverity, SonarQube
• DAST : OWAS ZAP, Qualys
• IAST : Synopsys Seeker, Veracode

Vous l’aurez compris, la réponse efficace pour tester la sécurité de ses applications n’oppose pas SAST et DAST : elle les combine (séparément ou au sein d’un outil IAST). L’utilisation de ces méthodes d’audit de code au bon moment du cycle de développement de l’application (SDLC) permet de réduire la dette de sécurité en amont et de valider en aval l’exploitabilité en conditions réelles.

🤔 Vous souhaitez en savoir plus sur la gestion de la sécurité des applications web ?

• Formez-vous avec Kedros à la sécurité dans les développements !
• Faites-vous accompagner par Kedros sur votre SDLC !

👉 Suivez-nous pour ne rien manquer des dernières actualités !

• Notre page LinkedIn
• Notre site web

Saviez-vous que 60 % des PME victimes d’une cyberattaque ferment dans les 6 mois¹ ? Pour éviter ce scénario catastrophe, les organisations doivent identifier leurs risques avant qu’ils ne deviennent des incidents de sécurité. Parmi les méthodes d’appréciation des risques en cybersécurité, OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) se distingue par son approche collaborative, systématique et adaptable — quels que soient la taille ou le secteur de l’entreprise.
Développée par le Software Engineering Institute (SEI) de l’Université Carnegie Mellon, OCTAVE est une méthode éprouvée qui aide les organisations à identifier et gérer les risques de sécurité de manière rigoureuse mais pragmatique. Son principal atout ? Trois versions conçues pour s’adapter aux besoins spécifiques des entreprises, des startups aux grands groupes, que nous allons étudier dans cet article.

1 : Source : Cybersecurity Ventures, 2024

Pour qui ? 
Entreprises avec des ressources dédiées à la sécurité (DSI, RSSI) et des enjeux complexes (ex : banques, hôpitaux, infrastructures critiques).

Pourquoi choisir cette version ? 
OCTAVE Original est la méthode la plus exhaustive et collaborative des trois versions. Elle ne se limite pas à l’IT : elle intègre les enjeux métiers (ex : interruption de service en période de pic commercial) et les contraintes réglementaires (ex : conformité à la directive NIS 2 ou au RGPD).

Points clés :

• Ateliers multi-départements : Implique la direction, les opérationnels (ex : responsables logistique) et les équipes techniques pour une vision 360° des risques.
• Inventaire détaillé : Cartographie des actifs (ex : systèmes de paiement, bases de données clients), menaces (cyberattaques, pannes matérielles) et vulnérabilités (ex : failles logicielles non patchées).
• Intégration avec les normes : Compatible avec ISO 27001 ou NIST, ce qui facilite les audits et certifications.
• Livrables actionnables : Rapport structuré avec une matrice de risques (probabilité/impact) et un plan de mitigation priorisé.

Cas d’usage concret : Utilisée par des banques pour évaluer les risques sur leurs systèmes de paiement critiques, ou par des hôpitaux pour déterminer des actions de sécurisation des dossiers patients.

Durée et ressources :

• 4 à 8 semaines (selon la complexité).
• Équipe dédiée (5+ personnes).

Pour qui ?

PME, ETI ou structures avec des ressources limitées (ex : responsables IT, DPO) mais des besoins concrets en sécurité.

Pourquoi choisir cette version ?

OCTAVE-S est rapide et pratique. Elle se concentre sur les processus métiers critiques (ex : facturation, relation client) et fournit des recommandations actionnables (ex : sauvegardes automatiques, authentification multifacteurs).

Points clés :

• Questionnaires préétablis : Permettent une analyse en 2 à 5 jours sans expertise technique poussée.
• Focus métiers : Identifie les risques liés aux activités quotidiennes (ex : perte de données clients, indisponibilité du site web).
• Solutions concrètes : Propose des mesures immédiatement applicables (ex : chiffrement des emails, sauvegardes cloud sécurisées).
• Documentation légère : Rapport synthétique, idéal pour une première analyse ou une mise en conformité RGPD.

Cas d’usage concret : Adoptée par des entreprises de distribution pour sécuriser leurs données clients et terminaux de paiement, ou par des professions libérales pour protéger les dossiers sensibles.

Durée et ressources :

• 2 à 5 jours ;
• 1 à 2 personnes.

Pour qui ?

Organisations cherchant une approche agile et évolutive, notamment les scale-ups tech, les équipes DevOps ou les projets ponctuels (ex : lancement d’une nouvelle application).

Pourquoi choisir cette version ?

OCTAVE Allegro est modulaire, personnalisable et scalable. Elle s’intègre parfaitement aux cycles DevOps ou Agile, et peut être combinée avec des outils d’automatisation (ex : scans de vulnérabilités avec Nessus, suivi des risques via Jira).

Points clés :

• Modules au choix :
  • Asset-Based : Cartographie des actifs (ex : bases de données clients, APIs).hreat-Based : Analyse des menaces (ex : ransomware ciblant les sauvegardes).
  • Process-Based : Sécurité des workflows (ex : validation des paiements en ligne).
  • Intégration continue : Adaptée aux pipelines CI/CD (ex : audits de sécurité automatiques avant chaque déploiement).
• Personnalisation : Combinaison possible avec des outils existants (ex : Splunk pour les logs, ServiceNow pour la gestion des incidents).
• Scalable : De l’analyse ponctuelle (ex : nouveau projet) à une gestion des risques en continu.

Cas d’usage concret : Intégrée dans les pipelines CI/CD pour des audits de sécurité agiles, ou utilisée par des éditeurs de logiciels pour sécuriser leurs mises à jour.

Durée et ressources :

• 1 à 5 jours par module ;
• Ressources variables (selon les modules).

En matière de cybersécurité, l’inaction coûte cher — que ce soit en termes financiers, opérationnels ou de réputation. OCTAVE se distingue comme une méthode accessible, structurée et collaborative, conçue pour :

• Rendre la gestion des risques compréhensible par tous les métiers, sans jargon technique ;
• Impliquer les opérationnels (RH, production, service client) dans l’identification des risques, bien au-delà de la DSI ;
• Servir de tremplin vers des méthodologies plus avancées (EBIOS RM, MEHARI) ou s’intégrer dans un Système de Management de la Sécurité de l’Information (SMSI) existant.

Contrairement à des approches purement techniques, OCTAVE place les enjeux métiers au cœur de l’analyse. Que vous soyez une PME cherchant à sécuriser ses données clients ou un grand groupe visant la conformité NIS 2, OCTAVE offre un cadre adaptable — sans complexité inutile.

Vous souhaitez en savoir plus sur la gestion des risques ? Suivez la formation ISO 27005 Risk manager !

👉 Suivez-nous pour ne rien manquer des dernières actualités !

• Notre page LinkedIn

• Notre site web

De plus en plus d’entreprises imposent à leurs partenaires des questionnaires de cybersécurité censés évaluer leur niveau de maturité. Si l’intention est louable — sécuriser la chaîne d’approvisionnement numérique — la réalité est souvent bien plus complexe. Ces questionnaires, souvent standardisés, mal adaptés au contexte du partenaire, peuvent devenir contre-productifs, voire décourageants.

Nombreuses sont les entreprises qui par manque de connaissances en cybersécurité évaluent leurs (futurs) partenaires de manière générique, maladroite ou parfois inproductive, en utilisant parfois : 

• Des référentiels standardisés : ISO 27001, NIST, CIS Controls… souvent utilisés comme base, pas toujours pertinents si la réponse est « oui » ou « non » ;
• Une approche unique : peu ou pas d’adaptation au secteur, à la taille ou au rôle du partenaire ;
• Des exigences parfois déconnectées de la réalité : demander un SOC 24/7 à une PME de 10 personnes, par exemple ;
• On voit souvent des PME ou des startups crouler sous des exigences conçues pour des multinationales.

C’est évident, la réponse est oui. Mais cela nécessite un peu de travail des deux côtés. Histoire de se comprendre et de parler le même langage. 

1. Adapter les questionnaires au contexte : taille, secteur, rôle dans la chaîne de valeur.
2. Privilégier le dialogue à la checklist : un échange humain vaut mieux qu’un fichier Excel de 300 lignes. Du moins cela se discute ! Peut être qu’un entre deux est envisageable.
3. Favoriser une approche basée sur les risques : quels sont les vrais risques liés à ce partenaire ? Lui faire appliquer toutes les mesures est vraiment nécessaire ? Pensons à l’importance relative ;
4. Encourager la transparence plutôt que la conformité aveugle : fourniture de preuves sur les sujets essentiels (cf le point précédent) ;
5. Mettre en place un dispositif de suivi des éventuels écarts entre les niveaux requis et les niveaux actuels. Le prestataire qui coche toutes les cases n’existe peut être pas vraiment. On peut tolérer des écarts et étudier sa capacité à les réduire.

Enfin, en tant que partenaire, posez vous les bonnes questions : tout déclarer de son niveau de sécurité à son client en lui fournissant parfois des documents confidentiels, sans même vous inquiéter de sa manière à conserver tout cela de manière sécurisée, n’est-ce déjà pas là votre première négligeance ? Ah oui, il faut faire vite sinon on perd le contrat, c’est vrai. Merci le business ! 

Les questionnaires de cybersécurité ne devraient pas être une épreuve de force, mais un outil de collaboration. En les rendant plus intelligents, plus humains et plus adaptés, on renforce non seulement la sécurité, mais aussi la confiance entre partenaires.

👉 Suivez-nous pour ne rien manquer des dernières actualités !

• Notre page LinkedIn

• Notre site web