Tags + Properties
Et si la classification ne vivait pas dans un tableau à côté du contenu, mais sur le bloc lui-même — interrogeable, cohérente, sans double entretien ? Les tags et les properties réduisent le temps de classification par rapport d'environ 65 % et la charge d'entretien des tableaux de 80 %, tandis que la cohérence entre la source et la vue atteint 100 % par définition.
- Sans convention de domaine, les clés et les valeurs prolifèrent — trois personnes écrivent status::, statu:: et Status::, et la query revient bredouille.
- Les properties sur le bloc demandent de la discipline à la saisie ; taguer 1 000 blocs après coup coûte plus cher que de le faire dès le départ.
- La prolifération de tags sans noyau curaté crée des îlots de synonymes — #wettbewerber à côté de #competitor à côté de #wb.
#wettbewerber, status:: review, source:: bloomberg — la classification sur le bloc qui en a besoin. Plus de tableau à côté.
- Temps de classification par rapport : −65 %
- Charge d'entretien des tableaux : −80 %
- Cohérence source ↔ vue : 100 %
Pourquoi le tableur Excel devient une seconde vérité
Dans le quotidien de la due diligence, le contenu et la classification avancent séparément — des mémos dans Word, un registre Excel avec statut, source et concurrent à côté. Dès qu'un mémo est mis à jour, le registre dérive. Au bout de 12 semaines, on retrouve 18 entrées au statut « review » dont le texte source est passé à « final » depuis longtemps.
5 règles
- Le tag, c'est la classification transversale. `#wettbewerber`, `#risiko`, `#vendor` — à plat, sans hiérarchie, pour des vues qui traversent les domaines.
- La property, c'est la métadonnée structurée. `status:: review`, `quelle:: bloomberg`, `frist:: 2026-06-30` — clé-valeur, interrogeable, typée (`quelle::` = source, `frist::` = échéance).
- La query, c'est la vue vivante. Une requête sur tous les blocs en `status:: review` remplace le tableau tenu à la main. Le résultat se met à jour dès qu'un bloc change.
- Les properties, sur la page ou sur le bloc. Une property de page vaut pour tout le document (client, type de contrat). Une property de bloc vaut pour l'affirmation (la source d'un chiffre, l'échéance d'un paragraphe).
- Une convention par domaine. Les clés et les valeurs autorisées se fixent par domaine et se versionnent — pas d'improvisation au gré de chacun.
## Mémo concurrent Acme
status:: review
quelle:: bloomberg
frist:: 2026-06-30
Chiffre d'affaires T4 : 142 M€ #wettbewerberAvant / après — liste Excel vs bloc en status:: review
| Avant (Excel à côté) | Après (property sur le bloc) |
|---|---|
| Mémo dans Word, entrée dans tracker.xlsx ligne 47 | Le bloc du mémo porte `status:: review` |
| Changement de statut : ouvrir deux fichiers, les enregistrer tous les deux | Changement de statut : modifier une valeur, la vue se met à jour |
| Question d'audit « état au 2026-04-12 ? » → confronter l'historique de deux fichiers | Question d'audit « état au 2026-04-12 ? » → une seule piste de versions, un seul bloc |
| Cohérence source ↔ vue : vérifiable seulement par sondage | Cohérence source ↔ vue : 100 % par définition |
Le tableau ne disparaît pas — il devient une query. Qui veut voir « tous les blocs en status:: review avec frist:: < 2026-07-01 » écrit la requête une fois et la relit chaque jour.
Une question honnête
Combien de fois entretenez-vous vos contenus et leur tableau séparément ? Comptez sur la semaine en cours les cas où vous avez modifié la même information à deux endroits — une fois dans le document, une fois dans le registre.