Accueil/Guides pratiques/Données & gouvernance

Données & gouvernance

Cartographier les données et leurs responsabilités

Comment obtenir une cartographie des données exploitable ? Suivez un traitement de la collecte jusqu’aux copies, exports, sauvegardes et suppressions. Le registre attendu décrit finalité, catégories de données, applications, prestataires, accès, durées, responsables et preuves de contrôle. L’objectif est de pouvoir expliquer une décision, traiter une demande et vérifier une modification. Les exemples sont méthodologiques ; la qualification juridique dépend du contexte et doit être vérifiée à la source.

PrivacyRiskGovernance
Cartographie mondiale des réseaux dans une salle de briefing vide
Illustration éditoriale générée par IA

Votre checklist d’action

  1. 01

    Décrire les finalités

    Pour chaque usage, documentez l’objectif, les personnes concernées et les données nécessaires. Repérez les collectes sans finalité claire et les copies inutiles. Commencez par une opération concrète, par exemple répondre à une demande de contact. Identifiez ce qui est indispensable à cette réponse et ce qui relève d’un autre usage. Évitez qu’un même intitulé général masque plusieurs finalités et circuits de données.

  2. 02

    Tracer les flux

    Dessinez les transferts entre applications, prestataires et pays. Incluez sauvegardes, exports manuels, journaux et outils d’IA utilisés par les équipes. Suivez un exemple de bout en bout avec les responsables des outils. Incluez les pièces jointes, tableurs locaux et intégrations automatisées. Distinguez le lieu d’hébergement, le lieu d’accès et les entités contractuelles ; ce sont des informations différentes.

  3. 03

    Nommer les responsables

    Clarifiez qui décide des usages, qui opère les systèmes et qui valide les demandes. Reliez contrats et responsabilités aux traitements observés. Attribuez à chaque changement une personne qui décide et une personne qui vérifie sa réalisation. Un contrat décrit un cadre ; le contrôle doit aussi examiner les accès effectivement ouverts et les sous-traitants réellement utilisés.

  4. 04

    Définir les durées et les accès

    Fixez des durées documentées et vérifiez leur application. Limitez les accès par fonction et testez la suppression sur un exemple incluant les copies et les exceptions justifiées. Une règle de conservation ne se résume pas à une valeur dans une politique. Testez un dossier arrivé à échéance, relevez les copies encore présentes et documentez les exceptions. Les mécanismes de sauvegarde demandent une procédure adaptée et vérifiable.

  5. 05

    Examiner les risques

    Évaluez les conséquences d’une divulgation, d’une altération ou d’une indisponibilité. Faites examiner les exigences d’analyse d’impact et les transferts internationaux par les responsables compétents. Décrivez les personnes affectées, le contexte d’usage et les conséquences possibles avant de classer un risque. Faites valider les points juridiques par les interlocuteurs compétents. Conservez le raisonnement qui justifie l’action retenue et ses limites.

  6. 06

    Maintenir les preuves

    Conservez les validations, les changements et les tests. Vérifiez les demandes d’accès, les incidents et les changements de fournisseur à intervalles définis. Révisez la carte lors d’un nouvel outil, d’un export supplémentaire ou d’un usage IA. Conservez une trace de la demande, de l’autorisation et du test après changement. Un registre utile reflète le fonctionnement réel plutôt qu’un état théorique initial.

    Exemple pédagogique : une équipe conserve des demandes clients dans un outil SaaS et dans des exports de travail. Pour tester sa règle de conservation, suivez un dossier représentatif jusqu’aux copies, journaux et sauvegardes concernés. Distinguez suppression immédiate, expiration différée et conservation justifiée. Consignez les exceptions et les accès restants plutôt que de déclarer une suppression totale sur la seule disparition du dossier à l’écran.

Références : données, usages et limites

Documentation consultée le .

Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
FIRST · Traffic Light Protocol

Indiquer à qui une information peut être redistribuée.

TLP 2.0 utilise RED, AMBER, GREEN et CLEAR ; AMBER+STRICT limite le partage à l’organisation du destinataire. Les libellés ne se traduisent pas. Conservez le marquage avec l’information et vérifiez les destinataires avant transfert. En cas d’ambiguïté, demandez une clarification à la source.

Approfondir la méthode →

TLP n’est ni une classification formelle ni une licence de réutilisation. Il ne garantit pas l’exactitude du contenu.
NIST · AI Risk Management Framework

Organiser la gestion des risques associés à l’IA.

Le cœur de l’AI RMF s’articule autour de Govern, Map, Measure et Manage. Il s’agit d’un cadre volontaire de gestion du risque. Définissez usage, personnes concernées et conséquences d’erreur. Rapprochez chaque risque d’une évaluation, d’un responsable et d’un moyen d’arrêt ou de reprise.

Approfondir la méthode →

Le cadre ne certifie ni un modèle ni une application. Son utilisation ne dispense pas d’examiner les obligations applicables.
NIST · Privacy Framework

Examiner les risques pour les personnes liés au traitement de données.

Le Privacy Framework est un outil volontaire de gestion des risques pour la vie privée. Il se distingue d’une liste unique d’obligations juridiques. Décrivez le traitement réel : données, finalités, destinataires, accès et durées. Comparez documents, configurations et tests de suppression ou de récupération.

Approfondir la méthode →

L’utilisation du cadre ne détermine pas à elle seule la conformité au droit applicable. Le contexte du traitement et la juridiction restent à examiner.

Publication et visibilité dans la recherche IA

Attribuer les décisions de diffusion à un responsable

La publication publique et l’accès privé exigent des preuves différentes. Les choix d’extrait et de participation IA doivent être rattachés au service et à la propriété concernés.

  • Documenter propriétaire, périmètre, choix effectif et héritage des réglages de publication.
  • Protéger les ressources privées par autorisation ; leur présence dans robots.txt rend les chemins publics.
  • Dater la recette et prévoir une nouvelle lecture des documents lorsque le service change.

Comparer les contrôles IA et les données du rapport →

Références relues le

security.txt et divulgation

Conserver le périmètre du contact lors des changements de domaine

Une migration, une délégation à un prestataire ou un changement de sous-domaine peut rendre un canal de divulgation ambigu. Le suivi du domaine doit donc inclure la publication et la révision de security.txt.

  • Contrôler chaque hôte concerné : le fichier d’un domaine parent ne s’applique pas automatiquement à ses sous-domaines.
  • Comparer les URI Canonical à la récupération réelle et documenter les redirections vers un prestataire.
  • Réexaminer contacts, clés, politique et expiration lors d’un transfert de responsabilité ; garder les anciennes versions comme historique.

Lire la fiche security.txt et les cas de divulgation →

Sources vérifiées le · IETF · RFC 9116 · §2.5, §3, §5