Aller au contenu

ADR : KYC Update Lemonway — option Manuelle plutôt que Plug & Play

Contexte

Lemonway impose à tous ses clients PSP une mise à jour périodique du KYC (Know Your Customer), au titre de la réglementation européenne LCB-FT (Directive UE 2015/849 — 4ème AMLD, renforcée par l'art. 26 du Règlement AML (UE) 2024/1624). Fréquence selon profil de risque : tous les 5 ans (faible), 3 ans (moyen), 12 mois (élevé).

Lemonway propose deux modes d'implémentation, présentés dans le webinaire du 24 mars 2026, avec une deadline de choix initialement fixée au 30 avril 2026 :

  1. Plug & Play : Lemonway gère intégralement les communications (3 emails clés : demande J-60, rejet, blocage) directement auprès de nos utilisateurs finaux. Bascule automatique au 1er juillet 2026.
  2. Manuelle : nous gérons les comms et l'UX en interne via les webhooks 53 (Requirement) et 54 (Restriction). Premières comms à envoyer avant le 15 septembre 2026.

À l'ouverture de cette ADR (6 mai 2026), la deadline du 30 avril est dépassée — sans réponse formelle de notre part, l'option Plug & Play s'applique par défaut. D'où l'urgence d'arbitrer et formaliser.

Sujet remonté par Denis Mludek dans le thread Slack du 29 avril 2026, avec proposition initiale en faveur de l'option Manuelle.

Options envisagées

Option A : Plug & Play

  • Description : Lemonway envoie ses propres emails à nos utilisateurs finaux à 3 moments clés. Aucune action technique de notre côté.
  • Avantages :
  • Zéro effort de delivery côté Bricks.
  • Pas de risque de loupé delivery (Lemonway porte la responsabilité opérationnelle).
  • Permet de focaliser l'équipe sur d'autres sujets build prioritaires.
  • Inconvénients :
  • Perte de la maîtrise UX : les utilisateurs reçoivent un email Lemonway dans un parcours qu'ils associent à Bricks → confusion, perte de confiance possible.
  • Pas de contrôle sur le ton, le branding, le timing.
  • Pas de relances intermédiaires possibles (Lemonway ne fait pas de relance entre les 3 emails).
  • Difficile de revenir en arrière si l'expérience pose problème.
  • Coût estimé : nul en effort, élevé en risque de friction utilisateur.

Option B : Manuelle

  • Description : on intègre les webhooks 53 (Requirement, 4 statuts : REQUESTED / UNDER_ANALYSIS / ACCEPTED / REJECTED) et 54 (Restriction, statut KYC_OUTDATED), on conçoit nos propres écrans dans l'app et on envoie nos propres emails (avec relances).
  • Avantages :
  • Cohérence UX de bout en bout : ton Bricks, branding Bricks, parcours Bricks.
  • Possibilité d'organiser des relances intermédiaires (J-30, J-15, J-7…) pour maximiser le taux de mise à jour.
  • Logique de blocage différenciée finement modulable selon profil (investisseur, prêteur, porteur de projet) — cf. matrice Lemonway.
  • Tracking analytique complet du parcours.
  • Pattern technique déjà connu : Vincent Besnier confirme que c'est proche de ce qu'on a déjà mis en place pour les utilisateurs devant compléter leurs infos compte (Slack 2026-04-29 [non sourcé : permalink à récupérer]).
  • Inconvénients :
  • Effort de dev non négligeable : backend (webhooks + restrictions), front (écrans), comms (templates + workflow).
  • Responsabilité opérationnelle de la campagne portée par Bricks (volumétrie à instruire pour calibrer l'effort).
  • Prérequis dur : la migration des wallets V1 → comptes + wallets V2 doit être finalisée avant. Statut actuel à clarifier.
  • Coût estimé : effort dev moyen-élevé, étalé sur Q3 2026 ; deadline dure 15 septembre 2026.

Décision

Option retenue : B — Manuelle

Justification : la qualité de l'expérience utilisateur sur les parcours liés au KYC est stratégique pour Bricks. Un email Lemonway envoyé sans contexte Bricks dans un parcours d'investisseur ou de porteur de projet crée un risque de confusion et d'attrition disproportionné par rapport à l'économie d'effort qu'apporterait Plug & Play. On accepte donc l'effort de delivery contre la maîtrise de bout en bout. L'effort est par ailleurs limité par la réutilisation du pattern existant (cf. point Vincent Besnier ci-dessus).

Conséquences

Positives attendues

  • Continuité d'expérience utilisateur sur les parcours KYC update (mêmes écrans, mêmes emails, même ton que le reste de l'app).
  • Capacité à déployer des campagnes de relance propriétaires pour maximiser le taux de mise à jour avant l'échéance.
  • Tracking analytique de bout en bout (vue écran, clic CTA, lien régénéré) → instrumentation des relances et mesure de conversion.
  • Logique de blocage différenciée par profil alignée avec nos modèles métier (investisseur crowdequity, prêteur crowdlending, porteur de projet) — pas un blocage uniforme.

Négatives acceptées

  • Effort de dev sur Q3 2026 (back + front + comms) — chemin critique vers le 15 septembre 2026.
  • Responsabilité opérationnelle pleine : si on rate la fenêtre du 15 septembre, Lemonway prend la main par défaut à partir du 16 septembre et envoie ses propres emails à nos utilisateurs (perte d'UX rétroactive).
  • Dépendance au prérequis migration wallets V2 — peut décaler le calendrier si non tenu.
  • Ownership de la qualité des comms (taux de délivrance, taux d'ouverture, conformité réglementaire des templates) à porter en interne.

Reversibilité

  • Coût d'annulation : moyen. Si on rencontre un problème majeur en cours de delivery, on peut basculer en Plug & Play en cours de route en informant Lemonway, à condition de rester dans la fenêtre opérationnelle (avant 1er septembre 2026, début du blocage Plug & Play). Au-delà, le coût de bascule devient élevé (utilisateurs déjà notifiés par Bricks dans une mécanique différente).

Plan d'implémentation

Projet Linear dédié : KYC Update Lemonway — option Manuelle.

Découpage en 8 issues avec dépendances :

  • [ ] BRI-687 — Confirmer Manuelle auprès de l'AM Lemonway (Urgent, 8 mai)
  • [ ] BRI-688 — Instruire volumétrie + statut migration wallets V2 (22 mai)
  • [ ] BRI-689 — Récupérer liste comptes Ondorse à exclure (22 mai)
  • [ ] BRI-690 — Cadrage produit & UX du parcours KYC update (15 juin)
  • [ ] BRI-691 — Backend : webhooks 53/54 + blocage différencié (15 août)
  • [ ] BRI-692 — App : écrans utilisateur + flow régénération lien (31 août)
  • [ ] BRI-693 — Templates emails + organisation des relances (31 août)
  • [ ] BRI-694 — Recette + déploiement + lancement avant 15 sept.

Ownership : - Lead projet : Denis Mludek (CTO). - Relation AM Lemonway : Cédric ou Denis (à trancher). - Cadrage produit : Romain (à confirmer). - Dev back : équipe tech (Denis + Vincent Besnier pressenti vu la proximité avec ce qu'il a déjà fait). - Comms / templates emails : équipe à désigner.

Calendrier : - 8 mai 2026 : email à l'AM Lemonway pour formaliser le choix (Romain a pris le point). - 22 mai 2026 : volumétrie + statut V2 + liste Ondorse instruites. - 15 juin 2026 : cadrage produit & UX validé. - 15 août 2026 : backend prêt et déployable. - 31 août 2026 : app + templates prêts. - 15 septembre 2026 : campagne lancée en prod (deadline dure Lemonway). - 15 novembre 2026 : début des blocages côté Lemonway pour les comptes non mis à jour.

Métriques de succès

  • Hard : première vague de comms envoyée avant le 15 septembre 2026 (sinon Lemonway prend la main).
  • Quality : taux de mise à jour KYC ≥ X% (à définir au cadrage) avant l'échéance individuelle de chaque utilisateur, mesuré 30 jours après l'envoi de la demande.
  • UX : pas de pic de tickets CS liés à de la confusion sur le parcours KYC update.
  • Conformité : 0 utilisateur bloqué pour défaut de notification de notre fait.

Sources

Révisions

  • 2026-05-06 : créée et acceptée (status: accepted) suite à l'arbitrage Romain ↔ Denis dans le thread Slack du 29 avril 2026.