La loi européenne sur l'IA, expliquée : ce que les entreprises doivent vraiment savoir

The EU AI Act is no longer a future regulation to prepare for. As of August 2026, most of it is already in force. It also applies far beyond companies headquartered in Europe. If your AI system’s output reaches someone in the EU, the regulation likely reaches you too.

That surprises a lot of teams. Many still treat the EU AI Act as a distant compliance project, something to revisit “closer to the deadline.” In practice, though, the deadlines have already started passing. More are coming through 2027.

This post breaks down what the regulation actually says. It covers how the EU AI Act classifies risk, what it bans outright, what it demands from high-risk systems, and what your team should be doing right now.

What Is the EU AI Act, Exactly?

Formally, it’s Regulation (EU) 2024/1689. It defines an AI system broadly. A machine-based system that operates with some autonomy, may adapt after deployment, and infers from its inputs how to generate outputs such as predictions, content, recommendations, or decisions all counts.

That definition matters because it’s intentionally wide. It covers everything from a resume-screening tool to a large generative model. It isn’t limited to headline-grabbing systems like facial recognition or autonomous vehicles.

Just as importantly, the EU AI Act reaches outside the EU’s borders. Say you place an AI system on the EU market, or its output gets used within the EU. Either way, you fall under scope. Location alone doesn’t exempt anyone, and neither does routing your AI infrastructure through a non-EU subsidiary.

The EU AI Act’s Risk-Based Approach

Rather than regulating every AI system the same way, the EU AI Act sorts systems into risk tiers. Each tier carries a different level of obligation.

At the top sits unacceptable risk: practices banned outright, with no compliance path available. Below that comes high-risk, meaning systems that stay on the market but only under strict obligations around risk management, documentation, and oversight. Below that sits limited risk, which mainly triggers transparency duties, such as disclosing that content was AI-generated. Everything else falls into minimal risk, where the regulation imposes no binding requirements at all.

This structure explains why compliance work looks so different from one AI use case to the next. A chatbot on a retail website faces a light touch. A tool used to screen job applicants faces a heavy one, even though both are technically “just AI.”

What’s Banned Outright Under the EU AI Act

Article 5 lists AI practices the EU AI Act prohibits entirely, regardless of sector or safeguards. These prohibitions have applied since February 2025, well ahead of the rest of the regulation.

Banned practices include AI systems that use subliminal or manipulative techniques to distort someone’s behavior in ways that cause harm. They also include systems that exploit vulnerabilities tied to a person’s age, disability, or economic situation. Social scoring by public or private actors is banned too. So is untargeted scraping of facial images from the internet or CCTV footage to build recognition databases.

A few other practices sit in this banned category with narrow carve-outs. Emotion recognition in workplaces and schools is prohibited, except for medical or safety purposes. Real-time remote biometric identification in public spaces for law enforcement is banned by default as well. A narrow exception exists for cases like searching for abduction victims or preventing an imminent terrorist threat. Even then, courts and strict safeguards apply before any deployment.

High-Risk AI Systems Carry the Heaviest Obligations

Annex III of the EU AI Act lists the areas where AI systems are automatically classified as high-risk. They include biometric identification and critical infrastructure. They also cover education and vocational training, employment and worker management, and access to essential public and private services. Law enforcement and migration and border control round out the list.

Falling into one of these categories doesn’t ban the system outright. Instead, it triggers a substantial compliance package. Providers must run a risk management process across the system’s lifecycle. They must maintain detailed technical documentation, ensure meaningful human oversight, and build in logging and traceability. Registration in an EU database is required too, before the system ever reaches deployment.

There’s a narrow exception worth knowing. A system that performs only a narrow procedural task, or one that merely improves on already-completed human work without replacing human judgment, may fall outside the high-risk category. But that exception has limits. Any system that profiles natural persons is automatically treated as high-risk, no matter how narrow its stated task looks.

General-Purpose AI Models Get Their Own Rules

Large generative models don’t fit neatly into the high-risk framework built around specific use cases. So the EU AI Act creates a separate track for general-purpose AI (GPAI) models instead.

All GPAI providers must maintain technical documentation. They also need to give downstream developers the information required to use the model responsibly. On top of that, providers must put a policy in place to comply with EU copyright law, including a summary of the content used to train the model.

Models presumed to carry systemic risk face additional duties. These include model evaluation, adversarial testing, incident reporting, and cybersecurity protections for the model itself. Open-source models get some relief from the transparency rules above. That relief disappears, however, the moment a model is considered to present systemic risk.

Transparency Obligations: Chatbots and Deepfakes

Article 50 covers systems that don’t reach high-risk status but still need to be honest with users about what they’re looking at.

Providers must ensure people know when they’re interacting with an AI system rather than a human. The exception is when that fact is already obvious from context. Separately, deployers of systems that generate deepfakes must disclose it too. A deepfake here means AI-manipulated image, audio, or video content that resembles a real person, place, or event.

These aren’t heavy obligations compared to the high-risk tier. Still, they’re easy to miss. That’s especially true for marketing or content teams experimenting with generative tools without security or legal in the loop.

The EU AI Act Timeline: What Applies When

The EU AI Act didn’t arrive all at once. It phases in across several dates, and by August 2026, most of those dates have already passed.

Prohibited practices under Article 5 became enforceable on 2 February 2025. That date also brought the general provisions and AI literacy obligations in Chapters I and II. Governance structures, GPAI obligations, and the penalty framework followed on 2 August 2025. Then, on 2 August 2026, the bulk of the regulation became applicable, including most high-risk system obligations under Annex III.

One piece still remains on the horizon. High-risk AI systems that serve as safety components of products already regulated under other EU harmonization law, think machinery or medical devices, get extra time. Article 6(1) and its corresponding obligations won’t apply to them until 2 August 2027.

Penalties: How Much Non-Compliance Actually Costs

The EU AI Act backs its obligations with real financial exposure. The amounts scale with the type of violation, not a flat penalty across the board.

Violating the Article 5 prohibitions carries the steepest penalty: fines up to €35 million, or 7% of global annual turnover, whichever is higher. Non-compliance with high-risk system obligations, transparency duties, or requirements for importers and distributors caps lower, at €15 million or 3% of turnover. Supplying incorrect or misleading information to regulators tops out at €7.5 million or 1% of turnover.

For SMEs and startups, each of those caps applies at whichever figure is lower, not higher. That softens the blow somewhat. Even so, regulators weigh factors like intent, cooperation, and harm caused when setting the actual fine. In other words, the ceiling isn’t the only number that matters.

How to Start Preparing

Given how much of the EU AI Act is already active, the practical question isn’t whether to prepare. It’s where to start.

Begin with an inventory. Map every AI system your organization builds, buys, or deploys. Don’t forget tools embedded in third-party software that teams may not even think of as “AI.” From there, classify each system against the risk tiers above, since that classification determines everything else about your obligations, from documentation depth to whether you can deploy the system at all.

If you already run an ISO 27001 or NIS2 compliance program, resist the urge to treat AI governance as a separate track. The EU AI Act’s risk management, documentation, and audit requirements overlap heavily with controls you likely already have in place. Extending an existing information security management system to cover AI systems and their data pipelines is far more efficient than building a parallel compliance silo from scratch. It also keeps a lean compliance team from drowning under yet another standalone framework.

For related reading, see your Secure by Design and Default guide, your Cyber Resilience Act compliance guide, and your ISO 27001 documentation checklist.

À retenir

The EU AI Act is no longer a regulation on the horizon; it’s current, active law for most AI systems on the EU market. Its prohibitions have been enforceable since early 2025. Its core obligations took effect in August 2026. Only one narrow category, embedded high-risk systems inside already-regulated products, still has runway left, until August 2027.

The fastest path forward is classification. Once you know which risk tier each of your AI systems falls into, the rest of the compliance work follows a clear, documented path from there.

Sources: Regulation (EU) 2024/1689 (Artificial Intelligence Act) — EUR-Lex

Gestion des cyberrisques liés à l'IA : pourquoi votre programme GRC doit évoluer

Les dépenses en IA sont sur le point d'exploser, et la plupart des programmes ne sont pas prêts à faire face aux implications de cette évolution en matière de gestion des risques cyberliés à l'IA. Votre modèle de gouvernance risque de ne pas tenir le rythme.

Gartner prévoit que les dépenses consacrées à l'IA augmenteront de 44 % rien qu'en 2026. D'ici 2029, le montant total des dépenses consacrées à l'IA (infrastructures, produits et services confondus) atteindra 4 700 milliards de dollars. Pourtant, seules 15 % des entreprises déclarent avoir mis en place une gouvernance complète en matière d'IA.

C'est cette lacune qui constitue le véritable risque. Plus précisément, il s'agit avant tout d'un problème de gouvernance, et non d'un problème technologique. Cet article explique pourquoi, et présente les recommandations de Gartner à l'intention des RSSI et des responsables de la sécurité pour y remédier.

Le piège de la fragmentation dans la gouvernance des risques liés à l'IA

Voici l'erreur couramment commise. À mesure que l'adoption de l'IA s'accélère, de nombreuses équipes de sécurité réagissent en mettant en place de nouvelles solutions. Plus précisément, elles élaborent des politiques, des processus et des outils spécifiques, exclusivement destinés à la gestion des risques liés à l'IA.

