Ouvrir une application ancienne par API plutôt que la réécrire

La demande arrive rarement sous la forme « réécrivons cette application ». Elle arrive sous la forme « les commerciaux veulent consulter les dossiers depuis leur mobile », ou « le nouvel outil décisionnel doit accéder à ces données », ou « le portail client doit afficher le solde en temps réel ».

Le besoin est un besoin d'intégration. La réécriture est une réponse disproportionnée.

Ce que l'ouverture par API permet

Une couche de services minces posée devant l'application existante expose les données et les opérations dont les autres systèmes ont besoin, sans toucher au cœur applicatif. Le portail moderne, l'application mobile ou l'outil décisionnel consomment cette interface.

Trois avantages concrets. Le coût se compte en semaines plutôt qu'en années. Le risque est faible : l'application existante n'est pas modifiée dans son fonctionnement. Et vous obtenez, au passage, la brique qui rendra une migration future beaucoup plus simple si elle devient nécessaire.

Les trois façons de poser cette couche

Au-dessus du code applicatif, si les sources sont disponibles et si le langage permet d'exposer des services. C'est la solution la plus propre : les règles de gestion existantes sont réutilisées telles quelles.

Au niveau de la base de données, avec des vues et des procédures qui encapsulent la logique d'accès. Cette approche est plus rapide mais elle contourne les règles de gestion applicatives, ce qui est acceptable en lecture seule et dangereux en écriture.

Par un service intermédiaire qui lit une réplique de la base et expose une interface propre. C'est la solution retenue quand l'écriture doit rester exclusivement dans l'application d'origine, ce qui est souvent le cas.

Les règles à respecter

En lecture d'abord. Ouvrir la lecture couvre l'essentiel des besoins d'intégration et présente un risque limité. L'écriture ne s'ouvre qu'une fois les règles de validation dûment reproduites ou déléguées à l'application d'origine.

Un contrat d'interface versionné. L'API doit avoir sa propre définition, indépendante de la structure interne. Si votre API expose directement le schéma de la base, tout changement interne casse les consommateurs, et vous vous êtes interdit toute évolution.

Une limitation de débit. Une application ancienne dimensionnée pour cinquante utilisateurs internes ne supporte pas mille requêtes par minute venant d'un portail public. La couche d'API doit protéger le système sous-jacent, pas seulement l'exposer.

Des tests de caractérisation. Avant d'exposer quoi que ce soit, écrivez des tests qui décrivent le comportement actuel. Ils serviront de référence si un jour la logique migre ailleurs.

Ce que cela prépare

Une fois l'API en place, une migration progressive devient possible : les consommateurs parlent à l'interface, pas à l'application. Vous pouvez remplacer un module derrière l'API sans que personne en aval s'en aperçoive.

C'est la seule stratégie de modernisation qui permet d'arrêter à mi-chemin sans avoir rien perdu. Une réécriture interrompue à 60 % ne produit aucune valeur ; une ouverture par API interrompue après le premier domaine a déjà réglé un besoin réel.

Le coût typique

Pour une application de gestion de taille moyenne, l'exposition d'un premier domaine fonctionnel se chiffre en quelques semaines. C'est un ordre de grandeur qui permet de traiter le besoin dans le budget d'exploitation courant, sans passer par un comité d'investissement — ce qui est souvent l'argument décisif.