RGPD, IA Act, normes ISO : structurer sa conformité Data & IA

Dans la plupart des organisations, la conformité ressemble à trois chantiers qui ne se croisent jamais. Le RGPD est suivi par le délégué à la protection des données et le juridique. L'IA Act commence à occuper une cellule dédiée, parfois rattachée à la direction des risques. Les normes ISO, quand elles sont visées, relèvent de la qualité ou de la sécurité des systèmes d'information. Trois pilotes, trois plans d'action, trois budgets. Et très peu de passerelles entre eux.

Le résultat est prévisible. Les mêmes données sont cartographiées trois fois sous trois angles différents. Les mêmes systèmes d'IA sont audités par des équipes qui s'ignorent. Une analyse d'impact RGPD est produite d'un côté pendant qu'une évaluation de conformité IA Act se construit de l'autre, sans que personne ne remarque qu'elles parlent du même traitement. La conformité devient une accumulation de procédures qui se chevauchent au lieu d'un cadre qui se tient.

Cette situation n'a rien d'étonnant. Le RGPD est entré en vigueur en 2018, à une époque où l'IA générative ne faisait pas partie du quotidien des entreprises. L'IA Act est arrivé six ans plus tard, porté par d'autres équipes, avec un autre vocabulaire. Les normes ISO, elles, ont leur propre histoire et leur propre rythme de publication. Chaque cadre s'est installé dans l'organisation à un moment différent, par une porte différente. Personne n'a décidé de les cloisonner. Ils le sont devenus, faute d'avoir été pensés ensemble.

Cette fragmentation coûte cher, et pas seulement en heures de travail. Elle crée des angles morts. Un système peut être parfaitement conforme au RGPD et défaillant au sens de l'IA Act, parce que les deux textes ne regardent pas la même chose. Croire que l'un couvre l'autre, c'est le genre de raccourci qui se paie au moment d'un contrôle.

L'idée de cet article est simple. Le RGPD, l'IA Act et les normes ISO ne sont pas trois obligations concurrentes à traiter en parallèle. Ce sont trois couches qui s'emboîtent, et qui partagent un socle d'exigences communes bien plus large qu'il n'y paraît. Une organisation qui l'a compris ne mène pas trois projets de conformité. Elle en mène un seul, structuré, dans lequel chaque cadre vient se brancher au bon endroit. Cet article décrit ce socle, la méthode pour le construire, les erreurs qui guettent en chemin, et la trajectoire à suivre selon le point de départ de l'organisation.

‍

Conformité Data & IA : ce que couvre chaque cadre

Avant de parler d'articulation, il faut poser le périmètre de chacun. La confusion la plus fréquente vient de là : on traite ces trois cadres comme s'ils visaient la même chose, alors qu'ils répondent à des questions différentes. Tant que ce périmètre n'est pas clair, toute tentative de les unifier reste bancale, parce qu'on ne sait pas exactement ce qu'on unifie.

RGPD : la donnée personnelle

Le RGPD, en vigueur depuis 2018, encadre le traitement des données à caractère personnel. Son périmètre est à la fois précis et large : il s'applique dès qu'une organisation collecte, stocke, utilise ou transmet une information rattachable à une personne physique identifiée ou identifiable.

Ce que le RGPD demande tient en quelques principes opérables. Une base légale pour chaque traitement, c'est-à-dire un fondement juridique qui autorise la collecte : le consentement de la personne, l'exécution d'un contrat, une obligation légale, l'intérêt légitime de l'organisation. Une finalité explicite, déclarée dès le départ et non extensible après coup. La minimisation, c'est-à-dire ne collecter que ce qui sert réellement la finalité. Une durée de conservation définie, au-delà de laquelle la donnée doit être effacée ou anonymisée. Et la capacité, à tout moment, de démontrer sa conformité, ce que le règlement appelle l'accountability.

