Une présentation de dictionnaire de données doit résoudre un désaccord sur le sens des données, pas projeter un tableur contenant toutes les colonnes. Partez d'une question métier que les participants interprètent déjà différemment. Retrouvez son origine dans quelques enregistrements, convenez d'une définition, puis montrez qui la maintient et ce qui change pour les rapports qui l'utilisent.
Prenons une entreprise fictive fonctionnant sur rendez-vous. Son tableau de bord annonce « trois rendez-vous réalisés », mais la responsable des opérations affirme qu'un seul client a reçu la prestation. Personne n'a inventé de chiffre : le tableau de bord compte les dossiers clôturés, y compris les annulations et les absences. Son libellé confond trois résultats différents. Tous les enregistrements, rôles et changements ci-dessous sont inventés pour illustrer une revue de dictionnaire. Ce ne sont ni des données clients ni une mise en œuvre de Presenti.
Une fois les définitions convenues, vous pouvez utiliser Presenti pour transformer le texte en présentation et obtenir un brouillon de diapositives modifiable. Collez les définitions retenues et les lignes d'exemple, pas un export confidentiel de base de données. Le dictionnaire reste la référence ; la présentation en offre une vue limitée, adaptée au public et à la décision à prendre.
Commencer par le terme métier à l'origine du désaccord
Dans cet exemple, le public réunit la responsable des opérations, l'analyste reporting et l'ingénieure chargée de l'export des réservations. Ils doivent approuver le sens de « rendez-vous réalisé » avant la prochaine version du rapport. Ils n'ont pas besoin d'une visite exhaustive des champs du système.
Un dictionnaire utile relie les mots employés aux données vérifiables. Le guide de l'USGS sur les dictionnaires de données cite notamment les noms, définitions, types, règles relatives aux valeurs nulles, valeurs de référence et règles métier. Pour cette réunion, ces précisions doivent répondre à une question concrète : la ligne représente-t-elle une prestation délivrée ou seulement un rendez-vous qui n'aura plus lieu ?
Fixez le périmètre sur la première diapositive : « Une ligne par rendez-vous dans l'instantané quotidien des réservations, pour un seul établissement. » Dans l'exemple, cet instantané a été pris le 9 octobre 2026 à 08:00 UTC. Il décrit l'état enregistré à cette heure, pas le dernier état connu aujourd'hui. Affichez l'heure et la version du dictionnaire. Un rendez-vous n'est pas un client : un même client peut en avoir plusieurs. Un instantané n'est pas non plus l'historique de tous les changements de statut. Ces deux distinctions préviennent des usages plausibles, mais incorrects, de données pourtant valides.
| Identifiant du rendez-vous | Statut dans l'instantané | Heure de réalisation, UTC | Interprétation métier |
|---|---|---|---|
| 000271 | completed | 2026-10-08T09:30:00Z | La prestation a été enregistrée comme réalisée |
| 000272 | cancelled | Manquante | La réservation a été annulée ; aucune prestation réalisée |
| 000273 | no_show | Manquante | Le client ne s'est pas présenté ; aucune prestation réalisée |
| 000274 | booked | Manquante | Aucune issue définitive n'a été enregistrée dans cet instantané |
Selon l'ancienne règle du tableau de bord, completed, cancelled et no_show sont tous des statuts clôturés : le total affiché est donc de trois. Avec la définition proposée pour réalisé, seul 000271 répond au critère. La quatrième ligne ne doit pas devenir silencieusement une absence supplémentaire parce que la date prévue est passée. Son issue reste inconnue dans cet extrait.
Distinguer le format d'un champ de son sens métier
Le type indique la forme que peut prendre une valeur. La définition précise ce qu'elle représente. Une valeur au format date ne dit pas s'il s'agit de la date de réservation, de prestation ou d'export. De même, un identifiant composé de chiffres n'est pas nécessairement une quantité à additionner ou à arrondir.
| Champ | Type et valeurs autorisées | Définition | Erreur d'usage à éviter |
|---|---|---|---|
appointment_id | Chaîne obligatoire ; unique dans l'instantané | Identifiant stable d'un rendez-vous, par exemple 000271 | Ne pas convertir en nombre et perdre les zéros initiaux ; ce n'est pas un identifiant client |
service_date | Date obligatoire, YYYY-MM-DD | Date prévue de la prestation dans le fuseau Europe/London de l'établissement | Ne pas la remplacer par la date de création de la réservation ni par la date extraite d'un horodatage UTC tronqué |
status | Chaîne obligatoire : booked, completed, cancelled ou no_show | État enregistré du rendez-vous à l'heure de l'instantané | Ne pas employer closed comme synonyme de completed ; closed est un regroupement dérivé distinct |
completed_at | Horodatage UTC, ou valeur manquante | Heure enregistrée de réalisation de la prestation | Manquant ne signifie ni minuit, ni durée nulle, ni absence confirmée du client |
Le vocabulaire de métadonnées pour les données tabulaires du W3C permet de décrire les types de colonnes, valeurs obligatoires, clés et autres contraintes sous forme lisible par machine. Cette validation peut aider à détecter des valeurs mal formées ou absentes. Elle ne décide pas, à elle seule, si votre entreprise doit compter un rendez-vous annulé comme réalisé. Documentez ensemble la contrainte technique et l'accord métier sans les confondre.
Pour un public métier, montrez une ligne et une erreur possible à côté du champ plutôt que d'introduire tout le vocabulaire des bases de données. Les zéros initiaux de 000271 rendent immédiatement compréhensible le choix d'une chaîne de caractères. La différence entre date de prestation et heure de réalisation explique l'intérêt de la règle de fuseau horaire : ce n'est plus une obscure note technique.
Expliciter les valeurs manquantes et contradictoires
Dans l'extrait de quatre lignes, l'absence d'heure de réalisation accompagne trois statuts différents. Pour une annulation, elle est attendue. Pour une absence du client, elle l'est aussi, mais pour une autre raison. Pour la réservation non résolue, elle indique seulement qu'aucune réalisation n'a été enregistrée. Remplacer les trois cas par « non réalisé » peut faciliter un calcul, mais fait disparaître des distinctions nécessaires au pilotage de l'activité.
Ajoutez maintenant pendant la réunion un cinquième enregistrement hypothétique, qui constitue une exception : une ligne porte le statut completed sans heure de réalisation. La responsable des opérations sait peut-être que la prestation a eu lieu ; l'analyste ne peut pas en déduire l'heure à partir de cette ligne. La règle proposée consiste à classer ce cas comme une exception à la définition, à l'examiner, puis à afficher le nombre d'exceptions exclues à côté du total réalisé. Ne réécrivez pas le statut source simplement pour faire coïncider les totaux.
Ce choix est important, mais n'est pas universel. Une autre entreprise pourrait accepter le statut seul comme preuve de réalisation. Dans ce cas, il faut documenter cette politique et préciser quand l'horodatage est obligatoire. Le risque vient de deux auteurs de rapports qui choisiraient des politiques différentes sans distinction visible.
| Rubrique | Proposition à soumettre à la validation |
|---|---|
| Terme métier | Rendez-vous réalisé |
| Sens | Rendez-vous enregistré comme ayant donné lieu à une prestation, avec une heure de réalisation renseignée |
| Enregistrements inclus | status vaut completed et completed_at est présent |
| Enregistrements exclus | Statuts cancelled, no_show et booked ; les lignes completed sans l'horodatage requis sont déclarées séparément comme exceptions |
| Unité et périmètre | appointment_id distincts, pas clients distincts ; un établissement et un instantané daté |
| Convention temporelle | La période du rapport utilise service_date dans Europe/London ; completed_at est conservé en UTC |
| Correspondance avec la source | Instantané quotidien des réservations : appointment_id, service_date, status, completed_at |
| Responsabilité et version | La responsable des opérations approuve le sens ; l'analyste reporting maintient la fiche ; version proposée du dictionnaire : v2.0 |
| Limite connue | L'instantané courant ne suffit pas à reconstituer le statut à une date d'arrêté antérieure |
Réutilisez les rubriques de gauche pour un autre terme contesté, mais remplacez entièrement la colonne de droite. « Client actif », « ticket résolu » et « chiffre d'affaires comptabilisé » nécessitent des règles d'inclusion et des autorités différentes. Substituer leur nom dans cet exemple ne produirait pas des définitions valides.
Attribuer la responsabilité du sens, de la correspondance et des changements
La mention « responsable : équipe data » cache souvent trois questions sans réponse. Qui peut approuver le sens ? Qui peut corriger la correspondance avec la source ? Qui avertira les utilisateurs des rapports d'un changement de définition ? Dans l'équipe fictive, ces responsabilités sont attribuées séparément.
- Responsable des opérations : approuve la nécessité d'un horodatage pour une prestation réalisée et résout les exceptions opérationnelles.
- Ingénieure du système de réservation : confirme comment statuts et horodatages arrivent dans l'export, y compris les délais et les corrections.
- Analyste reporting : maintient l'entrée du dictionnaire, identifie les rapports touchés et consigne la version approuvée.
- Responsable du tableau de bord : modifie le libellé et la formule, puis fournit des exemples à faire accepter par la responsable métier.
Il s'agit des responsabilités de l'exemple, pas d'une obligation de créer quatre postes. Une petite équipe peut cumuler les rôles. Le compte rendu doit néanmoins nommer une personne responsable et un moyen de la contacter. Une ingénieure ne devrait pas inventer une définition commerciale, et un responsable métier ne devrait pas approuver une correspondance que personne n'a vérifiée.
Écartez de la validation les sujets dont le périmètre reste ouvert. L'équipe n'a pas encore décidé si les frais d'absence doivent entrer dans le chiffre d'affaires de ce rapport. La présentation ne doit pas laisser croire qu'une définition claire du rendez-vous règle aussi la comptabilisation des recettes, les remboursements ou la fiscalité. Ce sont d'autres termes, reposant sur d'autres sources et d'autres autorités de décision.
Montrer l'effet du changement de définition sur l'historique
La version v2.0 proposée sépare deux termes : rendez-vous clôturé et rendez-vous réalisé. L'ancien libellé « réalisé » du tableau de bord renvoyait à la règle plus large de clôture. Changer uniquement le libellé ou uniquement la formule laisserait les utilisateurs comparer des nombres qui ne désignent pas la même chose.
| Version du rapport | Terme affiché | Règle | Nombre |
|---|---|---|---|
| v1.0, ancien tableau de bord | Réalisé | completed, cancelled ou no_show | 3 |
| v2.0, regroupement clarifié | Clôturé | completed, cancelled ou no_show | 3 |
| v2.0, nouvel indicateur opérationnel | Réalisé | completed avec une heure de réalisation enregistrée | 1 |
Le passage de trois à un ne prouve pas une dégradation de la prestation. Les enregistrements sont identiques ; seule la définition change. Montrez cette correspondance avant tout graphique chronologique traversant la frontière entre les versions.
Pour le déploiement fictif, proposez v2.0 à partir de la semaine de reporting commençant le 2 novembre 2026. Conservez le dictionnaire v1.0 et les rapports exportés. Lorsque les instantanés archivés contiennent les champs nécessaires, calculez un historique retraité distinct et étiquetez-le v2.0. Sinon, séparez les séries et signalez la rupture. Un export de l'état courant ne peut pas reconstituer de façon fiable toutes les anciennes dates d'arrêté.
La fiche de changement doit indiquer l'ancienne règle, la nouvelle, la première période concernée, la personne qui approuve, les rapports touchés et le traitement de l'historique. Précisez aussi si l'export source change ou si seule son interprétation dans le rapport évolue. Ici, l'export reste identique ; définition métier, libellé et calcul changent ensemble. Cette distinction permet à l'équipe technique d'évaluer le travail sans confondre une décision sémantique avec une migration de schéma.
Présenter la décision de définition en cinq diapositives
Une revue métier a besoin du dictionnaire en appui, pas de son intégralité à l'écran. Pour cet exemple, utilisez les cinq diapositives suivantes :
- « Trois rendez-vous clôturés ne sont pas trois prestations réalisées. » Placez le libellé contesté à côté de la question opérationnelle.
- « Les quatre mêmes lignes expliquent les deux totaux. » Montrez le petit tableau en distinguant completed, cancelled, no_show et le statut booked non résolu.
- « Approuver ce sens de réalisé. » Présentez la fiche de champ et de terme en insistant sur l'inclusion, les exceptions et la convention temporelle.
- « v2.0 change la comparaison, pas les événements sous-jacents. » Montrez le passage de trois à un, la période d'application et les limites du retraitement historique.
- « Approuver la définition et attribuer la modification du rapport. » Nommez les responsables de la décision, de la correspondance source et du rapport ; laissez la question des recettes hors de cette validation.
Joignez le dictionnaire complet et la fiche de changement pour que l'équipe retrouve les détails approuvés après la réunion. Si vous créez un brouillon de diapositives à partir de ces notes, conservez exactement les identifiants de champs, gardez le mot « fictif » et ne laissez pas un titre raccourci effacer la distinction entre clôturé et réalisé. Transformer les notes en diapositives n'implique aucune analyse automatique de base de données ni synchronisation avec un catalogue.
Le résultat proposé est précis : approuver réalisé comme un rendez-vous ayant donné lieu à une prestation avec une heure renseignée ; conserver clôturé comme regroupement distinct ; publier la définition v2.0 avec une rupture historique visible ou un historique retraité séparément et clairement étiqueté. L'équipe dispose alors d'un accord applicable, et non d'un glossaire que chacun peut encore interpréter à sa manière.
