ADR-0025 — Comptoir : application distincte (sœur de RED), référentiel transverse des tiers externes¶
Date : 2026-06-30
Catégorie : B (création d'application / périmètre produit ; révocable 5 j)
Décideur : Lead architecte DYNORS (proposé)
Statut : Acceptée sous réserve (2026-07-03) — gate « spec formalisée » ✅ satisfait ; reste vérification marque/domaine du nom « Comptoir » avant Acceptée pleine. Voir Amendement en fin.
S'appuie sur : [[0004-perimetre-fige-fiscal-books-paiement]] (factures fournisseurs → BOOKS, pas FISCAL), [[0007-gouvernance-architecte-categories-abc]] · amendé par [[0026-derogation-comptoir-consommateur-fiscal-supplier-payments]] (règlement fournisseur → FISCAL, dérogation)
Source de vérité : docs/projet-nouveau/RelationsExternes/ — CADRAGE_PLATEFORME_TIERS_EXTERNES.md (besoin), ETUDE_GLOBALE_COMPTOIR.md (benchmark + règles), SPEC_TECHNIQUE_COMPTOIR_MVP.md (spec formalisée)
Contexte¶
Au-delà des clients (gérés par RED, CRM sell-side), DYNORS et ses tenants pilotent tout un graphe de tiers externes : fournisseurs, prestataires (garagistes, assureurs, moniteurs…), partenaires, institutions (DGI, collectivités), médias/influence. Aujourd'hui ces tiers seraient dupliqués dans chaque app (DAWALALE, ELISA…). RED ne couvre pas ce besoin : son intention est de transformer des prospects en clients et de suivre le revenu entrant — l'axe opposé de la relation (ressources / écosystème). Le seul recouvrement est la brique « contact + fiche 360° » ; les workflows (achats, SRM, contrats, risques tiers, presse) divergent totalement.
Le cadrage propose une application distincte nommée Comptoir (source-app: comptoir). Cet
ADR fixe la posture d'architecture en Proposée, le temps que la spec fonctionnelle soit formalisée.
Décision (proposée)¶
-
Comptoir = application distincte dans
dynors-internal, sœur de RED (Spring Boot + Angular, socle core DYNORS). Bounded context propre : RED possède les clients, Comptoir possède les tiers externes. On ne mélange pas sell-side et resource-side dans un même modèle RBAC. -
Référentiel transverse. Comptoir expose
/comptoir/**via SLY pour que DAWALALE, ELISA, RAGNAR, BOOKS lisent garagistes/assureurs/partenaires sans les redupliquer. Typologie extensible (générique + types métier).SlyTransitFilterobligatoire (app appelée par d'autres). -
Intégrations uniquement via SLY : compta fournisseurs / écritures d'achat → BOOKS (
/books/**) ; règlements fournisseurs → DYNORS PAIEMENT (/paiement/**) ; alertes échéances → notify (/notify/**) ; bons de commande PDF →dynors-pdf. FISCAL n'est pas concerné : les factures fournisseurs relèvent de la compta achats (BOOKS), pas de la certification de ventes. -
Pas de noyau « contact » extrait en force (règle pragmatisme-preuves). RED et Comptoir gardent chacun leurs données avec une modélisation de contact cohérente ; une registry de contacts partagée serait un refactor futur, justifié par les faits, pas pré-bâti.
-
MVP : modules 1 (annuaire des tiers) + 3 (SRM : qualification/évaluation) + 4 (contrats & échéances). Achats et dépenses en phase 2, branchés sur BOOKS/PAIEMENT une fois le socle posé.
Conséquences¶
Positif : un endroit unique pour tous les tiers non-clients ; réutilisation transverse (fin des duplications garagistes/assureurs) ; séparation nette des modèles de sécurité RED/Comptoir ; intégrations conformes (SLY, frontières figées).
Coût / contraintes : une app de plus à construire et exploiter (socle core, CI/CD SIRRAT, routes SLY) ; nom « Comptoir » générique → disponibilité marque/domaine à vérifier avant de figer ; recouvrement partiel « contact » avec RED assumé tant qu'un refactor n'est pas justifié par les faits.
Composants impactés : nouveau dynors-internal/comptoir, dynors-platform/selebeyone (route
/comptoir/**), consommateurs (DAWALALE, ELISA, RAGNAR, BOOKS).
Alternatives écartées¶
- Onglet/extension de RED : mélange sell-side et resource-side dans un seul modèle de données et de RBAC, pour des workflows qui divergent totalement. Écartée.
- Référentiel tiers dupliqué dans chaque app : redondance garagistes/assureurs/partenaires,
incohérence, pas de source unique. Écartée au profit du référentiel transverse
/comptoir/**.
Suivi¶
- Gate d'acceptation : spec fonctionnelle Comptoir formalisée (modules, modèle de données, RBAC) + vérification marque/domaine du nom.
- Tant que Proposée : sert de cadre d'architecture pour la pré-spec, sans engager la construction.
Amendement (2026-07-03)¶
Évolutions décidées en session de conception, à intégrer à cet ADR :
- Gate « spec formalisée » satisfait :
SPEC_TECHNIQUE_COMPTOIR_MVP.md(modèle de données, API/api/comptoir/v1, SLY, events, RBAC, §11 dépendances réelles) +ETUDE_GLOBALE_COMPTOIR.md(benchmark SRM/TPRM/CLM/PRM, moteur de règles config-driven). Reste vérif marque/domaine avant Acceptée pleine. - Nom retenu : Comptoir (
source-app: comptoir). Option de marque : Comptoir = plateforme, Vigie = assistant contrats/risques. - MVP élargi (décision produit) : le module Achats/Dépenses (P2P complet) est promu dans le MVP (contrairement au point 5 initial « phase 2 »). Cycle devis → BC → réception → facture reçue (saisie manuelle + preuves) → validation (rapprochement) → comptabilisation → règlement.
- Dépendances réelles (vérifiées workspace) : BOOKS n'a pas de REST → comptabilisation par événement
comptoir.facture.a_comptabiliser; PAIEMENT non livré → règlement statut manuel. - FISCAL — nuance au point 3 : la certification reste hors périmètre (achats non certifiés), mais la déclaration du règlement fournisseur passe par FISCAL
/supplier-payments— autorisée par ADR-0026 (dérogation temporaire au gel phase 2). RAS saisie manuelle (endpoint inexistant). - Scaffold lot 1 livré :
dynors-internal/applications/comptoir/backend/(socle hexagonal, catalogue + tiers + pièces d'achat, Liquibase + seed,SlyTransitFilter,FiscalSupplierPaymentClient).
Références¶
docs/projet-nouveau/RelationsExternes/:CADRAGE_PLATEFORME_TIERS_EXTERNES.md,ETUDE_GLOBALE_COMPTOIR.md,SPEC_TECHNIQUE_COMPTOIR_MVP.md,comptoir-ui-mockup.html- ADR-0004 (frontière FISCAL/BOOKS), ADR-0007 (catégories A/B/C), ADR-0026 (dérogation FISCAL supplier-payments)