Cette dernière obligation mérite qu'on s'y arrête, parce qu'elle est souvent sous-estimée. L'accountability ne dit pas seulement « soyez conformes ». Elle dit « soyez en mesure de le prouver, à tout moment, documents à l'appui ». Une organisation peut respecter chaque principe du RGPD dans les faits et se retrouver en difficulté lors d'un contrôle, simplement parce qu'elle n'a rien formalisé. C'est pourquoi le RGPD est indissociable d'une stratégie data structurée : sans pilotage d'ensemble, la preuve se construit dans l'urgence, quelques jours avant un contrôle, dans la panique générale.

Ce que le RGPD ne couvre pas mérite d'être dit tout aussi clairement. Il ne s'intéresse pas aux données non personnelles : un jeu de données de capteurs industriels, de relevés météo ou de cours de bourse, sans aucune information rattachable à un individu, sort de son champ. Il ne dit rien non plus de la performance d'un système, de sa disponibilité ou de sa résilience. Et surtout, il ne dit rien de la qualité du modèle d'IA, de sa robustesse, ni des biais qu'il peut produire. Un système peut traiter des données personnelles dans le respect parfait du RGPD tout en produisant des décisions discriminatoires. Le RGPD vérifie que les données des candidats sont bien protégées. Il ne vérifie pas que l'algorithme de tri ne défavorise pas certains profils. C'est précisément cet angle que l'IA Act vient combler.

IA Act : le risque du système d'IA

Le règlement européen sur l'intelligence artificielle, adopté en 2024 et dont l'application s'échelonne jusqu'en 2027, change la nature du regard. Là où le RGPD se concentre sur la donnée, l'IA Act se concentre sur le système et sur son usage. Cette bascule rejoint un mouvement de fond que nous avions analysé du côté de la gouvernance des données face à l'IA générative.

Sa logique repose sur une classification par niveau de risque. Quatre niveaux structurent le texte. Les usages jugés inacceptables, comme la notation sociale généralisée ou certaines formes de manipulation comportementale, sont purement et simplement interdits. Les systèmes à haut risque, par exemple ceux qui interviennent dans le recrutement, l'accès au crédit, l'éducation ou la gestion d'infrastructures critiques, sont soumis à des obligations lourdes : documentation technique détaillée, gestion des risques, qualité des données d'entraînement, supervision humaine, traçabilité, robustesse. Les systèmes à risque limité, comme un chatbot ou un générateur d'images, doivent surtout respecter des obligations de transparence : l'utilisateur doit savoir qu'il interagit avec une IA. Le reste, la grande majorité des usages, relève du risque minimal et n'est presque pas contraint.

Le calendrier d'application est progressif, et c'est un point que beaucoup d'organisations négligent. Les interdictions sont entrées en application les premières. Les obligations sur les modèles d'IA à usage général ont suivi. Les exigences les plus lourdes, celles qui pèsent sur les systèmes à haut risque, s'appliquent plus tard dans le calendrier. Cet échelonnement n'est pas une raison d'attendre. Une organisation qui repère aujourd'hui qu'elle exploite un système à haut risque a besoin de plusieurs mois pour bâtir la documentation, mettre en place la supervision et fiabiliser les données d'entraînement. Le temps réglementaire et le temps de mise en conformité ne sont pas les mêmes.

Le point à retenir : l'IA Act ne classe pas des données, il classe des usages. Un même modèle peut être à haut risque dans un contexte de recrutement et à risque minimal dans un usage de tri documentaire interne. Le modèle de langage qui aide un juriste à résumer des contrats et celui qui filtre des CV peuvent être techniquement identiques. Leur niveau de risque, lui, est radicalement différent. La conformité IA Act ne se décrète donc pas une fois pour le modèle, elle s'évalue système par système, usage par usage. C'est une différence de méthode majeure avec le RGPD, et une source fréquente d'erreurs quand les deux cadres sont confondus.

👉 À lire aussi : Gouverner l'IA en entreprise : rôles, règles et pilotage

ISO 27001, 27701, 42001 : la preuve et le pilotage

Les normes ISO occupent une place différente des deux précédentes. Le RGPD et l'IA Act sont des textes légaux : on les respecte parce qu'on y est obligé, sous peine de sanction. Une norme ISO est un référentiel volontaire. Personne n'oblige une organisation à se certifier. Mais celle qui le fait se dote d'une méthode structurée pour organiser sa conformité et, surtout, pour la prouver.

