Qu’est-ce que la classification des données, et pourquoi est-elle plus importante à l’ère de l’IA ?

La classification des données consiste à catégoriser les données selon leur sensibilité et leur valeur, afin qu’une organisation puisse appliquer le niveau de protection, de contrôle d’accès et de traitement adapté à chaque catégorie. Cette pratique existe depuis des décennies dans les domaines de la conformité et de la sécurité. Ce qui a changé d’ici 2026, c’est la nature de ce que la classification gouverne réellement : elle ne se contente plus de déterminer quel employé peut ouvrir un fichier. Elle détermine désormais ce qu’un agent IA est autorisé à lire, à conserver et sur quoi il peut agir — et de plus en plus, elle constitue la preuve que les régulateurs attendent qu’une organisation puisse produire sur demande.

Ce basculement explique pourquoi une pratique qui vivait autrefois discrètement au sein d’une politique de gouvernance des données se retrouve désormais dans les présentations aux conseils d’administration, les rapports sur le coût des violations de données et les textes de régulation de l’IA. Ce guide explique ce qu’est la classification des données, les quatre catégories que la plupart des organisations utilisent encore comme socle, et — l’aspect qui a le plus évolué — pourquoi la classification est devenue le contrôle fondamental de la gouvernance de l’IA plutôt qu’un simple exercice de classement pour des lecteurs humains.

Résumé exécutif

Idée principale : La classification des données — qui consiste à étiqueter les données selon leur sensibilité pour appliquer les bonnes protections et règles d’accès — a discrètement changé de rôle. Elle ne se limite plus à décider quel employé peut ouvrir un fichier ; elle détermine désormais ce qu’un agent IA est autorisé à lire, à conserver et sur quoi il peut agir, et sert de plus en plus de preuve que les régulateurs attendent qu’une organisation produise sur demande. Ce guide explique ce qu’est la classification et pourquoi elle est désormais fondamentale pour la gouvernance de l’IA.

Pourquoi c’est important : Pour les équipes cybersécurité, gouvernance, risque et conformité, la classification est discrètement devenue le contrôle dont dépendent tous les autres contrôles. Les politiques d’accès, les règles DLP, les exigences de chiffrement et les décisions d’accès pour l’IA ne sont fiables qu’à la hauteur de la classification qui les alimente — une étiquette obsolète ou absente signifie que tous les contrôles en aval fonctionnent avec de mauvaises informations. Les incidents liés au shadow AI trouvent leur origine dans cette même faille : du contenu sensible bascule vers des outils non gouvernés simplement parce que rien, dans l’environnement, ne l’a reconnu comme sensible au moment critique. Et alors que des textes comme l’AI Act européen imposent de plus en plus aux organisations de démontrer — et non plus seulement d’affirmer — comment les données alimentant les systèmes d’IA ont été gouvernées, la classification cesse d’être une simple tâche d’étiquetage administratif pour devenir la piste d’audit qu’un conseil d’administration, un régulateur ou un client finira par exiger de voir.

Points clés à retenir

1. La classification gouverne désormais les machines, pas seulement les personnes. Les agents IA qui se connectent au contenu de l’entreprise héritent de tous les accès associés à leurs identifiants. Sans classification appliquée au moment de chaque requête, la portée effective d’un agent n’est limitée que par ce qu’il est techniquement capable d’atteindre — pas par ce que quiconque a approuvé.
2. Le shadow AI a transformé la classification en risque documenté, et non plus seulement en bonne pratique d’hygiène. Le fait que des employés copient-collent du contenu sensible dans des outils d’IA non approuvés figure parmi les causes les plus fréquemment citées d’exposition de données liée à l’IA, et l’échec est presque toujours le même : rien, dans l’environnement, n’a reconnu le contenu comme sensible au moment où il en est sorti.
3. La réglementation évolue vers l’exigence de preuves, et non plus de simples documents de politique. Les obligations de gouvernance des données prévues à l’article 10 de l’AI Act européen pour les systèmes d’IA à haut risque annoncent une tendance plus large : les organisations devront de plus en plus disposer de registres auditables démontrant comment les données ont été classifiées, sourcées et gouvernées — et non se contenter d’affirmer qu’une politique existe.
4. L’étiquetage manuel par les utilisateurs n’est plus adapté à l’échelle actuelle. La création de données dépasse désormais tout flux de travail qui repose sur un humain pour étiqueter correctement chaque fichier, à chaque fois, à travers les e-mails, le stockage cloud, les outils SaaS et les invites d’IA. La classification automatisée, fondée sur le contenu et le contexte, est désormais le socle pratique incontournable.
5. Chaque contrôle en aval n’est fiable qu’à la hauteur de la classification qui l’alimente. Les contrôles d’accès, les règles DLP, les politiques de chiffrement et les décisions d’accès pour l’IA dépendent tous des étiquettes de classification. Une étiquette obsolète ou manquante ne se limite pas à mal identifier un fichier — elle signifie que tous les contrôles construits sur cette base fonctionnent avec de mauvaises informations.

