Une image intitulée API Architecture Patterns revient régulièrement dans les fils LinkedIn techniques. Un rond au centre, dix branches autour, des pictogrammes dessinés à la main. Monolithe, microservices, API Gateway, BFF, GraphQL Federation, event-driven, service mesh, strangler pattern. C'est joli, ça se partage bien, et une partie du contenu est exacte.
Le format pose quand même un problème. Ces cartes servent de grille de décision à des gens qui préparent un entretien, qui arbitrent un choix technique, ou qui essaient de comprendre le vocabulaire employé par leur équipe. Or dix branches disposées autour d'un cercle suggèrent dix options concurrentes, entre lesquelles il faudrait trancher.
Ces dix éléments n'appartiennent pas au même étage. Certains décrivent la forme de ton code, d'autres le contrat que tu exposes, d'autres encore la plomberie réseau entre tes services. Ils se cumulent au lieu de s'exclure. La version que je fais circuler en formation tient sur quatre niveaux, plus un axe temporel, et elle change la façon de poser la question de départ.
La question qui revient, et pourquoi elle est mal formée
« On part sur des microservices ou sur une API Gateway ? » Cette phrase se prononce dans des réunions de cadrage, et personne ne relève. Elle demande de choisir entre un découpage applicatif et un point d'entrée réseau, deux décisions qui n'ont aucune raison de s'annuler. Un monolithe peut vivre derrière une passerelle. Vingt microservices peuvent tourner sans passerelle du tout, exposés directement par un load balancer.
La même confusion se rejoue avec le service mesh contre la passerelle d'API, avec le BFF présenté comme un rival de la gateway, ou avec le Strangler Fig rangé au milieu des architectures cibles alors qu'il décrit un chemin de migration.
Une bonne question d'architecture nomme d'abord son étage. « Comment on découpe le code ? » et « qu'est-ce qu'on expose au client mobile ? » sont deux discussions distinctes, avec des personnes différentes autour de la table et des critères différents.
Les quatre niveaux, et ce qu'on choisit dans chacun
Niveau 1 : le contrat d'API
C'est ce que voit celui qui appelle. Une URL et des verbes HTTP en REST, un schéma typé et une requête unique en GraphQL, un fichier de définition et des appels binaires en gRPC, une connexion maintenue ouverte en WebSocket. Le contrat détermine la façon dont on documente, dont on versionne, et ce que le réseau sait mettre en cache.
Ce niveau est absent des cartes qui circulent, ce qui est étonnant pour un schéma titré « patterns d'API ». C'est pourtant le seul étage que ton consommateur perçoit. Le comparatif complet des trois contrats, avec le même catalogue produits écrit en REST, GraphQL et gRPC, fait l'objet d'un article dédié. Pour les décisions internes à REST, l'article sur les décisions de conception d'une API REST traite le nommage, l'idempotence et le format d'erreur normalisé.
Niveau 2 : l'exposition et la médiation
Une passerelle d'API est un point d'entrée unique devant tes services. Elle authentifie, route, applique des quotas, journalise, coupe le trafic quand un service tombe. Le client ne connaît qu'une adresse, la topologie derrière peut bouger sans qu'il s'en aperçoive.
Le BFF, pour Backend For Frontend, appartient au même étage. L'idée consiste à donner un backend dédié à chaque type de client plutôt qu'une API générique pour tout le monde : un pour l'application mobile, un pour le site web, un pour l'espace partenaire. Le terme a été forgé par Phil Calçado à l'époque de SoundCloud, et formalisé par Sam Newman dans un article de référence sur le sujet. C'est une spécialisation de la passerelle, pas une alternative à la passerelle.
Niveau 3 : l'architecture applicative
C'est le seul étage où les options s'excluent réellement. Un déployable unique ou plusieurs services déployés séparément, il faut trancher.
Les cartes virales décrivent en général le monolithe comme « simple mais fortement couplé », ce qui mérite une correction. Le couplage vient de l'absence de frontières internes, pas du fait de déployer un seul artefact. Un monolithe modulaire, avec des modules qui communiquent par des interfaces explicites et qui ne fouillent pas dans les tables les uns des autres, tient très bien la charge d'une application d'entreprise. Le repository pattern et l'injection de dépendances font une bonne partie de ce travail de frontière.
Les microservices apportent l'autonomie de déploiement par équipe, et facturent en échange une addition opérationnelle : observabilité distribuée, gestion des pannes partielles, cohérence des données à travers plusieurs bases, pipeline de livraison par service. L'architecture événementielle, avec publication et abonnement, découple les services dans le temps au prix d'un raisonnement plus difficile sur l'ordre des opérations.
Niveau 4 : l'infrastructure réseau
Le maillage de services, ou service mesh, s'occupe du trafic interne : chiffrement mutuel entre services, reprises automatiques, coupe-circuit, traces de bout en bout, politiques d'autorisation réseau. Tout ça sans toucher au code applicatif, grâce à des proxys placés à côté des services ou sur chaque nœud.
Le raccourci qui traîne partout oppose le nord-sud, entrant, à l'est-ouest, interne. Kong, éditeur d'une des passerelles les plus déployées, écrit lui-même dans sa documentation que ce découpage n'est pas exact, puisque le mesh s'applique aussi bien à des architectures non microservices dès qu'il y a plusieurs services qui se parlent sur le réseau. La comparaison détaillée entre passerelle d'API et maillage de services fait l'objet d'un article séparé, tant les deux briques sont mises en concurrence à tort.
L'axe qui traverse tout : la stratégie d'évolution
Le Strangler Fig, nommé par Martin Fowler en 2004 d'après le figuier étrangleur observé dans les forêts du Queensland, décrit une manière de remplacer un système existant sans réécriture totale. On pose une façade de routage devant l'ancien système, on redirige une fonctionnalité à la fois vers le nouveau, et l'ancien se vide progressivement jusqu'à pouvoir être arrêté.
Ranger ce pattern parmi les architectures cibles, comme le font les cartes en question, fausse la lecture. Personne ne « choisit le Strangler Fig » comme il choisirait les microservices : c'est le chemin, pas la destination. Sa limite bien documentée tient d'ailleurs à ce qu'il n'y a aucune pression pour finir, et beaucoup d'organisations se retrouvent à maintenir les deux systèmes pendant des années.
Trois configurations qui existent réellement
Voir les quatre niveaux combinés sur des cas réels aide plus qu'une définition supplémentaire. Aucune de ces trois configurations n'est plus avancée que les autres, elles répondent à des contraintes différentes.
| Niveau | SaaS à une équipe | PME, 4 équipes produit | Plateforme multi-clients |
|---|---|---|---|
| Contrat | REST | REST public, gRPC en interne | GraphQL pour les apps, REST pour les partenaires |
| Exposition | Rien, le serveur web suffit | Une passerelle | Passerelle plus un BFF par client |
| Applicatif | Monolithe modulaire | Monolithe plus 2 ou 3 services extraits | Microservices, avec de l'événementiel sur les flux lents |
| Réseau | Aucun mesh | Aucun mesh, TLS géré par la passerelle | Maillage de services |
La colonne du milieu est celle qui décrit le plus d'entreprises françaises que je croise en intra. Un socle historique qu'on ne réécrit pas, deux ou trois services extraits sur les parties qui bougent le plus, une passerelle devant, et aucun besoin de mesh parce que le trafic interne se compte en dizaines d'appels par seconde.
Les pièges de lecture
Croire qu'il faut choisir une seule branche
C'est le piège que la mise en page radiale installe. Sur les quatre niveaux, trois se cumulent sans difficulté et un seul, l'architecture applicative, demande un arbitrage exclusif.
Prendre « API Mesh » pour un pattern établi
Le terme apparaît sur plusieurs de ces cartes, à égalité avec la passerelle d'API. Il vient du marketing d'éditeurs qui vendent une couche d'orchestration au-dessus de plusieurs API, et il ne renvoie à aucune définition partagée, contrairement au service mesh, dont l'implémentation de référence est documentée publiquement depuis 2017. Mon avis tranché : tant qu'un terme n'a pas de spécification, de projet de référence ou d'article fondateur, il n'a pas sa place dans un schéma d'apprentissage.
Installer un maillage de services par anticipation
Un mesh résout des difficultés qui apparaissent avec le nombre de services et le volume d'appels internes. Sur cinq services et un trafic modeste, il ajoute une couche à exploiter, à mettre à jour et à déboguer, pour un bénéfice que personne ne mesure. La question à se poser avant de l'installer : quel incident récent aurait été évité par du mTLS automatique ou des reprises côté proxy.
Transformer la passerelle en fourre-tout métier
Une passerelle authentifie et route. Quand elle se met à agréger des réponses, à transformer des payloads et à porter des règles de gestion, elle redevient le point central dont on voulait sortir, avec en prime un langage de configuration à la place d'un langage de programmation. Les règles métier appartiennent aux services, ou à un BFF assumé comme tel, qui reste du code testable.
Confondre autonomie de déploiement et performance
« Microservices : hautement scalables » revient sur toutes ces cartes. Découper une application en services ne la rend pas plus rapide, et ajoute même des appels réseau là où il y avait des appels de fonction. Ce que les microservices apportent, c'est la possibilité de déployer et de dimensionner chaque morceau séparément, ce qui devient utile quand plusieurs équipes se marchent dessus dans le même dépôt ou quand une seule partie du système consomme l'essentiel des ressources.
L'ordre dans lequel ces décisions se prennent
Les quatre niveaux ne se décident pas en même temps, et cet ordre compte autant que le contenu de chaque décision. Une équipe qui commence par le niveau 4 se retrouve avec une infrastructure sophistiquée devant un produit dont le contrat n'est pas stabilisé.
Le contrat d'API vient en premier, parce qu'il engage vis-à-vis de l'extérieur. Publier une URL, c'est promettre qu'elle continuera de répondre, et revenir dessus coûte des semaines de coordination avec les consommateurs. Le découpage applicatif vient ensuite, dicté par le nombre d'équipes et par les parties du système qui bougent à des rythmes différents. La couche d'exposition arrive quand il y a plusieurs consommateurs à distinguer, avec des droits ou des quotas différents. L'infrastructure réseau ferme la marche, quand les incidents commencent à venir des appels internes.
Une décision peut être révisée à chaque étage, mais pas au même prix. Changer de maillage de services demande une migration d'exploitation, invisible pour le client. Changer un contrat d'API public demande une période de double exposition, des communications, une date de fin de support, et parfois des clients qui ne migrent jamais. C'est la raison pour laquelle une réunion d'architecture qui commence par « on prend quel service mesh ? » commence par la mauvaise question.
Deux de ces quatre sujets concentrent l'essentiel des erreurs de lecture et sont traités à part : passerelle d'API ou maillage de services pour le niveau exposition et le niveau réseau, REST, GraphQL ou gRPC pour le choix du contrat.
Par où commencer si tu apprends
Le niveau 1 est celui qui rapporte le plus vite, parce qu'il se pratique seul, sur une machine, sans cluster. Écrire une API propre, comprendre ce que HTTP transporte entre le navigateur et le serveur, choisir ses codes de retour, gérer l'authentification. La formation Créer une API REST avec Python et FastAPI couvre ce périmètre, et son équivalent Java existe avec Spring Boot.
Les niveaux 3 et 4 demandent un contexte que tu n'as pas chez toi : plusieurs équipes, du trafic, des incidents. Les lire pour comprendre le vocabulaire de tes collègues a de la valeur, les pratiquer sur un projet perso en a beaucoup moins. Si tu veux quand même toucher à la partie exploitation, les douze facteurs et Docker donnent plus de retour sur investissement qu'une installation de mesh sur un cluster local.
Un dernier mot sur ces cartes mentales. Elles ne sont pas à jeter, elles sont à lire pour ce qu'elles sont : une liste de mots-clés du domaine. Comme grille de décision, elles produisent des réunions où l'on compare un figuier étrangleur à un maillage de services.
