Aller au contenu

ADR-016 — Ownership statut projet piloté par l'Outil d'analyse (post-envoi-analyse)
Statut Accepted (validé en live par Romain × Alban en synchro équipe S21)
Date 20/05/2026 (S21)
Décideurs Romain BAZIL, Alban Huntziger
Origine Synchro équipe S21 (20/05/2026)
Caractère Temporaire — sera superseded par l'ADR qui actera la table statut centralisée (cf. BRI-354)

Contexte

Depuis l'origine, 3 outils écrivent dans le statut projet : le CRM AM (Bubble custom), l'Espace Financement Bubble, et l'Outil d'analyse. Ce triangle de synchronisation est la cause racine de la majorité des bugs remontés ces derniers mois :

  • Audit BRI-695 (en cours à la date de la décision) : 30-50 dossiers désynchronisés entre l’Outil d’analyse et EF Bubble, avec rattrapage manuel.
  • Récurrence hebdomadaire : des dossiers repassaient en attente porteur côté EF après leur passage en comité.
  • Confiance AM dégradée : les écarts entre ce qu'ils voient (CRM) et la réalité métier (Outil d'analyse) compromettent leur autonomie opérationnelle.

La cible long terme (table statut centralisée, BRI-354) implique de débrocher l'EF Bubble — chantier de plusieurs mois (refonte EF côté PDP post-financement encore à faire). On a besoin d'une solution intermédiaire qui stoppe la perte de dossiers maintenant, sans engager la refonte structurelle.

Décision

À partir du moment où un projet est envoyé en analyse, le statut projet est owned exclusivement par l'Outil d'analyse.

  • Le CRM AM et l'EF Bubble passent en read-only sur le statut après cette transition.
  • L'Outil d'analyse diffuse le statut en sens unique vers les 2 autres outils (CRM AM, EF Bubble) via le mécanisme déjà en place.
  • Aucune écriture parallèle n'est tolérée post-envoi-analyse, même « pour dépanner ».
  • Cette décision est explicitement temporaire : elle sera reversée par le futur ADR qui actera la table statut centralisée (cf. BRI-354) une fois la refonte EF terminée.

Rationale

  • Élimine la cause racine des bugs sans refonte structurelle : un sens d'écriture unique supprime les conflits par construction. Le débat « qui écrase qui » n'a plus lieu d'être.
  • N'introduit pas de friction opérationnelle nouvelle : l’équipe AM a confirmé qu’après l’envoi en analyse, elle n’a plus de statut métier à modifier. La restriction n’enlève donc aucune capacité utile.
  • Préserve la matière pour mesurer et apprendre : tant qu'un seul système écrit, on peut tracer, expliquer et corriger. Le triangle actuel rend impossible toute analyse de cause d'écart.
  • Découple le calendrier : on peut traiter les désynchros historiques (phase 1 BRI-695) sans bloquer sur la refonte data centrale.
  • Met l'ownership là où la valeur métier vit : post-envoi-analyse, le dossier est piloté par les analystes / le comité. C'est leur outil qui doit dicter l'état du dossier.

Conséquences

Ce qui change

  1. CRM AM : statut projet devient read-only sur l'UI dès que le projet a transité par « envoi en analyse ». Les boutons ou champs de modification sont désactivés ou masqués.
  2. EF Bubble : idem côté espace financement — le statut affiché ne peut plus être modifié manuellement post-envoi-analyse.
  3. Outil d'analyse : conserve sa capacité d'écriture + diffuse en sens unique vers les 2 autres outils via le mécanisme déjà existant.
  4. Doc opérationnelle AM : à mettre à jour pour expliciter ce nouveau comportement (pourquoi un statut n'est plus modifiable depuis le CRM).

Ce qu'il faut faire

  • Implémenter le verrouillage côté CRM AM + EF Bubble (Romain × Kevin × Alban — ticket Linear T1 dérivé de cet ADR).
  • Vérifier que la diffusion sens unique Outil d'analyse → autres outils couvre tous les statuts post-envoi-analyse (en attente d'analyse, analyse prête, en attente de comité, etc.).
  • Communiquer aux AM sur le canal #account-managers (changement UX visible + raison).
  • Tracer cet ADR comme dépendance bloquante de BRI-354 (la table statut centralisée doit considérer cet état comme baseline à reverser proprement).

Ce qu'il faut éviter

  • Ne pas réintroduire de chemin d'écriture parallèle « pour dépanner » : la pression de prod va inciter à patcher en local (« je modifie juste ce statut directement en DB »). Chaque dérogation rétablit le triangle.
  • Ne pas oublier l'horizon de supersede : quand la table statut centralisée arrivera (BRI-354), il faut explicitement créer un nouvel ADR qui supersede celui-ci. Ne pas laisser cet ADR « temporaire » devenir l'état de l'art par défaut.
  • Ne pas laisser des écritures résiduelles côté Bubble : audit à faire des automations Bubble qui pourraient écrire le statut en arrière-plan (webhooks, workflows internes).

Alternatives écartées

  • Statu quo — laisser les 3 outils écrire et continuer le rattrapage manuel : reproduit la perte de dossiers semaine après semaine. Coût opérationnel cumulatif important (12 à 50 dossiers tous les quinze jours environ). Inacceptable pour la dynamique de scale.
  • Refonte structurelle immédiate (table statut centralisée, BRI-354) : c'est la cible long terme, mais elle dépend de la débrochage complet de l'EF Bubble — refonte côté PDP encore plusieurs semaines (post-financement front non démarré). Trop coûteux et trop risqué pour un bénéfice qui n'arrivera pas avant Q3.
  • Synchronisation bidirectionnelle propre via un service bus dédié (webhook router) : ajoute une couche supplémentaire à un système qu'on veut justement simplifier. Réintroduit un middleware à maintenir qui aura ses propres bugs. Ne libère pas du triangle, le formalise juste différemment.

Voir aussi

Sources