Spring Boot : passer de Java à une vraie architecture
Comprenez le rôle du conteneur Spring, évitez les pièges des tutoriels et construisez un projet progressif pour relier Java à une application réaliste.
De Java à Spring Boot : comprendre ce qui se passe vraiment
Vous savez créer des classes Java, utiliser l'héritage et organiser du code en objets. Puis vous ouvrez un projet Spring Boot : annotations, beans, contexte applicatif, configuration automatique. Les exemples marchent... mais il reste une question : comment tout ça s'assemble dans une application réellement utilisée, avec des utilisateurs, des erreurs et des contraintes ?
Ce décalage est normal. Un exercice isolé montre comment déclarer un bean ou lancer un contrôleur, mais il dit moins bien qui fabrique quoi, qui déclenche quoi, et ce qui se passe quand plusieurs composants doivent coopérer. Du coup, le défi n'est pas seulement d'apprendre de nouvelles annotations. Il faut surtout changer de focale : passer d'un raisonnement « objets » à un raisonnement « cycle de vie » et « responsabilités ».
Voici une méthode pour faire cette transition sans traiter Spring comme une boîte noire. On clarifiera le rôle du conteneur, on gardera ce qui est utile (et on évitera le superflu), puis on construira un plan d'apprentissage solide pour toucher les vrais sujets d'architecture, sans démarrer par une application démesurée.
Pourquoi le passage de Java à Spring Boot semble-t-il abstrait ?
En Java « classique », vous créez généralement les objets vous-même : une classe instancie une autre classe, lui passe ses dépendances, puis appelle ses méthodes. Dans un petit exercice, le flux est visible dans le code.
Avec Spring, une partie de ce travail est confiée au conteneur : il crée des objets gérés, relie les dépendances entre eux, puis lance l'application.
Le code métier n'a pas disparu. Ce qui change, c'est l'endroit où certaines décisions sont prises. Au lieu d'écrire partout new Service(...), vous décrivez des composants et leurs relations. Spring construit ensuite le graphe d'objets à partir de cette description. On a vite l'impression de « magie », mais en réalité il s'agit surtout d'un mécanisme d'assemblage exécuté par le framework.
Les exercices isolent les mécanismes, pas les conséquences
Un cours qui montre @Component ou @Lazy répond souvent à une question locale : comment marquer une classe, ou différer sa création ? Très bien, mais ce n'est pas tout.
Une vraie application pose d'autres questions : qui appelle ce composant ? Quelles données il manipule ? Comment gérer les erreurs ? Et comment le tester sans démarrer toute la machine ?
C'est pour ça que comprendre la syntaxe ne suffit pas. Une annotation peut être « parfaitement comprise » et rester inutile dans votre projet. À l'inverse, l'injection de dépendances devient concrète dès que vous remplacez une implémentation (par exemple une base de données) et que vous voulez tester un service sans dépendre de cette base.
Le changement de modèle mental
Pour progresser, reliez chaque notion à trois questions simples :
- Qui porte la responsabilité ? Le contrôleur reçoit la requête et applique une partie des règles, ou il délègue tout au service ?
- Qui crée et configure l'objet ? Votre code directement, une configuration explicite, ou le conteneur Spring ?
- Comment vérifier que ça marche ? Test unitaire, test d'intégration, ou vérification via l'API ?
Ce cadre évite d'apprendre les annotations comme une liste de mots à placer. Vous remettez chaque concept dans une chaîne de responsabilités. Et souvent, le vrai tournant arrive au premier projet où une modification traverse plusieurs couches : requête HTTP, règle métier, persistance, puis réponse au client.
Que fait réellement le conteneur Spring ?
Le conteneur Spring crée et gère les objets que l'application lui confie. Ces objets s'appellent beans. Il lit la configuration, repère les composants, puis résout leurs dépendances. Spring Boot s'appuie sur ce mécanisme et ajoute des conventions et une configuration automatique pour démarrer plus vite.
Cette distinction évite un piège fréquent : tout attribuer à Spring Boot. Le conteneur et l'injection de dépendances viennent du cœur de Spring ; Boot rend surtout l'installation et la configuration plus simples. Si vous comprenez cette séparation, vous raisonnez sur ce que fait vraiment le framework, au lieu de mémoriser l'idée qu'une dépendance « apparaît » sans savoir pourquoi.
Des composants et des dépendances explicites
@Component, @Service et @Repository indiquent à Spring que la classe peut être détectée et gérée. @RestController désigne un composant orienté vers le traitement des requêtes HTTP.
Ces annotations ont des rôles différents et des conventions associées, mais elles ne remplacent pas une architecture. Elles ne décident pas, à votre place, où mettre une règle métier.
Pour une application standard, l'injection par constructeur rend les dépendances visibles et facilite les tests :
@Service
public class CommandeService {
private final CommandeRepository repository;
public CommandeService(CommandeRepository repository) {
this.repository = repository;
}
}
Le service dit clairement ce dont il a besoin. Il ne choisit pas comment le dépôt est construit. Et si vous changez d'implémentation (ou si vous remplacez le dépôt en test), vous voyez où intervenir. En revanche, ça n'a aucun intérêt d'ajouter des abstractions partout : créez une interface quand il y a une frontière utile, pas juste pour « faire propre ».
ApplicationContext et initialisation différée : à utiliser quand c'est nécessaire
ApplicationContext donne accès au conteneur (par exemple pour récupérer des beans). Ça peut se justifier dans des cas d'infrastructure où vous devez découvrir une implémentation à l'exécution.
Dans le code métier, l'accès direct au conteneur contourne souvent l'injection : les dépendances deviennent moins visibles, et les tests deviennent plus pénibles. Quand une classe a besoin d'un service, le plus simple reste de l'exprimer dans son constructeur.
@Lazy retarde la création d'un bean jusqu'à sa première utilisation (ou peut retarder la résolution d'une dépendance). Ce n'est pas une optimisation automatique à appliquer partout. Ça peut aider si un composant coûteux n'est presque jamais utilisé... mais ça reporte aussi le coût et parfois le diagnostic d'erreurs au premier appel. Avant de l'ajouter, regardez le problème, puis confirmez le cycle de vie attendu.
La règle de base : commencez avec l'assemblage standard et explicite. Ajoutez ApplicationContext ou @Lazy seulement quand vous pouvez expliquer le besoin (et le coût).
Comment passer des exemples à un projet réaliste ?
Une application « réaliste » ne se limite pas à un contrôleur qui renvoie une chaîne de caractères. Il faut gérer des entrées imparfaites, des erreurs, des changements de configuration, et surtout la façon dont vous testez le tout.
L'objectif d'un projet d'apprentissage n'est pas de simuler toute une entreprise. C'est de faire apparaître des problèmes que vous pourrez comprendre de bout en bout.
Commencez par suivre une requête complète. Un client envoie une demande HTTP ; un contrôleur lit l'entrée ; un service applique une règle ; un dépôt lit ou écrit des données ; l'application construit la réponse. Si vous pouvez expliquer ce parcours et justifier le rôle de chaque étape, vous êtes sorti du stade « copier-coller des exemples ».
Séparez les responsabilités sans tomber dans le formalisme
Au départ, vous pouvez distinguer contrôleurs, services et accès aux données. Le contrôleur gère le protocole HTTP et la validation de la requête. Le service porte les règles du cas d'usage. Le dépôt isole la persistance.
Cette séparation aide à tester et à faire évoluer le code. Mais elle n'exige pas de créer une interface et une classe pour chaque « petite idée ». Si une couche ne fait que transmettre un appel sans ajouter de responsabilité, vous payez surtout de la complexité.
Une architecture est utile si elle rend les changements moins risqués ou clarifie le fonctionnement. Elle devient du cérémonial si chaque modification vous force à toucher trop de fichiers sans gain clair.
Ajoutez les contraintes dans un ordre qui vous apprend quelque chose
Une progression simple peut ressembler à ça :
- Définir quelques opérations métier et leur représentation en Java.
- Les exposer via une API REST et vérifier que les réponses sont cohérentes.
- Ajouter la persistance, puis gérer les erreurs de lecture ou d'écriture.
- Valider les entrées et définir des erreurs compréhensibles pour le client.
- Écrire des tests unitaires pour les règles et des tests d'intégration pour les interactions importantes.
- Mettre en place une configuration séparée pour le développement et les tests, sans secrets dans le dépôt.
Chaque étape doit répondre à un besoin réel. Par exemple, la validation n'est pas une décoration : sans elle, une donnée invalide peut partir directement dans la logique métier ou jusqu'à la base. Et les tests d'intégration ne remplacent pas les tests unitaires : ils confirment que plusieurs morceaux (contrôleur et persistance, par exemple) marchent ensemble.
Vérifiez le comportement, pas seulement le démarrage
Oui, « ça démarre » veut dire que la configuration de base est cohérente. Mais ça ne prouve pas que les cas d'usage fonctionnent.
Testez : réponses attendues, données invalides, ressources absentes et erreurs de persistance pertinentes. Et gardez trace de vos choix : pourquoi cette règle est au bon endroit ? Pourquoi cette opération est transactionnelle ? Pourquoi tel profil de configuration existe ?
Dans un contexte professionnel, ces explications évitent des heures de discussion en revue de code. Elles aident aussi un autre développeur à comprendre les compromis sans tout reconstruire mentalement à partir du code.
Quel projet construire pour apprendre Spring Boot ?
Un bon projet de transition est assez petit pour être fini, mais assez riche pour vous obliger à traverser la pile complète. Un service de réservation de créneaux, un suivi de dépenses ou une gestion de commandes conviennent mieux qu'une « collection de classes » sans comportement.
Pour rester concret dans le contexte français, vous pouvez créer une API de suivi des notes de frais d'une petite équipe. Pas besoin d'aller chercher des données sensibles ni de prétendre reproduire un outil comptable réglementaire.
Le but, c'est d'être obligé de prendre des décisions : quelles données sont nécessaires ? Comment éviter un état incohérent ? Comment signaler une erreur ? Comment vérifier que le résultat tient encore après une modification ?
Définissez un périmètre livrable
Par exemple, une première version pourrait permettre de créer une dépense, la consulter, la modifier et la supprimer. Vous pouvez ajouter des catégories, un montant en euros, une date et un statut de remboursement. Une règle simple - par exemple refuser un montant nul ou négatif - suffit pour avoir un vrai cas métier.
Évitez de commencer par l'authentification, les rôles, les notifications, le déploiement sur plusieurs environnements et une architecture distribuée. Ces sujets viendront plus tard. Pour apprendre Spring Boot, mieux vaut une API locale avec une base relationnelle et des tests : c'est déjà un terrain de travail largement suffisant.
Une feuille de route en quatre livraisons
Livraison 1 : le parcours HTTP. Créez les opérations principales, définissez les formats d'entrée et de sortie, puis vérifiez les codes de réponse. Gardez la logique au minimum : l'objectif est de comprendre le rôle du contrôleur.
Livraison 2 : les règles métier. Déplacez la logique dans un service. Ajoutez la validation des données et un traitement cohérent des erreurs. Testez le service sans démarrer le serveur web.
Livraison 3 : les données durables. Introduisez une base de données et un dépôt. Vérifiez que les données survivent au redémarrage. Ajoutez des tests d'intégration pour les opérations importantes et, si vous faites évoluer le modèle, une stratégie de migration de schéma.
Livraison 4 : la qualité de fonctionnement. Séparez la configuration locale et celle des tests, documentez les variables nécessaires et vérifiez les parcours principaux via des tests. Ensuite seulement, vous pouvez étudier la sécurité ou le déploiement, si et quand il y a un besoin.
Comment savoir si le projet vous a fait progresser ?
Vous n'avez pas besoin de dix fonctionnalités. Vous progressez si vous pouvez répondre clairement à ces questions :
- Quel composant reçoit la requête ?
- Où se trouve la règle métier ?
- Qui crée le dépôt (et comment) ?
- Comment le test remplace une dépendance ?
- Que se passe-t-il si l'identifiant demandé n'existe pas ?
Un bon indicateur, c'est aussi le coût d'un changement. Si vous pouvez modifier une règle sans réécrire le contrôleur et sans redémarrer toute l'application pour tester chaque cas, vos responsabilités commencent à se tenir. À l'inverse, si chaque ajout exige une nouvelle couche, une nouvelle annotation et plusieurs contournements, simplifiez : il y a probablement trop de « forme » et pas assez de compréhension.
Conclusion : apprendre Spring en suivant les responsabilités
Le passage de Java à Spring Boot devient beaucoup plus clair quand vous arrêtez de chercher les annotations « comme sujet principal ». Le vrai sujet, c'est le graphe d'objets que Spring assemble, le cycle de vie des composants, et la façon dont les responsabilités circulent dans votre application.
Commencez avec l'injection par constructeur, une séparation simple entre API, logique métier et persistance, puis ajoutez validation et tests au rythme des besoins. Gardez ApplicationContext et @Lazy pour les cas où vous pouvez expliquer l'intérêt - et le coût. Un projet modeste, fini et testé vous apprendra plus qu'une architecture ambitieuse dont les couches restent floues.
Votre prochain pas peut être très concret : choisissez un petit cas d'usage, implémentez une requête de bout en bout, puis ajoutez une règle métier et un test. Si vous pouvez expliquer chaque décision et modifier le comportement sans perdre le fil, le « mode Spring » devient un outil plutôt qu'une boîte noire.