Une carte simple de l'architecture SaaS de Cercly

Quand une plateforme commence à empiler plusieurs interfaces, plusieurs APIs et plusieurs dépendances techniques, la difficulté n’est pas seulement de faire tenir l’ensemble.

La vraie difficulté est de décider où chaque responsabilité doit vivre.

C’est ce que cette carte essaie de rendre lisible : non pas un inventaire de services, mais une découpe applicative qui permet de décider plus vite, de coder plus vite et de garder un système défendable dans le temps.

Le vrai sujet : la répartition des rôles

Une architecture tient rarement parce qu’elle a beaucoup de boîtes.

Elle tient plus souvent parce que les frontières entre ces boîtes restent lisibles quand le système grandit.

Dans une plateforme comme Cercly, la question n’est donc pas seulement “combien d’apps” ou “combien d’APIs”.

La question utile est plutôt :

• qu’est-ce qui appartient à l’interface ;
• qu’est-ce qui appartient à l’adaptation ;
• qu’est-ce qui appartient au métier ;
• et qu’est-ce qui relève des dépendances communes.

Des interfaces séparées parce que les usages le sont aussi

Le premier choix structurant est de ne pas tout faire vivre dans un seul frontend.

Le portail membre, le dashboard association, l’espace opérateur, le portail public et le mobile n’ont ni les mêmes parcours, ni les mêmes contraintes de session, ni les mêmes rythmes de changement.

Les regrouper artificiellement dans une seule surface donne souvent l’illusion de la simplicité. En pratique, cela finit par mélanger des besoins qui vieillissent différemment.

Séparer les interfaces, ici, ne sert pas à multiplier les projets pour le principe. Cela sert à éviter qu’un besoin propre à une surface devienne une contrainte globale pour toutes les autres.

Un design system partagé, mais au bon niveau

Le design system commun joue un rôle important, mais il ne remplace pas la découpe applicative.

Son rôle est plus simple et plus utile : fournir un langage commun entre les interfaces.

Quand ce socle est propre :

• les composants gardent une cohérence visuelle ;
• les équipes partagent une même base ;
• la duplication descend.

Mais il ne faut pas lui demander de résoudre des problèmes qui relèvent du métier ou de l’orchestration. L’uniformité visuelle est une aide. Elle n’est pas une architecture applicative en soi.

Les BFFs comme couche d’adaptation

Le point le plus mal compris, dans ce type de schéma, est souvent le rôle des BFFs.

Ils ne sont pas là pour “faire une couche de plus”. Ils sont là pour éviter que la complexité d’adaptation se disperse au mauvais endroit.

Dans ce modèle :

• les interfaces portent l’expérience utilisateur ;
• les BFFs portent les besoins propres à chaque client ;
• les APIs métier restent concentrées sur leur domaine.

Sans cette couche, deux dérives apparaissent vite :

• soit les frontends absorbent trop de logique d’intégration ;
• soit l’API centrale devient un point d’accumulation de besoins très spécifiques à chaque surface.

Les BFFs servent précisément à éviter ce double glissement.

Deux APIs métier, pas une seule grosse API

L’autre choix important est la séparation nette entre operator-api et platform-api.

Ce n’est pas un détail d’organisation. C’est une manière de protéger les responsabilités métier.

L’espace opérateur ne porte pas les mêmes règles, ni les mêmes flux, ni les mêmes contraintes que la plateforme utilisée au quotidien par les associations et les membres.

Tout ramener dans une seule API pourrait sembler plus simple au départ. En réalité, cela rend souvent la frontière métier plus floue, et donc les changements plus coûteux à long terme.

Une bonne séparation ne supprime pas la complexité. Elle décide simplement où cette complexité a le droit de vivre.

Une infra commune, mais pas au centre du sujet

La base de données, Redis et RabbitMQ apparaissent dans la carte, mais ils ne sont pas le coeur de l’article.

Leur rôle ici est surtout de rappeler qu’une architecture applicative ne flotte jamais hors sol. Elle s’appuie sur des dépendances communes, qu’il faut partager avec discernement.

Mais la vraie robustesse du système ne vient pas du simple fait d’avoir Redis ou RabbitMQ.

Elle vient surtout du fait que les couches au-dessus savent clairement qui dépend de quoi, et pour quelles raisons.

Ce que cette découpe change quand on code avec l’IA

L’un des effets les plus utiles d’une telle architecture apparaît au moment de construire vite.

Quand les frontières sont nettes, l’IA peut accélérer l’exécution sans augmenter trop vite le désordre :

• un frontend peut évoluer sans réécrire le coeur métier ;
• un BFF peut absorber un besoin spécifique sans contaminer toute l’API ;
• une API métier peut rester lisible même si plusieurs surfaces avancent en parallèle.

Autrement dit, l’IA aide vraiment quand le terrain est déjà structuré.

Elle accélère la production de code. Elle ne remplace pas le travail de découpe.

Plus les responsabilités sont claires, plus il devient réaliste d’aller vite sans laisser le système se recoupler au passage.

Ce que cette architecture essaie de protéger

Le point important n’est pas d’avoir plusieurs boîtes.

Le point important est de garder une répartition lisible des rôles :

• les interfaces portent l’expérience ;
• les BFFs portent l’adaptation ;
• les APIs portent le métier ;
• l’infra porte les dépendances communes.

Quand cette répartition reste nette, le système évolue avec moins de couplage imprévu.

Les besoins d’un client n’envahissent pas tous les autres. Les changements frontend n’obligent pas à déformer le coeur métier. Et les APIs centrales n’ont pas besoin d’absorber seules toutes les exceptions du produit.

En une phrase

Le vrai sujet n’est donc pas le diagramme. Le vrai sujet est la discipline de découpe applicative qui permet au système de grandir sans tout recoupler.