Comment séparer configuration, code et contenu sur un site ?

Sur un site fait main, trois natures de données cohabitent et se confondent presque toujours : le code, qui décrit un comportement, la configuration, qui décrit un environnement, et le contenu, qui décrit ce que le site raconte. Tant que le projet est petit, les mélanger ne pose pas de problème visible. Le jour où il faut déployer une nouvelle version sans écraser les réglages, monter une préproduction fidèle, ou restaurer un contenu perdu sans revenir en arrière sur le code, l'absence de séparation entre configuration, code et contenu se paie d'un coup. Ce n'est pas une question d'élégance mais d'exploitation : ces trois familles ont des cycles de vie différents, des exigences de sauvegarde différentes et des personnes responsables différentes.

Classer chaque chose dans la bonne famille

Le classement n'est pas toujours évident, et c'est là que se joue la qualité de la séparation. Un critère simple permet de trancher presque tous les cas, et il complète utilement l'organisation que nous décrivons dans nos articles de la rubrique création de site Internet consacrés aux projets sur mesure.

Le critère qui tranche

Il suffit de se demander qui modifie la donnée et à quelle occasion. Ce que modifie un développeur lors d'une évolution est du code. Ce qui change quand on passe d'un serveur à un autre, sans que le comportement du site change, est de la configuration. Ce que modifie un rédacteur ou un gestionnaire sans intervention technique est du contenu. Ce critère résout les cas litigieux mieux que la nature du fichier : un tableau de valeurs écrit en PHP peut parfaitement être du contenu si c'est le client qui le met à jour, et une liste de contenus figée peut être du code si elle ne change qu'avec les évolutions du site.

Les cas frontière les plus courants

Quelques éléments résistent au classement et méritent une décision explicite, notée quelque part. Les textes de l'interface, boutons, messages d'erreur, libellés, sont du code tant que personne d'autre que l'équipe technique ne les modifie, et deviennent du contenu dès qu'on veut les confier à quelqu'un. Les listes de référence, pays, taux de taxe, catégories, sont de la configuration si elles conditionnent un comportement, du contenu si elles s'affichent. Les gabarits d'affichage sont du code, y compris quand ils ressemblent à des documents, parce que les modifier suppose de comprendre ce qu'ils font.

Le piège des valeurs en dur

La forme la plus répandue de mélange consiste à écrire directement dans le code une adresse électronique de contact, un identifiant de compte analytique, un chemin de dossier ou une clé d'accès. Chacune de ces valeurs est de la configuration, et leur présence dans le code oblige à modifier le code pour changer d'environnement, ce qui interdit tout déploiement automatisé sérieux. Le repérage se fait par une recherche textuelle sur les motifs caractéristiques, adresses, chemins absolus, chaînes de caractères longues, et prend une demi journée sur un projet moyen. Elle donne souvent lieu à une découverte utile : la même valeur écrite à cinq endroits différents, avec deux variantes qui ne correspondent plus à rien.

Le piège inverse

La dérive symétrique consiste à rendre configurable tout ce qui pourrait varier un jour, ce qui produit des fichiers de réglages de trois cents entrées dont personne ne connaît l'effet. Une option qui n'a jamais été modifiée depuis sa création est une complexité pure : elle double les chemins d'exécution à tester et ajoute une décision à documenter. La règle raisonnable consiste à n'ajouter une option que lorsqu'un besoin réel se présente, et à supprimer celles qui n'ont jamais servi lors des revues. Une option conservée doit avoir une valeur par défaut explicite et documentée, faute de quoi son comportement dépend de ce que fait le code en son absence, ce que personne ne vérifie.

Le contenu n'est pas seulement du texte

Les images, les documents joints, les traductions rédigées, les données saisies par les visiteurs et les journaux d'activité appartiennent tous à la famille du contenu, avec des exigences propres. Les oublier lors de la conception produit des situations pénibles, notamment celle du dossier d'envois qui vit dans l'arborescence du code et disparaît au premier déploiement par copie. Chaque type de contenu doit avoir un emplacement décidé, hors des zones que le déploiement remplace. Une convention simple, un dossier de données unique contenant tous les sous dossiers concernés, suffit à rendre cette règle applicable sans réfléchir à chaque nouvel usage.

Les migrations, quatrième famille discrète

Il existe une quatrième catégorie que la plupart des projets découvrent trop tard : les changements de structure, colonnes ajoutées, champs renommés, données transformées. Ce ne sont ni du code, puisqu'ils ne s'exécutent qu'une fois, ni du contenu, puisqu'ils ne sont pas modifiables. Les traiter comme des fichiers numérotés, versionnés avec le code, exécutés dans l'ordre et dont l'application tient un registre, est la seule manière de savoir dans quel état se trouve une base donnée. Sans ce mécanisme, chaque déploiement s'accompagne d'une instruction orale sur ce qu'il faut lancer à la main, et un environnement finit toujours par se retrouver dans un état que personne ne sait reproduire. Le coût de mise en place est d'une demi journée et il ne se paie qu'une fois.

