Le piège des microservices : pourquoi découper votre logiciel en dix briques coûte si cher

Imaginez une entreprise de quinze salariés dans une zone d’activités.

Au lieu de travailler dans le même bâtiment et de se parler à la machine à café, la direction a décidé, au nom de la modernité, d’installer chaque collaborateur dans un préfabriqué séparé au milieu du parking.

Pour transmettre une information, poser une question sur un devis ou valider une expédition, interdiction d’aller voir son voisin : chaque salarié doit rédiger une note formelle, l’enfermer dans une enveloppe cachetée et attendre le passage d’un coursier à vélo pour traverser la cour.

Tant que la météo est clémente et que personne n’est malade, le système donne l’illusion de tourner.

Mais qu’un orage éclate sur la cour, qu’un coursier crève un pneu ou que le destinataire soit parti déjeuner, la note se retrouve bloquée.

Et lorsque le client appelle pour savoir pourquoi sa commande n’est pas expédiée, le comptable, le gérant et le responsable d’atelier se renvoient la balle : « Chez moi, tout va bien. J’ai remis l’enveloppe au coursier à 14 h 12. S’il n’est pas arrivé, ce n’est pas mon problème ».

L’organisation a décuplé ses frais, ralenti son travail et créé dix frontières artificielles là où un échange direct suffisait.

C’est très exactement ce qui se produit quand une TPE, une PME, ou même une ETI adopte une architecture en microservices sans en avoir ni la taille, ni le besoin.

L’illusion de la modernité : importer le modèle des géants du web

Les microservices ne sont pas apparus par hasard, et ils ne sont pas une mauvaise idée en soi. Chez des géants technologiques comme Google, Netflix ou Amazon, ils apportent une réponse technique et organisationnelle à des contraintes extrêmes :

1. La coordination humaine à grande échelle : comment faire travailler dix mille ingénieurs sur un même système sans qu’ils se paralysent mutuellement ? Découper le logiciel en centaines de briques autonomes permet à chaque équipe de livrer son composant sans attendre les autres.
2. L’absorption de pics de charge massifs (load balancing ciblé) : quand la vidéo à la demande explose un vendredi soir ou que les paniers s’emballent lors du Black Friday, l’architecture permet de répliquer instantanément uniquement le service sollicité sur des centaines de serveurs, sans devoir démultiplier tout le reste de l’application.
3. Le traitement de volumes de données gigantesques : à l’échelle de millions d’opérations par seconde et de pétaoctets de données, une base de données unique sature. Les microservices permettent de scinder les données et d’associer à chaque brique le moteur de stockage le plus adapté (recherche distribuée, cache en mémoire, base orientée documents).

Pour ces multinationales, le coût faramineux de cette infrastructure distribuée, de la télémétrie complexe et des équipes réseaux dédiées est un arbitrage économique rationnel : il résout de réels goulets d’étranglement de charge et d’organisation.

Le piège se referme lorsque l’on plaque cette mécanique de multinationale sur une TPE, une PME ou même une ETI de vingt, cinquante ou deux cents personnes.

Dans une structure à taille humaine, ces trois contraintes n’existent tout simplement pas :

• Pas d’effet de foule ingérable : un outil de gestion interne, une plateforme B2B ou un site d’entreprise accueille quelques dizaines à quelques milliers d’utilisateurs simultanés. N’importe quel serveur standard à 50 € par mois encaisse ce trafic sans sourciller, sans avoir à multiplier les ressources pour gérer les pics d’activité.
• Des données qui tiennent largement sur une seule machine : la base de données d’une PME ou d’une ETI se compte en gigaoctets, rarement au-delà. Un unique serveur doté de disques SSD traite ces volumes rapidement et garantit leur cohérence, sans avoir besoin d’éparpiller vos données sur dix moteurs de stockage distincts.
• Deux développeurs pour dix briques : vous n’avez pas huit cents équipes spécialisées, mais deux développeurs internes ou une petite équipe prestataire. Ce sont les deux mêmes personnes qui conçoivent, livrent, surveillent et réparent les dix services dispersés.

Le gain qui justifie l’architecture distribuée chez les géants du web est ainsi strictement inexistant pour une TPE, une PME ou la grande majorité des ETI. En revanche, la complexité technique, les pannes réseau et la facture sont payées à 100 % par l’entreprise. L’architecture n’est pas agile : elle est surdimensionnée.

La taxe réseau : quand la panne partielle remplace la certitude

Dans un logiciel classique regroupé en un seul programme (un « monolithe »), les différentes parties se parlent directement au sein de la machine.

Quand la fonction Commande appelle la fonction Facturation, le transfert prend une fraction de milliseconde. Il ne peut pas y avoir d’embouteillage, de paquet perdu ou de câble débranché entre les deux : ils tournent sur le même processeur.

Surtout, l’enregistrement se fait dans une base de données unique, sous la protection d’une transaction atomique. C’est le principe du « tout ou rien » : soit la commande, la facture et la déduction de stock sont validées ensemble, soit aucune ne l’est si une règle métier bloque. Vos comptes et vos stocks restent parfaitement alignés.