Trois normes intéressent directement un dispositif Data & IA.

ISO/IEC 27001 structure la sécurité de l'information. Elle définit comment une organisation protège ses données contre la perte, la fuite et l'altération, à travers un système de management de la sécurité documenté et audité. C'est la norme la plus répandue des trois, beaucoup d'organisations la possèdent déjà, souvent à la demande de clients ou de donneurs d'ordre.

ISO/IEC 27701 étend la précédente à la protection de la vie privée. Elle outille concrètement une partie des exigences du RGPD : gestion des données personnelles, traitement des demandes des personnes concernées, relations avec les sous-traitants. Une organisation déjà certifiée 27001 peut viser la 27701 comme une extension naturelle, sans repartir de zéro.

ISO/IEC 42001, publiée fin 2023, est la première norme dédiée au système de management de l'intelligence artificielle. Elle structure la façon dont une organisation conçoit, déploie et surveille ses systèmes d'IA : évaluation des impacts, gestion des risques, supervision, amélioration continue. C'est le pendant méthodologique de l'IA Act. Là où le règlement dit ce qu'il faut atteindre, la norme propose une méthode pour y parvenir et un cadre auditable pour le démontrer.

L'intérêt des normes ISO ne tient pas seulement au certificat. Il tient à la discipline qu'elles imposent. Une norme exige des revues régulières, une amélioration continue, des responsabilités formalisées. Elle empêche la conformité de se dégrader silencieusement entre deux contrôles. Beaucoup d'organisations sont conformes le jour d'un audit et ne le sont plus six mois après, parce que rien n'oblige à entretenir le dispositif. La logique ISO répond exactement à ce problème.

Le socle commun aux trois cadres

C'est ici que se joue la thèse de l'article. Quand on lit le RGPD, l'IA Act et les normes ISO côte à côte, en dépassant les vocabulaires propres à chacun, on retrouve les mêmes exigences de fond. Quatre, pour être précis. Une organisation qui construit ces quatre briques une seule fois, proprement, a déjà couvert la majeure partie des trois cadres. Ce qui reste ensuite, ce sont les exigences spécifiques à chacun, plus légères à traiter une fois le socle en place.

Cartographier les données et les systèmes opérés

Aucun des trois cadres ne fonctionne sans inventaire. Le RGPD impose un registre des traitements : la liste de tous les traitements de données personnelles, avec leur finalité, leur base légale, les données concernées, les destinataires, les durées de conservation. L'IA Act impose, pour les acteurs concernés, de tenir un inventaire des systèmes d'IA et de les classer par niveau de risque. Les normes ISO demandent de définir le périmètre du système de management, ce qui suppose de savoir exactement quels actifs et quels systèmes sont couverts.

Trois exigences, un seul geste de fond : savoir ce qu'on opère. Une organisation qui ne sait pas quelles données elle détient ni quels systèmes d'IA tournent en interne ne peut être conforme à rien, parce qu'elle ne peut même pas décrire ce qu'elle doit protéger. La cartographie n'est pas une formalité administrative, c'est le préalable sans lequel les trois cadres restent lettre morte.

Le piège, ici, c'est l'illusion d'inventaire. Beaucoup d'organisations pensent connaître leurs traitements et leurs systèmes d'IA. En pratique, une partie échappe au radar. Des outils d'IA souscrits directement par une direction métier, sans passer par la DSI. Des extensions activées dans des logiciels existants. Des traitements hérités d'anciens projets, que plus personne ne pilote. Une cartographie sérieuse part du terrain, interroge les métiers, et ne se contente pas de la vision théorique du système d'information. Ce travail rejoint directement les fondations d'une gouvernance des données bien posée.

Évaluer le risque avant de déployer

