Aller au contenu

Architecture Decision Records (ADR)

Trace pourquoi chaque choix structurant du dépôt — pas le comment (couvert par la documentation thématique sous docs/architecture/, docs/quality/ et docs/collaboration/), mais le contexte, l’alternative écartée et les conséquences assumées.

Format léger inspiré de Michael Nygard :

  • Contexte — ce qui a forcé une décision.
  • Décision — ce qui a été acté.
  • Statut — Accepted / Superseded by NNNN / Deprecated.
  • Conséquences — gain, prix à payer, garde-fous à connaître.

Chaque ADR est numéroté en séquence (NNNN-titre-en-kebab-case.md). Une fois acté, un ADR n’est pas réécrit : il est superseded par un nouvel ADR qui décrit la nouvelle posture et référence l’ancien.

Nouveau venu ? Le parcours thématique regroupe ces décisions par sujet et propose un tour cohérent — par où commencer, comment elles s’articulent. L’index ci-dessous reste la référence par numéro.

Frontière avec le cluster ? L’index des décisions système recense les ADR qui décrivent la frontière cluster ↔ atlas (préfixés CL-/AT- pour lever la collision des numéros entre les deux dépôts).

#TitreStatut
0001DevSecOps périmètre repo complet, périphérie sine dieAccepted
0002Monorepo organisé en 8 catégoriesAccepted
0003packages/logos splitté en assets/logos + cli/logosAccepted
0004Volumes anonymes pour sandbox/sillage-sandbox/Accepted
0005Effect pour la programmation fonctionnelleAccepted
0006SvelteKit, Hono et Bootstrap comme socleAccepted
0007REDCap et Appwrite comme plateformes externesAccepted
0008CLIs thins, logique métier dans packages/Accepted
0009atlas source canonique vs amarre standaloneAccepted
0010node-appwrite SDK 25.x conservé pour TablesDBAccepted
0011Trois paquets internes marqués privateAccepted
0012Neutralisation du framing institutionnelAccepted
0013Documentation pour public non-expert, en françaisAccepted
0014Conventional Commits, scopes restreintsAccepted
0015Hooks Git via lefthook, jamais bypassésAccepted
0016Branch protection sur mainAccepted
0017Releases npm signées par OIDC sur deux registresAccepted
0018SLA de remédiation des findings sécuritéAccepted
0019Dérogations explicites au workspace auditAccepted
0020Lint Svelte au preset strictAccepted
0021Politique de dépendances pour les sandboxesAccepted
0022Convention de nommage atlas- pour les paquets publiésAccepted
0023storybook:build cassé en amont (Storybook 10.4 / Svelte 5.55)Accepted
0024Ranges ~ sur les dependencies des paquets publiablesAccepted
0025Documentation à plusieurs niveaux (surface, profondeur, inline)Accepted
0026Périmètre RGPD hors dépôt, questions ouvertesAccepted
0027Rôle de security champion : ouvert (vacant)Accepted
0028Documentation vérifiable : un miroir contrôlable du codeAccepted
0029Pipeline de collaborations : architecture V1 (plateforme DataOps, contrat Parquet)Accepted
0030Profilage de collaborations : gate RGPD, base légale et droit d’oppositionAccepted
0031Outil générique open-source : contribution inter-établissementsAmended by 0079
0032KPI documentés : généré déterministe (diff-checké) vs snapshot (append-only)Accepted
0033Contrat d’interface entre l’application (atlas) et le clusterAccepted
0034CI adaptative par chemin : court-circuit des jobs lourdsAccepted
0035Dépôt généraliste ouvert : neutralité de domaineAccepted
0036Migration de la documentation : VitePress → Astro StarlightAccepted
0037Retrait de la référence API générée (TypeDoc)Accepted
0038Épingler le niveau WCAG cible des tests d’accessibilitéAccepted
0039Cadence d’audit transverse : trimestriel, rappel automatiséAccepted
0040Caches applicatifs : flux + backing-service injectable vs fichier localAccepted
0041Stratégie d’authentification du service CRF (Hono)Accepted
0042Périmètre des sandbox : dev/test local dans atlas, pas dans clusterAccepted
0043Publication des images de déploiement sur GHCRAccepted
0045Runtime Effect central par type de processusAccepted
0046Frontière Effect ↔ SvelteKitAccepted
0047Stratégie de validation (Effect Schema, zod en cohabitation)Accepted
0048Modèle d’erreur HTTP (atlas-errors conservé + couture Effect)Accepted
0049Convention de test Effect (it.effect, layers partagés, garde-fou)Accepted
0050Limite de l’audit knip face aux peerDependenciesAccepted
0051Rétrospective du chantier socle Effect (E1–E14)Accepted
0052Charte rédactionnelle de la documentation (règles de relecture)Accepted
0053Merge commit imposé sur main (abandon du squash)Accepted
0054Ingestion massive OpenAlex par snapshot S3 (works + authors)Accepted
0055Catégorie dataops/ : code DataOps en Python natifAccepted
0056Registre de drifts : catalogue indexé des écarts révélés à l’exécutionAmended by 0071
0057Reproductibilité : tests hermétiques et fixtures figéesAccepted
0058Chargement de l’index (mart→Postgres) : report de index_load faute de producteur researchersAccepted
0059Producteur par chercheur : ancrage author_id, purge d’opposition au grain (author_id, work_id)Accepted
0060Consignation des reconnaissances multi-agents pré-implémentationAccepted
0061Accélérer la CI : cache de contenu, parallélisation des jobs, court-circuit élargiAccepted
0062MLOps niveau 1→2 : suivi de modèles, détection de dérive, réentraînement déclenchéAmended by 0079
0063Échantillon cohérent par construction sur les petits bancs (authors dérivés des works)Accepted
0064Collecte « veille médiatique » (GKG v2) par pull HTTP incrémental, code-location dédiéAccepted
0065Qualifier une organisation comme « université » : heuristique de nom + référentielAccepted
0066Cache Turbo des checks dataops : package.json minimal et entrée dans le workspaceAccepted
0067Modèle prédictif d’uplift FWCI sur EUNICoast (réorientation du pipeline citation)Accepted
0068Suivi de dérive du modèle d’uplift FWCI (drift applicatif, porte de sécurité)Accepted
0069Scan, signature et provenance des images conteneur publiées sur GHCRAccepted
0070Page de preuves (vitrine d’orientation) et doctrine des badges admissiblesAccepted
0071Méta-gouvernance documentaire exécutable et cartographie de la couverture E2EAccepted
0072Tests basés sur les propriétés au dataops Python (Hypothesis)Accepted
0073Corriger le code, pas l’état, et garde-fou de cible de déploiementAccepted
0074Typologie documentaire d’intention (Diátaxis)Accepted
0075Déploiement prod par digest : atlas fournit les points d’injection, cluster les remplitAccepted
0076Portails d’orientation et accueil par intentionAmended by 0078
0077Topologie : deux dépôts cluster & atlas, frontière outilléeAccepted
0078Barre latérale thématique, navigation Diátaxis intra-catégorieAccepted
0079Boucle fermée dérive → réentraînement, active par défaut (citation)Accepted
0080Capture assistée des drifts au point d’échecAccepted
0081Modèle de prévision du volume d’articles par université (mediawatch)Accepted
0082Boucle fermée dérive → réentraînement, active par défaut (mediawatch)Accepted
0083Câblage d’OpenSSF Scorecard (note supply-chain et badge en tête)Accepted
0084Épinglage des images de base par digest (Pinned-Dependencies)Accepted
0085Cache de flux : package partagé Effect adossé à Postgres (CNPG)Accepted
0086Posture vis-à-vis des paliers Best Practices (silver visé, gold exclu)Accepted
0087Signature cosign des artefacts de Release GitHubAccepted
0088Portabilité : architectures (arm64/x86_64), OS et libcAccepted
0089Métriques Prometheus des services applicatifs (/metrics via Effect)Accepted

Un ADR se justifie quand :

  • la décision est durable (~ trimestres, pas semaines) ;
  • une alternative crédible a été écartée et le « pourquoi » se perdrait dans l’historique Git sans note explicite ;
  • une tension est assumée (compromis, dette acceptée, exception à une règle générale) que les contributeurs futurs doivent retrouver.

Un ADR n’est pas le bon endroit pour : une convention de code (→ docs/quality/code-style.md), un guide opérationnel (→ README de paquet), une décision opérationnelle court-terme ou un chantier actionnable (→ une issue GitHub, label enhancement ou tech-debt).