Où poser la configuration

Une fois le classement fait, reste à choisir l'endroit et la forme. Les possibilités sont peu nombreuses et se combinent, chacune correspondant à un besoin précis. Ce choix conditionne directement la manière dont l'application se construit, sujet traité dans notre article sur la façon d'injecter ses dépendances sans conteneur.

Les variables d'environnement

C'est la forme la plus adaptée à tout ce qui diffère d'un serveur à l'autre : identifiants de base de données, adresse du site, mode de débogage, clés de services externes. Elles ne figurent dans aucun fichier versionné, se définissent au niveau du serveur ou d'un fichier local exclu du dépôt, et sont lues au démarrage. Leur limite est le type : tout y est chaîne de caractères, ce qui impose une conversion et une validation explicites, faute de quoi une valeur mal saisie produit un comportement silencieusement faux.

Le fichier de configuration versionné

Tout ce qui est identique sur tous les environnements et ne relève pas du code peut vivre dans un fichier versionné : liste des rubriques, réglages d'affichage, paramètres métier stables. Ce fichier suit le code, se relit dans un différentiel, et bénéficie de l'historique du dépôt. Le mélanger avec les valeurs propres à un environnement est la faute classique, qui aboutit à des conflits à chaque déploiement et à des identifiants de production dans le dépôt. Le format retenu importe peu, tant qu'il est typé et relu par un humain sans effort.

La configuration modifiable par l'interface

Certains réglages doivent être modifiables par le client sans intervention technique : coordonnées, horaires, textes légaux, activation d'une fonctionnalité. Ils relèvent alors du contenu et doivent vivre avec lui, dans la base ou dans les fichiers de contenu, jamais dans un fichier versionné qu'un déploiement écraserait. Cette distinction entre configuration technique et réglages fonctionnels est celle qui évite les incidents les plus pénibles, où une mise en ligne remet les horaires d'ouverture de l'an dernier, sans que personne ne comprenne d'où vient la valeur affichée.

Les secrets, à part

Les clés d'interfaces de programmation, les mots de passe et les jetons ne doivent jamais figurer dans un dépôt, même privé, parce qu'un dépôt se clone, s'archive et se partage. Ils se transmettent par variables d'environnement ou par un gestionnaire dédié, se remplacent périodiquement, et leur présence accidentelle dans l'historique impose de les considérer comme compromis, la suppression d'un fichier ne retirant rien de l'historique. Un contrôle automatique refusant toute livraison contenant un motif de clé connue coûte dix minutes à mettre en place, et il attrape le cas le plus courant, celui du fichier de configuration local ajouté par mégarde au dépôt.

Valider au démarrage

Quelle que soit la source, la configuration doit être validée immédiatement au lancement de l'application : présence des valeurs obligatoires, types corrects, valeurs dans les plages attendues. Un site qui démarre avec une configuration incomplète produira une erreur plus tard, dans un contexte sans rapport avec la cause, et le temps perdu à diagnostiquer dépasse largement celui qu'aurait coûté la validation. Un message explicite au démarrage, nommant la variable manquante, est ce qui distingue un projet exploitable d'un projet pénible. Cette validation doit refuser le démarrage plutôt qu'avertir : un site qui fonctionne à moitié avec une configuration incomplète est plus dangereux qu'un site qui ne démarre pas.

Ce que la séparation permet

Les bénéfices ne sont pas théoriques, ils se constatent sur des opérations quotidiennes qui deviennent simples au lieu d'être redoutées. Ils supposent en amont une arborescence pensée dès le départ, telle que décrite dans notre article sur la manière de structurer un projet PHP sans framework.

Un déploiement qui ne détruit rien

Quand le code vit dans un dossier remplacé intégralement à chaque livraison, et que la configuration et le contenu vivent ailleurs, le déploiement devient une opération sans état d'âme : on remplace, on vide les caches, on vérifie. La bascule peut même se faire par changement de lien symbolique, ce qui la rend instantanée et réversible. Toute la difficulté des déploiements manuels vient de l'obligation de préserver certains fichiers au milieu de ceux que l'on remplace.

Une préproduction réellement fidèle

Monter un environnement de test suppose de copier le code, de copier le contenu, et de fournir une configuration différente. Si les trois sont séparés, l'opération prend quelques minutes et se scripte. Si elles sont mêlées, chaque copie demande des retouches manuelles, et l'environnement obtenu diffère toujours un peu de la production, ce qui lui retire une grande partie de son intérêt puisque les écarts constatés ne sont plus interprétables. La copie du contenu vers un environnement de test pose par ailleurs une question de données personnelles, qu'il vaut mieux régler par une anonymisation systématique à l'import plutôt que par la promesse de faire attention.

