Tags + Properties
Le tag et la property appartiennent au bloc — pas à une arborescence de panneau latéral qui survit à chaque réorganisation.
- ··La classification à l'atome — tag et property en DSL inline sur le bloc (#wettbewerber, status::offen).
- ··Les filtres s'appuient sur les propriétés du bloc plutôt que sur l'arborescence de fichiers.
- ··Une recherche sur status::done trouve des actions, pas des documents.
Transcription
Et si la classification ne vivait pas dans un tableau à côté du contenu, mais sur le bloc même qui porte l'affirmation ? Dans les minutes qui viennent, vous entendrez pourquoi la liste Excel à côté du mémo devient une seconde vérité — et comment un tag et une property la dissolvent.
Dans le quotidien de la due diligence, le contenu et la classification avancent séparément. Le mémo vit dans Word, le statut se trouve dans un tableau Excel à côté, avec des colonnes pour la source, l'échéance et le concurrent. Dès que quelqu'un met le mémo à jour, le registre dérive. Au bout de douze semaines, vous trouvez dix-huit entrées au statut review dont le texte source est passé à final depuis longtemps. Personne n'a menti — le second endroit n'a tout simplement pas suivi.
C'est exactement là que se loge le risque. Deux vérités parallèles sont une affaire de piste d'audit, car la personne qui tient le tableau est rarement celle qui modifie le contenu. Le remède n'est pas plus de discipline à l'alignement, mais de poser la classification là où l'affirmation se trouve déjà.
Pour cela, il vous faut deux briques. Le tag, c'est la classification transversale à plat — concurrent, risque, fournisseur, sans hiérarchie, pour des vues qui traversent les domaines. La property, c'est la métadonnée structurée sur le bloc — statut fixé à review, source fixée à bloomberg, une échéance portant une date. Clé et valeur, interrogeables et typées, sur l'affirmation même à laquelle elles appartiennent.
Et là, le tableau ne disparaît pas, il devient une query. Une seule requête sur tous les blocs en statut review remplace le registre tenu à la main. Le résultat se met à jour dès qu'un bloc change. Qui veut voir tous les points ouverts à échéance proche écrit la requête une fois et la relit chaque jour.
Pour que cela tienne, il vous faut une convention par domaine. Quelles clés et quelles valeurs sont autorisées se décide une fois et se versionne — sinon trois personnes écrivent status, statu et Status, et la query revient bredouille. Une page par domaine suffit, et la dispersion s'arrête avant de commencer.
La question honnête pour finir : combien de fois entretenez-vous la même information à deux endroits — une fois dans le document, une fois dans le tableau d'à côté ? Si le compte dépasse trois en une semaine, le tableau n'est plus une vue, c'est une seconde source. Accrochez le sens au bloc, et votre deuxième cerveau garde le statut et la source là où l'affirmation se trouve.
#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.