Les trois cadres demandent la même chose au même moment : qualifier le risque en amont, avant la mise en production. Le RGPD prévoit l'analyse d'impact relative à la protection des données, l'AIPD, obligatoire dès qu'un traitement présente un risque élevé pour les personnes. L'IA Act impose une évaluation de conformité pour les systèmes à haut risque avant leur mise sur le marché ou en service. Les normes ISO placent l'analyse de risque au cœur de leur fonctionnement, comme étape obligatoire et récurrente.

Le vocabulaire diffère, le geste est identique. On n'évalue pas le risque une fois le système en production, on l'évalue avant. L'enjeu est double. D'abord, un risque identifié avant le déploiement coûte beaucoup moins cher à corriger qu'un risque découvert après. Ensuite, l'évaluation préalable est elle-même une exigence : ne pas l'avoir faite est une faute en soi, indépendamment du fait que le système se révèle finalement risqué ou non.

Une organisation qui a construit un processus d'évaluation des risques solide peut le faire servir aux trois cadres simultanément, à condition de l'avoir pensé comme un processus unique dès le départ, et non comme trois formulaires distincts à remplir séparément. C'est l'un des gisements d'économies les plus évidents : la même équipe, réunie une fois, peut produire une évaluation qui répond aux questions du RGPD, de l'IA Act et de l'ISO, plutôt que trois réunions distinctes sur le même système.

Documenter et tracer pour pouvoir prouver

La preuve est la monnaie commune des trois cadres. Le RGPD repose sur l'accountability : il ne suffit pas d'être conforme, il faut pouvoir le démontrer, documents à l'appui. L'IA Act exige une documentation technique détaillée pour les systèmes à haut risque, ainsi que la journalisation de leur fonctionnement. Les normes ISO ne délivrent une certification qu'au terme d'un audit qui examine, précisément, la documentation.

Une organisation qui documente correctement un traitement, un système d'IA ou un processus produit en réalité une seule documentation, utilisable pour les trois cadres. Le problème survient quand chaque équipe documente dans son coin, dans son format, sur son outil. La même information est alors saisie trois fois, et personne ne sait laquelle fait foi. Pire, les trois versions divergent avec le temps : l'une est mise à jour, les autres non, et l'organisation se retrouve avec trois descriptions contradictoires du même système.

La fiabilité de cette documentation dépend directement de la qualité des données qui l'alimentent : un registre rempli avec des informations approximatives ne prouve rien. Une documentation utile est une documentation vivante, mise à jour quand le système évolue, et non reconstituée a posteriori pour les besoins d'un audit. Une documentation morte donne une fausse sécurité : elle existe, donc on se croit couvert, alors qu'elle décrit un système qui n'existe plus sous cette forme.

👉 À lire aussi : Audit qualité des données : méthode et indicateurs clés

Désigner des responsables nommés

Un cadre de conformité ne tient que si quelqu'un en répond. Le RGPD impose, dans de nombreux cas, la désignation d'un délégué à la protection des données, le DPO. L'IA Act crée de fait le besoin d'un référent IA, chargé de piloter la classification des systèmes et le suivi des obligations. Les normes ISO exigent un responsable du système de management, garant du dispositif et de son amélioration.

Ces trois rôles ne se recouvrent pas, et c'est important de le comprendre. Le DPO a une mission précise et encadrée par le RGPD : il conseille, contrôle, fait le lien avec l'autorité de contrôle. Son indépendance est protégée par le texte. Le référent IA, lui, n'est pas défini par un texte avec la même précision : c'est une fonction que l'organisation construit, dont le périmètre couvre la classification des usages, le suivi des obligations IA Act et la veille réglementaire. Le responsable du système de management ISO porte la logique d'amélioration continue et prépare les audits. Trois rôles, trois logiques, mais qui travaillent sur les mêmes systèmes.

Ces rôles réglementaires ne vivent pas seuls non plus. Ils s'articulent avec les fonctions data déjà en place, le Data Owner qui répond du périmètre d'un domaine de données, le Data Steward qui en assure la qualité au quotidien. Sans noms en face de toutes ces responsabilités, la conformité reste une intention. La question n'est pas de créer des fonctions cloisonnées de plus, mais de s'assurer que ces responsabilités sont attribuées, connues et articulées entre elles. Un système d'IA à haut risque qui traite des données personnelles concerne à la fois le DPO, le référent IA et le Data Owner. Si ces trois personnes ne se parlent jamais, le système tombe entre les chaises.

