Quelles normes s'appliquent réellement à un projet Data ou IA ?

Quand on lance un projet Data ou IA, la question des normes arrive rarement en premier. Elle surgit plus tard, souvent au pire moment : un client demande une garantie, un DPO pose une question gênante, ou un comité s'inquiète d'un usage qui ressemble à du scoring. Et là, c'est la course pour comprendre ce qui s'applique, à qui, et depuis quand.

Le problème n'est pas le manque de textes. Il y en a beaucoup, entre le RGPD, l'AI Act et les normes ISO. Le problème, c'est le flou sur ce qui est réellement obligatoire et ce qui ne l'est pas. Beaucoup d'organisations confondent une loi qui s'impose, une norme que l'on peut choisir de suivre, et une simple bonne pratique. Cette confusion mène à deux erreurs symétriques : se croire concerné par tout, ou se croire concerné par rien.

Cet article fait le tri. Il distingue d'abord le vocabulaire, puis liste les normes qui s'imposent juridiquement, ensuite celles que l'on adopte volontairement pour sécuriser sa démarche, et enfin la méthode pour identifier ce qui concerne réellement votre projet.

‍

Normes, lois et standards : ce que recouvre vraiment la question Data ou IA

Avant de répondre, il faut clarifier les mots. Quand quelqu'un demande « quelles normes s'appliquent à notre projet ? », il mélange souvent trois choses très différentes, qui n'ont ni la même force ni les mêmes conséquences. Tant que ces trois mots restent confondus, aucune réponse utile n'est possible.

Trois mots souvent confondus : norme, loi et standard volontaire

Dans le langage courant, « norme » désigne tout et n'importe quoi. Dans les faits, il faut séparer trois familles, et c'est en les séparant qu'on sait quoi prioriser.

• La loi ou le règlement : un texte contraignant, voté par une autorité publique, dont le non-respect expose à des sanctions. Le RGPD et l'AI Act entrent dans cette catégorie. On ne choisit pas de s'y conformer, on y est tenu.
• La norme volontaire : un référentiel publié par un organisme de normalisation comme l'ISO. On peut décider de s'y conformer, parfois jusqu'à se faire certifier, mais aucune loi n'oblige à le faire. Elle structure et rassure, sans contraindre.
• La bonne pratique : une recommandation, un framework, un guide méthodologique. Aucune valeur juridique, aucune certification, mais une utilité réelle pour bien faire.

Retenir cette hiérarchie change tout dans la priorisation. On traite d'abord ce qui est imposé par la loi, ensuite ce qui apporte une garantie, enfin ce qui relève du confort. Confondre les trois, c'est risquer de soigner un référentiel optionnel pendant qu'une obligation légale reste en souffrance.

Le piège de la conformité découverte en fin de projet

La seconde source de confusion n'est pas de vocabulaire, elle est de calendrier. Dans beaucoup d'organisations, la question des normes arrive une fois le projet déjà construit, parfois déjà en production. C'est le pire moment possible.

Traiter la conformité à la fin revient à découvrir, après avoir bâti la maison, qu'il fallait un permis de construire. Les données ont déjà été collectées sans base légale claire, le modèle a déjà appris sur un périmètre douteux, l'architecture ne permet pas de tracer les décisions. Tout reprendre coûte cher, et dans l'urgence, tout coûte encore plus cher. À l'inverse, les obligations posées dès la conception deviennent de simples contraintes de design, peu coûteuses à respecter. La suite de cet article part donc d'un principe simple : mieux vaut savoir ce qui s'applique avant de commencer.

Les normes obligatoires d'un projet Data ou IA

Commençons par ce qui ne se discute pas. Voici les textes qui s'imposent, que vous le vouliez ou non, dès lors que votre projet touche à la donnée ou à l'intelligence artificielle. Ce sont eux, et eux seuls, qui exposent à des sanctions.

Le RGPD, socle de tout traitement de données personnelles

Le Règlement général sur la protection des données s'applique en Europe depuis mai 2018. C'est le premier texte à vérifier, pour une raison simple : la quasi-totalité des projets Data ou IA manipulent, à un moment, des données personnelles. Un nom, un identifiant client, une adresse IP, un historique d'achat suffisent à faire entrer le projet dans son champ.