Ce qui a changé depuis que la classification est devenue une simple case à cocher pour la conformité

Pendant la majeure partie de son histoire, la classification des données répondait à une seule question : qui est autorisé à voir ceci ? Un fichier était étiqueté Public, Interne, Confidentiel ou Restreint, et cette étiquette indiquait à un lecteur humain — et au système de contrôle d’accès derrière lui — s’il était habilité à l’ouvrir. Ce modèle supposait qu’une personne se trouvait toujours à l’origine de la demande d’accès.

Cette hypothèse ne tient plus, et trois évolutions expliquent pourquoi 2026 marque un tournant réel par rapport à 2024 sur ce sujet.

Les agents IA lisent désormais des données classifiées de manière autonome, à grande échelle. L’usage en entreprise d’agents IA connectés aux systèmes internes — stockage de fichiers, CRM, référentiels documentaires, souvent via un protocole comme le MCP (Model Context Protocol) — est passé du stade de projet pilote à un déploiement courant dans une part croissante d’organisations. Un agent qui formule l’une de ces requêtes ne s’arrête pas pour se demander s’il est autorisé, comme le ferait un employé prudent. Il hérite de tous les accès associés à l’identifiant qui le porte, et si la classification n’est pas appliquée au moment où cet identifiant demande les données, la portée effective de l’agent n’est limitée que par ce qu’il est techniquement capable d’atteindre — pas par ce que quiconque a approuvé. La classification est discrètement devenue un contrôle d’accès pour l’IA, que l’organisation ait ou non mis à jour sa politique pour en tenir compte.

Le shadow AI a transformé la classification, d’une simple bonne pratique d’hygiène en un risque documenté. Le fait que des employés collent une fiche client, une clause contractuelle ou du code source dans un chatbot non approuvé figure parmi les causes les plus fréquemment citées d’exposition de données liée à l’IA dans les récentes études sectorielles sur les violations de données, et les organisations rapportent de plus en plus ces incidents à la fois comme des défaillances de sécurité et de conformité. Le mécanisme est presque toujours le même : rien n’a bloqué le copier-coller au moment où il s’est produit, car rien dans l’environnement n’a reconnu le contenu comme sensible. La classification est le signal dont un moteur de politique a besoin pour bloquer automatiquement ce type d’action — une règle DLP ou d’accès ne peut empêcher un contenu confidentiel de sortir par un canal non gouverné si rien ne lui a d’abord indiqué que ce contenu était confidentiel.

La réglementation évolue vers l’exigence de prouver la classification, et non plus seulement de l’affirmer. L’article 10 de l’AI Act européen définit des obligations de gouvernance des données pour les systèmes d’IA à haut risque, incluant des exigences relatives à la provenance, à la qualité et au traitement des données sur lesquelles ces systèmes sont construits et fonctionnent. L’orientation de cette exigence reste significative, quelle que soit la manière exacte dont l’application se déroulera dans une juridiction ou un calendrier donné : les régulateurs s’attendent de plus en plus à ce que les organisations produisent des registres auditables démontrant comment les données ont été classifiées, sourcées et gouvernées, et non simplement à ce qu’elles affirment qu’une politique existe sur papier. C’est un argument structurel en faveur d’une classification traitée comme une infrastructure produisant des preuves en continu, plutôt que comme un projet que l’équipe conformité finalise une fois pour toutes et ne révise qu’au renouvellement. Les organisations doivent vérifier les dates d’application actuelles et les obligations spécifiques directement auprès du texte réglementaire et de leurs propres conseils juridiques, car les échéances de conformité dans ce domaine continuent d’évoluer.

