Alain Rees · 11-07-2026 · 15 min leestijd
Comment traduire les exigences des lois, des normes et des contrats en un ensemble cohérent et opérationnel
La gestion de la conformité a, chez beaucoup de professionnels, une image poussiéreuse. Elle évoque des listes à cocher, des preuves à rassembler et un auditeur à satisfaire. Cette image ne rend pas justice à la discipline. Une gestion de la conformité bien conçue est le processus qui traduit les exigences externes et internes en mesures concrètes, puis qui rend démontrable que ces mesures fonctionnent. La différence entre une organisation qui, chaque année, rassemble ses preuves dans la panique et une organisation qui traverse ses audits de manière routinière tient presque entièrement à ce processus. Dans cet article, vous découvrirez comment mettre en place la gestion de la conformité pour la sécurité de l'information et la protection des données, et comment y intégrer dès maintenant le règlement sur l'IA.
En bref
- La gestion de la conformité traduit les exigences issues de la législation, des normes, des contrats et des politiques internes en mesures, et rend leur fonctionnement démontrable.
- Conforme n'est pas synonyme de sûr : la conformité est pilotée par les règles, la sécurité est pilotée par les risques, et les deux processus doivent s'alimenter mutuellement.
- Le processus comporte cinq étapes : registre des exigences, analyse d'applicabilité, traduction en mesures, surveillance et mesure, puis reporting et ajustement.
- Un jeu de mesures commun servant tous les référentiels évite de faire trois fois le même travail.
- Le processus de conformité coïncide avec les quatre phases du modèle Kantyra : détecter, évaluer, résoudre et démontrer.
Un avertissement s'impose d'abord : conformité et sécurité se recouvrent fortement, mais ne coïncident pas. La conformité est pilotée par les règles, car vous satisfaites une exigence formulée par quelqu'un d'autre. La sécurité est pilotée par les risques, car vous maîtrisez une menace pertinente pour votre organisation. Une organisation peut satisfaire à toutes les exigences formelles et rester vulnérable, par exemple parce que les exigences sont en retard sur le paysage des menaces ou parce que des mesures existent sur le papier mais ne fonctionnent pas dans la pratique. À l'inverse, une organisation bien sécurisée peut néanmoins avoir un problème de conformité, parce qu'elle ne peut pas démontrer sa propre maîtrise.
La conclusion pratique est que la gestion de la conformité ne doit jamais prendre la place de la gestion des risques, mais que les deux processus doivent s'alimenter mutuellement. Les exigences légales constituent le plancher et le cadre, tandis que l'analyse des risques détermine ce dont votre organisation a besoin au-delà.
Pour la sécurité de l'information et la protection des données, les exigences arrivent de quatre directions. La première source est la législation. Le RGPD régit le traitement des données à caractère personnel et s'applique à presque toute organisation. NIS2, la directive (UE) 2022/2555, transposée en France sous l'autorité de l'ANSSI et en Belgique par la loi du 26 avril 2024 (en vigueur depuis le 18 octobre 2024, sous l'autorité du CCB), impose un devoir de diligence, une obligation de notification et une obligation d'enregistrement aux organisations des secteurs essentiels et importants, avec une responsabilité explicite de l'organe de direction. Pour le secteur financier s'y ajoute DORA, et des secteurs comme la santé et l'administration disposent de leurs propres référentiels.
La deuxième source est constituée des normes que vous adoptez volontairement ou contractuellement, avec ISO 27001 comme exemple le plus connu. Formellement, une certification n'est pas une obligation légale, mais dès que des clients la demandent ou que vous vous y engagez dans des contrats, l'effet est le même. La troisième source, ce sont les contrats eux-mêmes, tels que les accords de sous-traitance, les annexes de sécurité aux contrats d'achat et les conditions de raccordement des partenaires de la chaîne. La quatrième source est la politique interne, car vos propres règles internes sont elles aussi des exigences auxquelles vous devez satisfaire de manière démontrable.
Et puis il y a le règlement sur l'IA, l'AI Act européen, qui entre en vigueur par étapes. Pour la plupart des organisations, son influence reste pour l'instant limitée, mais pas nulle. L'obligation d'assurer une maîtrise suffisante de l'IA chez les collaborateurs s'applique déjà, et quiconque déploie des systèmes d'IA doit savoir dans quelle catégorie de risque ils se situent. La leçon de vingt ans de législation sur la protection des données est qu'il ne faut pas attendre l'échéance ultime pour se saisir de tels règlements. Intégrez donc dès maintenant les systèmes d'IA dans votre registre des traitements et votre inventaire des actifs : l'AI Act viendra alors s'inscrire dans votre processus de conformité existant au lieu de devenir un chantier distinct. Dans Kantyra, cela a sa propre place : le module IA contient un registre de l'IA dans lequel chaque système porte son rôle, sa catégorie de risque et sa supervision humaine, relié au fournisseur, à l'actif et au traitement.
La gestion de la conformité est un processus cyclique, non un événement annuel. Elle se compose essentiellement de cinq étapes.
La première étape est le registre des exigences. Rassemblez dans un seul registre l'ensemble des lois et réglementations, normes, contrats et documents de politique pertinents, avec, par source, le propriétaire, l'applicabilité et les principales obligations. Ce registre est le fondement de tout ce qui suit. Beaucoup d'organisations sautent cette étape et travaillent référentiel par référentiel, isolément, et c'est précisément là que naissent les doublons et les angles morts. Dans Kantyra, le registre de conformité est ce lieu unique : les référentiels pour NIS2, le RGPD, l'ISO 27701, le règlement sur l'IA et l'ISO/IEC 42001 sont intégrés, et vous saisissez vos propres référentiels, comme les exigences contractuelles ou la politique interne, ou vous les importez depuis Excel, après quoi ils tournent dans le même registre. Chaque exigence porte alors un statut, un propriétaire et une explication.
La deuxième étape est l'analyse d'applicabilité. Toute exigence ne s'applique pas à chaque organisation ou à chaque système. Sous NIS2, la première question est de savoir si votre organisation relève ou non de la loi, et, le cas échéant, en tant qu'entité essentielle ou importante. Sous le RGPD, votre rôle de responsable du traitement ou de sous-traitant détermine les obligations qui pèsent sur vous. Sous le règlement sur l'IA, la catégorie de risque d'un système détermine le régime. Consignez ces analyses, y compris leur justification, car même la décision selon laquelle quelque chose ne s'applique pas doit pouvoir être justifiée par la suite. Dans Kantyra, vous marquez une exigence comme non applicable en y joignant une explication, et pour la question du champ d'application de NIS2 elle-même, la plateforme contient une auto-évaluation qui parcourt le devoir de diligence, l'obligation de notification et l'obligation d'enregistrement. Pour les systèmes d'IA, il existe une classification de risque dédiée, qui vérifie pour chaque système les pratiques interdites, le haut risque et les obligations de transparence.
La troisième étape est la traduction en mesures. C'est ici que se fait le véritable travail, car chaque exigence applicable est reliée à une ou plusieurs mesures concrètes, avec un propriétaire et un statut de mise en œuvre. L'approche la plus astucieuse est un cadre de mesures commun. Le RGPD demande des mesures techniques et organisationnelles appropriées, NIS2 des mesures de gestion des risques et l'ISO 27001 les mesures de l'annexe A, et ces trois ensembles se recouvrent en grande partie. Qui tient un seul jeu de mesures et relie chaque mesure à tous les référentiels qu'elle couvre démontre la conformité au moyen d'une seule preuve face à plusieurs autorités de contrôle et auditeurs. Qui tient une liste distincte par référentiel fait trois fois le même travail. Kantyra est bâti exactement ainsi : vous reliez une même mesure à la fois à des exigences issues de plusieurs référentiels et aux mesures de l'annexe A de l'ISO 27001, de sorte que le cadre commun devient la façon de travailler par défaut plutôt qu'une ambition.
La quatrième étape est la surveillance et la mesure. Une mesure que vous avez mise en œuvre mais que vous ne testez jamais se relâche insensiblement. Définissez, pour chaque mesure, comment vous en constatez le fonctionnement, par exemple au moyen de contrôles automatisés, d'échantillonnages, d'audits internes ou de rapports de direction. Consignez la preuve au moment où elle apparaît, et non après coup ; la démontrabilité est une propriété de vos processus quotidiens, et qui l'organise après coup comme un projet d'archivage arrive trop tard. Dans Kantyra, la preuve est donc rattachée directement à l'objet lui-même : vous reliez des éléments de preuve (un fichier ou une référence) à une exigence, à une mesure ou à un constat, et chaque mesure comporte un test d'efficacité assorti d'une date planifiée qui revient sous forme de tâche dès qu'elle approche.
La cinquième étape est le reporting et l'ajustement. Les écarts reçoivent un propriétaire, un délai de remédiation et, si nécessaire, un risque résiduel formellement accepté. L'image agrégée est transmise périodiquement à la direction, qui, sous NIS2, est elle-même responsable de la supervision de la gestion des risques et doit se tenir activement informée des risques, des mesures et des incidents. Les modifications des lois et réglementations alimentent le registre des exigences, et le cycle recommence. Dans Kantyra, les écarts atterrissent dans le registre des constats, avec source, gravité, personne en charge et échéance (les rapports d'audit s'importent au besoin en une fois), un risque résiduel formellement accepté passe par le registre des exceptions avec une approbation à quatre yeux, et le registre de conformité montre l'avancement par référentiel.
La gestion de la conformité touche plusieurs fonctions, et c'est précisément pourquoi elle exige une répartition claire des rôles. La ligne est et demeure propriétaire de la conformité au sein de son propre processus, tout comme la ligne est propriétaire des risques. La fonction conformité, le RSSI et le responsable central de la protection des données forment ensemble la deuxième ligne. Ils traduisent les exigences, contrôlent la conformité et conseillent, mais ne reprennent pas la responsabilité à leur compte. Le délégué à la protection des données détient en outre un rôle de contrôle indépendant, ancré dans la loi, sur le respect du RGPD. L'audit interne constitue la troisième ligne et fournit une assurance indépendante sur l'ensemble.
Dans les organisations plus petites, ces rôles se confondent en partie en une seule personne. C'est praticable, tant que l'organisation reste consciente des différentes casquettes. Qui conçoit les mesures ne peut pas être aussi le seul à en juger le fonctionnement.
Comme la gestion des risques, la gestion de la conformité ne se laisse pas enfermer dans une seule phase du modèle Kantyra : elle est le cycle du modèle, appliqué aux exigences plutôt qu'aux risques. Les cinq étapes se répartissent comme suit entre les quatre phases.
Le registre des exigences et l'analyse d'applicabilité relèvent de la phase évaluer : vous déterminez quels référentiels et quelles exigences s'appliquent à vous et où vous en êtes, par exemple avec l'auto-évaluation NIS2. La traduction en mesures est la phase résoudre : un jeu de mesures couvrant tous les référentiels. La surveillance et la mesure sont la phase détecter : les tests d'efficacité, les écarts et les nouvelles lois et réglementations alimentent le registre. Et le reporting et l'administration de la preuve forment la phase démontrer : la preuve par exigence et par mesure, l'avancement par référentiel et l'image destinée à la direction et à l'auditeur.
Là où la gestion des risques parcourt le cycle avec la question « pouvons-nous continuer à livrer et qu'est-ce qui peut mal tourner », la gestion de la conformité le fait avec la question « à quoi devons-nous nous conformer et pouvons-nous le montrer ». Les deux processus partagent les mêmes registres, les mêmes mesures et le même rythme, et c'est exactement pourquoi ils ont leur place dans un même environnement.
Comme la gestion des risques, la gestion de la conformité ne fonctionne que lorsqu'elle est reliée aux processus qui l'entourent.
La connexion la plus importante est celle avec la gestion des risques elle-même. Les exigences légales constituent le plancher de votre traitement des risques, car un risque qui touche une obligation légale ne peut pas être simplement accepté. À l'inverse, l'analyse des risques fournit la justification pour concrétiser les normes ouvertes. Là où la loi demande des « mesures appropriées », c'est votre analyse des risques qui détermine ce qui est approprié dans votre contexte.
La deuxième connexion est le processus de gestion des incidents, car les obligations de notification s'accumulent. Une violation de données à caractère personnel se notifie dans les 72 heures à l'autorité de protection des données compétente, un incident important sous NIS2 se notifie par une alerte précoce dans les 24 heures à l'autorité désignée, et les contrats prévoient souvent leurs propres délais de notification envers les clients. Le processus de gestion des incidents doit connaître ces circuits et documenter les arbitrages, y compris lorsque vous décidez qu'une notification n'est pas nécessaire. Dans Kantyra, vous consignez pour chaque incident s'il s'agit d'une violation de données et s'il a été notifié, et le registre surveille les délais NIS2 pour l'alerte précoce, la notification et le rapport final. Dans le champ d'arbitrage, vous consignez également pourquoi vous notifiez ou non.
La troisième connexion est la gestion des fournisseurs, car de nombreuses exigences de conformité se répercutent dans la chaîne. Pensez aux accords de sous-traitance sous le RGPD, aux exigences de sécurité de la chaîne d'approvisionnement sous NIS2 et, bientôt, aux exigences de transparence à l'égard des fournisseurs de systèmes d'IA. Les achats et la gestion des contrats sont ainsi des canaux d'exécution de votre processus de conformité.
La quatrième connexion est la sensibilisation et la formation, car plusieurs référentiels y posent des exigences explicites. NIS2 rend la formation obligatoire pour l'organe de direction, le RGPD suppose que les collaborateurs savent comment traiter les données à caractère personnel, et le règlement sur l'IA exige la maîtrise de l'IA de quiconque travaille avec des systèmes d'IA. Un programme de formation commun qui combine ces exigences est plus efficace et plus crédible que trois modules obligatoires distincts.
Quelle est la différence entre conformité et sécurité ? La conformité est pilotée par les règles : vous satisfaites des exigences formulées par d'autres. La sécurité est pilotée par les risques : vous maîtrisez les menaces pertinentes pour votre organisation. Une organisation peut être conforme et pourtant vulnérable, ou bien sécurisée et pourtant incapable de le prouver. Vous avez besoin des deux processus, et ils doivent s'alimenter mutuellement.
Qu'est-ce qu'un registre des exigences ? Un registre unique où convergent toutes les sources d'exigences : lois et réglementations, normes, contrats et politique interne, avec, par source, l'applicabilité et les principales obligations. Il évite que chaque référentiel n'ait sa propre liste, avec, à la clé, des doublons et des angles morts.
Dois-je tenir des mesures distinctes pour chaque référentiel ? Non, bien au contraire. Le RGPD, NIS2 et l'ISO 27001 demandent en grande partie les mêmes mesures. Tenez un seul jeu de mesures et reliez chaque mesure à tous les référentiels qu'elle couvre ; une seule preuve démontre alors la conformité face à plusieurs autorités de contrôle et auditeurs.
Que dois-je déjà faire pour le règlement sur l'IA ? Assurez la maîtrise de l'IA chez les collaborateurs qui travaillent avec des systèmes d'IA, car cette obligation s'applique déjà. Recensez en outre les systèmes d'IA que vous utilisez et la catégorie de risque dont ils relèvent, et intégrez-les dans votre registre des traitements et votre inventaire des actifs. Le reste du règlement viendra alors s'inscrire dans votre processus existant.
Comment éviter la panique avant un audit ? En consignant la preuve au moment où elle apparaît, rattachée à l'exigence ou à la mesure à laquelle elle se rapporte, et en testant en continu le fonctionnement des mesures. Qui fait cela n'a plus rien à reconstituer pour un audit.
La gestion de la conformité devient maîtrisable dès l'instant où vous cessez de penser en référentiels séparés et commencez à penser en un registre des exigences, un jeu de mesures et une administration de la preuve. Le RGPD, NIS2, l'ISO 27001 et bientôt le règlement sur l'IA posent chacun leurs propres questions, mais la réponse provient du même ensemble de mesures. Qui maîtrise cet ensemble et en consigne en continu le fonctionnement n'a plus rien à reconstituer pour aucun audit ni aucune autorité de contrôle. Qui travaille ainsi n'a plus besoin d'organiser la démontrabilité comme un projet : elle naît d'elle-même, chaque jour.
Vous préféreriez ne pas gérer vos référentiels, exigences, mesures et preuves dans des listes séparées, mais dans un environnement qui s'articule avec votre gestion des risques ? Dans la plateforme GRC de Kantyra, vous gérez le registre de conformité avec des référentiels intégrés et personnalisés, vous reliez un jeu de mesures à tout ce qu'il couvre, et la preuve est rattachée à l'exigence ou à la mesure elle-même. Demandez une démo et découvrez comment la démontrabilité naît naturellement de votre travail quotidien.
Kantyra est une plateforme européenne d'ISMS et de GRC qui permet aux organisations de gérer de manière démontrable leur sécurité de l'information, leur gestion des risques et leur continuité, en cohérence avec l'ISO 27001, l'ISO 22301 et NIS2.
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoMesurez, en tant que CISO, où en sont votre organisation et votre CISO Office, et découvrez comment piloter et corriger à temps grâce à une carte de score.
Comment piloter la gestion des vulnérabilités en tant que RSSI, de la politique jusqu'à la reddition de comptes à la direction.
Comment structurer vos tests d'intrusion, de la politique de pentest et du calendrier jusqu'au rapport et au suivi des constats.