Microservices pour PME : une fausse bonne idée ?

Microservices pour PME: une fausse bonne idée?

Ce chiffre suffit à alimenter les présentations commerciales, les feuilles de route technologiques et les conversations de comité de direction. Il ne suffit pas à justifier une migration.

Pour une PME, choisir entre architecture microservices ou monolithe n’est pas une décision de mode. C’est une décision de capacité opérationnelle. Elle engage l’organisation des équipes, la surveillance de la production, les processus de déploiement, les coûts d’infrastructure et la manière même de corriger une erreur à trois heures du matin.

Le problème n’est pas que les microservices soient une mauvaise architecture. Le problème est de les adopter avant d’avoir les équipes, les flux métier et la maturité technique qui leur donnent un sens.

Le piège de la complexité opérationnelle

La promesse est connue: découper une application en services indépendants, faire évoluer chaque composant séparément, déployer plus vite et absorber la charge sans redimensionner tout le système. Sur le papier, c’est propre. Dans un environnement à grande échelle, cela peut être redoutablement efficace.

Mais une PME ne part pas d’une plateforme mondiale avec plusieurs équipes spécialisées. Elle part souvent de deux à cinq personnes, parfois moins, qui développent le produit, répondent aux incidents, gèrent les déploiements et discutent directement avec les utilisateurs. Dans ce contexte, chaque service supplémentaire crée une surface opérationnelle.

Un service n’est pas seulement un dépôt Git et un fichier de configuration. Il faut lui associer:

• un processus de déploiement et de retour arrière;
• des journaux exploitables séparément;
• des métriques propres;
• une surveillance de sa disponibilité;
• une gestion des secrets et des droits d’accès;
• une documentation des contrats d’interface;
• une stratégie de montée en charge;
• une procédure de diagnostic lorsqu’il dépend de plusieurs autres services.

Avec un monolithe bien structuré, une partie de ces sujets reste centralisée. Avec des microservices, elle se répète, se distribue et se complexifie. Le coût de développement microservices ne se limite donc pas au temps passé à écrire les fonctionnalités. Il comprend l’environnement qui permet à ces fonctionnalités de rester opérables.

La fausse bonne idée consiste à croire que le découpage technique réduit automatiquement la charge de travail. Il la déplace souvent vers l’infrastructure et l’exploitation.

L’observabilité n’est pas une option

Dans une application monolithique, une requête traverse plusieurs modules dans un même processus. Lorsqu’elle échoue, le développeur dispose généralement d’une trace relativement directe: une erreur, une pile d’appels, un contexte de requête.

Dans une architecture distribuée, la même opération peut passer par un service d’authentification, un service de commande, un service de paiement et un système de notification. Si le résultat est lent ou incomplet, il faut savoir quel appel a ralenti, quel service a répondu avec une erreur et quelle version était déployée à chaque étape.

Cela implique une chaîne d’observabilité distribuée: centralisation des journaux, suivi des appels, métriques, identifiants de corrélation et outils de traçage comme Jaeger ou Datadog. Prometheus peut mesurer l’état des composants, mais il ne résout pas à lui seul la question du parcours fonctionnel.

Sans cette instrumentation, les microservices ne donnent pas de la souplesse. Ils donnent des incidents difficiles à localiser.

Découper le code ne supprime pas la complexité. Cela décide seulement de l’endroit où elle réapparaîtra.

Pour une PME, la question n’est donc pas seulement: combien de services voulons-nous créer? Elle est plutôt: qui va maintenir leur environnement d’exécution, interpréter les alertes et prendre la responsabilité d’un incident transversal?

Loi de Conway: votre organisation écrit déjà votre architecture

En 1968, Melvin Conway formulait une observation devenue incontournable: une organisation conçoit des systèmes qui reproduisent sa structure de communication. Une équipe unique qui travaille dans un même espace produit naturellement des composants fortement reliés. Plusieurs équipes autonomes, disposant de responsabilités distinctes, peuvent davantage justifier des services indépendants.

Cette idée est souvent citée comme une règle abstraite. Elle est pourtant très concrète.