Rien de tout cela ne remplace la finalité originelle de la classification. Cela l’élargit. La question en 2026 n’est plus seulement « qui peut voir ce fichier » — c’est « que peut faire chaque identité, humaine ou machine, avec ces données, et pouvons-nous le prouver ». Cette question est au cœur de la gouvernance des données moderne.

Qu’est-ce que la classification des données ?

La classification des données consiste à organiser les données en catégories selon leur sensibilité, afin d’appliquer de manière cohérente les protections, règles d’accès et exigences de traitement adaptées. Elle couvre généralement les informations dont l’exposition pourrait nuire à un individu, une entreprise ou un gouvernement : secrets commerciaux, informations relevant de la sécurité nationale, et tout ce qui pourrait identifier ou nuire à une personne en cas de divulgation.

La classification vise à garantir trois propriétés regroupées sous le nom de triade CIA :

• Confidentialité — empêcher toute consultation non autorisée, que l’observateur soit une personne ou un système.
• Intégrité — garantir que les données ne sont ni altérées ni corrompues sans autorisation.
• Disponibilité — garantir que les utilisateurs et systèmes autorisés puissent accéder aux données lorsqu’ils en ont légitimement besoin, sans friction inutile.

La classification ne fonctionne qu’au sein d’un ensemble plus large de contrôles, de pratiques et de mécanismes d’application. Ceux-ci se répartissent généralement en trois catégories :

• Sécurité et conformité — les cadres réglementaires (HIPAA, RGPD, PCI DSS, CMMC, et de plus en plus des règles spécifiques à l’IA) qui dictent la façon dont les données classifiées doivent être traitées.
• Gouvernance — les politiques qui définissent comment les données doivent être étiquetées, stockées et gérées dans la durée, y compris par des systèmes automatisés.
• Facilité d’usage — garantir que les personnes et processus autorisés à utiliser les données puissent réellement accomplir leur travail sans que le schéma de classification ne devienne un obstacle.

Les trois méthodes de classification des données

La plupart des schémas de classification reposent sur l’une de ces trois approches, et les programmes modernes tendent de plus en plus à les combiner :

• La classification basée sur le contenu (ou les données) examine le contenu réel d’un fichier pour déterminer s’il contient des informations protégées — un numéro de sécurité sociale, un code de diagnostic, une clause contractuelle — indépendamment de l’emplacement du fichier ou de son créateur.
• La classification basée sur le contexte s’appuie sur les métadonnées : qui a créé le fichier, quelle application l’a généré, où il a été stocké, ou de quel service il provient. Un document produit par le système financier, par exemple, peut être automatiquement signalé comme sensible sur le plan financier sans que personne n’en lise le contenu.
• La classification basée sur l’utilisateur repose sur une personne — le créateur du document ou une autorité de classification désignée — qui porte un jugement manuel fichier par fichier.

Les approches basées sur le contenu et le contexte s’adaptent à l’échelle ; la classification basée sur l’utilisateur, non — c’est précisément pour cette raison qu’elle perd du terrain à mesure que le volume de données augmente.

Étiquetage manuel vs classification automatisée : pourquoi l’ancienne approche s’effondre

Pendant des années, de nombreuses organisations ont géré la classification comme un processus largement manuel : les employés sélectionnaient une étiquette de sensibilité en enregistrant un document, ou une équipe dédiée aux dossiers passait périodiquement en revue et étiquetait les fichiers à la main. Cette approche était déjà mise à rude épreuve à l’échelle de l’entreprise en 2024. D’ici 2026, elle est largement considérée comme insuffisante à elle seule, pour une raison simple : la création de données dépasse désormais tout flux de travail qui repose sur un humain se souvenant de l’étiqueter correctement, à chaque fois, à travers les e-mails, le stockage cloud, les outils SaaS et désormais les invites d’IA.