👉 À lire aussi : Définir les rôles et responsabilités en matière de gouvernance des données

Structurer sa conformité Data & IA en 4 étapes

Le socle commun décrit ce qu'il faut construire. Reste à le construire dans le bon ordre. Voici une trajectoire en quatre étapes, pensée pour qu'une organisation passe d'une conformité en silos à un cadre unique sans tout refaire. Ces étapes sont séquentielles : chacune s'appuie sur la précédente, et vouloir sauter une marche fragilise l'ensemble.

Étape 1 : un référentiel unique données + systèmes d'IA

La première étape consiste à fusionner ce qui est aujourd'hui éclaté. La plupart des organisations possèdent déjà un registre des traitements RGPD, tenu par le DPO. Beaucoup commencent un inventaire des systèmes d'IA pour l'IA Act, souvent dans un autre fichier, tenu par une autre équipe.

L'objectif est de rassembler ces inventaires dans un référentiel unique. Concrètement, chaque entrée décrit soit un traitement de données, soit un système d'IA, soit les deux quand un système d'IA traite des données personnelles, ce qui est le cas le plus fréquent. Chaque entrée porte les informations utiles aux trois cadres : finalité, données concernées, base légale, niveau de risque IA, mesures de sécurité, responsable nommé.

Un système de scoring de dossiers de crédit, par exemple, est à la fois un traitement de données personnelles soumis au RGPD et un système d'IA à haut risque au sens de l'IA Act. Dans un référentiel unique, il apparaît une seule fois, avec les deux qualifications côte à côte. Dans une organisation en silos, il apparaît dans deux fichiers, sans que personne ne fasse le lien, et chaque équipe le traite comme si l'autre dimension n'existait pas.

La construction de ce référentiel n'est pas qu'un travail de fusion de fichiers. C'est l'occasion de fiabiliser l'inventaire, de retrouver les systèmes oubliés, de clarifier les finalités floues. Le bon moment pour bâtir ce référentiel coïncide souvent avec le moment de lancer une gouvernance des données digne de ce nom : les deux chantiers se nourrissent mutuellement, et il serait absurde de les mener séparément.

Étape 2 : une évaluation du risque qui sert les trois cadres

Une fois le référentiel en place, chaque entrée à risque doit être évaluée. Plutôt que de mener une AIPD d'un côté et une évaluation IA Act de l'autre, on construit un processus d'évaluation unique qui couvre les deux dimensions.

Ce processus pose, pour chaque traitement ou système, les questions qui comptent pour les trois cadres. Quel risque pour les personnes concernées, au sens du RGPD : la donnée est-elle sensible, le traitement peut-il porter atteinte aux droits des individus. Quel niveau de risque du système, au sens de l'IA Act : l'usage relève-t-il du haut risque, le système prend-il des décisions qui affectent des personnes. Quelles mesures de sécurité, au sens des normes ISO : la donnée est-elle protégée contre la fuite et l'altération. Une seule évaluation, plusieurs angles, un seul document de sortie.

L'intérêt n'est pas seulement de gagner du temps. C'est de voir les risques que les évaluations séparées laissent échapper. Un système peut présenter un risque RGPD modéré mais un risque IA Act élevé à cause d'un biais dans ses données d'entraînement. Évalué séparément par deux équipes, ce décalage passe inaperçu : l'équipe RGPD valide, l'équipe IA n'a jamais été saisie. Évalué d'un seul tenant, par un groupe qui regarde le système sous tous les angles, le décalage saute aux yeux.

Cette évaluation unique a aussi une vertu organisationnelle. Elle force le DPO, le référent IA et le responsable sécurité à s'asseoir à la même table et à parler du même système en même temps. Ce simple fait, réunir les bons acteurs autour d'un objet commun, règle déjà une grande partie des angles morts, indépendamment de la qualité du formulaire utilisé.

Étape 3 : une documentation produite une fois

