Démarrer seulement une partie des microservices

Mis à jour : 22 août 2026

Votre système a douze services et vous allez en toucher deux. La machine encaisse douze —tout juste— mais les démarrer tous prend quatre minutes, mange la mémoire et n'apporte rien au changement que vous faites. La question n'est pas de savoir si l'on peut découper : c'est où appellent ceux que vous démarrez.

Le découpage n'est pas le problème ; la destination si

Démarrer un sous-ensemble est trivial dans n'importe quel outil : vous en choisissez deux et vous démarrez. Ce que personne ne résout à votre place, c'est ce qui arrive quand l'un de ces deux appelle un troisième qui n'est plus là.

Chaque dépendance qui sort du découpage a exactement trois destinations possibles :

• Local — il est démarré juste à côté. Le cas facile, et aussi celui qui entraîne : si vous le démarrez, vous entraînez sa propre queue de dépendances.
• Le cloud — votre environnement partagé. Cela vous évite de le démarrer, en échange du VPN, de données qui changent sous vos pieds, et du fait que si cet environnement est en panne, vous aussi.
• Un mock — parfait quand sa réponse n'est pas ce que vous testez. En échange de maintenir le stub.

La décision est par dépendance, pas par environnement. C'est là la différence avec presque tout le reste : vous ne voulez pas un « mode local » ou un « mode cloud », vous voulez que cet appel aille au service que vous avez ouvert, celui-là au cloud et un troisième à un mock, et changer d'avis au milieu de l'après-midi.

Pourquoi un compose ne fait pas la différence

docker compose up bff orders démarre bien deux services. Mais dans un compose tout est un conteneur du même réseau, et les URLs entre eux sont des noms de service de ce réseau. La configuration de bff dit http://payments:8081, et payments n'existe plus : vous obtenez un échec de résolution de nom.

La sortie habituelle est d'éditer l'URL à la main dans la configuration de bff —un dépôt qui souvent n'est pas le vôtre—, de penser à ne pas la commiter, et de le défaire quand vous voulez essayer autre chose. Multiplié par services et par fois dans la journée, c'est de là que sort le LOCAL_SETUP.md de quarante étapes.

Ce qui casse quand on découpe mal

Deux échecs, et le second est bien pire que le premier :

1. Cela échoue bruyamment. connection refused, ou un nom qui ne résout pas. Pénible, mais honnête : vous le découvrez au premier essai.
2. Cela fonctionne sans que personne ne l'ait décidé. La configuration portait par défaut l'URL de l'environnement partagé, donc l'appel part vers le cloud, répond, et tout a l'air correct. Vous le découvrez le jour où cet appel écrit : une migration, une commande de test, un courriel envoyé à un vrai client depuis votre machine.

Le second est ce qui justifie d'en faire une décision explicite plutôt qu'une valeur par défaut. Un environnement local qui atteint la production par inadvertance ne prévient pas.

Et un cas que presque tout le monde rate

Si un service est bien démarré juste à côté, l'appel devrait aller vers lui —même si le fichier de configuration général dit « cloud »—. Cela paraît évident et presque aucun outil ne le fait : vous finissez avec un service démarré sur votre machine que son voisin appelle par internet. Cela consomme du VPN, c'est plus lent, et le jour où le VPN tombe vous avez un scénario local entier qui ne démarre pas à cause d'un service que vous aviez juste à côté.

La bonne règle : ce qui est démarré juste à côté s'appelle en local, et la configuration générale ne décide que de ce qui n'est pas dans le scénario.

Comment Aseptic le résout

Un scénario est exactement cela : le sous-ensemble que vous voulez démarrer, avec la décision prise pour chaque dépendance qui en sort.

• Vous choisissez ce qui entre. Deux sur douze, ou autant que vous voulez, regroupés par flux —« Checkout », « Création de client »— et enregistrés avec un nom, pour ne pas avoir à redécider demain.
• Pour chaque dépendance vous choisissez une destination —local, cloud ou mock— et le moteur réécrit l'URL au démarrage, injectée comme propriété -D ou variable d'environnement. Vos dépôts ne sont pas touchés.
• Ce qui est dans le scénario s'appelle en local, au-dessus de ce que dit le manifeste : la décision récente et spécifique l'emporte sur la générale.
• Si les déclarations se contredisent, le démarrage est coupé au lieu de trancher en silence. Deux vérités sur la même dépendance, c'est le bug qui finit avec le panneau qui dit « cloud » pendant qu'un service appelle son voisin local.
• Le scénario se partage comme fichier autonome : celui qui arrive importe et démarre, sans lire le document de qui que ce soit.

Quelle part faut-il vraiment démarrer

La règle qui marche : seulement les services que vous allez changer, plus ceux dont vous vérifiez le comportement. Tout le reste est une URL qui pointe ailleurs. En pratique, la plupart des après-midis cela fait deux ou trois services sur un système de douze.

Si en découpant vous constatez que l'un des deux ne démarre pas, il y a pourquoi un microservice ne démarre pas en local ; et si ce dont vous avez besoin est de remplacer ceux que vous laissez dehors, simuler un service que vous ne contrôlez pas. Le panorama complet est dans ce dont a besoin un environnement local de microservices.

← Retour à l'accueil