Dès que vous découpez ces fonctions en services distincts reliés par le réseau local ou Internet, cette garantie disparaît.

Pour enregistrer une commande, le premier serveur doit contacter le deuxième via le réseau, qui doit à son tour contacter le troisième. Vous payez alors une taxe invisible :

• La latence permanente : chaque clic utilisateur déclenche une chaîne d’appels réseau en cascade. Ce qui prenait 5 millisecondes en mémoire vive en demande désormais 400.
• La panne partielle : le réseau n’est jamais infaillible. Le serveur de commande enregistre l’achat, le serveur de facturation encaisse, puis le serveur de stock met 10 secondes à répondre ou redémarre. La commande est validée, l’argent est débité, mais le produit n’est pas réservé.
• La boîte noire distribuée : dans un programme unique, une erreur laisse une trace nette dans un seul journal (log). Dans dix microservices, retrouver pourquoi une opération a échoué exige de recouper des journaux éparpillés sur dix serveurs différents. Personne ne sait exactement où le dossier a disparu.

Remplacer un appel de fonction par un appel réseau ne rend pas un logiciel plus performant. Cela ajoute simplement un câble susceptible de casser entre chaque ligne de code.

L’explosion silencieuse des coûts d’infrastructure et de maintenance

Cette complexité technique a une traduction budgétaire immédiate sur vos comptes d’exploitation.

Pour faire tourner un logiciel bien conçu pour une TPE, une PME ou même une ETI, un serveur dédié correctement dimensionné suffit largement. Il coûte quelques dizaines d’euros par mois, se sauvegarde en bloc et se redémarre en deux minutes.

Pour faire tourner dix microservices, la donne change du tout au tout :

• L’infrastructure se transforme en usine à gaz : chaque service a besoin de son propre environnement d’exécution, de son processeur réservé, de sa mémoire et de sa base de données. La facture d’hébergement ne paye plus un simple serveur : elle se met à financer un cluster d’orchestration, plusieurs machines en batterie, des répartiteurs de charge et des outils d’analyse de journaux. Pour faire tourner le même service métier, la note d’infrastructure se retrouve facilement multipliée par cinq ou dix.
• Le moindre changement coûte des jours de travail : pour ajouter une information sur une fiche client, il ne suffit plus d’ajouter une colonne dans une table. Il faut modifier le contrat d’échange du service A, redéployer le service B, adapter la base du service C, puis vérifier que le service D ne plante pas à cause du nouveau format. Ce qui devrait être réglé en deux heures de développement devient un chantier de trois semaines.
• La dépendance envers les prestataires se renforce : l’infrastructure est devenue tellement tentaculaire qu’aucun nouvel intervenant ne peut la comprendre sans des semaines d’apprentissage payées par vos soins.

L’alternative pragmatique : le monolithe modulaire

Face à ces dérives, une idée fausse très répandue consiste à croire que l’alternative à l’anarchie des microservices serait un plat de code désordonné où tout le monde touche à tout.

C’est une erreur fondamentale : il ne faut pas confondre séparation logique et séparation physique.

On peut, et on doit, concevoir un logiciel avec des frontières rigoureuses, des responsabilités isolées et des contrats stricts, comme nous l’avons vu pour le découplage logiciel. Chaque domaine métier (les commandes, la facturation, le stock, l’atelier) dispose de son propre code, sans ingérence chez le voisin.

Mais ces domaines tournent dans le même programme et sur le même serveur.

C’est ce qu’on appelle un monolithe modulaire :

• Découplé dans le code : chaque brique est propre, isolée et remplaçable sans perturber le reste.
• Unifié à l’exécution : les échanges se font en mémoire vive à la vitesse du processeur, avec zéro panne réseau entre les briques.
• Une seule base de données sous-jacente : intégrité garantie par le moteur de base de données, sauvegardes simples et instantanées, zéro état bancal.
• Exploitation élémentaire : un seul programme à démarrer, un seul binaire à mettre à jour, un seul journal d’incidents à consulter.

Vous obtenez tous les bénéfices de maintenabilité et de lisibilité que vantaient les vendeurs de microservices, sans payer la taxe du réseau, sans usine à gaz d’infrastructure et sans risque de corruption silencieuse de vos données.

Les rares cas où le microservice a du sens

Une architecture n’est jamais bonne ou mauvaise dans l’absolu ; elle est adaptée ou inadaptée à des contraintes concrètes. Les microservices fonctionnent très bien chez Google ou Netflix parce qu’ils répondent à leur échelle hors norme.

Pour une TPE, une PME ou même une ETI de moins de cinq cents salariés, découper son outil principal en microservices est une erreur d’ingénierie dans 95 % des cas. Il existe toutefois des exceptions précises et justifiées où isoler une brique sur sa propre machine est une décision technique saine :

