30 quater. Configuration et flags : gouverner les décisions à l'exécution
Pourquoi ce chapitre existe
La configuration est souvent perçue comme ce qui évite un déploiement : une valeur d'environnement, une règle distante, un feature flag. Cette souplesse a un coût. Une valeur mal nommée peut changer un comportement critique sans revue de code ; des environnements peuvent dériver ; un flag abandonné peut multiplier les chemins impossibles à tester ; un secret peut apparaître dans un log de diagnostic. La configuration est du logiciel qui s'exécute à un autre moment et sous une autre gouvernance.
Les idées essentielles
- Toute configuration modifie un comportement, une capacité ou un accès ; elle mérite une source, un propriétaire et une traçabilité proportionnés.
- Les flags séparent déploiement et exposition, mais doivent avoir une cible, une durée, une règle d'activation et un plan de retrait.
- Valeurs par défaut, validation de schéma, droits d'écriture et audit limitent les erreurs de configuration.
- Secrets, paramètres et décisions métier n'ont pas les mêmes cycles de vie et ne doivent pas être gérés comme une seule catégorie.
Classer avant de configurer
Une limite de timeout, une clé API, une règle de remise et un flag de déploiement peuvent tous être des « configurations », mais leurs risques diffèrent. Les regrouper dans un fichier libre sans contrôle rend impossible une gouvernance adaptée.
| Catégorie | Exemple | Contrôle attendu |
|---|---|---|
| Secret | Clé de partenaire | Stockage dédié, accès minimal, rotation, absence de logs |
| Paramètre opérationnel | Timeout, limite de concurrence | Valeur bornée, validation, observabilité et propriétaire |
| Flag de transition | Activation d'un nouveau flux | Cohorte, seuil d'arrêt, durée et nettoyage |
| Règle métier | Éligibilité, tarif, politique | Décision de domaine, audit, tests et droits adaptés |
| Configuration d'environnement | URL, capacité, région | Reproductibilité, comparaison d'environnements, promotion contrôlée |
Rendre le changement observable et réversible
Modifier une configuration critique doit créer une trace : qui a changé quoi, dans quel périmètre, avec quelle justification et quel comportement a été observé ensuite. Cette trace n'est pas une bureaucratie si elle est proportionnée : un ajustement de logging interne n'a pas le même impact qu'une règle qui affecte la facturation ou l'autorisation.
Un flag de transition doit préciser son état attendu, sa cohorte et sa date de retrait dès sa création. Le nombre, l'âge et les combinaisons de flags doivent être visibles. Lorsqu'ils dépassent une limite raisonnable, l'équipe doit décider quels comportements simplifier avant d'en ajouter d'autres.
Anti-patterns
Utiliser un flag pour cacher une décision produit non résolue
Un flag est un mécanisme de transition, pas une manière de laisser tous les comportements possibles vivre indéfiniment. Si une règle métier nécessite plusieurs variantes durables, elle mérite un modèle, des droits et une gouvernance explicites.
Modifier la production sans validation
Une variable mal orthographiée, une valeur hors borne ou un secret manquant peut produire un défaut silencieux. Valider les schémas au démarrage, refuser les configurations impossibles et exposer les valeurs non sensibles réduisent le temps de diagnostic.
Réutiliser des secrets comme paramètres ordinaires
Les secrets exigent une rotation, une journalisation d'accès et une séparation des droits. Les mélanger aux fichiers de configuration ou aux dashboards augmente le risque de fuite et rend leur cycle de vie difficile à gérer.
Bonnes pratiques
Traiter les changements sensibles comme des livraisons
Pour une configuration à fort impact, préparer cohorte, signaux, seuil d'arrêt et responsable de décision. Le changement peut être plus rapide qu'un déploiement de code ; il ne doit pas être moins maîtrisé parce qu'il est invisible dans un diff.
Automatiser le retrait de la complexité de transition
Créer une alerte sur les flags expirés, attacher une échéance au ticket ou refuser les flags sans propriétaire. Le mécanisme importe moins que le fait de rendre le nettoyage impossible à oublier sans laisser un signal.
Checklist — Une configuration peut-elle changer sans surprise ?
- De quelle catégorie relève cette valeur et quel risque de changement porte-t-elle ?
- Qui peut la modifier, dans quel périmètre, avec quelle trace et quelle revue ?
- Les valeurs sont-elles validées, bornées et sûres par défaut ?
- Quel comportement, signal et seuil vérifient son effet après activation ?
- Le secret, le paramètre ou le flag possède-t-il le cycle de vie adapté ?
- Quand et comment la configuration temporaire ou obsolète sera-t-elle retirée ?
À retenir
La configuration est une surface de décision de production. La classer, la valider, l'observer et la retirer avec discipline permet de gagner en souplesse sans créer un second système de comportements invisibles.