Spring Boot : développer plusieurs services en local

Mis à jour : 21 août 2026

Un service Spring Boot sur votre machine est un problème résolu : vous exécutez la classe principale et vous travaillez. Cinq, qui se parlent, avec un Kafka et un Postgres dessous, c'est par là que part la matinée.

Ce qui coûte vraiment du temps

• L'ordre. Celui qui s'enregistre doit être levé avant celui qui le cherche, et « levé » veut dire qu'il répond à /actuator/health, pas qu'il a un PID.
• Les ports. Deux services arrivent avec 8080 par défaut. Le troisième que vous démarrez en trouve un occupé et il faut deviner lequel.
• Les URL. Chaque service a une propriété qui pointe vers un autre —app.catalog.url et ses quinze sœurs— et en pointer trois ailleurs signifie éditer des fichiers qu'il faudra ensuite penser à ne pas committer.
• L'infrastructure. Kafka, Redis et PostgreSQL, levés toujours pareil, avec les topics et le schéma que les services attendent.
• Vos propres bibliothèques. Une bibliothèque partagée qu'il faut en plus modifier signifie mvn install, monter la version et espérer que personne d'autre n'a pris le snapshot.

Ce qu'Aseptic en fait

Aseptic détecte un service Spring Boot par son manifeste —Maven ou Gradle— et sait comment le démarrer, où est son endpoint de santé et comment lui passer de la configuration. La configuration est injectée au démarrage, sous forme de propriétés système -D ou de variables d'environnement, donc les URL entre services sont réécrites sans toucher à application.yml ni à quoi que ce soit de votre dépôt. Rien à committer, rien à penser à annuler.

Un scénario regroupe les services d'un flux et les démarre dans l'ordre des dépendances, en attendant la santé et non le processus. Les ports qui se heurtent sont remappés tout seuls, et c'est la nouvelle valeur qui est annoncée aux autres services. Kafka, Redis et PostgreSQL se lèvent dans Docker, gérés par l'app.

Pour chaque dépendance vous choisissez où elle se résout : un autre service ouvert en local, votre environnement cloud partagé —avec le VPN, si c'est ainsi que vous y accédez— ou un mock. Ce choix se fait par dépendance et non par environnement, donc « ces deux-là en local et le reste vers le cloud » est un mardi ordinaire et non un exercice de configuration.

Des bibliothèques sans les publier

Si le changement couvre un service et une bibliothèque à vous, Aseptic construit la bibliothèque et la lie chez ceux qui la consomment là où Maven et Gradle la cherchent —votre dépôt local ~/.m2— et peut la reconstruire et la relier à chaque changement. Il n'édite ni le pom.xml ni le build.gradle du consommateur, et délier ne défait que ce qu'il a fait.

Ce qu'il ne fait pas

Il ne remplace pas votre build. Maven et Gradle restent exactement où ils sont, et Aseptic les appelle. Il n'exécute pas de cluster Kubernetes : si ce que vous devez vérifier est une probe, un ingress ou un sidecar, c'est le mauvais outil —un cluster local est le bon—. Et il a besoin de Docker pour l'infrastructure commune, donc il faut avoir Docker Desktop ou un moteur Docker installé.

Il est en bêta publique, publié pour Windows, macOS et Linux, et gratuit pour un usage personnel.

Où cela se situe face aux suspects habituels

Si vos services ont déjà des images et des manifestes que vous maintenez, Tilt ou Skaffold gardent à la boucle locale la forme de la production, au prix d'un build et d'un déploiement à chaque changement. La page des alternatives à Docker Compose déploie tout le terrain, et le comparatif général couvre Compose et Kubernetes local directement.

Il existe des équivalents de cette page pour Quarkus et pour Node.

← Retour à l'accueil