Si votre équipe comprend trois développeurs qui interviennent tous sur le même produit, séparer artificiellement l’application en huit services ne crée pas huit équipes autonomes. Vous obtenez huit unités techniques que les mêmes personnes doivent comprendre, déployer et surveiller. Le logiciel est distribué, mais l’organisation ne l’est pas. C’est le monolithe distribué, avec les inconvénients du monolithe et ceux du réseau.

Le découpage fonctionnel ne suffit pas. Pour qu’un service soit réellement autonome, il faut une responsabilité claire, un périmètre métier stable et une capacité à prendre des décisions sans solliciter en permanence les mêmes interlocuteurs.

Le mauvais découpage commence souvent par la technique

Les premières séparations sont généralement séduisantes:

• un service pour les utilisateurs;
• un service pour les produits;
• un service pour les commandes;
• un service pour les paiements;
• un service pour les courriels.

Le problème apparaît lorsque ces services partagent les mêmes données, les mêmes règles métier et les mêmes cycles de livraison. Le service de commande ne peut pas fonctionner sans le service utilisateur. Le service de paiement dépend d’un état produit par un autre composant. Une modification apparemment simple exige plusieurs déploiements coordonnés.

Nous n’avons alors pas construit des frontières métier. Nous avons déplacé des fichiers derrière des interfaces réseau.

Un bon service doit porter une responsabilité cohérente et limiter les dépendances synchrones. S’il doit appeler quatre autres services pour répondre à chaque requête, son indépendance est théorique. Le système devient plus difficile à raisonner, sans gagner la capacité d’évolution annoncée.

Pour les décideurs, le signal est simple: si l’organisation ne sait pas encore attribuer clairement la responsabilité d’un domaine fonctionnel, elle n’est probablement pas prête à l’isoler dans un service.

Performance réelle: le prix de chaque appel réseau

Le réseau est rarement visible dans une maquette. Il devient central en production.

Dans un monolithe, les appels internes s’effectuent en mémoire avec une latence inférieure à 1 milliseconde. Dans une architecture en microservices, chaque saut réseau ajoute généralement une latence moyenne de 5 à 20 millisecondes. Cette différence semble modeste. Elle devient significative lorsqu’une requête traverse plusieurs services, attend des réponses successives et doit gérer les erreurs de communication.

Prenons une opération simple en apparence: afficher une page de commande. Elle peut nécessiter les informations du compte, l’adresse de livraison, le contenu du panier, les règles tarifaires et la disponibilité des articles. Dans un monolithe, ces appels restent internes au processus ou à la base de données. Dans une architecture distribuée, ils peuvent devenir une succession de requêtes réseau.

Le calcul n’est pas seulement arithmétique. Il faut aussi intégrer:

• les délais de connexion;
• les files d’attente;
• les reprises automatiques;
• les expirations de délai;
• les réponses partielles;
• les erreurs de service;
• les variations de charge;
• les mécanismes de limitation.

Une architecture qui paraît rapide à faible charge peut se dégrader dès que plusieurs dépendances attendent simultanément. Les appels parallèles réduisent parfois le temps total, mais augmentent la pression sur les services appelés et rendent le diagnostic plus délicat.

La résilience a un coût de conception

Un service qui appelle un autre service doit savoir quoi faire lorsque celui-ci ne répond pas. Faut-il réessayer? Combien de fois? Avec quel délai? Peut-on afficher une réponse dégradée? Peut-on placer l’opération en attente? Que se passe-t-il si la première requête a abouti mais que la réponse n’est jamais revenue?

Ces questions ne sont pas des détails d’implémentation. Elles touchent directement au comportement métier.

Un paiement ne se traite pas comme une image de profil manquante. Une indisponibilité du catalogue ne se gère pas comme un retard de notification. Les microservices obligent à expliciter ces cas, ce qui est une force lorsque le système est mûr, mais une charge considérable lorsque les règles métier sont encore en évolution.

La performance ne se résume donc pas à la capacité de lancer davantage d’instances. La scalabilité indépendante a une valeur lorsque certaines parties du système sont réellement plus sollicitées que d’autres. Si tout évolue ensemble, la séparation apporte peu et le réseau ajoute une contrainte.

Le monolithe modulaire: une réponse moins spectaculaire, mais plus solide

Le monolithe a mauvaise réputation parce qu’on confond souvent deux réalités.