Au premier abord, cela semble logique. Mais dans la pratique, cela se retourne contre nous.

Comme ces cadres fonctionnent en parallèle, ils fragmentent la gestion des cyber-risques avant même qu’elle ne commence. En conséquence, ils ralentissent la prise de décisions fondées sur l’analyse des risques. Pire encore, ils compliquent la tâche des dirigeants qui souhaitent comparer les risques liés à l’IA à tous les autres risques figurant dans le registre des risques.

Les recommandations de Gartner sont donc claires : ne mettez pas en place un deuxième système dédié à l'IA. Faites plutôt évoluer celui dont vous disposez déjà.

Cette situation reflète une lacune en matière de gouvernance à laquelle les conseils d’administration sont déjà confrontés ailleurs. Le rapport « Global Cybersecurity Outlook 2026 » du Forum économique mondial a mis en évidence une tendance similaire dans la supervision de la chaîne d’approvisionnement : c’est généralement la visibilité fragmentée, et non le manque d’outils, qui constitue le véritable problème.

Six façons de faire évoluer la gestion des risques cyberliés à l'IA

Gartner présente six mesures concrètes portant sur la méthodologie, les ressources humaines et la technologie. Ensemble, elles permettent de maintenir les risques liés à l'IA au sein de votre structure de gouvernance existante, plutôt que de les y ajouter en parallèle.

1. Renforcer la responsabilisation en matière de cyber-risques liés à l'IA. Les équipes de sécurité se retrouvent souvent désignées par défaut comme responsables de tous les risques liés à l'IA. Cela pose problème, car ce sont les unités opérationnelles qui déploient des outils d'IA qui doivent assumer la responsabilité des risques que ces outils engendrent.

Concrètement, cela implique de mettre à jour votre charte de cybersécurité. Cela implique également d'exiger des responsables métier qu'ils reconnaissent et acceptent formellement les risques liés à l'IA avant le déploiement, et non après.

2. Tenez un registre unifié des risques cybernétiques. Résistez à la tentation de créer un registre distinct pour les risques liés à l'IA. Évaluez plutôt les menaces liées à l'IA en utilisant la même méthodologie que celle que vous appliquez à tous les autres risques.

En quoi est-ce important ? Parce qu’un registre unique impose une hiérarchisation cohérente à tous les niveaux. Cela empêche ainsi l’IA de devenir un sujet de discussion isolé, déconnecté des décisions plus larges en matière de risques.

3. Adopter une approche axée sur les menaces. Les registres de risques traditionnels répertorient souvent des lacunes en matière de conformité et des vulnérabilités isolées. Cette approche ne s’adapte toutefois pas bien aux menaces spécifiques à l’IA, telles que l’injection de prompts ou la fuite de données des modèles.

Au contraire, fondez vos évaluations des risques sur le comportement réel des attaquants. Par exemple, élaborez des scénarios spécifiques à l'IA, mais évaluez-les selon les mêmes critères que pour tout autre risque cybernétique.

4. Intégrez la gouvernance de l'IA dans les politiques existantes. Évitez de rédiger une toute nouvelle « politique relative à l'IA » pour chaque situation. En effet, la plupart des risques liés à l'IA s'inscrivent naturellement dans les politiques que vous appliquez déjà, comme celles relatives à la gestion des identités et des accès.

Ne créez de nouvelles normes spécifiques à l'IA que lorsque les normes existantes ne s'appliquent pas. La validation de l'intégrité des modèles, par exemple, illustre bien un cas où une telle norme pourrait s'avérer nécessaire.

5. Renforcez les compétences en matière de sécurité de l'IA. Vous n'avez probablement pas besoin de nouveaux postes. Au contraire, vos professionnels GRC actuels sont déjà bien placés pour gérer les risques liés à l'IA, à condition de bénéficier d'une formation adaptée.

Investissez donc dans le perfectionnement des compétences. Commencez par vous associer au service des ressources humaines pour financer des certifications en sécurité de l'IA. Ajoutez ensuite des scénarios d'attaque générés par l'IA à vos exercices de simulation existants.

6. Utilisez la technologie pour renforcer votre programme, et non pour le fragmenter. Les nouveaux outils destinés à faciliter la gouvernance de l’IA peuvent apporter une réelle valeur ajoutée. Cependant, le simple fait d’ajouter davantage d’outils disparates ne résoudra pas automatiquement les problèmes.

Avant d'acheter un nouveau produit, il convient donc de bien comprendre ce que font déjà vos plateformes existantes. En résumé, l'objectif est la consolidation, et non la prolifération.

Pourquoi la gestion des risques cybernétiques grâce à l'IA est-elle aujourd'hui si importante ?

Quelque 302 responsables de la cybersécurité ont été interrogés dans le cadre de l'étude de Gartner intitulée « Gestion des risques liés à l'IA à l'horizon 2025 ». Les résultats sont éloquents : la plupart ont déclaré que leurs organisations devaient mettre en œuvre des changements importants, voire globaux, pour gérer les risques émergents en matière de cybersécurité liés à l'IA.

Il est évident que ce n'est pas un problème lointain pour la gestion des cyberrisques liés à l'IA. Au contraire, cela se produit dès à présent, à mesure que les outils d'IA générative, les applications d'IA sur mesure et les fonctionnalités d'IA intégrées sont mis en production.

Pour autant, la technologie à elle seule ne suffira pas à combler ce fossé. En effet, la gestion des risques cybernétiques repose sur le jugement d’experts humains. L’IA permet plutôt aux équipes de traiter davantage de signaux, plus rapidement, afin que les personnes puissent se concentrer sur les décisions les plus importantes.

Pour découvrir comment cela se traduit concrètement pour les petites entreprises en particulier, découvrez comment l'IA redéfinit les risques cybernétiques pour les entreprises en pleine croissance.

Le point sur la gestion des risques cyberliés à l'IA

L'IA n'est plus un simple projet secondaire. Elle fait désormais partie intégrante du mode de fonctionnement des entreprises.

C'est pourquoi votre programme de GRC cybernétique ne peut pas considérer l'IA comme une exception. Il doit au contraire intégrer les risques liés à l'IA dans la même structure, le même registre et le même modèle de responsabilité auxquels vous faites déjà confiance.

Ainsi, les organisations qui font évoluer leur gouvernance existante, plutôt que de la reproduire à l'identique, parviendront à se développer bien plus efficacement. Dans un environnement axé sur l'IA, ce n'est pas seulement une bonne pratique. En réalité, c'est la seule pratique qui permette de suivre le rythme.

Source : Gartner, « Les pratiques de Cyber GRC doivent évoluer pour gérer les risques liés à l'IA », 27 avril 2026 (réf. G00846514).

« Secure by Design » : ce que le nouveau guide de l’ENISA signifie pour les petites équipes

La plupart des petites équipes chargées du développement logiciel et matériel s'accordent à dire que la sécurité est importante. Mais s'accorder sur ce point n'est pas le plus difficile. Le plus difficile, c'est de savoir exactement quoi mettre en place. Et lorsqu'on doit le faire avec un budget quasi inexistant et sans personnel dédié à la sécurité, le fossé entre les intentions et la mise en œuvre ne tarde pas à se creuser.

C’est précisément cette lacune que l’ENISA vient d’essayer de combler. En juillet 2026, l’Agence de l’Union européenne pour la cybersécurité a publié le Guide pratique « Secure by Design and Default ». Il s’agit d’un guide pratique spécialement conçu pour les petites et moyennes entreprises. Ce document ne se contente pas de répéter le conseil habituel consistant à « anticiper la sécurité en amont ». Il décompose plutôt le concept de « sécurité dès la conception » en 22 guides d’application concrets. Chacun d’entre eux comprend une liste de contrôle, une liste des preuves minimales requises et un critère de validation que votre équipe peut copier directement dans un modèle de pull request.

Cet article passe en revue le contenu du guide. Il explique pourquoi ces recommandations ont été mises en place et comment une équipe réduite peut commencer à les appliquer sans avoir à créer au préalable un service dédié à la sécurité.

Ce guide s'adresse à un public spécifique : les développeurs de logiciels, les chefs de produit techniques, les responsables de la sécurité dans les PME et les architectes système travaillant avec des ressources limitées. Si cela correspond à votre équipe, sachez que ce guide a été rédigé spécialement pour vous, et non pour un service de sécurité d'une entreprise du classement Fortune 500.

Pourquoi « Secure by Design » avait besoin de son propre guide pratique

Le concept de « sécurité dès la conception » semble simple : intégrer la protection dès le départ plutôt que de l'ajouter a posteriori. Cependant, les idées simples ne se traduisent pas toujours par des actions simples.

L'ENISA met en évidence un schéma récurrent. Les PME du secteur manufacturier sont confrontées à des contraintes budgétaires, à un savoir-faire limité en matière de sécurité et à une pression constante de la part de l'entreprise en termes de délais. Par conséquent, des principes qui semblent évidents lors d'une conférence restent souvent lettre morte dans le code source.

