Gestion de configuration Drupal : le workflow professionnel

La différence la plus visible entre un projet Drupal amateur et un projet professionnel ne se trouve pas dans le code des modules. Elle se trouve dans la façon dont la configuration circule entre les environnements. Un projet sans gestion de configuration disciplinée finit toujours au même endroit : une production qui diverge du code, des développeurs qui s'écrasent mutuellement et des déploiements qui font peur.

Contenu et configuration : la séparation fondatrice

Drupal sépare deux choses que beaucoup de CMS mélangent. Le contenu (articles, pages, médias, utilisateurs) vit dans la base de données et appartient à chaque environnement. La configuration (types de contenu, champs, vues, permissions, réglages de modules) est exportable en fichiers YAML.

Cette séparation change tout : la configuration devient du texte, et du texte se versionne. Chaque modification de structure (un nouveau champ, une vue ajustée, une permission accordée) laisse une trace lisible dans Git, avec un auteur, une date et un contexte. Six mois plus tard, on sait qui a changé quoi et pourquoi.

Le workflow sain

Le cycle professionnel tient en une phrase : on développe en local, on exporte, on committe, on déploie, on importe. Concrètement :

1. Le développeur fait ses changements de configuration dans son environnement local, via l'interface d'administration ou des update hooks.
2. Il exporte la configuration en fichiers YAML et les committe dans Git avec le code.
3. La revue de code porte sur le diff de configuration autant que sur le code : un champ supprimé ou une permission élargie se voient noir sur blanc.
4. Le déploiement applique la configuration en préproduction, où l'on teste.
5. Le même déploiement, reproductible, s'applique en production.

Le mot clé est reproductible. Le changement testé en préproduction est exactement celui qui arrive en production, pas une reconstitution manuelle de mémoire dans l'interface d'administration.

Les outils qui rendent ça robuste

Config Split. Tous les environnements ne doivent pas avoir la même configuration. Les modules de développement (Devel, les outils de debug) n'ont rien à faire en production, et les réglages d'agrégation ou de cache diffèrent entre local et production. Config Split permet de définir des ensembles de configuration par environnement, activés selon le contexte. Un seul export, des variantes propres.

Config Ignore. Certains réglages sont légitimement gérés en production par les équipes métier : le message du bandeau d'alerte, certains blocs, des réglages de contact. Config Ignore les exclut de l'import pour que le déploiement n'écrase pas ce que les équipes ont ajusté en direct. La frontière doit rester étroite et documentée, sinon elle devient une passoire.

Le pipeline de déploiement. L'import de configuration ne doit pas dépendre d'un humain qui pense à lancer la commande. Le pipeline exécute systématiquement la même séquence : mise à jour du code, application des mises à jour de base de données, import de la configuration, vidage des caches. Chaque déploiement est identique au précédent, donc ennuyeux. Un déploiement ennuyeux est un déploiement réussi.

Les pièges classiques

La modification directe en production. C'est la source numéro un de divergence. Quelqu'un ajuste une vue en production « juste pour dépanner », l'export local ne la contient pas et le déploiement suivant l'écrase. La règle d'équipe doit être claire : la production ne se modifie pas à la main, sauf périmètre Config Ignore explicitement défini.

L'export partiel. Exporter seulement « son » changement en laissant le reste, c'est committer un état incohérent. L'export de configuration est global : si le diff contient des changements inattendus, c'est le signal que quelqu'un a modifié un environnement sans le dire, et il faut régler ça avant de committer.

La configuration jamais testée à l'import. Un export qui fonctionne n'est pas un import qui fonctionne. Les dépendances entre configurations (un champ qui référence un vocabulaire, une vue qui dépend d'un module) peuvent casser l'import dans un ordre différent. D'où l'importance de la préproduction qui rejoue l'import complet à chaque déploiement.

Ce que ça change en pratique

Pour une équipe de plusieurs développeurs, la gestion de configuration est ce qui permet de travailler en parallèle sans se marcher dessus. Pour une organisation, c'est la garantie que l'état du site est connu, auditable et reconstructible. Pour la maintenance, c'est ce qui rend chaque intervention traçable et réversible.

C'est aussi un critère de sélection de prestataire : demandez comment la configuration est gérée et déployée. La réponse vous dira immédiatement à quel niveau de rigueur vous avez affaire. Un prestataire qui déploie ses changements en les recliquant dans l'interface de production vous fait courir un risque à chaque intervention.

Votre projet Drupal n'a pas encore ce niveau de discipline, ou vous reprenez un site dont les environnements ont divergé? Un audit technique établit l'état réel et le chemin pour revenir à un workflow sain. Vous pouvez aussi parler directement à un développeur senior qui met ces pipelines en place régulièrement.