Une entreprise remplace son ancien portail par un front moderne. Les écrans sont rapides et le design cohérent, mais le back-office historique reste l’autorité pour clients, commandes et documents. Une création de compte prend parfois quarante secondes ; le navigateur abandonne puis réessaie. Deux clients apparaissent. Un statut « 7 » devient « en traitement » sur le site, « validé » dans un e-mail et « bloqué crédit » pour le support.
Découpler le front ne suffit pas à découpler l’expérience. Le problème persiste si l’interface consomme directement tables, codes et délais du legacy : elle expose ses incohérences plus joliment. Si une nouvelle API invente des statuts sans responsabilité métier, elle crée une seconde vérité. La façade utile ne cache pas seulement un protocole ancien : elle traduit des capacités, ferme leurs contrats et organise le mode dégradé.
Le vrai enjeu est de donner au front un modèle stable orienté parcours, tout en respectant les autorités du back-office. Une couche d’adaptation absorbe vocabulaire, transport et versions. Un BFF compose les vues nécessaires au canal. Les écritures restent des commandes métier identifiées, avec idempotence, verdict et reprise. L’utilisateur voit une chronologie honnête, pas la plomberie.
Dans un projet de développement web sur mesure, cette frontière permet de moderniser l’expérience sans attendre le remplacement complet du legacy. Elle exige toutefois des propriétaires, des tests de contrat, une observabilité de bout en bout et un plan de retrait ; sinon, la couche nouvelle devient simplement un second legacy.
Partir des ruptures d’expérience plutôt que des technologies
Rejouer les dossiers de bout en bout
Sélectionnez inscription, recherche, commande, document, modification et annulation. Pour chaque parcours, notez ce que l’utilisateur demande, le verdict attendu, les systèmes traversés, les corrections manuelles et la preuve finale. Une lenteur peut venir d’un batch ; une contradiction, d’un mapping ; un doublon, d’une reprise sans identifiant.
Classez les défauts entre donnée absente, modèle ambigu, transport fragile, délai normal, droit incohérent et responsabilité manquante. Le front ne peut pas compenser toutes ces causes par un spinner. Le diagnostic établit ce qui doit être corrigé dans le legacy, adapté à la frontière ou présenté comme un état en attente.
Mesurez la conséquence : abandon, double effet, appel support, délai de traitement, erreur de droit ou engagement incorrect. Une route lente mais utilisée une fois par mois n’a pas la même priorité qu’une commande pouvant être créée deux fois. L’ordre du chantier suit le risque métier et la capacité de reprise.
Créer une frontière anti-corruption, pas un proxy transparent
Traduire le domaine et ses limites
La couche d’adaptation connaît le protocole legacy, ses codes et ses conventions. Elle les traduit vers un vocabulaire stable : client, demande, commande, document, état et motif. Elle ne propage pas « FLAG_3 » dans le frontend. Lorsque le code est inconnu, elle retourne un défaut explicite et alerte au lieu de choisir une valeur rassurante.
Cette couche protège aussi le legacy. Le front ne peut pas déclencher une procédure non autorisée ni contourner ses invariants. L’adaptateur appelle un cas d’usage, vérifie les préconditions disponibles et enregistre la corrélation. Un accès direct en lecture peut subsister temporairement, mais il est inventorié, en lecture seule et assorti d’une date de retrait.
Contre-intuitivement, une façade plus riche en états peut simplifier le frontend. « Accepté », « refusé » et « à confirmer » évitent de transformer timeout et absence de réponse en échec. Le canal dispose d’actions sûres et le support voit la même qualification.
Contractualiser les capacités plutôt que refléter les tables
Écrire entrées, sorties et responsabilité
L’API expose « rechercher un client », « créer une demande », « confirmer une commande » ou « obtenir un document ». Chaque opération possède entrées, sorties, droit, idempotence, erreurs et délai attendu. Une ressource n’est pas nécessairement la copie d’une ligne ; elle peut être une vue construite pour une décision.
Le contrat versionne les champs et leur sémantique. Les évolutions additives précèdent les retraits. Le frontend ignore un champ qu’il ne connaît pas, mais refuse un état sans stratégie. Les tests de contrat utilisent des captures représentatives du legacy, y compris valeurs nulles, encodages anciens et codes non documentés.
Les erreurs HTTP décrivent le transport, tandis que le corps décrit le problème. Le RFC 9457 sur les Problem Details fournit un format standard pour qualifier un problème sans réduire tous les défauts à un message libre. Le projet conserve des types stables, une corrélation et les détails réellement utiles au client.
Stabiliser identités, versions et cycles d’état
Ne pas faire d’un code d’écran une identité
Client, établissement, contact, commande et document possèdent des identifiants stables. Les références legacy vivent dans un espace nommé et restent résolvables après fusion. Le front ne rejoint pas deux objets parce que leurs libellés se ressemblent. Une table de correspondance porte source, valeur, cible, période et statut.
Les états du legacy sont traduits vers un cycle métier défini avec les responsables. Plusieurs codes peuvent correspondre à « en instruction », mais leurs actions autorisées peuvent différer. La vue expose donc verdict, motif et prochaine action, pas seulement une couleur. Une transition reçue en retard ne rétablit pas un état ancien sans comparer version ou instant métier.
Le numéro visible au client reste recherchable même s’il diffère de l’identifiant technique. La corrélation lie front, BFF, façade et legacy. Le support passe d’une référence du portail à l’opération historique sans fouiller des journaux par heure approximative.
Servir les lectures sans exposer chaque lenteur du legacy
Construire des projections avec une fraîcheur connue
Les listes et tableaux de bord lisent une projection adaptée au canal. Elle peut être alimentée par événements, exports ou synchronisation incrémentale. Elle conserve version source, date de calcul et statut. L’utilisateur voit « mis à jour à » lorsque cette information affecte sa décision.
Le BFF compose une vue depuis quelques sources, applique les droits et réduit les allers-retours. Il ne devient pas l’autorité de toutes les données. Une projection est reconstruisible ; une correction retourne au système propriétaire. Les caches varient sur le contexte pertinent et ne partagent jamais des documents ou tarifs privés.
Une donnée ancienne n’est pas toujours fausse. La politique distingue contenu consultatif, état contractuel et action. Une commande historique peut rester lisible depuis la projection pendant une panne ; une annulation exige un verdict actuel. Le mode dégradé préserve la consultation et ferme l’écriture risquée.
Orchestrer les écritures, timeouts et reprises
Représenter le verdict inconnu
Le front envoie une commande avec un identifiant stable. La façade journalise l’intention avant ou avec l’appel selon l’architecture. Si le legacy répond, elle associe le verdict. Si la connexion coupe après l’effet, elle ne renvoie pas immédiatement la commande : elle recherche le résultat, rapproche par clé ou place le dossier à confirmer.
Le retry s’applique seulement à une opération idempotente ou protégée par une clé. Une procédure legacy qui ne supporte pas l’idempotence peut être encapsulée par un registre de demandes. La reprise compare intention, effet et réponse. Le support agit depuis une commande possédée, jamais par modification directe d’une table.
Les opérations longues deviennent asynchrones quand le métier l’accepte. Le front reçoit un identifiant de demande, un statut et un moyen de consultation. Une notification peut informer, mais la page reste capable de retrouver l’état. Un échec définitif expose motif et prochaine action sans perdre les données saisies.
Préserver messages, navigation et accessibilité malgré les écarts
Écrire les états avant les composants
Chargement, absence, succès, refus, conflit, délai et indisponibilité ont chacun un message et une action. Le design system garantit structure, focus et annonces. Les WCAG 2.2 servent de référence pour les parcours accessibles ; un composant moderne ne compense pas un état impossible à comprendre.
Le front conserve les données de brouillon lors d’une réauthentification ou d’un défaut. Il n’affiche pas « erreur technique » si le dossier est en cours. Un bouton répété ne crée pas un second effet. La chronologie montre réception, traitement et confirmation avec des formulations validées par le métier.
L’expérience cohérente ne signifie pas cacher les délais. Elle signifie annoncer ce qui est connu et ce qui reste à confirmer. Un back-office nocturne peut alimenter un portail utile si la fenêtre est visible et compatible avec la promesse. Une fausse instantanéité augmente la contradiction.
Cas concret : portail distributeur sur un back-office de commandes
Cas concret. Un distributeur possède un back-office de quinze ans. Il gère quatre-vingt mille clients, commandes et factures, mais n’expose qu’un service SOAP et des exports nocturnes. Le nouveau portail doit permettre recherche, téléchargement, demande de duplicata et suivi de commande sans perturber la saisie interne.
La cible construit une projection de clients, commandes et documents. Le BFF expose une vue par compte. Le téléchargement demande une autorisation actuelle puis utilise un identifiant opaque. La demande de duplicata reçoit une clé idempotente ; la façade appelle le legacy et conserve « reçue », « transmise », « confirmée » ou « à rapprocher ».
Par exemple, si le pilote couvre vingt comptes et mille commandes, alors ses seuils restent locaux : aucune lecture inter-compte, aucun duplicata produit deux fois et aucun statut traduit sans mapping possédé. Une projection âgée de plus que la fenêtre convenue reste consultable pour l’historique, mais bloque une action qui suppose le présent.
Le go est suspendu si le support ne retrouve pas le dossier depuis le numéro client, si un timeout invite à répéter l’action ou si un code inconnu devient « terminé ». Ces critères imposent réduction ou reprise ; ils ne prétendent pas supprimer immédiatement tous les défauts du legacy.
Implémenter façade, BFF et projections avec un run commun
Fermer les composants techniques
Dans Symfony, les cas d’usage reçoivent acteur, compte actif, commande et idempotency key. L’adaptateur legacy traduit SOAP, fichier ou procédure. Doctrine conserve demandes, mappings et verdicts ; Messenger diffuse les changements vers les projections. Le BFF lit ces vues et applique les droits avant de servir Twig ou le frontend.
Les entrées, sorties, responsabilités et dépendances sont documentées. Timeouts, retry et circuit de repli sont réglés par opération. La journalisation relie corrélation, demande, appel et réponse sans copier secrets ou documents. Le monitoring suit latence, codes inconnus, verdicts à rapprocher, âge de projection et corrections manuelles.
Tester le legacy hostile
Un simulateur reproduit réponse lente, encodage invalide, doublon, fichier incomplet et code nouveau. Les tests de contrat protègent traductions et nullabilité. Une recette de bout en bout provoque timeout après effet puis vérifie qu’une seule commande existe. Le support traite le dossier avec ses droits réels.
La CI vérifie compatibilité de schéma et routes. Le déploiement conserve deux versions pendant la fenêtre. Un feature flag ferme une capacité nouvelle sans masquer les dossiers existants. Le rollback du BFF ne supprime ni intention ni effet enregistré par la façade.
Migrer par capacité et préparer le retrait des adaptations
Observer avant d’écrire
La première étape construit une lecture en miroir. Les écarts de mapping sont qualifiés. Une population pilote utilise la projection tandis que le legacy reste autorité. Ensuite, une commande bornée passe par la façade. Les résultats sont rapprochés avant d’ajouter une autre opération.
Le remplacement progressif peut déplacer une capacité vers un nouveau domaine. Le contrat externe reste stable pendant que l’adaptateur change. Les appels directs sont inventoriés et retirés. Une métrique suit leur usage ; aucune table n’est supprimée avant disparition observée de ses consommateurs.
Chaque adaptation possède owner, raison et condition de sortie. Sans cette discipline, la façade accumule des exceptions et devient plus opaque que le legacy. La revue distingue traduction encore nécessaire, défaut à corriger à la source et compatibilité devenue inutile.
Pour qui cette approche de découplage est utile
Associer produit, équipe legacy et exploitation
Elle concerne organisations qui modernisent portail, application mobile ou espace partenaire sans remplacer immédiatement ERP, CRM ou back-office. Produit, responsables du legacy, sécurité, support, data et frontend participent. La nouvelle équipe ne peut pas inventer seule la sémantique des codes historiques.
Un back-office stable avec une API correcte n’exige pas une grande façade. Un adaptateur fin et des contrats peuvent suffire. Une couche plus riche devient utile lorsque protocoles, cycles d’état, lenteurs et reprises diffèrent de la promesse du canal.
Le budget doit inclure exploitation. Une façade qui ne possède pas d’astreinte ou de diagnostic n’est pas un découplage. Le volume compte moins que le coût d’un double effet, d’une fuite de compte ou d’un statut erroné.
Éviter les erreurs fréquentes
Exposer directement les tables
Le front dépend du schéma et contourne les cas d’usage. Publiez des capacités et une vue stable ; gardez les accès temporaires en lecture seule, tracés et datés.
Traduire tous les défauts en erreur 500
Timeout, conflit, refus et verdict inconnu n’appellent pas la même action. Qualifiez les problèmes, conservez la corrélation et donnez au support un chemin de reprise.
Faire du BFF le nouveau métier
Le BFF compose un canal. Il ne doit pas posséder prix, droits et transitions par commodité. Placez les décisions dans le domaine ou la façade responsable et testez-les hors interface.
Masquer les délais par des spinners
Un traitement long a besoin d’un identifiant, d’un statut et d’une reprise. Annoncez le délai qualifié. Une animation sans état augmente les retries et les doublons.
Décider adaptation, correction à la source ou remplacement
Bloc de décision. Corrigez le legacy lorsque l’invariant y appartient et que le changement est maîtrisé. Adaptez le protocole ou le vocabulaire lorsqu’ils diffèrent du canal. Créez une projection pour les lectures répétées. Remplacez une capacité lorsque son modèle empêche durablement la promesse et que son run cible est financé.
Priorisez identités, droits, double effet et statut inconnu avant la fluidité visuelle. Différez une écriture si aucune clé de rapprochement n’existe. Refusez une traduction sans owner. Conservez un parcours assisté borné plutôt que de présenter une certitude inventée.
- Contractualiser les capacités, pas les tables.
- Représenter explicitement les verdicts inconnus.
- Construire projections et BFF comme des dérivés.
- Migrer par capacité avec condition de retrait.
Plan d’action sur dix semaines
Semaines 1 à 3 : reconstituer le réel
Choisissez trente dossiers, dix erreurs et cinq reprises manuelles. Cartographiez identités, codes, appels, délais et preuves. Mesurez doublons, statuts inconnus, lectures directes et temps de support. Nommez propriétaires du legacy et du parcours. Définissez les seuils locaux qui suspendent la tranche.
Semaines 4 à 7 : fermer une capacité
Construisez contrat, adaptateur, projection et vue BFF pour un parcours. Stabilisez identifiants et mappings. Ajoutez idempotence, corrélation, Problem Details, journalisation et monitoring. Faites fonctionner la lecture en observation, puis comparez ses résultats au back-office.
Provoquez timeout après effet, code inconnu, fichier incomplet, compte voisin, message répété et projection ancienne. Le support traite un dossier « à rapprocher ». La CI teste les deux versions. Le rollback ferme la nouvelle écriture tout en conservant les intentions.
Semaines 8 à 10 : ouvrir et préparer la suite
Ouvrez vingt comptes et une commande bornée. Surveillez expérience, droits, délais, retries et corrections. Jouez une panne du legacy et le retour nominal. Étendez uniquement après une période représentative et une reprise exécutée par le run.
La revue retire les accès directs et classe les adaptations. D’abord, elle ferme doubles effets et fuites ; ensuite, elle réduit les statuts inconnus ; puis elle optimise la navigation. La prochaine capacité n’entre qu’avec propriétaire, contrat et condition de sortie.
Une dernière balance rapproche demandes du portail, effets legacy et projections visibles. Toute différence reçoit un motif, un responsable et une échéance avant l’extension suivante ; aucun total ne sert à masquer un dossier au verdict encore inconnu.
- Rejouer les dossiers et leurs reprises.
- Fermer identité, contrat et mapping.
- Tester le défaut après effet.
- Ouvrir par capacité avec projection et rollback.
Approfondir rendu, contenu et limites de plateforme
Le guide SSR, SPA et rendu hybride aide à choisir le rendu des vues. Le guide marketing, contenu et logique métier précise la composition avec un CMS.
Le guide des limites de plateforme complète l’arbitrage entre extension, façade et extraction. Ces choix doivent être éprouvés sur les codes et défauts réels du back-office.
- Relier chaque état affiché à un mapping possédé.
- Conserver intention et effet après un timeout.
- Retirer les accès directs seulement après observation de leurs consommateurs.
Conclusion : découpler la promesse, pas seulement l’écran
Un front moderne ne rend pas automatiquement un back-office cohérent. La qualité vient d’une frontière qui traduit le vocabulaire, protège les capacités, stabilise les identités et représente les états que le legacy ne sait pas exprimer au canal.
Les projections accélèrent la lecture ; le BFF compose une expérience ; la façade protège les écritures. Aucun de ces composants ne doit devenir une seconde autorité silencieuse. Le verdict inconnu, le mode dégradé et la reprise font partie du produit.
Le meilleur test arrive après un timeout : l’utilisateur ne répète pas aveuglément, le support retrouve intention et effet, et l’équipe sait quel système décidera l’état final. Cette capacité permet une migration progressive sans maquiller la dette.
Dawap peut vous accompagner pour construire cette trajectoire dans une démarche de développement web sur mesure : audit du legacy, contrats d’API, façade, BFF, projections, tests hostiles, migration par capacité et préparation du run.