La loi sur la cyber-résilience (CRA) renforce encore davantage les exigences. Les produits comportant des éléments numériques vendus dans l’Union européenne doivent désormais présenter un niveau adéquat de cybersécurité. Ils doivent également être livrés avec des configurations par défaut sécurisées et prendre en charge des mises à jour de sécurité en temps opportun. Ainsi, la « sécurité dès la conception » n’est plus seulement une bonne pratique. Pour de nombreux fabricants, elle devient une condition d’accès au marché.

Ce guide ne fournit pas de conseils juridiques. Il offre en revanche aux équipes d’ingénieurs quelque chose de bien plus utile au quotidien : une méthode reproductible pour transposer les principes liés à la CRA dans le cadre du travail quotidien des sprints.

Deux idées, quatre catégories

L'ENISA articule ses recommandations autour de deux concepts liés, mais distincts.

Le concept de « Secure by design » porte sur la manière dont un système est conçu. Il s'agit d'intégrer dès le premier jour la modélisation des menaces, les modèles d'architecture sécurisée et la gestion des vulnérabilités dans le processus de développement. C'est très différent de les mettre en place a posteriori, après le lancement.

La sécurité par défaut désigne les mesures mises en place dès la première mise en marche du produit par l'utilisateur. Un produit « sécurisé par défaut » est livré avec la configuration la plus protectrice raisonnablement possible. Les utilisateurs ne devraient pas avoir besoin de connaissances spécialisées pour bénéficier d'une sécurité optimale dès la sortie de l'emballage.

Dans le cadre de l’approche « Secure by Design », l’ENISA regroupe les principes en deux catégories : les fondements architecturaux et l’intégrité opérationnelle. Les fondements architecturaux concernent la structure du système. L’intégrité opérationnelle, quant à elle, porte sur la manière dont celui-ci est géré et entretenu après sa mise en service. Dans le cadre de l’approche « Secure by Default », les principes se divisent en deux catégories : le renforcement par défaut et la protection guidée. Le renforcement par défaut décrit l’état du système à sa sortie d’usine. La protection guidée, quant à elle, décrit la manière dont le système aide les utilisateurs à rester en sécurité au fil du temps.

Ces quatre catégories regroupent à elles seules l'ensemble des 22 guides pratiques. Elles couvrent des thèmes allant des limites de confiance et du principe du privilège minimal jusqu'à la reprise sécurisée et au transfert de propriété.

Dans les coulisses d'un guide pratique : comment fonctionnent réellement les listes de contrôle

Chacun des 22 guides pratiques suit la même structure en cinq parties. C'est notamment cette cohérence qui rend ce guide si pratique pour les petites équipes.

On commence par le principe lui-même, formulé en une seule phrase. Vient ensuite l'objectif : quel type de défaillance ce principe est censé prévenir. Puis, une liste de contrôle énumère les actions ayant le plus grand impact. Celles-ci sont conçues pour être mises en œuvre par des équipes « lean », et non par de grandes structures dédiées à la sécurité.

Ensuite, une section intitulée « Preuves minimales » répertorie l'ensemble minimal d'éléments prouvant que la liste de contrôle a bien été mise en œuvre. Enfin, une « porte de validation » propose des critères de réussite ou d'échec que vous pouvez directement intégrer dans un pipeline d'intégration continue (CI) ou dans une revue de mise en production.

Prenons par exemple la réduction de la surface d’attaque. La liste de contrôle demande aux équipes de répertorier toutes les interfaces exposées et d’appliquer des règles réseau basées sur le principe du « refus par défaut ». Elle leur demande également de supprimer les outils de développement et de diagnostic des versions de production, et de réduire au minimum les données collectées dès le départ. Le processus de validation de mise en production vérifie ensuite, avant chaque mise en production, qu’aucun nouveau port ou point de terminaison d’administration n’a échappé au contrôle.

Ce format est important car il permet de transformer l'expression « renforcer la sécurité » en un élément que le développeur peut réellement cocher lors de la révision d'une pull request.

Ces principes couvrent l'ensemble du cycle de vie du produit

Ces 22 guides couvrent toutes les étapes du cycle de vie d'un produit, et pas seulement la phase de développement.

Les limites de confiance et la modélisation des menaces sont prioritaires. Les équipes doivent savoir ce qu'elles protègent avant de pouvoir le faire. Viennent ensuite le principe du « privilège minimal », une architecture d'identité robuste et la défense en profondeur. Ensemble, ces éléments constituent la colonne vertébrale architecturale du système.

Les principes d'intégrité opérationnelle prennent alors le relais. Cela inclut les pratiques de codage sécurisé, la journalisation et la surveillance, la réponse aux incidents, ainsi que la gestion des vulnérabilités et des correctifs. Les contrôles de la chaîne d'approvisionnement viennent compléter l'aspect conception. Ils couvrent tous les aspects, depuis les artefacts de compilation signés jusqu'aux nomenclatures logicielles (SBOM).

En ce qui concerne les paramètres par défaut, le guide d’implémentation traite du contenu livré dans la boîte. Cela implique une réduction au minimum des services par défaut, l’absence d’identifiants d’administration partagés, une communication chiffrée dès la première connexion et des clés secrètes uniques pour chaque appareil. Des principes de protection guidés aident ensuite les utilisateurs à garantir leur sécurité après la configuration. Cela passe par des étapes d’intégration obligatoires, des mises à jour automatiques et des avertissements clairs chaque fois qu’un utilisateur désactive une mesure de protection.

Il convient notamment de noter que l'ENISA considère ces étapes du cycle de vie comme itératives plutôt que séquentielles. Une vulnérabilité détectée en production devrait entraîner un retour aux étapes antérieures de modélisation des menaces et d'évaluation des risques, et non pas se limiter à un simple correctif rapide et à un haussement d'épaules.

Modélisation des menaces sans surcoût

De nombreuses petites équipes évitent la modélisation des menaces, car celle-ci leur semble être un exercice de plusieurs semaines réservé aux services de sécurité des grandes entreprises. Dans la pratique, l’ENISA réfute directement cette idée reçue.

Le guide recommande le cadre en quatre questions d’Adam Shostack comme point de départ simple. Sur quoi travaillons-nous ? Quels sont les risques ? Que comptons-nous faire pour y remédier ? Avons-nous fait du bon travail ? Les équipes peuvent répondre à ces questions à l’aide d’un simple schéma et d’une brève liste des principales menaces. Un tableau simple mettant en correspondance chaque menace avec les mesures d’atténuation prévues vient compléter l’exercice.

L'objectif n'est pas de produire une documentation exhaustive. Il s'agit plutôt d'un modèle minimal viable, rapide à élaborer et facile à mettre à jour. Il est essentiel qu'il reste étroitement lié aux décisions de conception réelles. Un modèle de menaces que personne ne met à jour après la première version ne vaut même pas la peine d'être élaboré.

Le prouver, et pas seulement l'affirmer

L'une des sections les plus tournées vers l'avenir de ce guide traite de l'attestation exploitable par machine. Plutôt que de s'appuyer sur un rapport PDF statique que personne ne lit après l'audit, l'ENISA explique comment les déclarations de sécurité peuvent être exprimées sous forme de données structurées et lisibles par machine.

Par exemple, une attestation signée peut indiquer qu’un produit prend en charge le protocole TLS 1.3 avec un chiffrement AES-256. Cette affirmation est alors associée à des preuves concrètes, telles qu’une analyse de configuration, un résultat de test ou un journal de compilation. Des systèmes automatisés peuvent vérifier cette affirmation sans avoir à attendre l’intervention d’un réviseur humain.

Pour une PME, cela revêt une importance particulière, car cela permet de remplacer les audits manuels coûteux par des contrôles automatisés effectués à chaque nouvelle version. Le guide prend toutefois soin de souligner les limites de cette approche. Une attestation à elle seule ne suffit pas à prouver qu’un produit est sécurisé. La vérification et l’évaluation indépendante restent des étapes distinctes et indispensables. Les preuves structurées permettent simplement de rendre ces deux étapes plus rapides et moins coûteuses à mettre en œuvre.

Comment se lancer sans vouloir tout changer d'un seul coup

Vingt-deux guides opérationnels peuvent sembler insurmontables pour une équipe d’ingénieurs composée de cinq personnes. Heureusement, l’ENISA a anticipé cette réaction et propose plutôt une approche progressive de mise en œuvre.

Commencez par définir le contexte. Précisez le périmètre de votre produit, ses utilisateurs et ses principaux risques à l’aide de l’approche simplifiée de modélisation des menaces décrite ci-dessus. À partir de là, établissez une base de référence couvrant les pratiques de codage sécurisé, la journalisation et la surveillance, la gestion des vulnérabilités et les contrôles de la chaîne d’approvisionnement. Si votre produit gère les accès des utilisateurs, ajoutez également à cette base de référence des mesures d’accès initial restrictives et des communications sécurisées par défaut.

Ce n’est qu’une fois ces bases posées que les équipes devront aborder les autres guides opérationnels. Classez-les par ordre de priorité en fonction de vos risques spécifiques et de votre contexte de déploiement, et non selon l’ordre dans lequel ils apparaissent dans le document. L’adoption progressive ne doit toutefois pas servir de prétexte pour reporter les obligations liées à l’évaluation des risques (CRA). Il s’agit simplement d’une séquence réaliste pour les équipes disposant d’un temps et de ressources limités.

