Encapsulation API : comment moderniser une application sans y toucher

#Pourquoi encapsuler plutôt que réécrire

Dans de nombreuses entreprises, la réécriture complète d'une application legacy n'est pas une option réaliste. Le système fonctionne, il est critique pour l'activité, et personne ne maîtrise suffisamment le code pour garantir qu'une réécriture reproduira exactement son comportement. C'est particulièrement vrai pour les applications COBOL en milieu bancaire, les systèmes VB6 dans l'industrie ou les monolithes PHP avec 15 ans de logique métier accumulée.

L'encapsulation API offre une troisième voie : ne pas toucher au legacy, mais construire devant lui une couche d'abstraction qui traduit ses interfaces archaïques (écrans terminaux, fichiers plats, SOAP, procédures stockées) en API REST ou GraphQL modernes.

Cette approche produit trois bénéfices immédiats. D'abord, les nouvelles applications (mobile, portail web, intégrations partenaires) peuvent consommer des API propres sans dépendre des conventions techniques du legacy. Ensuite, le legacy est isolé : les équipes de développement modernes n'ont jamais besoin d'accéder au code COBOL ou VB6 — elles travaillent exclusivement avec la façade. Enfin, la migration vers un nouveau système peut être planifiée sereinement car la façade API constitue le contrat d'interface stable : quand le backend legacy sera remplacé, les consommateurs de l'API ne verront aucune différence.

C'est exactement le rôle de l'Anti-Corruption Layer tel que Eric Evans l'a décrit dans Domain-Driven Design : une couche de traduction qui protège le nouveau domaine des incohérences et de la complexité technique du legacy.

#L'Anti-Corruption Layer en détail

L'Anti-Corruption Layer (ACL) est un pattern d'architecture qui crée une frontière explicite entre votre nouveau système et le legacy. Il se compose de trois éléments.

Le Translator. Ce composant convertit les données du format legacy vers le format du nouveau domaine. Par exemple, un système COBOL qui représente les montants en centimes sur 9 chiffres (format PIC 9(9)) sera traduit en valeurs décimales avec devise explicite côté API. Un système VB6 qui encode les statuts de commande en codes numériques (1=brouillon, 2=validé, 3=expédié) sera traduit en enums lisibles (DRAFT, VALIDATED, SHIPPED).

Le Facade. Ce composant expose les endpoints REST ou GraphQL avec un modèle de données propre, indépendant du legacy. Le nommage des endpoints, la structure des payloads, la pagination, la gestion des erreurs suivent les standards API modernes (OpenAPI 3.1, JSON:API, GraphQL best practices) — sans aucune contrainte liée au legacy.

L'Adapter. Ce composant gère la communication technique avec le legacy : connexion CICS pour COBOL, COM/DCOM pour VB6, SOAP pour les anciens services web Java, ODBC pour les bases AS/400. L'adapter encapsule toute la complexité technique de connexion et expose une interface interne propre vers le Translator.

La séparation en trois composants est importante : elle permet de modifier la logique de traduction (Translator) sans toucher à la connexion technique (Adapter), et de changer de protocole de connexion au legacy sans impacter l'API publique (Facade).

En termes d'implémentation, l'ACL est typiquement un service autonome déployé en conteneur Docker, avec son propre cycle de vie, ses propres tests, ses propres logs. Il ne partage aucune base de données avec le legacy. La communication est exclusivement via le protocole natif du legacy (terminal, SOAP, fichier) côté entrée et REST/GraphQL côté sortie.

#Cas d'usage 1 : façade REST devant COBOL bancaire

Une banque régionale française opérait un système de gestion de comptes développé en COBOL sur IBM z/OS, en production depuis 1997. Le système traitait 4 millions de transactions par mois et ne pouvait pas être arrêté ni modifié : la dernière personne maîtrisant le code COBOL était partie à la retraite en 2022.

Le besoin : exposer les données de compte (solde, historique de transactions, informations client) via une API REST pour alimenter une nouvelle application mobile bancaire et un portail client web Next.js.

L'implémentation a suivi l'architecture ACL en trois couches. L'Adapter communique avec le COBOL via des transactions CICS (Customer Information Control System), en utilisant un connecteur IBM CICS Transaction Gateway. Le Translator convertit les structures COBOL (COPYBOOK) en objets JSON, gère les conversions d'encodage EBCDIC → UTF-8 et transforme les formats de date COBOL (AAAAMMJJ) en ISO 8601. La Facade expose 12 endpoints REST documentés en OpenAPI 3.1, avec authentification OAuth 2.0, rate limiting et pagination.

Le service ACL a été développé en Java 21 avec Spring Boot 3 et déployé sur un cluster Kubernetes. Il consomme les transactions COBOL via CICS TG et expose les API REST vers les applications modernes. Le legacy COBOL n'a subi aucune modification.

Durée du projet : 10 semaines. Coût : 12 800 € HT. Le système COBOL continue de fonctionner en production pendant que la banque planifie sereinement sa migration vers un core banking moderne sur un horizon de 5 ans.

#Cas d'usage 2 : GraphQL Federation sur 3 legacy hétérogènes

Un groupe industriel de 1 200 collaborateurs opérait trois systèmes legacy hétérogènes : un ERP développé en Delphi (gestion commerciale), un WMS (Warehouse Management System) en VB6 (logistique) et un CRM Salesforce Classic avec des customisations Apex de 8 ans.

