Microservices

Architecture en microservices : l’inverse du logiciel monolithique

Un seul programme, ou vingt petits

Longtemps, une application d’entreprise était un bloc unique : la facturation, les clients, les stocks et les droits d’accès vivaient dans le même programme. Découpée en microservices, la même application devient une vingtaine de programmes distincts, qui s’échangent des demandes par des API ; chacun a son code, souvent sa base de données, et tourne de son côté, généralement dans un conteneur.

Pourquoi les entreprises y sont venues

Parce qu’une correction sur la facturation n’oblige plus à réinstaller toute l’application, et qu’elle ne peut plus casser les stocks au passage. Parce que plusieurs équipes avancent en parallèle sans s’attendre. Et parce que la brique la plus sollicitée peut être multipliée seule, sans payer pour agrandir le reste. Sur une application qui vit et change souvent, le gain est réel.

Ce que le découpage déplace

Ce qui était un échange interne au programme devient un appel entre deux machines, avec une adresse, une authentification et une panne possible. Vingt briques, ce sont vingt cycles de vie, vingt versions, vingt endpoints à connaître. La complexité n’a pas disparu : elle a quitté le code pour s’installer dans la coordination, là où elle se documente au lieu de se lire.

La seule question à poser

« Combien de services tournent chez nous, et lesquels sert-on encore ? » Dans une maison bien tenue, la réponse est immédiate et vient de l’orchestrateur, qui sait exactement ce qu’il fait tourner. Là où elle demande une enquête de plusieurs jours, ce n’est pas l’architecture qui est en cause : c’est l’inventaire qu’elle exige et que personne n’a tenu.

Mise à jour : 27 septembre 2026