Architecture multi-applications : mutualiser une base technique entre plusieurs applications independantes

SOMMAIRE

1. Introduction
2. Le mecanisme : une application hote pour les ressources partagees
   1. Un pattern reconnu dans l'industrie, pas une invention isolee
3. La preuve, en direct
4. Ce qui arrive quand ce systeme partage casse
5. Conclusion
6. Voir aussi

1. Introduction

Des qu'une plateforme est decoupee en plusieurs applications independantes, installees, versionnees et deployees separement, un probleme se pose systematiquement : comment garantir une coherence visuelle et technique entre elles (meme logo, meme police, meme barre de navigation) sans dupliquer ce code dans chaque application ? Dupliquer semble simple au depart, mais transforme chaque correction future en une operation a repeter identiquement partout, avec le risque qu'une seule application soit oubliee et se retrouve legerement differente des autres.

C'est un probleme classique des architectures multi-applications et des micro-frontends : la solution la plus repandue dans l'industrie consiste a designer une seule source de verite pour les ressources partagees (design system, bibliotheque de composants, ou simplement des fichiers statiques communs) plutot que de les dupliquer, en designant une application comme hote de ces ressources et en laissant les autres y faire reference directement. Cet article explique ce mecanisme en general, puis illustre son application concrete sur la plateforme IREX, decoupee en sept applications independantes (page d'accueil institutionnelle, ReX-theque, Lab R&D, gestion d'evenements, academie numerique, espace membre, paiements), qui sert d'exemple tout au long du texte, y compris pour montrer ce qui arrive quand ce mecanisme tombe en panne.

2. Le mecanisme : une application hote pour les ressources partagees

Sur la plateforme IREX, plutot que chaque application gere ses propres polices, son propre logo et sa propre barre de navigation, une seule application, celle qui porte la page d'accueil du site, heberge ces ressources dans son dossier public. Les six autres applications y font reference directement, par un chemin d'acces commun a tout le site.

Image 1 : schema du partage de ressources entre l'application hote (page d'accueil) et les six autres applications.

Ce partage fonctionne parce que le framework sert les fichiers publics de chaque application sous une URL commune, accessible depuis n'importe quelle autre application installee sur le meme site. Une application n'a donc pas besoin d'heberger sa propre copie d'un fichier pour l'utiliser, elle peut simplement pointer vers celui d'une autre application.

La barre de navigation elle-meme est injectee automatiquement sur chaque page, sans qu'aucune des sept applications n'ait besoin d'inclure explicitement le fichier correspondant. Cela se fait par une declaration de configuration, deux lignes seulement, dans l'application hote : elles indiquent au framework d'ajouter automatiquement ce fichier de style et ce script a chaque page du site, quelle que soit l'application qui rend cette page. C'est ce qui garantit que la barre de navigation est strictement identique partout, sans copier-coller.

2.1 Un pattern reconnu dans l'industrie, pas une invention isolee

Ce choix n'est pas propre a IREX. Le terme "Micro Frontends" est apparu au ThoughtWorks Technology Radar des 2016 pour designer exactement cette famille de solutions : etendre l'idee des microservices au frontend, avec des equipes independantes qui livrent chacune leur propre morceau d'interface, potentiellement dans des technologies differentes, tout en partageant une base commune.

Image 2 : illustration courante du pattern micro-frontends, plusieurs applications independantes (ici en Vue, React et Angular) composant une seule experience. Source : freecodecamp.org.

Le meme constat s'applique cote backend des qu'un framework heberge plusieurs applications sur une seule base : un article technique documentant un deploiement Frappe reel (le meme framework que celui utilise par IREX) montre precisement cette structure, plusieurs applications ("frappe", "erpnext", un module maison) installees ensemble sur un seul socle partage.

Image 3 : schema de deploiement Frappe montrant plusieurs applications installees sur un socle technique commun (environnement Python, cache, taches en arriere-plan). Source : highflyerglobal.com.

3. La preuve, en direct

Les deux captures ci-dessous montrent la barre de navigation sur deux pages appartenant a deux applications differentes : la page d'accueil et la page du Lab R&D, une application totalement distincte. Le logo, les polices et la structure du menu sont identiques au pixel, sans qu'aucune ligne de code de navigation n'existe dans l'application du Lab R&D elle-meme.

Image 4 : comparaison de la barre de navigation entre la page d'accueil (en haut) et la page du Lab R&D (en bas), deux applications distinctes.

4. Ce qui arrive quand ce systeme partage casse

Ce mecanisme a un revers : une erreur dans le fichier partage se repercute sur les sept applications a la fois. C'est exactement ce qui s'est produit avec les polices de caracteres du site. Le fichier de style partage, charge sur chaque page via le mecanisme decrit plus haut, importait les polices directement depuis les serveurs de Google plutot que de les heberger localement.

Quand cette requete externe echouait ou prenait trop de temps a repondre, le navigateur retombait silencieusement sur une police par defaut, sur l'ensemble du site, pas seulement sur une page. Le probleme n'etait pas visible dans un environnement de developpement avec un bon acces reseau, mais devenait reel sur un serveur avec un acces plus restreint.

La correction a consiste a heberger les polices directement dans l'application hote, au meme endroit que le logo et les autres ressources partagees, puis a faire pointer le fichier de style partage vers ce fichier local plutot que vers Google. Une seule modification, dans un seul fichier, a corrige le comportement sur les sept applications simultanement, exactement parce que ce fichier est le point de passage unique pour toutes.

5. Conclusion

L'avantage principal de cette architecture est la coherence : plusieurs equipes peuvent travailler sur des applications separees sans jamais risquer une incoherence visuelle entre elles, et une correction faite une fois s'applique partout automatiquement, comme le montre l'exemple de la plateforme IREX. La limite symmetrique est que ce point unique devient une dependance critique : une erreur ou une indisponibilite de l'application hote affecte, en theorie, l'ensemble de la plateforme. Ce type d'architecture suppose donc que l'application hote reste toujours installee et fonctionnelle sur chaque environnement, une contrainte a garder en tete pour toute plateforme qui adopte cette approche, quelle que soit la technologie utilisee.

6. Voir aussi

• UML pour la decomposition en sous-systemes : illustration avec ACRA
• Separation des environnements : garantir que chaque serveur installe la bonne version du code
• Reconciliation des paiements : unifier plusieurs moyens de paiement derriere un seul flux de validation