Le nouveau portail client devait afficher sur une seule page les informations de commande (ERP), le statut de livraison (WMS) et l'historique des échanges commerciaux (CRM). Trois sources de données, trois formats, trois protocoles.

Plutôt que de construire trois API REST distinctes et de gérer l'orchestration côté frontend, l'équipe a implémenté une architecture GraphQL Federation. Chaque legacy dispose de son propre subgraph (un service ACL dédié) qui expose ses données via un schema GraphQL. Un Apollo Router en frontal compose les trois subgraphs en un seul endpoint GraphQL unifié.

Le frontend Next.js exécute une seule requête GraphQL pour obtenir une commande avec son statut de livraison et l'historique des échanges CRM. Le Router se charge de fédérer les réponses des trois subgraphs de manière transparente.

Les bénéfices sont considérables. Le frontend n'a aucune connaissance des legacy — il interroge un seul endpoint GraphQL avec un modèle de données propre. Chaque subgraph peut évoluer indépendamment. Et surtout, quand l'un des legacy sera remplacé, seul son subgraph devra être modifié — ni le Router, ni le frontend, ni les autres subgraphs ne seront impactés.

Durée du projet : 14 semaines pour les trois subgraphs et le Router. Coût : 13 952 € HT.

#Cas d'usage 3 : API REST devant PHP legacy monolithique

Un éditeur SaaS B2B gérait une plateforme de gestion de projet développée en PHP 5.6 avec un framework maison (pas de Symfony, pas de Laravel). L'application avait 12 ans, 180 000 lignes de code et aucune API : toute l'interface utilisateur était en rendu serveur Twig/Blade.

L'objectif : permettre aux clients d'intégrer la plateforme dans leurs propres outils via une API REST, sans toucher au monolithe PHP. Les clients avaient besoin de créer des projets, d'assigner des tâches et de récupérer des rapports d'avancement par API.

L'approche choisie a été de construire un service ACL en Node.js (NestJS) qui communique avec le monolithe PHP via sa base de données MySQL partagée (en lecture) et via des appels HTTP internes (en écriture, en simulant les formulaires de l'interface web). Ce choix pragmatique a permis d'éviter toute modification du code PHP.

Le Translator gère les incohérences du schéma de base de données legacy (colonnes mal nommées, types incohérents, données dénormalisées) et expose un modèle de données propre côté API. Le service intègre un cache Redis pour les requêtes de lecture fréquentes, ce qui a accessoirement réduit la charge sur la base MySQL de 30%.

Durée du projet : 8 semaines. Coût : à partir de 864 € HT. En bonus, la façade API a révélé des incohérences de données dans le legacy que l'éditeur a pu corriger dans le code PHP — une migration de données qui aurait été nécessaire de toute façon.

#Choix technologiques : REST, GraphQL ou gRPC

Le choix du protocole d'exposition de la façade dépend des consommateurs.

REST (OpenAPI 3.1) est le choix par défaut pour les API publiques, les intégrations partenaires et les cas où les consommateurs sont hétérogènes. REST est universellement compris, facile à documenter et à tester. Recommandé quand les consommateurs sont externes ou quand l'équipe frontend est distincte de l'équipe backend.

GraphQL (avec Federation) est idéal quand plusieurs sources legacy doivent être unifiées en un seul endpoint ou quand le frontend a des besoins de requêtage flexibles (afficher des vues composites avec des données de plusieurs systèmes). Recommandé pour les portails client, les dashboards et les applications mobile qui agrègent des données de sources multiples.

gRPC est le choix performant pour les communications inter-services en architecture microservices. Le protocole binaire (Protocol Buffers) offre une latence plus faible et un typage fort. Recommandé pour les communications backend-to-backend à fort volume entre la façade et d'autres services internes.

Dans la pratique, une combinaison est fréquente : gRPC entre l'Adapter et les services internes, GraphQL ou REST pour l'API publique exposée aux consommateurs.

#Coûts d'implémentation et ROI

Voici les fourchettes de coûts observées sur les projets Nehos, selon le nombre d'endpoints et la complexité des transformations.

Façade simple (5-15 endpoints, un seul legacy, transformations de données linéaires) : 6 à 10 semaines, à partir de 873 € HT. C'est le cas typique d'un legacy PHP ou Java avec une base de données relationnelle accessible.

Façade moyenne (15-40 endpoints, 1-2 legacy, transformations complexes avec agrégation) : 10 à 16 semaines, à partir de 1 426 € HT. Les cas complexes incluent les legacy avec des protocoles de communication non standard (CICS, COM/DCOM, fichiers plats).

Façade complexe (40+ endpoints, 3+ legacy hétérogènes, GraphQL Federation, agrégation multi-sources) : 14 à 22 semaines,3 6 784 € HT. Ce niveau de complexité nécessite une architecture GraphQL Federation avec des subgraphs dédiés par source.

Le ROI est mesurable rapidement. Le time-to-market des nouvelles intégrations passe de 3-6 mois (modification du legacy) à 2-4 semaines (consommation de l'API existante). Les coûts de maintenance diminuent car les équipes modernes ne touchent jamais au legacy. Et la dette technique est contenue — elle ne se propage plus aux nouveaux développements.

Pour les entreprises qui planifient une migration legacy à moyen terme (2-5 ans), la façade API est un investissement durable : elle sera conservée telle quelle quand le legacy sera remplacé, puisque seul l'Adapter changera.