10 erreurs de gestion de configuration en production

Gestion de la configuration des applications : 10 erreurs à éviter en production

Des délais d’attente mal configurés, des secrets exposés ou des limites de ressources inadaptées provoquent des pannes plus rapidement que les bogues logiques. Contrairement au code, la configuration échappe souvent aux revues, aux tests automatisés et aux pipelines CI — créant des risques silencieux : services écrivant dans la mauvaise base de données, épuisant les pools de connexions ou divulguant des identifiants. L’analyse d’incidents réels a révélé 10 erreurs subtiles de configuration qui restent invisibles jusqu’à ce que la panne survienne.

Délais d’attente codés en dur : plus de 30 occurrences dans le code

Coder en dur les délais d’attente oblige à reconstruire l’application pour toute modification. Une recherche grep sur Duration.ofSeconds a révélé plus de 30 occurrences dispersées, avec des valeurs incohérentes : 10 s dans NotificationService, 30 s dans SearchService, 15 s dans ApiRoutes.

private static final Duration TIMEOUT = Duration.ofSeconds(10);  // NotificationService
private static final Duration TIMEOUT = Duration.ofSeconds(30);  // SearchService
private static final Duration TIMEOUT = Duration.ofSeconds(10);  // AuthFilter
private static final Duration TIMEOUT = Duration.ofSeconds(15);  // ApiRoutes

Sous charge, l’ajustement des délais est critique — mais le codage en dur tue l’agilité. Solution : Externalisez-les dans la configuration, avec possibilité de surcharge via des variables d’environnement.

Absence de validation : effacement accidentel de bases de données de production

Une classe de configuration de 695 lignes ne valide qu’un seul paramètre. Tous les autres sont acceptés sans contrôle : pool de connexions = 0, délai = -1, URL de base de données vide.

String authType = config.getString("authType");
if (!Set.of("kerberos", "jwt").contains(authType)) {
    throw new IllegalArgumentException("Type d’authentification invalide. Valeurs autorisées : kerberos, jwt");
}

Des exemples dangereux incluent http.server.parsing.max-content-length = 10g : une seule requête consomme 10 Go de RAM. Ou encore dropAll = ${?DROP_ALL} dans Liquibase — qui supprime intégralement votre schéma sans confirmation. Détecter les erreurs dès le démarrage évite les incidents.

Valeurs par défaut masquant les échecs

Les valeurs par défaut cachent l’absence de clés jusqu’à l’exécution. Lors de l’activation du SSO :

Duration maxResponseDelay = ssoEnabled
    ? config.getDuration("sso.maxResponseDelay")
    : Duration.ofMinutes(10);
long responseCacheSize = ssoEnabled
    ? config.getLong("sso.responseCacheSize")
    : 10_000;

L’absence de clés fait planter la production. De même, tokenTtl passe silencieusement de 1 min (dans la config) à 3 min (en code), violant les politiques de sécurité.

• Le piège des valeurs par défaut : les erreurs de configuration restent invisibles jusqu’à l’activation de la fonctionnalité.
• Solution : Validez toutes les clés obligatoires au démarrage ; journalisez un avertissement si une valeur par défaut est utilisée.

Dérive de configuration entre test et production

Les configurations de test s’écartent fortement de celles de production, par ordres de grandeur :

| Paramètre | Production | Test |

|-----------|------------|------|

| api.responseLimit | 10 Mo | 1 Go |

| api.contextLimit | 10 Mo | 1 Mo |

Une réponse de 50 Mo passe les tests mais échoue en production. À l’inverse, des configurations de test trop restrictives génèrent des faux négatifs.

Nommage incohérent des paramètres

Un seul fichier application.conf mélange plusieurs conventions :

fileStoragePath = "/opt/storage"          # camelCase
retention-days = 7                        # kebab-case
createdump-interval-seconds = 240         # hybride
usage-threshold = 80                      # kebab-case
compressHeapDump = true                   # camelCase

Les booléens varient largement : sslValidationEnabled, smtpSslEnable, saml.enabled, isUseSecureCookieJWT. Les surcharges par environnement échouent silencieusement : smtpSslEnable → SMTP_SSL_ENABLED (mais Enable ≠ Enabled).

• Mélange de camelCase et kebab-case dans un même fichier.
• Incohérence entre les clés HOCON et les variables d’environnement.
• Quatre conventions distinctes pour les indicateurs booléens.

Drapeaux de fonctionnalités fantômes sans gestion de cycle de vie

16 drapeaux dans la classe Config : ws-cache-enabled=false partout, history-import-enabled=true systématiquement. Aucune date de création, aucun propriétaire, aucune justification de suppression — la charge cognitive s’accumule.

• À ajouter : date de création, propriétaire, objectif et échéance de dépréciation.
• À supprimer : les drapeaux immortels — toujours true/false et jamais utilisés.

Ordre incorrect des surcharges HOCON

En HOCON, la dernière valeur définie l’emporte. Correct :

key = "valeur-par-défaut"
key = ${?ENV_OVERRIDE}

Incorrect :

dump {
  enabled = ${?DUMP_ENABLED}
  enabled = false
  directory = ${?DUMP_DIR}
  directory = "opt/myapp/dumps/auto"
}

La surcharge par environnement est écrasée par false — les dumps restent désactivés.

Configuration non documentée : plus de 100 paramètres, zéro clarté

Le fichier docker.md liste des variables d’environnement comme EMAIL_ENABLED=false/true — sans description. AppConfig.java fait 695 lignes, sans une seule ligne de Javadoc. Que contrôle sync-request-timeout-seconds=600 ? Que se passe-t-il si workflowStepLimit=200 atteint 0 ou 100000 ?

URL externes et niveaux de journalisation codés en dur

Les points de terminaison API intégrés au code nécessitent une reconstruction pour tout changement. Les niveaux de journalisation intégrés aux images Docker obligent à monter des volumes ou à reconstruire l’image rien que pour activer le niveau DEBUG.

Points clés à retenir :

• Externalisez tous les paramètres — et validez-les rigoureusement au démarrage.
• Appliquez une convention de nommage unique, cohérente entre fichiers HOCON et variables d’environnement.
• Documentez chaque paramètre : type, plage de valeurs autorisée, valeur par défaut et impact métier.
• Privilégiez le « échec immédiat » plutôt que les retours silencieux.
• Gérez les drapeaux de fonctionnalités avec discipline : propriétaire, objectif et date de fin de vie.

— Editorial Team