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 meme objectif, mais ils different en syntaxe, lisibilite et cas d'utilisation specifiques. Cette comparaison detaille les differences pratiques et couvre les questions d'entretien qui reviennent frequemment sur la configuration externalisee de Spring Boot.

Comparaison Syntaxique Entre YAML et Properties

La difference la plus visible concerne la representation des donnees hierarchiques. Les fichiers Properties utilisent la notation pointee 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 equivalente regroupe visuellement les parametres associes :

# 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 reduit la repetition lorsque plusieurs proprietes partagent le meme prefixe. Dans le fichier properties, spring.datasource apparait trois fois, alors que YAML le declare une seule fois.

Gestion des Profils dans la Configuration Spring Boot

Les profils Spring Boot permettent differentes configurations pour les environnements de developpement, staging et production. Les deux formats supportent les profils, mais YAML les gere de maniere plus elegante.

Avec les fichiers properties, des fichiers separes sont necessaires pour chaque 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 separateur --- :

# 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

Depuis Spring Boot 2.4, la propriete spring.config.activate.on-profile a remplace l'ancienne syntaxe spring.profiles. La documentation Spring Boot detaille l'activation des profils.

Listes et Structures de Donnees Complexes

YAML excelle dans la representation des listes et structures imbriquees. Cela s'avere important pour les configurations comme les regles de securite, les mappings CORS ou les beans personnalises.

# 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'equivalent en properties necessite 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 entree necessite le numero d'index suivant.

Configuration Type-Safe avec @ConfigurationProperties

Spring Boot 3.4 lie les valeurs de configuration aux classes Java via @ConfigurationProperties. Les deux formats fonctionnent de maniere 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 relache de Spring Boot convertit automatiquement entre les differentes conventions de nommage. La propriete app.security.allowed-origins se lie a 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;
    }
    
    // Configuration CORS utilisant 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 frequent dans les entretiens Spring Boot. Les recruteurs evaluent la comprehension de la configuration externalisee, des parametres specifiques a l'environnement et du binding des proprietes.

Question : Quel est l'ordre de precedence des sources de configuration ?

Spring Boot charge la configuration depuis plusieurs sources dans un ordre specifique. Les sources de precedence superieure ecrasent les inferieures :

1. Arguments de ligne de commande (--server.port=9000)
2. Proprietes systeme Java (-Dserver.port=9000)
3. Variables d'environnement du systeme d'exploitation (SERVER_PORT=9000)
4. Properties specifiques au profil (application-{profile}.yml)
5. Properties d'application (application.yml ou application.properties)
6. Annotations @PropertySource
7. Proprietes par defaut via SpringApplication.setDefaultProperties

Un candidat qui connait cet ordre demontre sa comprehension de la facon dont Spring Boot resout les valeurs conflictuelles.

Question : Quand choisir properties plutot que YAML ?

Les fichiers properties presentent des avantages dans des situations specifiques :

• Support IDE : Certains IDE anciens offrent une meilleure autocompletion pour les fichiers .properties
• Familiarite de l'equipe : La syntaxe properties est plus simple pour les developpeurs debutant avec Spring Boot
• Valeurs sur une seule ligne : Les configurations plates sans imbrication ne gagnent rien avec YAML
• Integration outils de build : Le filtrage de ressources Maven et Gradle fonctionne directement avec properties

YAML fonctionne mieux quand :

• La configuration a une imbrication profonde (trois niveaux ou plus)
• Plusieurs profils appartiennent a un seul fichier
• Les listes necessitent des modifications frequentes
• La lisibilite compte pour les configurations complexes

Question : Comment gerer les valeurs de configuration sensibles ?

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

# application.yml - reference variable d'environnement
spring:
  datasource:
    password: ${DB_PASSWORD}

Pour les systemes de production, Spring Cloud Config Server ou HashiCorp Vault fournissent une gestion centralisee des secrets. Le guide de monitoring Actuator couvre la securisation des endpoints sensibles.

Validation de Configuration dans Spring Boot 3.4

Spring Boot valide les classes @ConfigurationProperties au demarrage lorsqu'elles sont combinees 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 negatif, l'application echoue rapidement au demarrage avec un message d'erreur clair. Cette validation fonctionne de maniere identique pour les sources YAML et properties.

Fichiers de Configuration Specifiques a l'Environnement

Spring Boot 3.4 supporte des emplacements de fichiers de configuration supplementaires au-dela du src/main/resources par defaut. La propriete spring.config.import charge des fichiers externes :

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

Le prefixe optional: empeche l'echec du demarrage lorsque le fichier n'existe pas. Ce pattern permet le developpement local avec des valeurs par defaut tandis que la production recupere la configuration depuis un serveur central.

Points Cles pour la Configuration Spring Boot

• YAML reduit la repetition pour les configurations avec des prefixes partages et gere les listes plus proprement
• Les fichiers properties fonctionnent bien pour les configurations plates et les equipes moins familieres avec la syntaxe YAML
• Spring Boot 3.4 traite les deux formats de maniere egale pour le binding et la validation @ConfigurationProperties
• La gestion des profils en YAML garde les environnements associes dans un seul fichier, reduisant la proliferation des fichiers
• La precedence de configuration suit un ordre defini : les arguments de ligne de commande ecrasent les variables d'environnement, qui ecrasent la configuration basee sur fichier
• Les valeurs sensibles appartiennent aux variables d'environnement ou aux systemes de gestion de secrets, jamais aux fichiers sous controle de version
• Utiliser spring.config.import pour charger la configuration depuis des sources externes dans les environnements de production