La classification automatisée répond à ce défi en combinant reconnaissance de motifs, métadonnées contextuelles et, de plus en plus, apprentissage automatique, pour scanner et étiqueter les données en continu plutôt qu’à un instant donné. Un moteur de classification moderne peut reconnaître qu’un document correspond à la structure d’un formulaire fiscal ou d’un accord de confidentialité, appliquer l’étiquette correcte sans qu’un humain ouvre le fichier, et rescanner en permanence à mesure que les données se déplacent, changent ou sont copiées — un rythme qu’un audit manuel trimestriel ne pourra jamais suivre.

Les enjeux pratiques de ce basculement sont considérables, car les étiquettes de classification constituent la donnée d’entrée dont dépend chaque contrôle en aval. Les contrôles d’accès, les règles DLP, les exigences de chiffrement, et désormais les décisions d’accès pour l’IA, ne sont fiables qu’à la hauteur de la classification qui les alimente. Une étiquette obsolète ou manquante ne signifie pas seulement qu’un fichier est mal identifié ; cela signifie que tous les contrôles construits sur cette étiquette fonctionnent avec de mauvaises informations.

Public, interne, gouvernemental et confidentiel : les quatre catégories toujours en usage

Malgré le basculement vers l’automatisation et une gouvernance consciente des enjeux liés à l’IA, les catégories de sensibilité sous-jacentes utilisées par la plupart des organisations n’ont pas beaucoup évolué. Elles restent un socle utile pour comprendre ce qui est réellement protégé.

Classification publique

La classification publique est le niveau le plus permissif. Elle peut inclure des informations sensibles dans d’autres contextes, mais largement accessibles par ailleurs via un canal légitime, ce qui explique qu’elle ne soit pas soumise aux mêmes contrôles de sécurité que les données plus restreintes.

Exemples :

• Organigrammes
• Noms et prénoms déjà publiés ailleurs
• Communiqués de presse
• Livres blancs
• Guides architecturaux

Classification interne

La classification interne couvre les informations commerciales et d’entreprise qui ne sont pas publiques, mais dont la divulgation nuirait à la compétitivité de l’organisation ou à sa propriété intellectuelle.

Exemples :

• Schémas produits
• E-mails internes
• Contenus d’intranet
• Budgets et projections financières

Classification gouvernementale

La classification gouvernementale correspond au sens traditionnel de l’expression « information classifiée », et elle a pris une importance renouvelée à mesure que la chaîne d’approvisionnement numérique des agences fédérales — plateformes cloud, applications SaaS, outils d’IA — s’est développée. Elle couvre plusieurs catégories de protection distinctes :

• La classification secrète — le système à paliers Confidentiel, Secret et Top Secret, chacun avec des restrictions d’accès croissantes. Le matériel Top Secret n’est consultable que par un cercle restreint de personnes habilitées, souvent davantage limité selon le principe du besoin d’en connaître, et il réside généralement sur des réseaux isolés tels que SIPRNET.
• Les informations non classifiées contrôlées (CUI) — des informations générées par des sous-traitants travaillant avec des agences de défense, qui ne sont pas formellement classifiées mais nécessitent tout de même une protection. Les CUI disposent de leur propre cadre de conformité dédié, la Cybersecurity Maturity Model Certification (CMMC), supervisée conjointement par le NIST et le Department of Defense américain. Les CUI peuvent résider sur des réseaux plus conventionnels, mais ces réseaux doivent satisfaire à des contrôles de sécurité stricts et documentés, conformes à la norme NIST 800-171 — et démontrer cette posture de contrôle via des preuves prêtes pour l’audit est devenu d’autant plus important à mesure que l’application de la CMMC a évolué.

Classification confidentielle

Dans le secteur privé, la classification vise moins à désigner des secrets officiels qu’à identifier les données selon leur sensibilité, afin de protéger les intérêts commerciaux et les personnes que l’organisation sert. C’est ici que se déploie concrètement, au quotidien, la majeure partie de la stratégie de gestion des risques cybersécurité.

Les principales catégories confidentielles incluent :