Le RGPD impose des principes que tout projet doit intégrer en amont : une base légale pour chaque traitement, une finalité définie, une minimisation des données collectées, une information des personnes, et des droits qu'elles peuvent exercer. Pour un projet IA, deux points méritent une vigilance particulière. D'abord, les données d'entraînement : entraîner un modèle sur des données personnelles est un traitement comme un autre, qui doit être justifié. Ensuite, les décisions automatisées : le RGPD encadre spécifiquement le fait de prendre une décision produisant des effets juridiques sur une personne sans intervention humaine. C'est exactement le terrain où l'IA et la gouvernance des données se rejoignent, et où les angles morts coûtent le plus cher.

L'AI Act et son approche par niveaux de risque

L'AI Act (règlement européen 2024/1689) est la première réglementation au monde dédiée à l'intelligence artificielle. Il est entré en vigueur le 1er août 2024 et s'applique de façon progressive. Son principe directeur est une approche par le risque : plus un système d'IA présente de risques pour les personnes, plus il est encadré. Le texte distingue quatre niveaux, du risque inacceptable (purement interdit) au risque minime (libre), en passant par le haut risque (fortement encadré) et le risque limité (soumis à transparence).

Le calendrier d'application est essentiel à comprendre, car plusieurs obligations sont déjà actives. Voici les grandes échéances telles qu'elles se présentent à la rédaction de cet article.

• Depuis février 2025 : les pratiques à risque inacceptable sont interdites (notation sociale, manipulation, certains usages biométriques), et l'obligation de littératie en IA s'applique, c'est-à-dire former les équipes à un usage responsable.
• Depuis août 2025 : les obligations propres aux modèles d'IA à usage général, comme les grands modèles de langage, sont applicables à leurs fournisseurs.
• À partir d'août 2026 : la majorité des règles entrent en application, notamment pour les systèmes à haut risque listés à l'annexe III et les obligations de transparence.

Un point demande de la prudence et une vérification à jour. Une réforme du calendrier, discutée en 2026 sous le nom de Digital Omnibus, prévoit de reporter les obligations des systèmes à haut risque d'août 2026 à décembre 2027. Tant que ce report n'est pas formellement adopté et publié, la date contraignante reste celle d'août 2026. Autrement dit, le calendrier exact bouge encore : c'est précisément pour cela qu'il faut vérifier l'état du texte au moment de votre projet, et ne pas se fier à une date entendue il y a six mois.

Les obligations sectorielles, qui s'ajoutent au socle commun

Au-dessus du socle commun, certains secteurs empilent leurs propres exigences. Un projet Data ou IA dans la santé, la finance ou le secteur public hérite de couches réglementaires supplémentaires, parfois plus strictes que le tronc commun. La règle à retenir : votre secteur peut ajouter des obligations, jamais en retrancher.

Sans viser l'exhaustivité, on pense aux hébergeurs de données de santé et à leurs exigences de certification, aux règles prudentielles et de gestion du risque dans la finance, ou aux obligations spécifiques du secteur public en matière de transparence des algorithmes. Le point méthodologique est simple : votre secteur d'activité est une variable de la question « quelles normes s'appliquent ? », et il faut l'instruire au cas par cas avec les bons experts.

Les normes volontaires qui sécurisent un projet Data ou IA

Passons à ce qui n'est pas imposé, mais fortement recommandé. Ces référentiels ne sanctionnent pas, mais ils structurent la démarche, rassurent les clients et facilitent grandement la mise en conformité réglementaire. Une norme volontaire bien choisie est souvent le chemin le plus court vers une obligation légale.

ISO 27001 et la sécurité de l'information

L'ISO/IEC 27001 est le standard international de référence pour le management de la sécurité de l'information. Elle ne porte pas sur l'IA en particulier, mais sur quelque chose de plus fondamental pour tout projet data : protéger les données contre la perte, la fuite et l'accès non autorisé. Une organisation certifiée 27001 démontre qu'elle gère ses informations de façon structurée, avec une analyse des risques et des mesures de protection documentées.

Pour un projet Data ou IA, son intérêt est double. D'une part, la sécurité des données est un prérequis de fait du RGPD, donc avancer sur la 27001 fait avancer la conformité légale. D'autre part, elle constitue un argument commercial concret face à des clients qui veulent des garanties. À noter que la sécurité ne dit rien de la qualité des données elle-même : un patrimoine peut être parfaitement sécurisé et profondément faux. La qualité relève d'autres référentiels dédiés, comme la famille ISO 8000, et surtout d'une gouvernance interne dont on suit les indicateurs de gouvernance dans la durée.

ISO/IEC 42001, le management des systèmes d'IA