Des sauvegardes proportionnées

Les trois familles n'ont pas les mêmes besoins. Le code est déjà sauvegardé par son dépôt et n'a pas à figurer dans une sauvegarde quotidienne. La configuration est minuscule et change rarement. Le contenu, lui, est irremplaçable et doit être sauvegardé souvent, avec un historique. Séparer permet de sauvegarder beaucoup ce qui compte et rien de ce qui se reconstitue, ce qui divise le volume par un facteur important et rend les restaurations bien plus rapides. Une sauvegarde plus légère est aussi une sauvegarde que l'on peut tester régulièrement, alors qu'une archive de plusieurs dizaines de gigaoctets ne se restaure jamais à titre d'essai.

Une restauration ciblée

Le cas réel le plus fréquent n'est pas la panne totale mais l'erreur locale : un contenu supprimé par accident, une image écrasée. Avec des sauvegardes séparées, on restaure ce seul élément sans toucher au reste. Avec une sauvegarde monolithique, restaurer la veille signifie revenir en arrière sur tout, y compris sur les modifications légitimes de la journée, ce qui conduit souvent à renoncer et à ressaisir à la main. La capacité à restaurer un seul élément est d'ailleurs le meilleur test de la qualité d'une séparation : si l'opération demande de réfléchir, c'est que quelque chose est encore mélangé.

Un environnement de développement conforme

La séparation prend tout son sens quand un développeur peut installer le projet sur sa machine en quelques minutes. Cela suppose trois choses : un exemple de fichier de variables d'environnement, versionné, avec toutes les clés attendues et des valeurs factices ; un jeu de contenus de démonstration, distinct des contenus réels et dépourvu de données personnelles ; et une commande unique qui monte l'ensemble. Le bénéfice dépasse le confort : un projet qui s'installe difficilement finit par n'être modifié que directement en production, ce qui annule toutes les précautions prises par ailleurs.

Reprendre un projet qui mélange tout

La situation courante n'est pas le projet neuf mais l'existant, où tout cohabite. La bonne nouvelle est que la séparation peut se faire par étapes, chacune apportant un bénéfice immédiat.

Commencer par les secrets

La première étape, non négociable, consiste à sortir les identifiants et les clés du code versionné, à les remplacer par une lecture de variables d'environnement, et à considérer comme compromis tout ce qui a séjourné dans le dépôt. Cette opération prend une journée, réduit immédiatement le risque, et ne demande aucune réorganisation du reste du projet. Elle s'accompagne d'un renouvellement des clés concernées, sans quoi le nettoyage n'a qu'une valeur cosmétique.

Isoler ce que le déploiement ne doit pas toucher

La deuxième étape consiste à identifier tous les dossiers qui contiennent des données produites par le site ou envoyées par les utilisateurs, et à les déplacer hors de l'arborescence remplacée, avec un lien depuis leur emplacement d'origine si nécessaire. Cette étape est celle qui rend le déploiement automatisable, et elle se mesure : après elle, le dossier de code doit pouvoir être supprimé et recréé sans aucune perte. Ce test se pratique réellement, sur une copie, et il est le seul qui prouve que la séparation est effective plutôt que supposée.

Extraire progressivement les valeurs en dur

La troisième étape se mène au fil de l'eau : chaque fois qu'on touche un fichier, on en extrait les valeurs de configuration qu'il contient. Vouloir tout faire d'un coup conduit à une session de plusieurs jours dont le résultat est difficile à vérifier ; procéder au fil des interventions ne coûte presque rien et converge en quelques mois. Une recherche périodique sur les motifs suspects mesure l'avancement, et son résultat, reporté dans un tableau, montre une décroissance qui motive à poursuivre.

Écrire la carte des données

La dernière étape est documentaire et vaut toutes les autres. Un fichier listant, pour chaque famille, où vivent les données, qui les modifie, comment elles sont sauvegardées et ce qui se passe lors d'un déploiement, tient sur une page et répond à la moitié des questions que se pose un intervenant extérieur. C'est aussi ce document qui permet, le jour d'un incident, de savoir immédiatement ce qui est perdu et ce qui ne l'est pas. Le tenir à jour coûte quelques minutes à chaque évolution importante, et son absence se paie toujours au pire moment. Il doit indiquer, pour chaque catégorie, où se trouve la sauvegarde et à quelle fréquence elle est prise, ces deux informations étant les seules réellement utiles au moment où l'on cherche à savoir ce qui est récupérable.