À retenir

Le concept de « sécurité dès la conception » a toujours été facile à défendre, mais difficile à mettre en pratique. Le guide de l’ENISA ne résout pas entièrement cette difficulté. Il transforme toutefois un principe vague en 22 listes de contrôle qu’une petite équipe peut réellement passer en revue avant la mise sur le marché. Compte tenu des exigences à venir de la CRA, ce passage de l’aspiration à l’action est exactement ce dont la plupart des fabricants ont besoin à l’heure actuelle.

Si votre équipe n'a pas encore mis en place un modèle de menace simplifié, c'est par là qu'il faut naturellement commencer. Tout le reste du guide s'articule autour de ce point de départ, étape par étape, à chaque phase de lancement.

Pour les équipes qui s'occupent déjà de la conformité aux exigences de la CRA, ce guide mérite également d'être lu en parallèle de l'annexe C du document original. Il établit un lien direct entre chacun des 22 principes et les exigences essentielles spécifiques de la CRA, ce qui peut vous faire gagner un temps précieux lorsque vous constituez un dossier de conformité interne. En d'autres termes, le travail de vérification que vous effectuez à des fins techniques sert également de preuve à des fins réglementaires.

Source : ENISA, Guide pratique « Secure by design and default »

Le registre des informations DORA : un guide pratique

Si votre organisation est une entité financière exerçant ses activités dans l'UE, le registre d'informations prévu par la loi DORA n'est pas une simple formalité administrative facultative. Il s'agit d'une obligation légale, déjà en vigueur. La loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act, ou DORA) est entrée en vigueur le 17 janvier 2025. À compter de cette date, les entreprises concernées doivent disposer d'un registre complet et à jour de tous les accords contractuels qu'elles ont conclus avec des prestataires de services informatiques tiers.

Sur le papier, cela semble simple. Dans la pratique, cela s’est avéré être l’une des obligations de déclaration les plus exigeantes auxquelles les entités financières aient été confrontées depuis des années. L’Autorité bancaire européenne (ABE) a mené un exercice de simulation en 2024 dans le but précis d’identifier les problèmes avant le début des déclarations officielles. Malgré cela, les problèmes qu’elle avait repérés continuaient d’apparaître lors des tests jusqu’en 2025.

Cet article explique en détail les exigences réelles du registre d’informations DORA. Il explique pourquoi les autorités de régulation l’ont conçu de cette manière et ce que les conclusions de l’ABE en matière de qualité des données suggèrent que votre équipe devrait vérifier attentivement avant de procéder au dépôt.

Qu'est-ce que le registre d'informations DORA ?

Le registre d'informations DORA est un inventaire structuré des relations d'une entité financière avec des tiers dans le domaine des technologies de l'information et de la communication (TIC). Il doit être tenu à trois niveaux : celui de l'entité, celui du périmètre sous-consolidé et celui du périmètre consolidé. Une entreprise autonome établit ses rapports différemment d'un groupe bancaire comptant plusieurs filiales. Dans les deux cas, le registre doit être à jour et exact.

Il ne s'agit pas non plus d'une déclaration ponctuelle. Les entités financières doivent tenir ce registre à jour en permanence. Elles le transmettent ensuite à leur autorité compétente sur demande. Cette dernière transmet à son tour les registres collectés aux autorités européennes de surveillance, appelées « AES », en vue de leur utilisation ultérieure.

Le champ d'application est ici également déterminant. La directive DORA s'applique de manière générale à l'ensemble du secteur financier de l'UE. Elle couvre les banques, les assureurs et les entreprises d'investissement. Les établissements de paiement et une longue liste d'autres entités réglementées relèvent également de son champ d'application. Si votre organisation relève de la directive DORA, l'obligation d'enregistrement des informations s'applique très certainement à vous.

Pourquoi le registre DORA des informations existe-t-il ?

Les autorités de régulation n'ont pas mis en place cette obligation de déclaration dans le seul but d'alourdir la charge administrative. Au contraire, le registre d'informations DORA répond à trois objectifs distincts. Chacun d'entre eux détermine la forme que doivent prendre les données.

Tout d'abord, cela permet aux entités financières de surveiller leurs propres risques liés aux tiers dans le domaine des TIC. Un registre complet met en évidence les risques de concentration. Imaginons, par exemple, que cinq fonctions métier essentielles dépendent toutes du même fournisseur de services cloud. Ce schéma apparaît clairement dans les données, au lieu de rester dissimulé dans cinq dossiers contractuels distincts.

D'autre part, cela fournit aux autorités compétentes de l'UE un outil de surveillance. Les régulateurs peuvent ainsi évaluer la manière dont les entreprises gèrent les risques liés aux TIC et aux tiers sans avoir à attendre qu'un incident vienne mettre en évidence les lacunes.

Troisièmement, et c’est peut-être le plus important, les AES utilisent les registres agrégés pour désigner les fournisseurs tiers de TIC d’importance systémique. Ceux-ci sont souvent désignés par l’acronyme CTPP. Une fois qu’un fournisseur obtient cette désignation, il est soumis à une surveillance directe au niveau de l’UE. En d’autres termes, le registre d’informations ne concerne pas seulement la conformité de votre entreprise. C’est également le mécanisme qui identifie quels fournisseurs de cloud et de technologies revêtent une importance systémique pour l’ensemble du secteur financier européen.

Ce qu'a révélé la simulation de 2024

Avant le début de la déclaration officielle, les autorités de surveillance européennes (ESA) ont mené un exercice de simulation tout au long de l’année 2024. Dans ce cadre, les entités financières de toute l’Union européenne ont transmis des registres à titre d’essai. Cela a permis aux régulateurs, ainsi qu’aux entreprises elles-mêmes, d’identifier d’éventuels problèmes avant que cette obligation n’acquière une valeur juridique effective.

Cette simulation n’était pas non plus un simple projet pilote. Elle comprenait des ateliers avec les acteurs du secteur, un modèle de rapport spécifique et un projet de taxonomie. Elle s’accompagnait également de ses propres contrôles de qualité des données. L’ABE a ensuite publié un rapport de synthèse, ainsi qu’une fiche d’information expliquant les objectifs de cet exercice.

Cette préparation s’est avérée cruciale, car elle a permis de mettre en lumière très tôt des problèmes structurels. À l’issue de l’exercice de 2024, l’ABE a publié ses observations issues de l’examen des déclarations officielles de RoI. Ces conclusions ont mis en évidence des problèmes communs majeurs identifiés dans l’ensemble du secteur. Concrètement, cela signifie que les entreprises ne se contentaient pas de commettre des erreurs sur des données ponctuelles. Elles se heurtaient à des problèmes récurrents et systémiques liés à la manière même dont elles structuraient et validaient leurs registres.

Aspects techniques du registre d'informations DORA

La saisie des informations dans le registre DORA ne consiste pas simplement à remplir librement un tableur. Au contraire, le format de déclaration est strictement défini dans un cahier des charges technique officiel.

Au cœur de ce dispositif se trouvent les normes techniques d’exécution (ITS) relatives au registre d’informations. Celles-ci ont été adoptées et publiées au Journal officiel de l’Union européenne. Sur cette base, l’ABE gère un modèle de données complet. Celui-ci comprend un dictionnaire du modèle de points de données ainsi qu’un schéma de tableau annoté définissant chaque champ qu’une entreprise pourrait être amenée à remplir.

Les déclarations doivent, en définitive, être conformes à une taxonomie reposant sur l'architecture XBRL-CSV. Des fichiers types et un ensemble complet de taxonomies sont mis à la disposition des entreprises afin qu’elles puissent les tester avant de procéder à la déclaration effective. De plus, l’ABE publie des règles de validation. Elle fournit également un aperçu détaillé des contrôles techniques et métier qu’elle applique à chaque déclaration. Il existe même un ensemble de rapports au format CSV simple pour les entreprises qui souhaitent une solution plus simple que l’utilisation complète des outils XBRL, ainsi qu’un outil de conversion permettant de passer d’un format à l’autre.

Ce niveau de précision technique s'explique par une raison bien précise. Les données proviennent de centaines d'entités financières, réparties dans différents pays et utilisant différents systèmes internes. Il faut ensuite regrouper toutes ces informations en un ensemble de données cohérent que les AES puissent réellement analyser.

Pièges courants liés au registre des déclarations d'informations DORA

Compte tenu du caractère très technique du format, il n’est pas surprenant que la qualité des données soit un thème récurrent. L’ABE a publié des documents explicatifs sur les retours d’information relatifs à la qualité des données que les entreprises reçoivent à l’issue des contrôles de validation. Elle met également à disposition des exemples de réponses concernant la qualité des données, afin que les entreprises puissent se faire une idée de ce à quoi ressemble un rapport d’erreurs avant d’en recevoir un elles-mêmes.

Plusieurs tendances se dégagent de ces données. Les entreprises ont parfois du mal à classer correctement les activités faisant l'objet d'une licence, ce qui nécessite de se référer à une annexe spécifique répertoriant les valeurs possibles. D'autres rencontrent des difficultés quant à la manière dont les registres sous-consolidés et consolidés s'articulent entre eux. Le reporting au niveau du groupe introduit des interdépendances qu'un registre portant sur une seule entité n'a tout simplement pas à gérer.