Le mauvais monolithe est un bloc sans frontières, où chaque module accède directement aux données des autres, où les règles métier sont dispersées et où toute modification menace l’ensemble. Il accumule de la dette technique jusqu’à devenir impossible à faire évoluer.

Le monolithe modulaire est différent. L’application est déployée comme une unité, mais son code est organisé autour de domaines clairement séparés. Les modules possèdent leurs responsabilités, limitent leurs dépendances et exposent des interfaces internes. Les accès aux données sont contrôlés. Les règles métier restent localisées.

Cette approche ne promet pas une indépendance parfaite. Elle donne quelque chose de plus utile au démarrage: de la simplicité opérationnelle et des frontières réelles.

Monolithe modulaire contre microservices

Le monolithe modulaire permet aussi de reporter une décision coûteuse. Les modules peuvent être mesurés, stabilisés et observés avant d’être éventuellement extraits. Ce n’est pas une promesse de migration automatique. C’est une manière de conserver des options.

Chez Doctolib, le travail d’ingénierie lié à la sortie du monolithe a permis de faire passer le temps d’intégration continue d’une heure à cinq minutes en neuf mois. Ce retour d’expérience ne signifie pas que toute entreprise doit quitter son monolithe. Il montre surtout qu’une évolution d’architecture peut produire des gains très concrets lorsqu’elle répond à une contrainte réelle et qu’elle est menée comme un chantier d’ingénierie, pas comme un simple changement de vocabulaire.

Le meilleur premier système distribué est parfois un monolithe dont les frontières sont assez propres pour être mesurées avant d’être séparées.

Ce que le monolithe ne doit pas devenir

Choisir un monolithe ne dispense pas de discipline. Il faut éviter que les modules deviennent de simples répertoires décoratifs. Une architecture modulaire crédible repose sur des règles vérifiables:

1. Un module possède un périmètre métier identifiable et ne devient pas le lieu de stockage de tout ce qui n’a pas trouvé sa place.

2. Les dépendances entre modules sont explicites et limitées.

3. L’accès direct aux tables d’un autre domaine est restreint, voire interdit lorsque le modèle métier l’exige.

4. Les tests vérifient les contrats internes et les comportements essentiels, pas seulement la couverture statistique du code.

5. Le pipeline de déploiement reste suffisamment rapide pour que l’équipe n’ait pas intérêt à contourner les contrôles.

6. Les métriques distinguent les opérations critiques afin de repérer les vrais goulots d’étranglement.

Cette structure est moins visible qu’une collection de services avec des noms modernes. Elle est souvent plus utile.

Quand éviter les microservices

La complexité architecture microservices devient difficile à justifier dans plusieurs situations très fréquentes.

Lorsque le produit cherche encore son modèle

Au début d’un projet, les frontières fonctionnelles changent. Le flux d’inscription évolue, les règles de facturation sont réécrites, le catalogue change de structure, les responsabilités se déplacent. Extraire trop tôt des services revient à figer des hypothèses qui ne sont pas encore validées.

Le résultat est prévisible: des interfaces à maintenir alors que le métier n’est pas stabilisé. Chaque changement traverse davantage de couches. La dette technique se forme avant même que le produit ait trouvé son marché.

Lorsque les équipes partagent tout

Si les mêmes développeurs modifient tous les services, la séparation ne crée pas d’autonomie. Elle multiplie les contextes à charger mentalement. Les réunions de coordination augmentent. Les mises en production nécessitent davantage de synchronisation. Le temps gagné sur une petite modification est mangé par la gestion du système.

Une PME peut parfaitement employer des services indépendants, mais elle doit pouvoir leur associer des responsabilités durables. Sans cela, la distribution est principalement administrative.

Lorsque la charge ne justifie pas la séparation

La scalabilité indépendante est un avantage seulement si un composant présente un besoin de dimensionnement distinct. Si l’authentification, le catalogue et les commandes doivent tous évoluer au même rythme, les séparer n’apporte pas automatiquement un bénéfice.

Le nombre de visiteurs ne suffit pas à justifier une architecture distribuée. Il faut comprendre le profil de charge, les opérations coûteuses, les contraintes de disponibilité et les limites actuelles. Une base de données mal indexée, un traitement synchrone inutile ou une requête front-end trop lourde peuvent être les vrais goulots d’étranglement. Les microservices ne corrigent aucun de ces problèmes par magie.