• Une contrainte matérielle radicalement différente : si vous devez exécuter un modèle lourd d’intelligence artificielle ou de vision par ordinateur sur un serveur équipé de cartes graphiques puissantes et coûteuses, il est logique d’isoler ce traitement précis sur sa propre machine, plutôt que de payer des cartes graphiques pour l’ensemble du système.
• Une dépendance technologique exogène incontournable : lorsqu’une brique clé repose sur un composant ou un SDK fermé disponible uniquement dans un autre écosystème (par exemple une bibliothèque exclusive à un environnement spécifique alors que votre monolithe applicatif tourne sous un autre langage), isoler un service dédié pour faire tourner ces dépendances spécifiques est une décision pragmatique.
• L’isolation d’un flux d’atelier temps réel : dans l’industrie, un composant qui pilote des automates ou remonte des données de capteurs à haute fréquence (comme un tampon de collecte local) doit parfois être physiquement séparé de l’ERP pour ne jamais subir les ralentissements ou les redémarrages de la gestion commerciale.
• Une équipe de développement massive : quand votre entreprise emploie plus de cinquante ou cent personnes à temps plein uniquement sur le logiciel, l’isolation physique permet d’éviter les conflits de livraison entre équipes.

Si vous n’êtes dans aucun de ces cas précis, découper votre application métier en microservices ne résout aucun de vos problèmes. Cela ne fait qu’en créer de nouveaux, à vos frais.

Questions fréquentes

Mon prestataire affirme qu’avec un seul programme, si une partie plante, tout s’arrête. Est-ce vrai ?

Non, c’est un argument commercial qui masque une mauvaise conception.

Dans une solution correctement conçue, une erreur dans l’édition d’une facture est interceptée localement. Elle renvoie un message d’erreur clair à l’utilisateur sans faire s’écrouler le serveur.

Surtout, l’argument oublie une réalité : dans une architecture microservices, si le service Facturation tombe en panne, le client ne peut de toute façon pas finaliser sa commande. Le résultat pour l’utilisateur final est exactement le même, à une différence près : avec les microservices, il est plus difficile de détecter l’origine de la panne.

Si mon entreprise se développe vite, un monolithe ne risque-t-il pas d’être dépassé ?

Non. C’est l’un des mythes les plus tenaces de l’informatique.

Des plateformes de renommée mondiale traitant des millions de transactions quotidiennes (comme Shopify ou Basecamp) tournent sur des monolithes modulaires.

Un serveur moderne à quelques dizaines d’euros traite sans forcer des milliers de requêtes par seconde. Avant que votre entreprise n’atteigne les limites physiques d’une seule machine bien exploitée, votre chiffre d’affaires aura été multiplié par dix. Et si un module spécifique devient un jour un goulet d’étranglement matériel, un monolithe modulaire bien délimité permet de l’extraire en quelques jours.

Pourquoi tant d’agences et de développeurs proposent-ils des microservices ?

Parce que leurs intérêts ne sont pas les vôtres.

Pour une équipe technique ou une agence, concevoir une architecture distribuée présente un attrait immédiat : cela permet d’expérimenter les technologies en vogue sur un projet concret et de valoriser des compétences très recherchées sur le marché.

Surtout, le modèle économique traditionnel des sociétés de services valorise la masse d’heures vendues et la maintenance au long cours plutôt que la simplicité opérationnelle. Un système éclaté, par nature plus fragile et dépendant du réseau, génère mécaniquement davantage de prestations de configuration, de surveillance et de reprise d’incidents.

Ce qui constitue pour votre entreprise un coût récurrent et un frein à la réactivité représente pour le prestataire un volume d’activité garanti. Là où votre priorité de dirigeant est la rentabilité et la maîtrise des coûts, l’écosystème technique est incité à privilégier une complexité valorisante mais superflue.

À retenir

• Les microservices sont une solution éprouvée pour les géants comme Google ou Netflix, mais un piège de suringénierie et de coûts pour les TPE, PME et la quasi-totalité des ETI.
• Remplacer des appels de fonctions en mémoire par des appels réseau dégrade les temps de réponse, crée des pannes intermittentes et détruit l’intégrité transactionnelle des données.
• L’infrastructure distribuée fait exploser les factures d’hébergement et rend la moindre évolution longue et coûteuse.
• Le monolithe modulaire offre le meilleur des deux mondes : un code propre, compartimenté et maintenable, qui s’exécute localement avec une fiabilité maximale et un coût d’exploitation dérisoire.

C’PRAG réalise des diagnostics d’architecture logicielle et audite la complexité de vos systèmes.

L’approche pragmatique

• Analyse de la structure de vos applications et identification des surcoûts d’infrastructure inutiles.
• Évaluation des dépendances réseau fragiles et des risques de désynchronisation de vos bases de données.
• Simplification de votre chaîne de déploiement pour réduire vos frais de maintenance et accélérer vos livraisons.
• Restitution priorisée des actions pour regrouper ou découpler vos briques selon les besoins réels du terrain.

En une à deux journées, sans interrompre la production.

Réservez un échange préalable de 15 minutes pour en parler : un premier examen de votre architecture permet d’identifier immédiatement les briques artificielles qui freinent vos équipes et gonflent vos devis.