Concevoir une charte de données qui résiste à l'usage

Une charte de données n’est pas seulement un document de conformité. C’est un contrat de fonctionnement : elle explique pourquoi une donnée existe, qui peut l’utiliser, combien de temps elle reste utile et que faire lorsqu’une personne conteste son usage. En anglais, on parle de data governance : l’ensemble des règles, rôles et contrôles qui rendent les données utilisables, compréhensibles et responsables dans la durée.

Deux notions sont particulièrement utiles. Le data lineage décrit le parcours d’une donnée, de sa source jusqu’à ses transformations et ses usages. Le data catalog est l’inventaire qui rend ce parcours consultable : définition d’un champ, propriétaire, niveau de qualité, fréquence de mise à jour et consommateurs connus.

Partir d’un usage précis

Le point de départ n’est pas la technologie mais une situation concrète : recommander une ressource, instruire un dossier ou mesurer un service. Pour chaque usage, la charte doit répondre à cinq questions.

Question	Décision attendue	Preuve à conserver
Pourquoi collecter ?	Finalité courte et compréhensible	Fiche d’usage validée
Qui est responsable ?	Un rôle clairement nommé	Référent et contact
Qui peut accéder ?	Périmètre et privilèges minimaux	Matrice des accès
Quand supprimer ?	Durée et événement de fin	Règle d’archivage
Comment contester ?	Canal, délai et responsable de réponse	Journal des demandes

Cette grille évite la formule vague « les données sont utilisées pour améliorer le service ». Une finalité exploitable décrit une décision et ses limites.

Transformer les droits en parcours

Un droit difficile à exercer n’est pas un droit opérationnel. Le parcours doit permettre de demander une information, corriger une donnée, signaler un usage inattendu et obtenir une réponse compréhensible. Il faut également définir ce qui se passe lorsqu’une donnée est corrigée : quelles vues, exports, modèles ou décisions doivent être réévalués ?

Un registre simple suffit pour commencer : identifiant de la demande, date de réception, donnée concernée, responsable, décision, justification et date de clôture. Le registre ne remplace pas une politique juridique ; il rend le traitement vérifiable.

Ce registre constitue un audit trail, c’est-à-dire une piste d’audit chronologique. Il ne doit pas enregistrer davantage de données personnelles que nécessaire. Il doit surtout permettre de répondre à trois questions : quelle décision a été prise, sur quelle version de la donnée et par quelle personne ou quel service ?

Passer de la promesse au contrôle

Une charte devient crédible lorsque ses engagements produisent des contrôles testables :

• refuser un accès qui ne correspond pas au rôle déclaré ;
• signaler une donnée conservée au-delà de sa durée prévue ;
• journaliser les exports et les changements de permission ;
• relier une décision automatisée à la version de la donnée utilisée ;
• prévoir une suspension lorsque la qualité ou la légitimité de l’usage n’est plus établie.

Le contrôle n’a pas besoin d’être complexe. Un test automatisé, une revue mensuelle et un responsable identifié valent mieux qu’une liste de principes sans preuve.

Les technologies déjà disponibles

Plusieurs familles d’outils peuvent rendre cette chaîne de preuve concrète :

• un data catalog ou un outil de data lineage, comme DataHub ou OpenMetadata, pour relier une donnée à son schéma, ses transformations et ses consommateurs ;
• une politique d’accès déclarative, par exemple RBAC (Role-Based Access Control, accès selon le rôle) ou ABAC (Attribute-Based Access Control, accès selon des attributs), éventuellement évaluée par un moteur comme Open Policy Agent ;
• des contrôles de qualité, comme Great Expectations ou des tests SQL, pour vérifier les valeurs manquantes, les distributions et les ruptures de schéma ;
• un registre de versions pour les jeux de données, les règles et les modèles, afin de pouvoir expliquer quelle version a produit une décision. Cette pratique relève de la provenance, c’est-à-dire la capacité à retrouver l’origine et les transformations d’un résultat.