L'ABE tient également à jour une FAQ sur le registre des déclarations d'informations, mise à jour à mesure que de nouvelles questions apparaissent. Il convient de considérer cette FAQ comme un document évolutif plutôt que comme un document à consulter une seule fois. Elle reflète les problèmes que l'ABE constate réellement dans les données transmises, et non des cas limites hypothétiques.

Comment se préparer à la déclaration au registre DORA des informations

Si votre organisation n'a pas encore mis en place un processus standardisé à cet effet, certaines priorités peuvent faire toute la différence.

Commencez par recenser tous les contrats informatiques conclus par votre organisation avec des tiers, et pas seulement ceux avec les fournisseurs de cloud les plus évidents. La définition des services informatiques tiers donnée par la DORA est large. Les lacunes dans votre inventaire des contrats se traduisent par des lacunes dans votre registre, et ce sont précisément ces lacunes que les contrôleurs sont formés à repérer. Ensuite, désignez clairement les responsables chargés de maintenir cet inventaire à jour. Le registre n’est pas un exercice ponctuel. Les contrats évoluent et les fournisseurs changent ; le registre doit donc refléter ces changements en temps quasi réel.

À partir de là, effectuez dès que possible des tests par rapport aux règles de validation publiées par l’ABE. N’attendez pas la date limite de dépôt pour découvrir un problème de mise en forme que vous auriez pu repérer des mois plus tôt. L’exercice de simulation et le rapport sur les problèmes courants qui s’ensuit ont tous deux pour objectif spécifique de permettre aux entreprises de tirer les leçons des erreurs commises par d’autres plutôt que des leurs. Enfin, si votre organisation met déjà en œuvre d’autres programmes de conformité aux normes européennes, recherchez les recoupements. Le travail d’évaluation des risques liés aux fournisseurs, qui sous-tend la conformité à la norme ISO 27001 ou à la directive NIS2, correspond souvent étroitement aux données de tiers désormais exigées par la DORA, mais sous un format plus structuré et plus adapté à la production de rapports.

À retenir

Le registre d’informations DORA a désormais dépassé le stade de la planification. Il s’agit désormais d’une obligation contraignante et effective, étayée par un ensemble détaillé de rapports techniques et par un corpus de conclusions concrètes sur la qualité des données issues des propres tests de l’ABE. Les entreprises qui gèrent efficacement cette obligation ne sont pas celles qui la considèrent comme une course contre la montre annuelle. Ce sont celles qui tiennent à jour un inventaire précis et constamment actualisé de leurs relations avec des tiers dans le domaine des TIC, validé au regard des règles publiées par l’ABE bien avant l’échéance de dépôt.

Si vous n’avez pas encore testé votre registre au regard des règles de validation de l’ABE, c’est la prochaine étape la plus utile. Tout le reste de ce processus repose sur le fait que ces données soient correctement structurées dès le départ.

Pour en savoir plus, consultez votre guide de mise en conformité avec la loi sur la cyber-résilience, votre aperçu des exigences de la directive NIS2 et votre liste de contrôle pour la documentation relative à la norme ISO 27001.

Sources : Autorité bancaire européenne — Préparatifs en vue de la communication des registres d’informations DORA

Risques cybernétiques liés à la chaîne d'approvisionnement : ce que les conseils d'administration doivent savoir en 2026

Un seul fournisseur défaillant peut désormais mettre toute une entreprise à l'arrêt. Ce n'est plus une simple mise en garde. Cela s'est déjà produit, et pas qu'une seule fois.

Le rapport « Global Cybersecurity Outlook 2026 » du Forum économique mondial le confirme. Le risque lié à la chaîne d’approvisionnement est devenu le principal défi en matière de cybersécurité pour les grandes entreprises. Pour les conseils d’administration, il ne s’agit plus d’un sujet à déléguer. C’est une question de gouvernance.

Cet article explique pourquoi ce risque a augmenté si rapidement. Il présente également les questions que les administrateurs et les dirigeants devraient poser à leurs équipes dès maintenant.

Les chiffres qui expliquent cette évolution

Selon ce rapport, 65 % des grandes entreprises considèrent désormais les failles de la chaîne d'approvisionnement comme leur principal obstacle à la cyber-résilience. Ce chiffre est en forte hausse par rapport aux 54 % enregistrés il y a tout juste un an.

Pourquoi cette augmentation ? Parce que les chaînes d'approvisionnement numériques d'aujourd'hui sont étroitement interconnectées. Une faille chez un fournisseur peut avoir des répercussions en cascade sur l'ensemble d'un écosystème. Elle peut affecter simultanément la production, les opérations et même d'autres clients.

Il est évident qu'il ne s'agit pas là d'un risque hypothétique. En réalité, cette situation se produit déjà dans les conseils d'administration du monde entier.

Des incidents réels, des coûts réels

Prenons l'exemple de Jaguar Land Rover. En 2025, une seule cyberattaque a paralysé la production pendant cinq semaines. En effet, cette attaque a perturbé simultanément l'activité de plus de 5 000 fournisseurs.

Les répercussions financières directes ont été lourdes : 196 millions de livres sterling de coûts liés aux cyberattaques et une baisse de près de 25 % du chiffre d'affaires trimestriel. L'économie britannique dans son ensemble a subi des pertes estimées à 1,9 milliard de livres sterling. Le gouvernement est même intervenu en accordant une garantie de prêt de 1,5 milliard de livres sterling afin de stabiliser la chaîne d'approvisionnement.

Prenons l'exemple d'Asahi, le fabricant japonais de boissons. Une cyberattaque survenue fin 2025 a paralysé ses principaux systèmes informatiques. En conséquence, le personnel a dû se rabattre sur le stylo et le papier simplement pour suivre l'état des stocks.

De même, en Europe, une faille relativement mineure chez un prestataire chargé de l'enregistrement dans un aéroport a entraîné des retards et des annulations de vols à grande échelle. La solution technique était simple. En revanche, les répercussions sur l'activité n'avaient rien de simples.

Ensemble, ces cas envoient un message clair aux dirigeants. La faiblesse d'un fournisseur se transforme rapidement en crise pour votre entreprise.

Pourquoi la confiance envers les fournisseurs s'effrite-t-elle ?

Au cœur de ce problème se cache une vérité simple, mais dérangeante : la plupart des entreprises ne sont pas en mesure de vérifier pleinement la sécurité des fournisseurs dont elles dépendent.

Le rapport du Forum économique mondial (WEF) qualifie ce phénomène de « risque d’héritage ». En termes simples, cela signifie hériter des vulnérabilités d’un fournisseur sans en avoir conscience. Ce risque figure désormais en tête des préoccupations liées à la chaîne d’approvisionnement dans cette enquête.

Vient ensuite le manque de visibilité. De nombreuses entreprises ne disposent tout simplement pas d'une vue d'ensemble claire de leur chaîne d'approvisionnement étendue. Elles ne peuvent donc pas gérer les risques qu'elles ne voient pas.

Enfin, il y a le risque de concentration. Les entreprises dépendent de plus en plus d’un petit nombre de fournisseurs essentiels, comme les grandes plateformes cloud. Ainsi, si l’un de ces fournisseurs venait à faire faillite, les répercussions pourraient toucher des milliers d’entreprises du jour au lendemain.

Ce qui distingue les entreprises les plus résilientes

Le rapport établit une distinction claire entre les organisations résilientes et les autres. Cette différence tient à des pratiques spécifiques, dont le conseil d'administration a pleinement conscience.

Les entreprises très résilientes associent leurs équipes de sécurité aux décisions d'achat dans 76 % des cas. Les entreprises moins résilientes ne le font que dans 53 % des cas. En d'autres termes, la sécurité doit avoir son mot à dire avant la signature des contrats, et non après une violation.

De même, 74 % des entreprises résilientes évaluent de manière formelle le niveau de maturité de leurs fournisseurs en matière de sécurité. Seules 48 % des entreprises moins résilientes font de même.

Les entreprises résilientes se préparent également à faire face à des défaillances. Ainsi, 44 % d’entre elles organisent des simulations conjointes d’incidents avec leurs partenaires de la chaîne d’approvisionnement, contre seulement 16 % de leurs homologues moins résilientes. Cette préparation porte ses fruits : seules 15 % des entreprises hautement résilientes font état d’une planification insuffisante de la réponse aux incidents, contre 37 % des autres.

Le rôle du conseil d'administration n'est plus facultatif

C'est désormais l'implication du conseil d'administration qui distingue les entreprises résilientes des entreprises vulnérables. Les données à ce sujet sont frappantes.

Parmi les organisations faisant preuve d'une grande résilience, 99 % indiquent que leur conseil d'administration s'implique activement dans la cybersécurité. Un peu plus de la moitié reçoivent régulièrement des informations sur les risques cybernétiques. Près de la moitié affirment que leur conseil d'administration a un rôle de supervision clairement défini.

À l'inverse, les conseils d'administration des entreprises moins résilientes se désengagent beaucoup plus souvent. Cet écart en matière de surveillance se répercute directement sur l'écart observé au niveau des résultats.