Lorsque l’exploitation est déjà sous tension

Une équipe qui peine à maintenir un pipeline de déploiement fiable, à suivre ses erreurs applicatives ou à restaurer une sauvegarde n’a pas besoin d’ajouter immédiatement une couche de distribution.

Elle doit d’abord stabiliser le socle: automatisation des tests, livraison reproductible, surveillance des ressources, journalisation claire, gestion des secrets et procédures d’incident. Les microservices peuvent ensuite devenir une option. Avant cela, ils augmentent le risque.

Quand envisager réellement la transition

Il existe des raisons sérieuses de passer d’un monolithe modulaire à des services distribués. Elles sont moins glamour que les arguments de présentation, mais beaucoup plus solides.

Une extraction peut se justifier lorsqu’un domaine:

• possède un rythme de livraison très différent du reste de l’application;
• nécessite une montée en charge indépendante et mesurable;
• doit utiliser une technologie ou un environnement d’exécution spécifique;
• représente une frontière métier stable;
• doit être isolé pour des raisons de sécurité ou de conformité;
• est maintenu par une équipe clairement responsable;
• peut fonctionner avec un nombre limité de dépendances synchrones.

La décision doit partir d’une contrainte observée. Temps de livraison trop long sur une zone précise. Saturation indépendante d’un composant. Risque de panne circonscrit. Équipe devenue suffisamment autonome. Besoin de déployer un domaine sans immobiliser tout le produit.

Elle ne doit pas partir d’un schéma cible dessiné avant les premiers vrais incidents.

Extraire progressivement, pas réécrire pour se rassurer

La réécriture complète est rarement la première solution viable. Elle concentre le risque, suspend les évolutions métier et donne souvent une illusion de progrès pendant que l’ancien système continue de produire de la valeur.

Une extraction progressive permet de traiter un domaine à la fois. Elle oblige toutefois à définir une frontière précise, à choisir le propriétaire des données et à accepter une période de coexistence. Cette période est rarement élégante. Elle peut comporter des synchronisations temporaires, des doubles lectures ou des mécanismes de transition. Mais elle rend les arbitrages visibles.

Nous devons aussi accepter qu’un service extrait ne soit pas automatiquement un bon service. Il peut devenir un nouveau point de couplage, une dépendance fragile ou une base de données difficile à administrer. La distribution n’est pas un diplôme d’architecture. C’est une contrainte supplémentaire qui doit produire un bénéfice identifiable.

Le vrai dilemme n’oppose pas deux styles de code

Le choix entre architecture microservices ou monolithe pour PME est souvent présenté comme une opposition entre une architecture moderne et une architecture dépassée. C’est une mauvaise lecture du problème.

Le véritable choix porte sur le niveau de complexité que l’entreprise est capable d’absorber sans ralentir le produit ni fragiliser la production.

Un monolithe modulaire bien conçu peut offrir une excellente vitesse d’exécution, une livraison simple et une base saine pour évoluer. Une architecture en microservices peut devenir indispensable lorsque les domaines, les équipes et les contraintes de charge atteignent une certaine échelle. Entre les deux, il n’existe pas de seuil universel ni de nombre magique d’utilisateurs.

La bonne question n’est pas: quelle architecture utilisent les entreprises les plus avancées? Elle est: quelle contrainte actuelle notre architecture doit-elle résoudre?

Si la réponse est floue, gardons la structure la plus simple qui respecte le métier. Si le système possède déjà des frontières stables, des équipes autonomes et des besoins de déploiement ou de dimensionnement distincts, alors les services distribués méritent une étude sérieuse.

Mais ne confondons pas ambition technique et progrès. Une PME ne gagne rien à administrer une plateforme complexe pour résoudre un problème qu’elle n’a pas. Elle gagne beaucoup à construire un système lisible, mesurable et capable d’évoluer sans transformer chaque livraison en opération à risque.

Le monolithe n’est pas une condamnation. Les microservices ne sont pas une consécration. Ce sont deux niveaux de contraintes. À nous de ne pas choisir le plus coûteux avant d’en avoir le besoin.