Spring Boot YAML vs Properties : comparaison des configurations et questions d'entretien 2026

Spring Boot propose deux formats de configuration natifs : YAML (application.yml) et Properties (application.properties). Les deux permettent d'atteindre le même objectif, mais ils diffèrent en syntaxe, lisibilité et cas d'utilisation spécifiques. Cette comparaison détaille les différences pratiques et couvre les questions d'entretien qui reviennent fréquemment sur la configuration externalisée de Spring Boot.

Properties ou YAML dans Spring Boot : vue d'ensemble

Sur Spring Boot 4.1, la ligne de versions actuelle, les deux formats alimentent le même Environment et se lient de façon identique. Les différences tiennent à la syntaxe, à quelques règles de chargement et à ce qui se passe quand les deux fichiers coexistent.

Les deux dernières lignes sont celles que les candidats oublient le plus souvent. La référence Spring Boot sur la configuration externalisée indique que les fichiers YAML ne peuvent pas être chargés via @PropertySource ni @TestPropertySource, et que lorsque application.properties et application.yml sont côte à côte, la valeur du .properties l'emporte. La recommandation officielle est de choisir un seul format pour toute l'application.

Comparaison syntaxique entre YAML et Properties

La différence la plus visible concerne la représentation des données hiérarchiques. Les fichiers Properties utilisent la notation pointée sur chaque ligne, tandis que YAML utilise l'indentation pour exprimer l'imbrication.