La troisième étape applique au quotidien le principe de la fiche maîtresse. Pour chaque traitement et chaque système d'IA, une documentation de référence existe et fait foi. Elle est mise à jour quand le traitement évolue, pas reconstruite à chaque audit.

Cette documentation alimente ensuite, par extraction, les livrables propres à chaque cadre : le registre pour le RGPD, le dossier technique pour l'IA Act, le corpus documentaire pour l'audit ISO. L'organisation ne produit pas trois documentations, elle produit une source unique et en tire trois vues. Le registre RGPD est une vue filtrée de cette source, centrée sur les données personnelles. Le dossier IA Act est une autre vue, centrée sur les systèmes à risque. Le corpus ISO est une troisième vue, centrée sur les processus de management.

Tenir cette source dans la durée suppose des outils adaptés. Un tableur partagé peut suffire au démarrage, pour une petite organisation. À mesure que le nombre de traitements et de systèmes augmente, un outil dédié devient nécessaire, ne serait-ce que pour gérer les versions, les droits d'accès et l'historique des modifications. Ce sujet, nous l'avons détaillé du côté des outils de gouvernance des données : les mêmes catégories d'outils servent la conformité.

Le bénéfice se mesure le jour d'un contrôle. Une organisation qui documente en silos passe les semaines précédant un audit à rassembler des informations dispersées et parfois contradictoires. Une organisation qui tient une documentation unique extrait ce qui est demandé et le présente. La différence se compte en semaines de travail et en niveau de stress des équipes. Elle se compte aussi en crédibilité : une documentation cohérente et à jour inspire confiance à un auditeur, une documentation reconstituée éveille la suspicion.

Étape 4 : une instance de pilotage transverse

La dernière étape est organisationnelle, et c'est elle qui garantit que tout le reste tient dans la durée. Tant que le RGPD, l'IA Act et les normes ISO sont pilotés par trois personnes qui ne se parlent pas, le référentiel unique se désynchronise et les silos reviennent par la fenêtre.

La solution est une instance de pilotage transverse, un comité de conformité Data & IA, qui réunit le DPO, le référent IA, le responsable sécurité et un représentant des métiers concernés. Ce comité n'a pas vocation à tout traiter lui-même. Son rôle est de garantir la cohérence : que le référentiel reste à jour, que les évaluations de risque suivent une méthode commune, que les nouveaux projets passent par le bon processus dès leur conception et non la veille de leur lancement.

Ce comité a besoin de règles de fonctionnement claires pour ne pas devenir une réunion de plus, sans effet. Un rythme régulier, mensuel ou trimestriel selon le volume. Des règles de saisine précises : tout nouveau projet impliquant des données personnelles ou un système d'IA doit y être présenté à son cadrage. Des supports de décision factuels : l'état du référentiel, la liste des systèmes en cours d'évaluation, les alertes éventuelles. Pour suivre ce dispositif dans le temps, les KPI de gouvernance des données offrent une grille de lecture directement réutilisable : taux de traitements documentés, délai moyen d'évaluation, part des projets passés en comité avant leur lancement.

👉 À lire aussi : Comment mettre en place la gouvernance des données ?

Conformité Data & IA : les 3 erreurs à éviter

Trois erreurs reviennent systématiquement dans les organisations qui structurent leur conformité. Les nommer permet de les repérer tôt, avant qu'elles ne coûtent cher.

Croire qu'être conforme RGPD suffit pour l'IA

C'est l'erreur la plus répandue, et la plus risquée. Beaucoup d'organisations, parce qu'elles ont investi dans leur conformité RGPD depuis 2018, considèrent qu'un système d'IA respectant le RGPD est un système conforme. C'est faux, et la confusion est dangereuse parce qu'elle est rassurante.

Le RGPD ne dit rien des biais d'un modèle, de sa robustesse, de l'explicabilité de ses décisions ou de la supervision humaine. Un système de tri de candidatures peut respecter parfaitement le RGPD sur le traitement des données des candidats, et écarter systématiquement certains profils à cause d'un biais dans ses données d'apprentissage. Le RGPD vérifie que les données sont collectées avec une base légale, conservées le temps nécessaire, sécurisées. Il ne vérifie pas que l'algorithme est juste. L'IA Act, lui, en fait une exigence centrale.

