Spring Boot et les « starters » : comprendre la magie sans la subir
Auto-configuration, starters, convention plutôt que configuration : comment Spring Boot vous fait gagner un temps fou, et ce qui se passe réellement en coulisses.
Avant Spring Boot, démarrer un projet Spring impliquait des heures de configuration XML et de gestion fine des versions de dépendances. Spring Boot a renversé cela avec deux idées : les starters et l'auto-configuration. Résultat : une application web opérationnelle en quelques minutes. Voyons ce qui se cache derrière cette « magie ».
Les starters : des dépendances par thème
Un starter est une dépendance « chapeau » qui tire toutes les bibliothèques cohérentes pour une fonctionnalité, avec des versions déjà accordées entre elles. Au lieu d'assembler à la main une dizaine de jars compatibles, vous déclarez un seul artefact :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>spring-boot-starter-web apporte Spring MVC, un serveur Tomcat embarqué, Jackson (JSON), la validation… tout ce qu'il faut pour une API REST. Autres starters courants : -data-jpa (persistance), -security (authentification), -validation, -mail, -actuator (supervision). Le parent BOM (spring-boot-starter-parent) gère les versions : vous ne les précisez plus, tout est aligné et testé ensemble.
L'auto-configuration : la convention plutôt que la configuration
La deuxième idée est plus subtile. Au démarrage, Spring Boot examine le classpath et configure automatiquement ce qu'il détecte. Il trouve le driver H2 ? Il configure une base en mémoire. Il voit spring-boot-starter-web ? Il lance un serveur web sur le port 8080. Ce mécanisme repose sur des classes annotées @Conditional : « si telle classe est présente et qu'aucun bean équivalent n'est déjà défini, alors configure ceci ».
La règle : des valeurs par défaut sensées, que vous ne surchargez que lorsque vous en avez besoin. On appelle cela « convention over configuration ».
Reprendre la main quand il le faut
L'auto-configuration n'est pas une boîte noire fermée. Vous gardez le contrôle à plusieurs niveaux :
application.yml— surcharger les propriétés (port, URL de base, pool de connexions…).- Définir votre propre bean — Spring Boot recule dès que vous fournissez le vôtre (grâce à
@ConditionalOnMissingBean). - Diagnostiquer — lancez avec
--debugpour voir le « Conditions Evaluation Report » : ce que Boot a configuré, et pourquoi.
# application.yml — surcharger sans code
server:
port: 9000
spring:
datasource:
url: jdbc:postgresql://localhost/appLe point d'entrée
Tout tient dans une classe minuscule. @SpringBootApplication combine trois annotations : @Configuration, @EnableAutoConfiguration et @ComponentScan.
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}Créer un projet en 30 secondes
Le site start.spring.io (Spring Initializr) génère un squelette prêt à l'emploi : choisissez le gestionnaire (Maven/Gradle), la version de Java, et cochez les starters voulus. Vous obtenez un projet qui démarre du premier coup — la meilleure façon de commencer.
En résumé
Spring Boot n'est pas magique : les starters assemblent des dépendances cohérentes, l'auto-configuration applique des défauts raisonnables selon ce qu'elle détecte, et vous reprenez la main dès que nécessaire via des propriétés ou vos propres beans. Comprendre ce contrat — défauts intelligents, surcharge facile — vous rend bien plus efficace et vous évite de « subir » le framework.