Rendre explicites les engagements autour des données

Ce que signifie une colonne, qui en répond, quelle fraîcheur ou quelle qualité on peut en attendre : un contrat réunit ces engagements pour que producteurs et consommateurs puissent s’y référer. Certaines informations décrivent le sens des données ou les responsabilités ; d’autres peuvent être associées à des contrôles. Déclarer un engagement et vérifier qu’il est tenu sont deux fonctions distinctes.

Avant de définir les écrans, j’ai commencé par décrire ce qu’est un contrat : qui le propose, qui l’accepte, ce qu’il garantit, par quels états il passe, et ce qui se passe quand il n’est plus tenu.

Dans le modèle proposé, le contrat constitue un objet du produit à part entière, avec un responsable et un cycle de vie à définir.

Le contrat ne naît pas de rien : il s’appuie sur un dataset qui a déjà ses propres mesures de qualité, par dimensions et par règles de validation. La première question n’était donc pas « à quoi ressemble un contrat ? », mais « quelle relation le lie au dataset ? ».

J’ai choisi de m’appuyer sur ces mesures plutôt que de créer un second système de mesure propre aux contrats. Cette relation devait éviter de dupliquer la description de la qualité. Elle ne dispense pas de préciser ce que chaque engagement exige : une mesure commune et le seuil attendu par un consommateur ne sont pas la même chose.

Pour illustrer cette distinction, imaginons un engagement de mise à jour avant 8 heures. L’heure de dernière mise à jour constitue une mesure ; « avant 8 heures » exprime l’attente ; leur comparaison permet d’évaluer le respect de cet engagement. Cet exemple explique le principe, sans décrire une fonctionnalité livrée.

Nous avons d’abord listé tout ce qu’un contrat peut garantir, puis donné des règles à chaque type de garantie : certaines se répètent, d’autres sont uniques par nature. Nous avons utilisé ces règles pour structurer les types de garanties et concevoir des patterns d’usage destinés à leur création, leur édition et leur suivi.

L’objectif est de partager le vocabulaire et les comportements récurrents, tout en conservant les différences entre types de garanties. Les écrans et les prototypes permettent ensuite d’éprouver ces règles.

J’ai prototypé en code, avec Claude et Figma Make, pour rendre les comportements manipulables lors des échanges avec l’ingénierie. Le prototype sert de support à la discussion ; il ne constitue pas à lui seul une validation des règles ou de leur utilisabilité.