# application.properties
server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=${DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

La configuration YAML équivalente regroupe visuellement les paramètres associés :

# application.yml
server:
  port: 8080
  servlet:
    context-path: /api

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: false

YAML réduit la répétition lorsque plusieurs propriétés partagent le même préfixe. Dans le fichier properties, spring.datasource apparaît trois fois, alors que YAML le déclare une seule fois.

Gestion des profils dans la configuration Spring Boot

Les profils Spring Boot permettent différentes configurations pour les environnements de développement, staging et production. Les deux formats prennent en charge les fichiers par profil et les fichiers multi-documents.

L'approche classique utilise un fichier par profil :

# application-dev.properties
server.port=8080
spring.datasource.url=jdbc:h2:mem:devdb
logging.level.root=DEBUG

# application-prod.properties
server.port=80
spring.datasource.url=jdbc:postgresql://prod-server:5432/proddb
logging.level.root=WARN

YAML supporte la syntaxe multi-document dans un seul fichier en utilisant le séparateur --- :

# application.yml
spring:
  profiles:
    active: dev

---
spring:
  config:
    activate:
      on-profile: dev
server:
  port: 8080
logging:
  level:
    root: DEBUG

---
spring:
  config:
    activate:
      on-profile: prod
server:
  port: 80
logging:
  level:
    root: WARN

Les fichiers properties acceptent la même organisation multi-document. Une ligne contenant uniquement #--- (ou !---) découpe le fichier en documents :

# application.properties
spring.profiles.active=dev
#---
spring.config.activate.on-profile=dev
server.port=8080
logging.level.root=DEBUG
#---
spring.config.activate.on-profile=prod
server.port=80
logging.level.root=WARN

Le séparateur ne doit avoir aucun espace en début de ligne et exactement trois tirets. Depuis Spring Boot 2.4, la propriété spring.config.activate.on-profile a remplacé l'ancienne syntaxe spring.profiles, dans les deux formats.

L'activation des profils, les groupes et les beans @Profile sont travaillés dans le module d'entretien sur les profils et l'environnement.

Listes et structures de données complexes

YAML excelle dans la représentation des listes et structures imbriquées. Cela s'avère important pour les configurations comme les règles de sécurité, les mappings CORS ou les beans personnalisés.

# application.yml
app:
  security:
    allowed-origins:
      - https://sharpskill.dev
      - https://api.sharpskill.dev
    cors:
      allowed-methods:
        - GET
        - POST
        - PUT
        - DELETE
    jwt:
      secret: ${JWT_SECRET}
      expiration-ms: 86400000

L'équivalent en properties nécessite la notation avec index :

# application.properties
app.security.allowed-origins[0]=https://sharpskill.dev
app.security.allowed-origins[1]=https://api.sharpskill.dev
app.security.cors.allowed-methods[0]=GET
app.security.cors.allowed-methods[1]=POST
app.security.cors.allowed-methods[2]=PUT
app.security.cors.allowed-methods[3]=DELETE
app.security.jwt.secret=${JWT_SECRET}
app.security.jwt.expiration-ms=86400000

Ajouter une nouvelle origine dans le fichier YAML signifie simplement ajouter une ligne. En properties, chaque index existant doit rester correct, et la nouvelle entrée nécessite le numéro d'index suivant.

Configuration type-safe avec @ConfigurationProperties

Spring Boot lie les valeurs de configuration aux classes Java via @ConfigurationProperties. Les deux formats fonctionnent de manière identique avec cette annotation.

import org.springframework.boot.context.properties.ConfigurationProperties;
import java.util.List;

@ConfigurationProperties(prefix = "app.security")
public record AppSecurityProperties(
    List<String> allowedOrigins,
    CorsConfig cors,
    JwtConfig jwt
) {
    public record CorsConfig(List<String> allowedMethods) {}
    public record JwtConfig(String secret, long expirationMs) {}
}

Le binding relâché de Spring Boot convertit automatiquement entre les différentes conventions de nommage. La propriété app.security.allowed-origins se lie à allowedOrigins que la source soit YAML ou properties.

import org.springframework.context.annotation.Configuration;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@Configuration
@EnableConfigurationProperties(AppSecurityProperties.class)
public class SecurityConfig {
    
    private final AppSecurityProperties securityProperties;
    
    public SecurityConfig(AppSecurityProperties securityProperties) {
        this.securityProperties = securityProperties;
    }
    
    // CORS configuration using securityProperties.cors().allowedMethods()
}

Pour plus d'informations sur les patterns de configuration Spring Security, consulter le module bases Spring Security.

Questions d'entretien courantes sur la configuration Spring Boot

La configuration est un sujet fréquent dans les entretiens Spring Boot. Les recruteurs évaluent la compréhension de la configuration externalisée, des paramètres spécifiques à l'environnement et du binding des propriétés.

Question : Quel est l'ordre de précédence des sources de configuration ?

Spring Boot charge la configuration depuis plusieurs sources dans un ordre spécifique. Les sources de précédence supérieure écrasent les inférieures (liste simplifiée par rapport à la liste officielle, qui couvre aussi JNDI, les paramètres de servlet et les annotations de test) :

1. Arguments de ligne de commande (--server.port=9000)
2. SPRING_APPLICATION_JSON (JSON inline dans une variable d'environnement ou une propriété système)
3. Propriétés système Java (-Dserver.port=9000)
4. Variables d'environnement du système d'exploitation (SERVER_PORT=9000)
5. Fichiers de config data (application.yml, application.properties et leurs variantes par profil)
6. Annotations @PropertySource
7. Propriétés par défaut via SpringApplication.setDefaultProperties

L'étape 5 a son propre ordre interne : les fichiers spécifiques à un profil écrasent les fichiers génériques, et les fichiers situés hors du jar packagé écrasent ceux qui sont dedans. Au sein d'un même emplacement, .properties écrase .yml. Un candidat capable d'expliquer pourquoi une valeur définie dans application.yml est ignorée sans message (un application.properties oublié juste à côté) montre une vraie expérience du débogage.

Question : Quand choisir properties plutôt que YAML ?

Les fichiers properties présentent des avantages dans des situations spécifiques :

• Chargement via @PropertySource : YAML ne peut pas être chargé de cette façon, les fichiers supplémentaires importés par l'annotation doivent donc être des .properties
• Familiarité de l'équipe : la syntaxe properties est plus simple pour les développeurs débutant avec Spring Boot
• Valeurs sur une seule ligne : les configurations plates sans imbrication ne gagnent rien avec YAML
• Pas d'erreur d'indentation : un espace mal placé en YAML déplace une clé sous le mauvais parent sans aucun avertissement

YAML fonctionne mieux quand :

• La configuration a une imbrication profonde (trois niveaux ou plus)
• Les listes nécessitent des modifications fréquentes
• La lisibilité compte pour les configurations complexes

Question : Comment gérer les valeurs de configuration sensibles ?

Ne jamais committer de secrets dans le contrôle de version. Spring Boot propose plusieurs approches :

# application.yml - reference environment variable
spring:
  datasource:
    password: ${DB_PASSWORD}

Pour les systèmes de production, Spring Cloud Config Server ou HashiCorp Vault fournissent une gestion centralisée des secrets. Le guide de monitoring Actuator couvre la sécurisation des endpoints sensibles.

Question : Qu'est-ce que Jasypt et comment chiffre-t-il les propriétés Spring Boot ?

Jasypt Spring Boot déchiffre les valeurs encadrées par ENC(...) au moment où l'Environment est construit. Les secrets chiffrés peuvent donc vivre dans application.yml ou application.properties et se lier comme des valeurs en clair :

# application.properties
spring.datasource.password=ENC(nrmZtkF7T0kjG/VodDvBw93Ct8EgjCA+)

# The master password is supplied at runtime, never committed
java -Djasypt.encryptor.password=$JASYPT_MASTER_KEY -jar app.jar

jasypt.encryptor.password est la seule propriété obligatoire, et l'algorithme par défaut est PBEWITHHMACSHA512ANDAES_256. Le format ne change rien : la même valeur ENC(...) fonctionne en YAML comme en properties.

La réponse qui distingue un profil senior : Jasypt ne supprime pas le secret, il le déplace. Quiconque détient le mot de passe maître peut déchiffrer toutes les valeurs du dépôt, et le changer impose de rechiffrer chacune d'elles. Vault ou un gestionnaire de secrets cloud ajoute le contrôle d'accès, l'audit et la rotation, ce que Jasypt ne fait pas.

Valider @ConfigurationProperties au démarrage

Spring Boot valide les classes @ConfigurationProperties au démarrage lorsqu'elles sont combinées avec les annotations Jakarta Bean Validation.

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Positive;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "app.database")
public record DatabaseProperties(
    @NotBlank String url,
    @NotBlank String username,
    @Positive int poolSize
) {}

Si app.database.pool-size est manquant ou négatif, l'application échoue rapidement au démarrage avec un message d'erreur clair. Cette validation fonctionne de manière identique pour les sources YAML et properties.

Fichiers de configuration spécifiques à l'environnement

Spring Boot supporte des emplacements de fichiers de configuration supplémentaires au-delà du src/main/resources par défaut. La propriété spring.config.import charge des fichiers externes :

# application.yml
spring:
  config:
    import:
      - optional:file:./config/
      - optional:configserver:http://config-server:8888

Le préfixe optional: empêche l'échec du démarrage lorsque le fichier n'existe pas. Ce pattern permet le développement local avec des valeurs par défaut tandis que la production récupère la configuration depuis un serveur central. D'autres questions d'entraînement sur ces fichiers se trouvent dans le module d'entretien application.properties et YAML.

Sources

• Référence Spring Boot : Externalized Configuration : ordre des sources de propriétés, fichiers properties multi-documents #---, priorité de .properties sur YAML, pas de YAML dans @PropertySource
• Versions de Spring Boot : 4.1.2 est la version GA actuelle (octobre 2026)
• README de Jasypt Spring Boot : syntaxe ENC(...), algorithme par défaut, exigence Spring Boot 3.5+

Points clés pour la configuration Spring Boot

• YAML réduit la répétition pour les configurations avec des préfixes partagés et gère les listes plus proprement
• Les fichiers properties fonctionnent bien pour les configurations plates et les équipes moins familières avec la syntaxe YAML
• Spring Boot 4.1 traite les deux formats de manière égale pour le binding et la validation @ConfigurationProperties
• Les deux formats acceptent plusieurs profils dans un même fichier : --- en YAML, #--- en properties
• Quand les deux fichiers existent au même emplacement, .properties l'emporte, et seuls les fichiers properties peuvent être chargés avec @PropertySource
• La précédence de configuration suit un ordre défini : les arguments de ligne de commande écrasent les variables d'environnement, qui écrasent la configuration basée sur fichier
• Les valeurs sensibles appartiennent aux variables d'environnement ou aux systèmes de gestion de secrets ; les valeurs Jasypt ENC(...) ne font que déplacer le secret vers le mot de passe maître
• Utiliser spring.config.import pour charger la configuration depuis des sources externes dans les environnements de production