Ces outils ne fabriquent pas la confiance automatiquement. Ils déplacent la discussion vers des objets vérifiables : une règle, une trace, un responsable et une décision. La question de recherche devient alors : la combinaison du lignage et d’un parcours de recours permet-elle de réduire le temps nécessaire pour contester une décision automatisée ?

De la charte à la décision

Une charte devient réellement utile lorsqu’elle accompagne une décision concrète. Prenons le cas d’un service qui recommande une ressource pédagogique à partir de l’historique d’un étudiant. La fiche de décision devrait indiquer la finalité, les variables utilisées, la durée de conservation, le niveau de confiance et la possibilité de demander une correction.

On peut représenter cette fiche comme un decision record : un enregistrement court qui relie la décision à ses preuves. Il ne cherche pas à exposer tous les détails du modèle ; il doit fournir assez d’informations pour qu’un responsable puisse expliquer le résultat, détecter une erreur et déclencher une revue humaine.

Élément	Question de contrôle
Finalité	Cette décision répond-elle au besoin annoncé ?
Données	Chaque variable est-elle nécessaire et documentée ?
Règle	Le système a-t-il appliqué la même règle à des cas comparables ?
Recours	La personne peut-elle demander une explication ou une correction ?
Arrêt	Qui peut suspendre le traitement si une anomalie apparaît ?

Cette approche évite de confondre transparence et accumulation de détails. Une documentation très longue peut rester inutilisable si elle ne permet pas de retrouver rapidement la preuve pertinente.

Un cas marocain pour tester la charte

Prenons un cas volontairement simple : un établissement d’enseignement utilise les données d’inscription, de présence et de progression pour proposer un accompagnement aux étudiants. La charte devrait préciser que la recommandation sert à proposer un soutien, et non à exclure automatiquement une personne d’un parcours.

Le test pourrait suivre cinq questions :

1. l’étudiant sait-il quelles données ont été utilisées ?
2. un conseiller peut-il consulter le data lineage de la recommandation ?
3. une correction de donnée déclenche-t-elle une nouvelle évaluation ?
4. l’étudiant peut-il refuser l’usage secondaire de ses données ?
5. l’établissement peut-il suspendre le système sans perdre le suivi pédagogique ?

Ce scénario rappelle qu’une charte n’est pas uniquement destinée à l’équipe informatique. Elle doit être lisible par les personnes concernées et utilisable par celles qui répondent aux recours.

Pistes à découvrir

Un premier protocole pourrait comparer trois configurations : une charte documentaire seule, une charte accompagnée d’un catalogue de données, puis une charte reliée à des contrôles d’accès et de qualité. On mesurerait le temps de compréhension d’un traitement, le nombre d’erreurs détectées et la capacité d’un nouvel arrivant à retrouver la preuve pertinente.

D’autres pistes méritent d’être explorées : générer automatiquement une fiche de finalité à partir du lignage, représenter les dépendances entre une correction de donnée et les décisions déjà produites, ou combiner anonymisation, apprentissage fédéré et minimisation pour limiter la circulation des données sensibles. L’enjeu n’est pas d’ajouter une couche d’outillage, mais de déterminer quelles preuves sont réellement utiles aux personnes qui devront décider, expliquer ou arrêter un usage.

Un test avant la mise en service

Avant de publier un nouveau traitement, faites relire sa fiche par trois personnes : une personne qui connaît le métier, une personne qui comprend les données et une personne capable de représenter les usages contestés. Si elles ne répondent pas de la même manière à « qui décide quoi, avec quelle donnée et selon quelle limite ? », la charte est encore trop abstraite.

À retenir

Une bonne charte réduit l’ambiguïté avant de réduire le risque. Elle relie finalité, responsabilité, accès, conservation, recours et contrôle dans une même chaîne de preuve. C’est cette chaîne qui permet ensuite de discuter un système de données avec les personnes qui le conçoivent, l’utilisent ou le subissent.