Les microservices sont une façon de construire une application sous forme de nombreux petits programmes séparés plutôt que d'un seul gros. Chaque petit programme, appelé service, s'occupe d'une tâche métier, le paiement, le catalogue, la recherche ou les emails, garde ses propres données et peut être mis à jour sans toucher aux autres. Ensemble, ils forment le produit que voit le client.

Le terme concerne les fondateurs et les marques qui commandent un logiciel ou évaluent une proposition technique. Certaines agences présentent les microservices comme le choix moderne et évolutif par excellence. Parfois, c'est vrai. Souvent, pour une petite entreprise, cela multiplie la facture d'hébergement, le temps de développement et le nombre de pièces qui peuvent casser. Comprendre l'arbitrage vous permet de dire oui ou non pour les bonnes raisons.

Qu'est-ce que les microservices ?

Les microservices sont un style d'architecture dans lequel une application se compose de petits services déployables indépendamment, organisés chacun autour d'une capacité métier et propriétaires de leurs données. Les services communiquent par le réseau, via des appels d'API ou via des événements.

Trois propriétés définissent ce style :

  • Un déploiement indépendant. Chaque service sort à son propre rythme. Mettre à jour la recherche n'oblige pas à redéployer le checkout.
  • La propriété des données. Chaque service a sa base ou son stockage. Aucun autre service ne lit ces données directement, il interroge le service propriétaire.
  • Des frontières métier. Les services suivent les domaines de l'activité, commandes, stock, clients, plutôt que des couches techniques du type « la partie base de données ».

Ce que les microservices ne sont pas : simplement « beaucoup de fichiers » ou « beaucoup de dossiers ». Une application découpée en modules reste une seule unité déployée. Ce ne sont pas non plus des fonctions serverless, même si des services peuvent tourner sur ce type de plateforme. Et découper le code en services qui partagent tous la même base de données apporte l'essentiel des coûts des microservices avec peu de leurs avantages. Les ingénieurs appellent cela un monolithe distribué.

Le style opposé est le monolithe, une application déployée d'un seul bloc. Beaucoup d'équipes se situent entre les deux, avec un monolithe bien organisé et deux ou trois services séparés pour les parties aux besoins particuliers. Les microservices s'appuient souvent sur une architecture événementielle pour que les services restent faiblement liés. Choisir entre ces styles est l'une des décisions centrales de l'architecture logicielle.

Pourquoi c'est important

Les microservices échangent la simplicité contre l'indépendance. Cet échange profite aux grandes organisations et coûte cher aux petites.

Prenons une startup qui a levé 140 000 € pour créer une marketplace d'objets artisanaux. Une agence propose 9 microservices : utilisateurs, catalogue, recherche, panier, commandes, paiements, avis, notifications et administration. Chacun demande son dépôt de code, sa chaîne de déploiement, sa base de données, sa supervision et ses mises à jour de sécurité. Le devis s'élève à 85 000 € et 5 mois, avec un hébergement d'environ 850 € par mois, puisque chaque service tourne séparément avec ses propres ressources.

Un autre développeur propose une seule application bien structurée, avec des modules clairs pour les mêmes fonctionnalités. Le devis s'élève à 47 000 € et 3 mois, avec un hébergement autour de 140 € par mois.

L'écart sur la première année atteint environ 38 000 € de développement et 8 500 € d'hébergement, près d'un tiers de la levée. Le monolithe arrive aussi deux mois plus tôt devant les clients, soit deux mois d'apprentissage et de chiffre d'affaires. À ce stade, la marketplace compte deux développeurs et quelques centaines de commandes par mois. Aucun avantage des microservices, équipes indépendantes ou recherche capable de monter en charge séparément, ne s'applique encore.

Le tableau s'inverse pour une entreprise de 80 ingénieurs et plusieurs millions de visites par mois. Là, un code unique partagé oblige les équipes à s'attendre, et un bug dans les avis peut faire tomber le checkout. Découper le système permet aux équipes de livrer tous les jours sans coordonner chaque mise en production.

Comment ça marche

Un système en microservices repose sur quelques mécanismes récurrents :

  • Des services par capacité métier. Chaque service a une mission claire, par exemple le service de stock sait combien d'unités existent et les réserve.
  • Des données privées. Le stock a sa propre base. Le service des commandes ne la lit jamais directement, il appelle le service de stock.
  • Des échanges par le réseau. Les services s'envoient des requêtes synchrones quand ils ont besoin d'une réponse immédiate, et des événements quand les autres doivent simplement être informés.
  • Une passerelle d'API. Une porte d'entrée reçoit les requêtes du client et oriente chacune vers le bon service.
  • Des chaînes de déploiement indépendantes. Chaque service a ses tests et son déploiement, une équipe peut livrer plusieurs fois par jour.
  • L'observabilité. Journaux, métriques et traçage suivent une même requête à travers les services, car un checkout lent peut venir d'un service situé trois appels plus loin.
  • Des mécanismes de résilience. Délais maximum, nouvelles tentatives et solutions de repli empêchent un service défaillant d'entraîner les autres.

