Donner le même sens à un champ dans tous les outils

Un dictionnaire de données pour les contacts est une référence qui explique ce que chaque champ signifie. Il devient particulièrement utile lorsque votre liste reçoit des informations de plusieurs formulaires ou applications. Sans définition commune, « actif », « date de contact » ou « langue » peuvent changer de sens d’un fichier à l’autre.

Les plans de collecte documentés par Twilio Segment illustrent cette logique : ils spécifient les événements et propriétés attendus et permettent de repérer des écarts entre données reçues et description prévue. Source : Twilio Segment, plan de collecte.

Pour une newsletter, vous pouvez appliquer cette discipline à un ensemble réduit de champs déclaratifs et de gestion. L’objectif est de rendre chaque information compréhensible, maintenable et utile à une décision.

Commencer par la définition métier

Avant de choisir un format technique, écrivez une phrase de définition. « Langue choisie pour recevoir cette publication » est plus précis que « langue du contact ». « Date de la dernière demande reçue » se distingue de la date du dernier envoi.

Ajoutez un exemple valide et un exemple invalide. Ces deux cas aident à repérer les interprétations possibles. Pour la langue, « français » peut être valide si cette version existe ; un pays n’est pas une réponse équivalente.

Nommez ensuite le propriétaire du champ. Cette personne doit pouvoir décider d’un changement de sens, expliquer les valeurs et résoudre les conflits. Un champ sans responsable risque de continuer à circuler après la disparition de son usage initial.

Une fiche minimale pour chaque champ

Nous proposons la structure suivante, à adapter à vos outils et à la taille de l’équipe.

Rubrique Contenu à documenter
Nom technique Nom stable utilisé dans les échanges
Libellé visible Question ou intitulé compris par le lecteur
Définition Sens exact de l’information
Type et valeurs Texte, nombre, date ou choix délimité
Valeur absente Interprétation et comportement prévu
Source de référence Parcours ou outil autorisé à modifier
Usage Message ou décision qui dépend du champ
Responsable Personne chargée de la qualité
Conservation Durée, point de départ et traitement à l’échéance

Cette fiche peut tenir dans un tableau partagé. Le document n’a pas besoin d’être complexe ; il doit être suffisamment précis pour qu’une autre personne produise le même résultat.

Distinguer absent, négatif et inconnu

Une valeur vide peut avoir plusieurs causes : question jamais posée, réponse facultative ignorée, erreur d’import ou donnée supprimée. Si vous traitez tous ces cas comme « non », vous transformez une absence d’information en choix.

Pour un thème, documentez la différence entre « non sélectionné » et « choix non recueilli ». Pour un statut d’inscription, utilisez des valeurs explicites plutôt qu’un champ ambigu que chacun complète selon ses habitudes.

Prévoyez aussi le comportement des messages. Une personnalisation sans donnée peut utiliser une formulation générale. Une sélection de campagne peut exclure un cas indéterminé jusqu’à ce que le contexte soit établi. Le dictionnaire doit relier le sens de la valeur à l’action qui suit.

Choisir les types selon les usages

Un nombre sert à calculer ; un code sert souvent à identifier. Un code postal ne devrait pas être traité comme un montant simplement parce qu’il contient des chiffres. Les zéros initiaux ou les formats internationaux peuvent avoir un sens.

Pour une date, précisez si vous avez besoin d’un jour ou d’un instant. Un rendez-vous éditorial peut utiliser une date simple ; un historique de modification peut demander un horodatage avec un fuseau clairement défini.

Pour les montants utilisés dans un système métier, indiquez l’unité et la devise. Pour un choix de thème, indiquez les valeurs admises et leur libellé visible. Ces détails évitent de laisser l’outil ou la personne qui importe inventer une interprétation.

La CNIL recommande d’adapter les formats à l’information nécessaire et d’intégrer la protection des données dès la conception. Source : CNIL, développements informatiques.

Exemple fictif : remplacer un champ « activité »

Imaginons une petite structure dont le fichier comporte une colonne « activité ». Certains collègues y inscrivent un métier, d’autres la date d’un échange et d’autres encore un état d’abonnement.

L’équipe commence par reconnaître qu’il s’agit de trois informations différentes. Elle crée un champ de rôle déclaré, un champ de date précisément défini et un statut d’inscription. Elle n’essaie pas de convertir automatiquement toutes les anciennes cellules.

Elle classe les valeurs existantes : certaines peuvent être reprises avec certitude ; d’autres demandent une revue ; les cellules incompréhensibles restent non renseignées. Elle conserve temporairement les éléments nécessaires à cette migration dans un espace adapté.

Avant le prochain envoi, elle vérifie que les campagnes n’utilisent plus l’ancienne colonne. Le travail a ainsi corrigé une ambiguïté au lieu de lui donner un nom technique plus moderne.

Préparer l’ajout d’un nouveau champ

Chaque nouveau champ devrait commencer par une demande courte : objectif, utilisateur de l’information, source et résultat attendu. Examinez ensuite les champs déjà présents pour éviter un doublon sous un autre nom.

Décrivez la valeur initiale des contacts existants. Laisser un champ vide est parfois plus exact que d’attribuer une préférence supposée à toute la base. Si une réponse est nécessaire, préparez un parcours compréhensible pour la recueillir.

Vérifiez les effets dans les exports. Un champ supplémentaire peut modifier un fichier attendu par un autre outil, une règle de sélection ou une fusion de données. Informez les personnes concernées avant la mise en service, avec un exemple fictif du nouveau format.

Versionner les changements qui modifient le sens

Corriger un libellé n’a pas le même effet que transformer la définition d’une donnée. Si « mensuel » désignait une synthèse et devient un ensemble de plusieurs alertes, la valeur identique ne représente plus la même promesse.

Nous conseillons de conserver un journal des changements : date, ancienne règle, nouvelle règle et traitement des données existantes. Lorsque le sens change fortement, créez une nouvelle version ou un nouveau champ plutôt que de réinterpréter silencieusement l’historique.

Préparez également la suppression. Un champ abandonné peut rester présent dans un export, un formulaire caché ou une ancienne automatisation. Listez les endroits qui l’utilisent et vérifiez leur mise à jour avant de clôturer la modification.

Tester avec des cas qui révèlent les erreurs

Créez des contacts fictifs comprenant une valeur absente, une valeur inattendue, des accents, une date ambiguë, une préférence modifiée et une opposition. Faites passer ces cas dans le formulaire, l’import, la sélection et le message final.

Examinez les erreurs affichées. Un refus de ligne doit être compréhensible pour la personne qui corrige le fichier. Une conversion automatique mérite une règle documentée : une donnée reçue sous un format inattendu ne doit pas être modifiée sans contrôle de son sens.

Terminez par une revue des dépendances. Si le champ disparaissait demain, quels messages changeraient ? Si personne ne peut répondre, son usage mérite une nouvelle discussion. Le dictionnaire reste utile lorsqu’il accompagne les décisions de l’équipe et l’évolution réelle des publications.