Pour les dirigeants, le message est clair : la supervision de la cybersécurité n'est pas une simple formalité technique. Il s'agit au contraire d'un élément central de la gestion des risques d'entreprise, au même titre que les risques financiers et opérationnels.

Les questions que tout conseil d'administration devrait se poser

Compte tenu de tout cela, que devraient faire concrètement les dirigeants ? Quelques questions ciblées peuvent être le moteur d'un véritable changement.

Commencez par vous demander dans quelle mesure les équipes chargées de la sécurité participent à la sélection des fournisseurs. Si le processus d'achat se poursuit sans examen de sécurité, il s'agit là d'une lacune en matière de gouvernance qu'il convient de combler.

Deuxièmement, demandez une cartographie des dépendances critiques. Plus précisément, la direction doit savoir quels fournisseurs, s'ils faisaient l'objet d'une violation, causeraient le plus de dommages.

Troisièmement, demandez si l'entreprise a testé son plan d'intervention avec ses principaux partenaires. En effet, un plan que personne n'a mis en pratique échoue souvent au moment où cela compte le plus.

Enfin, demandez comment l'entreprise gère le risque de concentration. Après tout, s'en remettre à un seul fournisseur essentiel, sans plan de secours, constitue une vulnérabilité stratégique, et pas seulement technique.

En résumé

Les risques liés à la chaîne d’approvisionnement ne sont plus l’affaire de la salle des serveurs, mais celle de la salle du conseil d’administration. Les conclusions du Forum économique mondial (FEM) pour 2026 ne laissent aucun doute sur cette évolution.

Cependant, la voie à suivre est clairement définie. Les entreprises qui intègrent la sécurité dès le début, recensent leurs dépendances et s'entraînent à réagir sont nettement plus résilientes.

Pour les conseils d'administration, le message est clair. Posez les questions qui fâchent dès maintenant, avant que les faiblesses d'un fournisseur ne fassent la une des journaux.

Source : Forum économique mondial, « Global Cybersecurity Outlook 2026 », janvier 2026.

Cybersécurité des petites entreprises : les signaux d'alerte dans le rapport 2025 du Forum économique mondial (WEF)

La cybercriminalité n'est plus l'apanage des grandes entreprises. En réalité, ce sont désormais les petites et moyennes entreprises qui constituent le maillon faible de la chaîne.

C'est le message clair qui ressort du rapport « Global Cybersecurity Outlook 2025 » du Forum économique mondial. Ce rapport s'appuie sur une enquête menée auprès de centaines de dirigeants d'entreprises et de responsables de la sécurité à travers le monde. Ses conclusions dressent un tableau inquiétant pour les petites entreprises.

Cet article présente en détail les conclusions du rapport. Il explique également ce que les chefs d'entreprise et les dirigeants de petites entreprises peuvent faire dès aujourd'hui pour y remédier.

Le fossé entre les petites et les grandes entreprises ne cesse de se creuser

Selon le rapport du Forum économique mondial, 35 % des petites entreprises déclarent aujourd'hui que leurs défenses informatiques sont insuffisantes. Ce chiffre a été multiplié par sept depuis 2022, année où il n'était que de 5 %.

Les grandes entreprises, quant à elles, prennent le contre-pied de cette tendance. À titre de comparaison, seules 7 % des grandes entreprises déclarent aujourd’hui disposer de systèmes de protection insuffisants, contre 13 % il y a quelques années.

En d'autres termes, les grandes entreprises gagnent en puissance. Les petites entreprises, quant à elles, prennent de plus en plus de retard. Et comme les chaînes d'approvisionnement relient les petits fournisseurs aux grandes entreprises, cet écart met tout le monde en danger.

Le rapport ne mâche pas ses mots. Lors de la réunion annuelle 2024 du Forum économique mondial (FEM) consacrée à la cybersécurité, 71 % des responsables de la cybersécurité se sont accordés sur un point. Selon eux, les petites entreprises ont déjà atteint un point de basculement. Beaucoup d’entre elles ne sont plus en mesure de se défendre contre les menaces actuelles.

Pourquoi les petites entreprises ont du mal à suivre le rythme

Plusieurs facteurs expliquent cet écart qui ne cesse de se creuser. Les comprendre constitue la première étape pour y remédier.

Une pénurie de personnel qualifié. Le rapport fait état d'un déficit mondial de 2,8 à 4,8 millions de professionnels de la cybersécurité. Ce sont les petites entreprises qui ressentent le plus durement cette pénurie. En effet, elles sont rarement en mesure de rivaliser avec les grandes entreprises en matière de salaires ou d'avantages sociaux.

Seules 14 % des entreprises déclarent disposer des compétences dont elles ont besoin. Pour les petites entreprises, le déficit de compétences occupe la deuxième place parmi les obstacles auxquels elles sont confrontées. Seule la complexité même des menaces actuelles arrive avant.

Budgets et ressources limités. Les grandes entreprises ont les moyens de se doter d’équipes de sécurité dédiées, d’outils de pointe et de faire appel à des consultants externes. Ce n’est généralement pas le cas des petites entreprises. Cela signifie que les moyens de défense en place sont moins nombreux lorsqu’une attaque se produit.

La complexité ne cesse de croître partout. Les tensions internationales, les nouvelles réglementations et l'évolution rapide des technologies ne font qu'accentuer la pression. Près de 60 % des entreprises affirment que les tensions internationales ont déjà bouleversé leurs plans de sécurité. Les petites équipes ont tout simplement moins de temps pour suivre chaque nouvelle évolution.

Les menaces que les petites entreprises doivent surveiller de près

Dans la pratique, toutes les cybermenaces n'affectent pas toutes les entreprises de la même manière. Le rapport du Forum économique mondial met en avant celles qui revêtent actuellement la plus grande importance.

Les ransomwares occupent toujours la première place. Quelle que soit la taille de l'entreprise, 45 % des personnes interrogées considèrent les ransomwares comme leur principal risque cybernétique. Les cybercriminels louent de plus en plus souvent des outils de ransomware à des malfaiteurs moins expérimentés. En conséquence, les attaques sont plus nombreuses et plus fréquentes.

La fraude et le hameçonnage suivent de près. Environ un répondant sur cinq a cité la fraude informatique, notamment le hameçonnage et les fausses demandes de paiement, comme sa principale préoccupation. Ces attaques visent souvent les petites entreprises. Pourquoi ? Parce que leur personnel ne bénéficie pas toujours de la même formation à la sécurité que celle dispensée dans les grandes entreprises.

Les « deepfakes » générés par l’IA constituent un risque émergent. Les cybercriminels utilisent désormais l’IA générative pour falsifier de manière convaincante la voix et l’image de dirigeants. En effet, une étude citée dans le rapport a révélé une hausse de 223 % du nombre d’outils de « deepfake » commercialisés sur le dark web. Cette augmentation s’est produite en l’espace d’une seule année. Plus de la moitié des responsables de la sécurité interrogés considèrent désormais les « deepfakes » comme une menace réelle.

Le risque lié aux tiers et à la chaîne d'approvisionnement est bien réel, même si cela ne semble pas être le cas. Les grandes entreprises considèrent le risque lié à la chaîne d'approvisionnement comme leur principale préoccupation. Cela s'explique en grande partie par le fait qu'elles dépendent de petits fournisseurs comme vous. Si vos systèmes sont compromis, les répercussions peuvent s'étendre à tous les partenaires avec lesquels vous travaillez.

Ce que les petites entreprises peuvent faire dès maintenant

Pour autant, ce rapport n'est pas seulement un avertissement. Il propose également des mesures concrètes qui permettent d'obtenir des résultats tangibles, même sans disposer d'un budget important en matière de sécurité.

Tout d'abord, misez sur vos collaborateurs. Le rapport du Forum économique mondial (FEM) révèle que 76 % des entreprises comblent leur déficit de compétences en formant leur personnel actuel. Elles sont de moins en moins nombreuses à se contenter de recruter de nouveaux spécialistes. Ainsi, une formation de base à la sécurité destinée à l'ensemble de votre équipe, et pas seulement au personnel informatique, contribue grandement à prévenir le hameçonnage et la fraude.

Deuxièmement, impliquez la direction. Le rapport révèle que 62 % des entreprises très résilientes informent régulièrement leurs dirigeants des risques liés à la cybersécurité. Seules 29 % des entreprises moins résilientes font de même. En résumé, la cybersécurité est plus efficace lorsqu’elle est considérée comme une priorité stratégique, et non comme une simple question technique.

Troisièmement, préparez-vous spécifiquement aux attaques par ransomware. Comme il s'agit toujours du risque numéro un, ne laissez rien au hasard. Conservez des sauvegardes hors ligne. Testez votre plan d'intervention. Et assurez-vous que chacun connaisse son rôle en cas d'attaque.

Quatrièmement, vérifiez les demandes inhabituelles. Les « deepfakes » générés par l'IA et les escroqueries par usurpation d'identité se multiplient rapidement. Il convient donc de former les employés à vérifier minutieusement les demandes de paiement inhabituelles ou les instructions provenant de la direction. Un simple coup de fil avant d'agir peut permettre de déjouer une escroquerie.