Repères et exemples

Quelques repères réalistes pour situer les microservices à la bonne échelle.

  • Créateurs solo et petites boutiques : aucun intérêt. Une plateforme hébergée ou une application simple absorbe des milliers de commandes par mois.
  • Startups avant d'avoir trouvé leur marché : en général un monolithe. Beaucoup d'entreprises connues ont commencé ainsi et découpé plus tard, une fois les vraies frontières identifiées.
  • Entreprises avec plusieurs équipes, à partir de 30 à 50 ingénieurs : les microservices commencent à rapporter, surtout pour des raisons d'organisation.

Une règle empirique courante veut qu'une équipe de 5 à 9 personnes puisse porter confortablement une poignée de services. Si vous avez plus de services que d'ingénieurs, la charge d'exploitation l'emporte en général. Chaque service supplémentaire ajoute souvent 20 à 200 € par mois d'hébergement à petite échelle, plus du temps de supervision et de maintenance. Un appel réseau entre services ajoute quelques millisecondes. Une page qui enchaîne dix appels peut prendre un retard perceptible, ce qui compte sur mobile où la vitesse influence le taux de conversion.

Erreurs fréquentes

  • Commencer par les microservices. Découper avant de comprendre l'activité place les frontières au mauvais endroit, et les déplacer ensuite coûte cher.
  • Partager une base de données. Des services qui lisent les tables des autres ne peuvent pas être déployés indépendamment. Vous payez la complexité sans la liberté.
  • Trop nombreux, trop petits. Un service par table produit des appels croisés permanents et des pages lentes et fragiles.
  • Sous-estimer l'exploitation. Sans traçage, journaux centralisés et alertes, comprendre pourquoi une commande a échoué peut prendre des heures.
  • Ignorer la cohérence des données. Une commande qui traverse paiement, stock et livraison ne peut pas s'appuyer sur une seule transaction de base de données. Il faut des mécanismes pensés pour les échecs partiels.

Bonnes pratiques

  • Commencez par un monolithe modulaire. Organisez le code par domaine métier dès le premier jour, pour qu'extraire un service plus tard revienne à couper le long d'une ligne existante.
  • Extrayez pour une raison concrète. Sortez une partie quand elle a besoin d'une montée en charge différente, d'un rythme de livraison différent ou d'une équipe dédiée, pas par effet de mode.
  • Un responsable par service. Une équipe identifiée répond de son code, de ses données et de sa disponibilité.
  • Soignez les contrats. Documentez l'API et les événements de chaque service, et faites-les évoluer sans casser l'existant.
  • Investissez tôt dans l'observabilité. Journaux centralisés et traçage des requêtes deviennent indispensables au-delà de deux ou trois services.
  • Demandez le coût total. Quand une agence propose des microservices, demandez le coût mensuel d'hébergement, de supervision et de maintenance, pas seulement le prix du développement.

Dans Roctify

Qu'une plateforme soit construite en microservices ou en monolithe relève de ses propres choix d'ingénierie, et sur un SaaS comme Roctify, ce n'est pas à vous de le gérer. Roctify héberge votre boutique, la tient à jour et sert chaque page en HTTPS avec un certificat SSL gratuit. Serveurs, déploiements et mises à jour de sécurité sont pris en charge, vous n'avez jamais à décider sur combien de services tourne votre boutique.

Ce que vous voyez, c'est le résultat : un catalogue partagé où produits, variantes, stock, prix, clients et commandes sont communs à votre page lien en bio et à votre boutique en ligne, avec un stock mis à jour partout à la fois. Vous profitez de ce que les microservices promettent aux grandes entreprises, un système qui tourne et évolue, sans payer neuf services et l'équipe pour les exploiter. Les intégrations au-delà des fonctionnalités incluses se discutent dans le plan Enterprise.

FAQ

Les microservices sont-ils meilleurs qu'un monolithe ?

Aucun des deux n'est meilleur dans l'absolu. Les microservices conviennent aux grandes organisations avec de nombreuses équipes et des parties dont la charge varie beaucoup. Le monolithe convient aux petites équipes et aux nouveaux produits, parce qu'il est plus rapide à construire, moins cher à faire tourner et plus simple à déboguer.

Les microservices rendent-ils un site plus rapide ?

Pas à eux seuls. Ils permettent de faire monter en charge séparément les parties les plus sollicitées, ce qui aide sous forte affluence. Pour une boutique ordinaire, les appels réseau supplémentaires peuvent même ralentir. La vitesse vient surtout du cache, d'images optimisées et de pages légères.

Combien de microservices compte une entreprise type ?

De quelques-uns à plusieurs milliers. Les petites entreprises produit qui adoptent ce style en ont souvent entre 5 et 20. Les très grandes plateformes en font tourner des centaines, avec des équipes dédiées uniquement aux outils qui les font fonctionner ensemble.