ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Backend for Frontend

Une API par expérience client : arrêter le compromis d'une seule API « qui sert tout le monde mal ».

Problème

Un hub EDI expose une API REST /orders commune au portail web fournisseur (Next.js), à l'app mobile ops (React Native), et au dashboard finance (Power BI). Chacun a des besoins incompatibles : le portail veut le détail complet d'une commande avec lignes ; l'app mobile veut un payload minimal compressé ; la finance veut des agrégats trimestriels. Si l'API tente de tout fournir, elle sur-livre pour mobile (latence) et sous-livre pour finance (10 appels enchaînés). Si elle ajoute des paramètres ?include=lines&agg=quarter, elle devient un nœud de complexité ingérable.

Forces

  • Les contextes UX divergent. Mobile = bande passante limitée, écran petit. Desktop = données détaillées. Reporting = agrégats lourds.
  • Les équipes diffèrent. Équipe portail = product + design ; équipe ops = SRE ; équipe finance = data engineers. Une seule API force des cycles de release joints.
  • L'agrégation côté client est coûteuse. Mobile qui fait 12 appels pour construire une vue = batterie + latence.
  • La sécurité diffère. Portail = OAuth fournisseur ; ops = SSO interne ; finance = MFA stricte. Politiques d'auth par consommateur.

Solution

Construire un BFF par expérience client. Le BFF Portail Fournisseur expose GET /orders/:id qui agrège l'order service, l'invoice service et l'audit service en un seul payload riche. Le BFF Ops Mobile expose GET /alerts qui ne retourne que les KPI temps réel filtrés par partenaire surveillé. Le BFF Finance expose GET /revenue?period=quarter avec pre-aggregation et cache long. Chaque BFF appartient à l'équipe qui livre la UI. Les services internes (Order, Invoice, Routing) restent stables et génériques. 

   Portail Fournisseur     App Ops mobile      Dashboard Finance
   (Next.js / web)         (React Native)      (Tableau de bord)
         │                       │                     │
         ▼                       ▼                     ▼
   ┌─────────────┐         ┌─────────────┐       ┌─────────────┐
   │ BFF         │         │ BFF Ops     │       │ BFF Finance │
   │ Fournisseur │         │ /alerts     │       │ /kpis       │
   │ /orders     │         │ /retries    │       │ /revenue    │
   │ /invoices   │         │ /backlog    │       │ /aging      │
   └──────┬──────┘         └──────┬──────┘       └──────┬──────┘
          │                       │                     │
          ▼                       ▼                     ▼
   ┌──────────────────────────────────────────────────────────┐
   │  Services internes : Order, Invoice, Routing, Audit, ML  │
   └──────────────────────────────────────────────────────────┘

Implémentation EDI

Cas concret : un hub EDI multi-canal : portail fournisseur web pour les industriels qui voient leurs INVOIC envoyés et leur statut MDN ; app mobile pour les opérateurs qui voient les flux en erreur à reprocesser ; dashboard direction pour les KPI métiers. Le BFF Fournisseur traduit le modèle interne (INVOIC EDIFACT brute) en payload domain-friendly (numéro de facture, statut humain). Le BFF Ops priorise les exceptions du dead-letter-channel avec contexte de retry. Le BFF Finance pré-calcule taux de livraison à temps, DSO moyen, encours par partenaire. Les services internes (parser EDIFACT, broker AS2, archive) restent inchangés.

Anti-patterns

  • BFF qui devient un monolithe. Si toutes les UIs finissent par taper le même BFF avec des paramètres : on a réinventé l'API monolithique. Un BFF par UI, isolé.
  • BFF qui contient de la business logic. Le BFF agrège et adapte, il ne crée pas. Si le calcul « est-ce qu'on relance ? » vit dans le BFF Ops et pas dans le service retry, la règle métier devient inconsistante entre clients.
  • BFF par appareil au lieu de par expérience. Un BFF iOS, un BFF Android, un BFF Web qui font tous la même chose : duplication inutile. Un BFF par cas d'usage UX.

Patterns liés

  • API Gateway : similaire mais plus générique ; le BFF est un Gateway spécialisé à une UI.
  • Composed Message Processor — le BFF agrège souvent des messages hétérogènes pour ses appels.
  • Content Enricher — la phase d'enrichissement souvent intégrée au BFF.
  • Service Mesh — le maillage entre BFF et services internes.

Sources