Enfin, posez des questions à vos fournisseurs et partenaires. Si vous approvisionnez de grandes entreprises, par exemple, attendez-vous à ce qu’elles vous interrogent sur vos pratiques en matière de sécurité. Anticiper ces questions permet d’instaurer un climat de confiance et de préserver vos relations commerciales.

En résumé

Le rapport 2025 du Forum économique mondial (FEM) met clairement en évidence une chose : disposer de solides défenses cybernétiques n’est plus une option pour les petites entreprises. L’écart entre les grandes et les petites entreprises est bien réel, et il ne cesse de se creuser.

Cependant, le rapport montre également que pour réaliser de réels progrès, il n'est pas nécessaire de disposer d'un budget important. Former son équipe, impliquer les dirigeants et se préparer à faire face aux menaces courantes peut déjà faire une grande différence.

On pourrait avoir l'impression que la cybersécurité est un problème réservé aux grandes entreprises. Mais comme le montre le rapport de cette année, les petites entreprises ne peuvent plus se permettre de penser ainsi.

Source : Forum économique mondial, « Global Cybersecurity Outlook 2025 », janvier 2025.

63% of boards say their cyber governance isn’t good enough

Cyber risk has become continuous. The governance that oversees it, however, is still periodic.

The result: 63% of boards consider their current practices insufficient to oversee this risk. Five structural causes explain why.

1. Periodic oversight for a continuous risk

Review cadence hasn’t caught up with how the risk actually behaves. In fact, 29% of French companies review cyber risk only once a year, at ExCo or board level.

Attackers don’t wait for the next quarterly meeting. Increasingly, neither can oversight. The World Economic Forum’s 2026 Global Cybersecurity Outlook confirms this shift: threat landscapes now move in near real time. AI drives that speed, on both the offensive and the defensive side.

2. Silos that don’t cover their own seams

Blind spots rarely form inside a single team. Instead, they form in the gap between teams.

Here’s an example: 79% of French companies already use AI internally, but only 42% do so with a formalized security strategy. That 37-point gap is exactly where risk hides.

This isn’t just a French pattern, either. Globally, 87% of organizations named AI-related vulnerabilities their fastest-growing cyber risk last year (WEF, 2026). Meanwhile, security teams are catching up: the share of organizations that assess AI tools before deployment jumped from 37% to 64% in just one year.

3. A skills gap that keeps widening

54% of organizations lack the skills to deploy AI securely. This gap doesn’t close on its own — it widens as AI adoption outpaces upskilling.

So which roles are missing? Globally, three stand out: threat intelligence analysts, DevSecOps engineers, and identity and access management specialists (WEF, 2026). These are exactly the profiles you need to secure AI at scale, not generalist security hires.

4. Regulatory fragmentation that redirects the effort

NIS2, DORA, ReCyF, ISO: each framework brings its own lens, its own evidence requirements, its own audit cadence. As a result, 76% of CISOs say this multiplicity hurts their ability to stay compliant.

So effort shifts from protection to regulatory paperwork. And the scope keeps expanding: 59% of French companies already consider themselves in scope for NIS2 alone, ahead of DORA (32%) and the Cyber Resilience Act (30%). Three overlapping regimes, three separate compliance tracks, one finite security budget.

5. Third-party risk managed by declaration, not by control

30% of French cyber incidents originate with a third party. Yet only 23% of companies monitor their attack surface continuously. The rest relies on a contract clause. In other words, it relies on trust, not on control.

A model built for a pace that no longer exists

The takeaway is simple: boards built cyber governance for a pace of risk that no longer exists.

Getting out of this impasse follows a four-step path:

Ad hoc GRC → Standardization → Centralization → Automation