La conséquence pratique est nette. Une organisation qui veut déployer un système d'IA à haut risque ne peut pas se contenter de son AIPD RGPD. Elle doit conduire une évaluation IA Act distincte, qui regarde le système, ses données d'entraînement, ses performances, sa supervision. Le tampon RGPD n'est pas un tampon IA. Confondre les deux, c'est se croire couvert là où on ne l'est pas.

Faire de l'ISO une fin en soi

L'erreur inverse consiste à se lancer dans une démarche de certification ISO en oubliant pourquoi. La certification devient l'objectif, le badge à afficher en pied de page du site, et les équipes remplissent des procédures pour satisfaire l'auditeur plutôt que pour réduire un risque réel.

Une norme ISO est un outil au service de la conformité, pas un trophée. Si la démarche de certification ne renforce pas concrètement la maîtrise des données et des systèmes d'IA, elle produit de la documentation morte : des procédures écrites pour l'audit, rangées dès le lendemain, que personne n'applique. L'organisation a son certificat et ses risques intacts.

La bonne question n'est jamais « comment obtenir le certificat » mais « comment la méthode ISO nous aide à mieux structurer ce qu'on doit de toute façon faire pour le RGPD et l'IA Act ». Posée ainsi, la certification redevient utile : elle apporte une discipline, un calendrier de revues, une exigence d'amélioration continue. Posée à l'envers, elle devient un coût sans contrepartie.

Laisser la conformité au seul juridique

La conformité Data & IA est souvent confiée en totalité à la direction juridique ou au DPO. C'est compréhensible, ce sont des textes réglementaires, et le réflexe naturel est de les confier à des juristes. Mais c'est insuffisant.

Cartographier les systèmes d'IA, évaluer leurs risques techniques, juger de la qualité des données d'entraînement, apprécier la robustesse d'un modèle : rien de tout cela n'est un travail purement juridique. Une conformité Data & IA portée par le seul juridique reste théorique, parce qu'elle n'a pas accès à la réalité technique des systèmes. Le juriste peut lire le texte de l'IA Act, il ne peut pas, seul, déterminer si tel modèle présente un biais.

À l'inverse, une conformité portée par la seule technique manque la lecture réglementaire : les équipes data savent évaluer un modèle, elles ne savent pas toujours qualifier juridiquement un usage. Le sujet est par nature transverse. Il a besoin du juridique pour la lecture des textes, de la technique pour la réalité des systèmes, et des métiers pour comprendre les usages réels. Cette montée en compétence partagée passe aussi par un effort d'acculturation data auprès des équipes concernées : chacun doit comprendre assez du sujet de l'autre pour que le dialogue soit possible.

👉 À lire aussi : L'IA générative et ses impacts sur la gouvernance des données

Par où commencer sa conformité Data & IA selon sa maturité ?

Toutes les organisations ne partent pas du même point. La trajectoire à suivre dépend de ce qui est déjà en place. Vouloir tout mener de front, quel que soit le niveau de départ, est le meilleur moyen de ne rien faire correctement. La bonne approche consiste à séquencer les chantiers selon leur impact et l'effort qu'ils demandent.

Sans cadre formalisé : sécuriser le RGPD d'abord

Une organisation qui n'a ni registre des traitements à jour, ni DPO clairement identifié, ni processus d'AIPD ne doit pas commencer par l'IA Act. Elle doit d'abord solidifier son socle RGPD.

La raison est pratique. Le registre des traitements est la brique de cartographie sur laquelle tout le reste se construit. Le processus d'AIPD est la base du futur processus d'évaluation des risques. Les principes du RGPD, base légale, finalité, minimisation, sont aussi les réflexes de fond qui serviront pour l'IA. Sans ces fondations, vouloir attaquer directement la conformité IA revient à bâtir un étage sur une dalle qui n'existe pas.