• Les informations personnelles identifiables (PII) — numéros de sécurité sociale, adresses, numéros de téléphone, informations financières, ou tout élément permettant d’identifier une personne ou, combiné à d’autres, de la localiser et de la contacter. Les PII constituent une exigence de protection de base présente dans presque toutes les réglementations relatives à la vie privée.
• Les informations de santé protégées (PHI) — informations relatives aux soins des patients définies par HIPAA, incluant dossiers médicaux, notes cliniques et informations de paiement des soins de santé. Tout service traitant des PHI, pas seulement le personnel clinique, est soumis à ces protections, et la règle du minimum nécessaire d’HIPAA limite en outre la quantité de ces données à laquelle un utilisateur ou un système donné devrait pouvoir accéder.
• Le numéro de compte principal (PAN) — données porteur de carte, incluant les numéros de compte, les données de puce ou de piste magnétique, et les codes CVV, régies par la norme PCI DSS.

Les catégories qui s’appliquent, et leur degré de rigueur, dépendent à la fois du type d’informations détenues par l’organisation et du secteur qu’elle sert.

La classification est désormais un contrôle de gouvernance de l’IA, et non plus une simple pratique d’hygiène des données

C’est l’aspect qui a le plus évolué dans ce tableau, et il mérite d’être énoncé clairement : en 2026, la classification des données est l’un des principaux mécanismes techniques qui déterminent si la gouvernance de l’IA est réellement applicable ou simplement aspirationnelle.

Imaginons ce qui se passe lorsqu’un agent IA se connecte au contenu d’une organisation via une intégration comme MCP. L’agent s’authentifie, généralement via un identifiant à portée limitée, puis demande l’accès à des fichiers, dossiers ou enregistrements pour accomplir une tâche — résumer un contrat, rédiger un rapport, répondre à une question à partir des connaissances internes. Si le contenu que l’agent peut atteindre n’a pas été classifié, un moteur de politique n’a aucun moyen de distinguer, dans cette requête, un communiqué de presse public d’un dossier juridique confidentiel. L’agent ne se comporte pas mal ; il fait exactement ce pour quoi il a été conçu, avec des données que personne n’a étiquetées comme interdites.

C’est précisément le schéma d’échec derrière la multiplication des incidents de shadow AI, et c’est pourquoi les approches de gouvernance des données pour l’IA les plus avancées construisent désormais explicitement les décisions d’accès autour de la classification plutôt qu’autour de la seule identité. Une politique qui évalue la sensibilité du contenu, le rôle du demandeur (humain ou agent) et le contexte au moment de chaque requête — plutôt que d’accorder un accès permanent une fois pour toutes et de ne jamais le réévaluer — est ce qui permet réellement de combler cette faille. C’est la différence concrète entre un contrôle d’accès basé sur les attributs (ABAC) appliqué de manière cohérente à tout type d’identité, et un schéma de classification qui existe sur papier mais n’a jamais été relié à ce qu’un agent, une API ou un flux de travail automatisé peut techniquement atteindre.

Le contexte réglementaire renforce directement ce constat. En vertu de l’article 10 de l’AI Act européen, les organisations exploitant des systèmes d’IA à haut risque doivent démontrer — et non simplement affirmer — la gouvernance appliquée aux données sur lesquelles ces systèmes s’entraînent et agissent : leur provenance, la façon dont elles ont été évaluées, et les contrôles qui les ont surveillées en pratique. La classification constitue le registre fondamental qui rend cette démonstration possible. Une organisation incapable de montrer quel contenu est public, interne ou restreint ne peut pas prouver à un régulateur, un auditeur ou son propre conseil d’administration que ses systèmes d’IA ne touchent que ce qu’ils sont autorisés à toucher.

Défis et bonnes pratiques pour protéger les données classifiées en 2026

La classification n’est pas un simple exercice d’étiquetage, et la considérer comme telle est la raison la plus fréquente pour laquelle les programmes ne résistent pas à un examen approfondi. Trois défis déterminent systématiquement si un programme de classification fonctionne réellement :

• Vulnérabilité. Les données sensibles peuvent être exposées via un nombre croissant de canaux — stockage cloud, outils SaaS, invites d’IA, intégrations API — et chaque nouveau canal modifie ce que « protégé » doit signifier. Maintenir un inventaire à jour des systèmes sensibles, des flux de données et désormais du contenu accessible à l’IA est le travail de gouvernance qui garde la classification pertinente plutôt que théorique.
• Expertise. La classification et ses contrôles de sécurité associés exigent une attention soutenue et spécialisée. Les organisations qui traitent des volumes importants de données sensibles ont généralement besoin d’une responsabilité dédiée à la conformité et à la classification — et non d’une charge greffée après coup sur un poste existant — et doivent faire appel à une expertise tierce spécialisée lorsque les capacités internes ne suffisent pas.
• Application. Une politique de classification ne vaut que par son application. Cela implique de déployer une technologie qui applique activement des contrôles fondés sur les étiquettes de classification — et non se contenter de stocker ces étiquettes — et de maintenir l’automatisation et la journalisation d’audit nécessaires pour prouver que ces contrôles fonctionnent et pour retracer l’origine d’un incident lorsque quelque chose se passe mal.