Each step corrects one of these five causes, in order. Standardization closes the gaps between silos (#2). Centralization turns periodic reporting into continuous visibility (#1), and it also cuts through regulatory duplication (#4). Automation closes the skills gap (#3) last, and it’s what finally makes continuous third-party monitoring (#5) realistic instead of aspirational.

So, where does your organization sit on that path today — still running ad hoc GRC, or already automating?

Sources: WEF, CESIN, Gartner

#SharpenCISO #CISO #GRC #Cybersecurity #ISO27001 #ISO27005 #EBIOS #NIS2 #DORA #NIST #Compliance #SecurityByDesign #RiskManagement

La conformité en matière de cybersécurité ne devrait plus constituer un frein à la croissance

Démontrer sa maturité en matière de cybersécurité est désormais un obstacle à surmonter avant qu'une entreprise puisse se développer. Pour de nombreuses organisations, la conformité fait désormais partie intégrante du chemin critique de chaque déploiement, de chaque appel d'offres et de chaque audit.

Trois situations de la vie quotidienne illustrent parfaitement comment cela fonctionne.

Un chef de projet doit obtenir l'accord de l'équipe chargée de la cybersécurité avant de déployer une nouvelle application — et cette validation peut prendre plusieurs semaines si les éléments justificatifs nécessaires ne sont pas déjà disponibles.
Un fournisseur informatique doit démontrer son niveau de sécurité lors d'un appel d'offres, généralement au moyen d'une certification ISO 27001 ou SOC 2 — et un seul document manquant peut le faire sortir de la course.
Une organisation doit prouver sa conformité aux autorités de régulation, dans le cadre de réglementations telles que la directive NIS 2, la directive DORA ou la CRA — chacune ayant ses propres exigences en matière de preuves et ses propres délais.

Un rythme que les méthodes traditionnelles ne peuvent pas suivre

Les cyberattaques se multiplient. L'intelligence artificielle se généralise. Les exigences réglementaires ne cessent de se multiplier, souvent au sein d'une même équipe et en même temps.

En conséquence, les équipes de sécurité doivent faire face à des exigences accrues avec les mêmes ressources limitées. Les référentiels eux-mêmes ne cessent de s'accumuler : NIS2, DORA et la CRA se chevauchent désormais dans de nombreuses organisations, chacun ayant sa propre fréquence d'audit et sa propre piste de vérification.

Les approches traditionnelles reposaient principalement sur une vérification manuelle effectuée par des personnes, et elles ne parviennent tout simplement plus à suivre le rythme. Les tableurs, les audits ponctuels et les certifications à un moment donné convenaient à un environnement de risque plus lent et plus prévisible — mais pas à un changement continu, accéléré par l'IA.

Pourtant, lorsque les entreprises innovent au rythme de l'IA, la mise en conformité en matière de cybersécurité doit suivre ce même rythme. Sinon, la conformité cesse de protéger l'entreprise et commence à la freiner.

SharpenCISO : une plateforme GRC enrichie

C'est précisément pour cette raison que nous avons créé SharpenCISO.

Notre plateforme automatise jusqu’à 80 % des tâches manuelles nécessaires pour démontrer la conformité en matière de cybersécurité et gérer les risques en temps réel. Il ne s’agit pas de supprimer l’intervention humaine du processus, mais de libérer votre équipe des tâches répétitives de collecte de preuves, afin que son expertise puisse être mise à profit là où elle crée le plus de valeur : les prises de décision, les évaluations des risques et les discussions stratégiques avec l’entreprise.

Concrètement, SharpenCISO automatise la collecte des éléments attestant de la maturité cybernétique pour quatre publics à la fois :

Les autorités de régulation, dans le cadre de réglementations telles que la directive NIS 2, la directive DORA et la CRA
Les équipes chargées de la sécurité interne (SSI), qui ont besoin d'une visibilité en continu plutôt que d'un aperçu annuel ponctuel
Organismes de certification pour des normes telles que l'ISO 27001 ou SOC 2
Appels d'offres et demandes de propositions des clients, où la démonstration de la maturité en matière de sécurité influence désormais les résultats commerciaux et les décisions relatives aux risques

Une base de données factuelles. Quatre publics cibles. Aucune duplication des efforts.

Faire de la cybersécurité un avantage concurrentiel

Telle est notre ambition. La démonstration de la maturité cybernétique ne devrait jamais freiner une organisation.

Bien menée, cette démarche produit l’effet inverse. Elle renforce la confiance des autorités de régulation et des clients. Elle accélère les projets au lieu de les freiner. Et elle ouvre des portes — contrats, partenariats et marchés — qui restaient auparavant fermées jusqu’à ce que les formalités administratives soient réglées.

La conformité ne devrait pas être un frein. Elle devrait être un accélérateur.

#SharpenCISO #CISO #RSSI #GRC #Cybersécurité #ISO27001 #ISO27005 #EBIOS #NIS2 #DORA #NIST #Conformité #SecurityByDesign #GestionDesRisques #IASécurisée #SécuritéDeL'IA

Les données relatives aux risques cybernétiques sont-elles suffisamment fiables pour permettre au comité de direction de prendre des décisions ?

Le risque cyber figure désormais à l'ordre du jour de presque tous les conseils d'administration. Mais les données qui sous-tendent ces discussions reflètent-elles réellement ce qui se passe au sein du système d'information ? C'est la question à laquelle chaque RSSI doit tôt ou tard répondre devant son comité exécutif ou son conseil d'administration.

Trois chiffres tirés du dernier baromètre OpinionWay réalisé pour le CESIN ont retenu notre attention :

92 % des entreprises classent le risque cyber parmi leurs cinq principaux risques commerciaux.
29 % ne l'examinent qu'une fois par an, au sein du comité exécutif ou du conseil d'administration.
61 % le révisent plusieurs fois par an, au même niveau.

Le risque cyber est donc clairement devenu un risque stratégique pour l'entreprise, et non plus seulement un risque technique. Et cette évolution a une conséquence : on attend désormais des responsables de la sécurité des systèmes d'information (RSSI) qu'ils contribuent à la prise de décisions stratégiques au sein du conseil d'administration, et non plus qu'ils se contentent de rendre compte des incidents passés.

Le risque cyber a gagné sa place à la table des discussions — mais les données n'ont pas encore rattrapé leur retard

Les données financières transmises au conseil d'administration font l'objet d'audits, sont présentées selon des formats standardisés et sont soumises à des contrôles mis en place au fil des décennies. Ce n'est toujours pas le cas des données relatives aux risques cybernétiques dans la plupart des organisations.

Cet écart ne se limite pas à une simple habitude de reporting. Il se reflète également dans les décisions qui en découlent. Pour la première fois en trois ans, la part des entreprises françaises consacrant 5 % ou plus de leur budget informatique à la sécurité a en effet diminué en 2025, passant de 48 % à 42 % (CESIN, 2026). Lorsque les données sur lesquelles repose cette décision ne sont qu’un instantané obsolète, le budget qui en découle est établi sur la base d’informations anciennes — et non en fonction des risques tels qu’ils se présentent aujourd’hui.

Une question qui revient sans cesse chez les RSSI

Voici ce qui revient sans cesse dans nos échanges avec les RSSI : les données consolidées à quelques moments clés de l'année reflètent-elles réellement la réalité opérationnelle du système d'information ? Et ces données sont-elles suffisamment fiables pour étayer les décisions stratégiques d'un RSSI au sein du comité exécutif ou du conseil d'administration ?

Dans de nombreuses organisations, les équipes continuent de rassembler ces données manuellement, à partir d’outils disparates, juste avant la réunion. Au moment où elles sont présentées au conseil d’administration, elles ne constituent déjà plus qu’un instantané de la situation telle qu’elle était quelques semaines auparavant — et non de celle d’aujourd’hui.

Chez SharpenCISO, nous sommes convaincus que le véritable enjeu ne réside pas dans l'augmentation de la fréquence des mesures, mais bien dans l'utilisation, dès le départ, de données plus fiables. Augmenter la fréquence des rapports sans veiller à la qualité des données revient simplement à présenter une image erronée, mais plus souvent.

Ce que signifie réellement le terme « fiable » dans ce contexte

La fiabilité ne se limite pas à l'exactitude des données au moment de leur collecte. Elle implique également que ces données soient à jour lorsqu'elles parviennent au décideur.

Prenons l’exemple des risques liés aux tiers. Seules 23 % des entreprises françaises surveillent en permanence leur surface d’attaque ; la plupart s’appuient encore sur une clause contractuelle, examinée une seule fois et rarement réexaminée. Il s’agit là autant d’un choix de gouvernance que d’un choix technique, et c’est précisément le genre de lacune qu’un rapport ponctuel peut masquer.

Cette même évolution est déjà en cours dans d’autres domaines de la sécurité. La part des organisations qui évaluent leurs outils d’IA avant leur déploiement a presque doublé en un an, passant de 37 % à 64 % (WEF, 2026). La vérification continue devient la norme en matière de risques liés à l’IA. Les rapports GRC en matière de cybersécurité destinés au conseil d’administration doivent suivre cette même évolution : passer d’un instantané périodique à une vue en temps réel.

Alors, quel est votre niveau de confiance ?

Nous sommes curieux de savoir : dans quelle mesure votre organisation se fie-t-elle à ses données GRC en matière de cybersécurité lorsqu'il s'agit de prendre une décision au sein du comité exécutif ou du conseil d'administration ?

Responsables de la sécurité des systèmes d'information (RSSI), les données que vous présentez correspondent-elles à la réalité sur le terrain ? Et vous, membres du conseil d'administration, avez-vous l'impression de prendre des décisions en fonction des risques actuels ou de ceux du dernier trimestre ? Faites-nous part de vos commentaires : nous aimerions savoir comment vous percevez la situation de votre point de vue.

#SharpenCISO #CISO #RSSI #GRC #Cybersécurité #ISO27001 #ISO27005 #EBIOS #NIS2 #DORA #NIST #Conformité #SecurityByDesign #CRA

La cybersécurité devient un enjeu de gouvernance. Il s’agit désormais d’une question de résilience et de maîtrise des risques, et non plus uniquement de défense technique. Le dernier baromètre OpinionWay réalisé pour le CESIN confirme cette évolution : trois cadres réglementaires dominent désormais les priorités des entreprises en France.

Au total, 59 % des entreprises françaises déclarent être concernées par la directive NIS 2, 32 % par la directive DORA et 30 % par la directive CRA (CESIN, 2026). Mais ces moyennes masquent un fossé marqué selon la taille des entreprises. C’est dans ce fossé que réside la véritable réalité.

1. NIS2 : le nouveau centre de gravité

70 % des grandes entreprises considèrent la directive NIS 2 comme une priorité absolue. Parmi les très petites et moyennes entreprises (TPE/PME), ce chiffre tombe à seulement 44 %.

Cet écart s'explique. Les grandes entreprises ont déjà franchi l'étape de la norme NIS1 ; elles connaissent donc bien la marche à suivre : gestion des risques, notification des incidents, responsabilité au niveau du conseil d'administration. Les structures plus modestes, en revanche, commencent seulement à prendre la mesure de la portée réelle des exigences, notamment des obligations qui s'étendent à leur chaîne d'approvisionnement et ne se limitent pas à leurs propres systèmes.

2. DORA : la résilience opérationnelle au cœur du secteur financier

La directive DORA reste une priorité majeure pour les grandes entreprises, avec un taux de 38 %. Ce chiffre reflète son champ d'application : les établissements financiers et leurs fournisseurs de services informatiques essentiels.

Tests de résilience, gestion des risques liés aux tiers, gouvernance : la directive DORA impose une discipline rigoureuse. Et comme elle s'applique directement tant aux prestataires de services informatiques qu'aux établissements financiers, son impact s'étend bien au-delà du secteur financier lui-même.

3. La CRA : la sécurité des produits dès la conception

Avec la CRA, la logique change. La sécurité doit être intégrée dès le départ, et non ajoutée a posteriori. C'est là l'essence même des principes « Secure by Design » et « Secure by Default ».

Les grandes entreprises ont là aussi une longueur d’avance : 37 % d’entre elles se préparent déjà à la CRA, contre seulement 23 % des entreprises de taille intermédiaire (ETI). Cet écart de 14 points est significatif, car la mise en œuvre des exigences fondamentales de la CRA — les listes de composants logiciels (SBOM) et la gestion des correctifs — prend du temps. Attendre la date limite n’est pas vraiment une option.

Ce qui distingue les organisations les plus performantes

Nous sommes convaincus que les organisations qui progressent le plus rapidement auront en commun trois habitudes :

Ils mutualisent les contrôles et les cadres de référence entre les différentes réglementations, au lieu de gérer en parallèle des programmes de conformité distincts pour la directive NIS2, la directive DORA et la CRA.
Ils hiérarchisent les mesures à prendre en fonction du niveau de risque réel, et non en fonction de la facilité avec laquelle on peut en apporter la preuve. La case la plus facile à cocher en matière de conformité n'est pas toujours celle qui correspond au risque le plus important.
Elles fournissent aux équipes chargées de la conformité, du risque et de la gouvernance (GRC) dans le domaine cybernétique les outils nécessaires pour industrialiser les évaluations, produire des preuves fiables et gérer simultanément plusieurs réglementations — sans multiplier les efforts à chaque fois.

Il ne s'agit pas d'une opportunité négligeable. Comme nous l'avons évoqué dans un article précédent, 76 % des RSSI affirment déjà que la gestion simultanée de plusieurs référentiels nuit à leur capacité à rester en conformité. La convergence n'est pas un simple atout supplémentaire : c'est la clé pour garantir une conformité durable.

Faire de la conformité un levier, et non une obligation

C'est précisément l'approche que nous mettons en place avec SharpenCISO, notre plateforme GRC native IA, automatisée en temps réel.

Notre objectif est simple : faire de la conformité un véritable levier de gestion des risques cybernétiques — un levier qui renforce durablement le niveau de sécurité — plutôt qu’une succession d’obligations réglementaires à cocher, un cadre à la fois.

Alors, qu'avez-vous mis en place ?

Nous sommes curieux : quelles mesures avez-vous mises en place pour améliorer les performances et l'impact de vos équipes chargées de la gouvernance, du risque et de la conformité (GRC) en matière de cybersécurité ?

Utilisez-vous toujours NIS2, DORA et la CRA comme des volets distincts, ou avez-vous déjà commencé à mettre en commun vos efforts ? Faites-le-nous savoir dans les commentaires.

#SharpenCISO #CISO #RSSI #GRC #Cybersécurité #ISO27001 #ISO27005 #EBIOS #NIS2 #DORA #NIST #Conformité #SecurityByDesign #CRA