Plus récente, l'ISO/IEC 42001 a été publiée en décembre 2023. C'est la première norme internationale certifiable dédiée au management des systèmes d'intelligence artificielle. Là où l'AI Act dit ce qu'il faut respecter, la 42001 propose une méthode pour s'organiser : politiques internes, gestion des risques liés aux modèles, supervision tout au long du cycle de vie, transparence et amélioration continue. Elle s'adresse à toute organisation qui développe, fournit ou utilise de l'IA, quelle que soit sa taille.

Son atout principal tient à son articulation avec la loi. Conçue sur la même structure que l'ISO 27001, elle s'y intègre facilement, et elle est de plus en plus reconnue comme un moyen de démontrer le sérieux de sa démarche face aux exigences de l'AI Act. Adopter la 42001 ne rend pas conforme automatiquement, mais cela rapproche fortement de la conformité en posant la gouvernance interne que le règlement attendra de toute façon. C'est un investissement de structure plus que de papier, qui rejoint la logique de la responsabilité de l'IA en entreprise.

👉 À lire aussi : IA générative : quand faut-il réellement mettre des règles ?

Identifier les normes applicables à votre projet Data ou IA

La théorie ne sert à rien sans méthode. Voici comment passer de la liste générale des normes à ce qui concerne réellement votre projet, sans rien oublier d'essentiel ni se noyer dans des référentiels hors sujet.

Cartographier selon la donnée, l'usage et le secteur

La bonne nouvelle, c'est que trois questions suffisent à dégrossir la quasi-totalité des cas. Posées au tout début d'un projet, elles font émerger les normes à instruire en priorité.

• Quelles données manipule le projet ? S'il y a des données personnelles, et c'est presque toujours le cas, le RGPD s'applique. S'il y a des données sensibles (santé, biométrie), les exigences montent d'un cran.
• Quel usage fait-on de l'IA ? Un système qui aide à décider sur des personnes (recrutement, crédit, accès à un service) glisse vite vers le haut risque au sens de l'AI Act. Un usage interne de productivité, beaucoup moins.
• Dans quel secteur opère-t-on ? La santé, la finance et le secteur public ajoutent leurs propres couches au socle commun.

Croiser ces trois réponses donne une première cartographie fiable : la nature des données fixe le socle RGPD, l'usage détermine le niveau d'exigence AI Act, le secteur ajoute ses obligations propres. Le tableau ci-dessous illustre comment ce croisement se traduit selon le type de projet.

Ce tableau n'a pas valeur d'avis juridique, mais il montre l'essentiel : deux projets IA dans la même entreprise peuvent relever de régimes complètement différents. La question n'est jamais « notre entreprise est-elle concernée ? », mais « ce projet précis l'est-il, et à quel niveau ? ».

Traiter la conformité dès la conception

Une fois la cartographie posée, le réflexe décisif est d'intégrer ces exigences immédiatement, pas de les garder pour plus tard. C'est le prolongement direct du piège évoqué plus haut : tout ce qui est anticipé coûte peu, tout ce qui est rattrapé coûte cher.

En pratique, cela veut dire faire de la conformité une brique du cadrage projet au même titre que le budget ou le planning. On nomme un responsable clair, souvent un Data Governance Manager ou un DPO selon les organisations, on documente les choix au fur et à mesure, et on prévoit dès le départ la traçabilité que les normes exigeront. La conformité n'est pas une couche que l'on pose à la fin sur un projet terminé, c'est une fondation que l'on coule au début. Cette logique rejoint celle d'une stratégie data mûre, où la question des normes n'est plus une surprise, mais un paramètre connu dès le cadrage.

👉 À lire aussi : Qui est responsable de l’IA en entreprise (et de quoi exactement) ?

La logique de ce schéma résume l'article entier. Ce qui est obligatoire se respecte parce qu'on y est tenu. Ce qui est volontaire se choisit parce qu'il rend le reste plus simple. Les organisations qui réussissent leurs projets Data et IA ne sont pas celles qui connaissent toutes les normes par cœur. Ce sont celles qui ont pris dix minutes, au cadrage, pour répondre à trois questions : quelles données, quel usage, quel secteur. Le reste découle de là.

Avant de lancer votre prochain projet, le point de départ utile n'est donc pas un audit juridique complet, mais un diagnostic de maturité honnête, qui inclut la question des normes parmi les fondations à poser. C'est exactement ce que mesure la grille de maturité data de Limpida. Et pour tout arbitrage réglementaire précis, le réflexe reste le même : valider avec un juriste ou un DPO, car cet article éclaire la démarche, il ne remplace pas un avis juridique.