Concrètement, le premier livrable d'une telle organisation est un registre des traitements complet et fiable, et la désignation formelle d'un DPO ou d'un référent protection des données. Six mois pour fiabiliser ce socle ne sont pas du temps perdu, c'est le temps qui rend la suite possible. Une organisation qui brûle cette étape se retrouvera, tôt ou tard, à la refaire.

Déjà conforme RGPD : intégrer l'IA Act

Une organisation qui dispose d'un RGPD solide est dans la meilleure position pour intégrer l'IA Act, parce qu'une grande partie du socle commun existe déjà. Le registre des traitements est là, il faut l'étendre aux systèmes d'IA. Le processus d'AIPD existe, il faut l'élargir à l'évaluation du risque IA. Le DPO est en place, il faut lui adjoindre un référent IA et organiser leur dialogue.

Le travail consiste à brancher le nouveau cadre sur l'existant. Recenser les systèmes d'IA, les classer par niveau de risque, identifier ceux à haut risque, et bâtir pour eux la documentation et la supervision exigées. C'est un chantier réel, qui demande des compétences nouvelles, notamment techniques. Mais il s'appuie sur des fondations déjà posées plutôt que de repartir de zéro, ce qui change tout en termes de délai et de coût.

Le premier livrable, ici, est un inventaire des systèmes d'IA classés par niveau de risque, intégré au registre existant. Cet inventaire révèle immédiatement la charge de travail à venir : s'il fait apparaître plusieurs systèmes à haut risque, l'organisation sait qu'elle a un chantier de documentation et de supervision devant elle, et peut le planifier.

RGPD et IA Act en place : viser la certification ISO

Une organisation qui maîtrise déjà le RGPD et a structuré sa conformité IA Act peut envisager la certification ISO, en particulier l'ISO 42001 pour le management de l'IA et l'ISO 27701 pour la vie privée.

À ce stade, la certification ne crée pas un chantier de plus. Elle vient formaliser et faire auditer un dispositif qui fonctionne déjà. Son intérêt est double : disposer d'une preuve opposable à un client ou à un régulateur, et inscrire la conformité dans une logique d'amélioration continue plutôt que de la laisser se dégrader entre deux contrôles.

Le premier livrable est la définition du périmètre de certification et la réalisation d'un audit blanc, qui mesure l'écart entre le dispositif existant et les exigences de la norme. Cet audit blanc est rarement une mauvaise surprise pour une organisation déjà mature : il confirme surtout ce qui est solide et pointe quelques ajustements. Pour une organisation à ce niveau, la certification est l'étape qui transforme un dispositif solide en avantage démontrable.

👉 À lire aussi : Comment faire progresser la maturité data de l'entreprise ?

Ce qu'il faut retenir

Le RGPD, l'IA Act et les normes ISO ne sont pas trois contraintes à traiter en parallèle. Le RGPD protège la donnée personnelle, l'IA Act encadre le risque des systèmes d'IA, les normes ISO outillent et prouvent la démarche. Trois objets différents, mais un socle commun : cartographier, évaluer le risque, documenter, nommer des responsables.

Une organisation qui construit ce socle une fois, proprement, ne mène plus trois projets de conformité. Elle en mène un, sur lequel chaque cadre vient se brancher. Le référentiel unique remplace les inventaires éparpillés, l'évaluation de risque unique remplace les formulaires en double, la documentation maîtresse remplace les corpus reconstruits dans l'urgence, et le comité transverse remplace les trois pilotes qui s'ignorent.

La première décision n'est pas réglementaire, elle est organisationnelle : choisir de traiter la conformité Data & IA comme un sujet unique, et arrêter de la découper en trois. Tout le reste, la méthode, les outils, le calendrier, découle de cette décision. Une organisation qui la prend transforme la conformité d'un coût subi en un cadre qui sécurise ses projets data et IA au lieu de les ralentir.

Pour situer votre point de départ, commencez par un état des lieux honnête de ce qui existe déjà, registre RGPD compris. C'est souvent là que se trouve la moitié du chemin : la matière est là, dispersée, il s'agit moins de la créer que de la rassembler et de lui donner une cohérence.