Pourquoi votre application se comporte différemment en staging et en production

Vous déployez le même code en staging, vous exécutez vos tests, tout passe. Puis vous déployez en production, et l'application plante. Le code est identique. La différence est une simple valeur de configuration que vous avez oublié de mettre à jour.

Ce scénario se produit chaque semaine dans les équipes. Le code est bon. La configuration ne l'est pas. Et quand le problème concerne un secret comme un mot de passe de base de données ou un jeton API, les enjeux sont encore plus élevés. Un secret divulgué peut causer plus de dégâts que la plupart des bugs de code.

Ce que sont réellement la configuration et les secrets

La configuration est toute valeur qui modifie le comportement de votre application sans changer son code. Adresses de serveurs, nombre maximum de connexions, niveaux de journalisation, feature flags — tout cela est de la configuration. La même base de code s'exécute différemment en développement, staging et production parce que la configuration change.

Les secrets sont une catégorie spéciale de configuration. Ce sont des valeurs qui doivent rester confidentielles : mots de passe, jetons, clés de chiffrement, certificats. Les secrets nécessitent un traitement différent car leur exposition est un incident de sécurité, pas seulement une erreur de configuration.

Le point clé est que la configuration et les secrets doivent être gérés séparément du code de votre application. Ils vivent dans une couche différente de votre système de livraison.

Commencez par un modèle de configuration

Avant de pouvoir gérer correctement la configuration, vous devez savoir de quelle configuration votre application a réellement besoin. Un modèle de configuration est simplement une liste complète de chaque valeur de configuration attendue par votre application, organisée par environnement.

Pour chaque élément de configuration, notez :

Voici un exemple concret de ce à quoi un tel modèle pourrait ressembler en YAML :

# config-template.yaml
# Modèle de configuration d'application
# Surcharger les valeurs par environnement dans des fichiers spécifiques

app:
  name: my-app
  version: 1.0.0
  log_level: info  # surcharge : dev=debug, staging=info, prod=warn
  max_retry: 3

database:
  host: localhost  # surcharge : staging=db-staging.example.com, prod=db-prod.example.com
  port: 5432
  name: myapp_db
  pool_size: 10  # surcharge : prod=50

cache:
  host: localhost  # surcharge : staging=redis-staging.example.com, prod=redis-prod.example.com
  port: 6379
  ttl_seconds: 3600

feature_flags:
  new_checkout: false  # surcharge : staging=true, prod=false
  dark_mode: true

• Le nom de la variable (comme DB_HOST ou MAX_RETRY)
• Le type de valeur (chaîne, nombre, booléen)
• Quels environnements l'utilisent
• Si la valeur diffère entre les environnements

Certaines valeurs seront les mêmes partout. MAX_RETRY pourrait être 3 en développement, staging et production. D'autres valeurs doivent différer. DB_HOST pointera vers votre base de données locale en développement et vers votre cluster de base de données de production en production.

Le modèle doit également indiquer qui peut modifier chaque valeur de configuration et comment ces modifications sont suivies. Tout le monde dans l'équipe ne devrait pas pouvoir modifier les chaînes de connexion à la base de données de production.

Les secrets ont besoin de leur propre modèle

Les secrets suivent la même idée mais avec des règles plus strictes. Un modèle de secret enregistre :

• Le nom du secret
• D'où il vient (coffre, magasin de paramètres, fichier chiffré)
• Quels environnements ont besoin d'y accéder
• Quand il a été roté pour la dernière fois
• Combien de temps il est valide
• Les étapes exactes pour le roter
• Comment vérifier que l'application fonctionne toujours après la rotation

La rotation est le processus de remplacement d'un ancien secret par un nouveau selon un calendrier régulier. De nombreuses équipes sautent cette étape jusqu'à ce qu'une brèche les force à agir. Un modèle fait de la rotation une opération de routine plutôt qu'une urgence.

L'étape de vérification est cruciale. Après avoir roté un mot de passe de base de données, vous devez confirmer que votre application peut toujours se connecter et interroger les données. Sinon, vous pourriez roter le secret et casser la production sans vous en rendre compte jusqu'à ce que les utilisateurs commencent à signaler des erreurs.

Auditez tout

La configuration et les secrets ont besoin de pistes d'audit. Un journal d'audit enregistre qui a accédé ou modifié une valeur de configuration ou un secret, quand et pourquoi.

Le modèle pour les journaux d'audit doit capturer :

• Horodatage de l'action
• Qui l'a effectuée
• Quelle action a été réalisée (visualiser, modifier, supprimer)
• Quelle configuration ou quel secret a été affecté

Ce journal est essentiel quand quelque chose tourne mal. Si un secret fuit, vous devez savoir qui y a accédé et quand. Si un changement de configuration casse la production, vous devez remonter jusqu'à la personne qui a fait le changement et quelle était la valeur précédente.

Sans journaux d'audit, vous déboguez à l'aveugle. Vous savez que quelque chose a changé, mais vous n'avez aucun moyen de découvrir quoi ou qui en est la cause.

Testez votre configuration et vos secrets

Voici une étape que la plupart des équipes négligent : la configuration et les secrets doivent être testés. Vous testez votre code. Vous testez votre infrastructure. Mais à quelle fréquence testez-vous que votre application peut réellement lire sa configuration et ses secrets correctement dans chaque environnement ?

Un test de configuration vérifie que :

• Toutes les valeurs de configuration requises existent
• Elles ont le bon type
• Elles sont dans les plages attendues
• L'application démarre correctement avec ces valeurs

Un test de secret vérifie que :

• Le secret existe et est accessible
• L'application peut s'authentifier en utilisant le secret
• L'application peut effectuer ses opérations de base après l'authentification

Ces tests détectent les problèmes avant le déploiement. Un secret manquant ou une valeur de configuration mal formatée fera planter votre application au démarrage. Mieux vaut détecter cela dans un test qu'en production.

Une liste de contrôle pratique

Voici une courte liste de contrôle que vous pouvez utiliser lors de la mise en place de la gestion de la configuration et des secrets pour une nouvelle application ou un nouveau service :

• Listez toutes les valeurs de configuration dont l'application a besoin, organisées par environnement
• Notez les valeurs qui diffèrent entre les environnements et celles qui restent identiques
• Identifiez les valeurs qui sont des secrets et nécessitent un traitement spécial
• Documentez la source de chaque secret (coffre, magasin de paramètres, etc.)
• Créez un calendrier de rotation pour chaque secret
• Mettez en place une journalisation d'audit pour l'accès à la configuration et aux secrets
• Écrivez des tests qui vérifient le chargement de la configuration et des secrets dans chaque environnement
• Documentez qui peut modifier chaque valeur de configuration et chaque secret

Ce qu'il faut retenir

La configuration et les secrets ne sont pas une réflexion après coup. Ce sont des préoccupations distinctes qui nécessitent leurs propres modèles, leurs propres tests et leur propre piste d'audit. Le même code qui fonctionne parfaitement en staging échouera en production si une seule valeur de configuration est erronée ou si un seul secret manque. Traitez la configuration et les secrets avec la même rigueur que le code de votre application, et vous éliminerez toute une catégorie d'échecs de déploiement.