Préservez la sécurité de vos informations classifiées avec Kiteworks

La conformité et la sécurité dépendent toutes deux d’une classification appliquée de manière cohérente, partout où circule un contenu sensible — y compris à l’entrée et à la sortie des systèmes d’IA, et pas uniquement entre utilisateurs humains.

Le Kiteworks Data Control Plane répond à cet enjeu en intégrant la classification des données directement dans l’application des politiques, à travers les e-mails, le partage sécurisé de fichiers, le transfert de fichiers managé, les API et les formulaires web, avec un chiffrement de bout en bout intégré partout.

Kiteworks propose notamment :

• Sécurité et conformité : le chiffrement AES-256 pour les données au repos et TLS 1.2+ pour les données en transit, une appliance virtuelle renforcée, des contrôles d’accès granulaires et une journalisation d’audit complète permettant aux organisations de démontrer rapidement leur conformité. Kiteworks fournit des rapports de conformité prêts à l’emploi pour HIPAA, PCI DSS, SOC 2 et RGPD, et détient des certifications incluant FedRAMP, FIPS et FISMA. Kiteworks est également évalué selon les contrôles de niveau IRAP PROTECTED et couvre une large majorité des pratiques CMMC de niveau 2.
• Contrôle d’accès basé sur les attributs (ABAC) : chaque demande d’accès — qu’elle provienne d’un utilisateur humain, d’une application ou d’un agent IA se connectant via le Kiteworks Secure MCP Server — est évaluée en fonction de la classification du contenu, de l’identité du demandeur et du contexte avant que l’accès ne soit accordé, afin que les étiquettes de classification pilotent réellement l’application des politiques plutôt que de rester inutilisées dans un champ de métadonnées.
• Journalisation d’audit : des journaux d’audit immuables offrent aux organisations une chaîne de preuves opposable, permettent de détecter les anomalies plus rapidement et unifient les entrées de journal à travers chaque composant de la plateforme, faisant gagner du temps aux équipes des opérations de sécurité et aidant les équipes conformité à se préparer aux audits — y compris le type de preuves documentées désormais attendu dans le cadre de textes comme l’AI Act européen.
• Intégration SIEM : Kiteworks s’intègre aux principales plateformes SIEM, incluant IBM QRadar, ArcSight, FireEye Helix et LogRhythm, et inclut un Splunk Forwarder ainsi qu’une application Splunk.
• Visibilité et gestion : le CISO Dashboard offre aux organisations une vue en temps réel de l’emplacement des données sensibles, de qui et quoi y accède, et de la conformité de cet accès aux réglementations applicables — donnant aux dirigeants d’entreprise une base factuelle pour des décisions éclairées plutôt que des estimations périodiques.
• Architecture mono-tenant : le partage de fichiers, les transferts automatisés, le stockage et les accès s’exécutent tous sur une instance Kiteworks dédiée — déployée sur site, sur l’infrastructure propre de l’organisation, ou hébergée en privé dans le Kiteworks Cloud — éliminant tout environnement d’exécution partagé, toute base de données partagée ou exposition croisée entre locataires.

Découvrez comment le Data Control Plane de Kiteworks applique une gouvernance pilotée par la classification à chaque interaction, humaine ou IA, avec votre contenu sensible. Pour en savoir plus, planifiez une démonstration personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog Architecture Zero Trust : ne jamais faire confiance, toujours vérifier
• Vidéo Microsoft GCC High : les inconvénients qui poussent les sous-traitants de la défense vers des alternatives plus intelligentes
• Article de blog Comment sécuriser les données classifiées une fois signalées par le DSPM
• Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
• Vidéo Le guide définitif du stockage sécurisé des données sensibles pour les responsables IT