Aller au contenu

ADR — Remote « team-internal » & partage par défaut du non-confidentiel

Statut : accepted (2026-06-12). Supersede la doctrine implicite « remote = public » qui régissait le .gitignore jusque-là.

Contexte

Le Bricks Brain visait un second cerveau d'équipe, mais son .gitignore traitait le remote comme public : par prudence, tout le contenu métier (areas/, projects/, meetings/, people/, la plupart des concepts business, journal/) était gitignoré et restait local.

Conséquence : un collègue qui clone reçoit le framework + la méthodo, mais aucun contenu d'équipe. Chacun reconstruit ses propres pages → ce n'est plus un cerveau partagé qui compound, mais N coquilles isolées. La valeur de centralisation est perdue.

Or le repo est privé (org brickssas, accès équipe Bricks). Dans la taxonomie maison, internal = « diffusable à toute l'équipe Bricks ». Traiter le remote comme public était donc une sur-prudence qui bloquait l'objectif.

Décision

Le remote est traité comme team-internal, pas comme public. On partage par défaut tout le contenu internal (connaissance d'équipe) et on garde local uniquement le confidentiel.

Frontière « reste local » (confidentiel) — validée le 2026-06-12

  • Perso & brut : private/**, inbox/** (transcripts Leexi verbatim, JSON Linear/Slack), règles perso (collaboration-romain, todo, transcript, business-and-blockers).
  • Données tierces : people/clients/, people/partners/, people/contractors/.
  • Finance, RH, commercial : areas/finance/, areas/rh/, areas/commercial/, resources/chiffres-cles.md, concepts/cadre-evaluation.md + career-paths (pm, pd, product-builder).
  • Partenaires / légal / process financier sensible : concepts/ lemonway, contrats, kyc-update-lemonway, partenariats-chaines-pdp, espace-financement, repartition-back-office-post-financement.
  • Leadership team : concepts/business-blockers.md.
  • Catalogues auto (listent des chemins locaux → fuite de noms) : index.md, log.md.

Devient partageable (après passe de confidentialité)

projects/, areas/{produit,tech,design}, concepts internes & design (outil-d-analyse, squads, sos-captain, stack-marketing-ia, product-design-bricks, design-system-bricks), people/team/ (sans jugements RH), meetings/ & journal/ (par fiche), resources/{strategie,vision,mission-valeurs,positioning,personas}, et les ADR — ces dernières formulées pour être partageables (la standardisation des décisions améliore la qualité du travail commun).

Conséquences

  1. Le .gitignore passe de denylist « tout le métier » à denylist « le confidentiel seulement ».
  2. Migration par passes, jamais en bloc. Chaque catégorie passe par un scrub de confidentialité avant d'être dé-gitignorée (le contenu internal peut contenir des poches restricted : chiffres, incidents, jugements nominatifs). Méthode éprouvée sur la KB produit (2026-06-11).
  3. Garde-fous existants suffisants : la lentille formalisation & confidentialité (écrire propre à l'entrée) + le pre-commit qui bloque tout fichier confidentiality: restricted.
  4. Réalité opérationnelle : partager du contenu vivant = plus de merges sur des pages éditées à plusieurs. Géré par /sync (merge, jamais force).
  5. Rédaction orientée partage : les nouvelles pages (specs, ADR, fiches) s'écrivent d'emblée pour le partage — le sensible relocalisé/abstrait, pas le sujet entier caché.

Passes de migration

  • Pass 1 : projects/ + areas/{produit,tech,design} + concepts internes non-partenaires.
  • Pass 2 : people/team/, meetings/, journal/ (triage fiche par fiche).
  • Pass 3 : resources/ (stratégie/vision/personas) + ADR (reformulées).

Sources