Reprise, maintenance (TMA) et évolutions d’un site institutionnel Drupal sous DSFR

Reprendre du code qu’on n’a pas écrit, sans tout casser

Une agence a rarement besoin qu’on réécrive son site : elle a besoin d’un renfort capable de reprendre l’existant et de le tenir. C’est le point de départ de ce projet — un site institutionnel Drupal déjà en ligne, riche, avec ses habitudes et sa dette. Avant toute modification, on audite : version réelle de Drupal et des dépendances, patchs en place et leur traçabilité, état de la configuration (peut-on déployer sans surprise ?), dette d’accessibilité, et présence — ou absence — d’une chaîne qualité. Le livrable de départ n’est pas du code, c’est un diagnostic priorisé : ce qui est risqué, ce qui est urgent, ce qui peut attendre.

Le socle : un Drupal 9 sous DSFR, remis à niveau

Le site repose sur un socle Drupal 9 industrialisé et un thème sur-mesure conforme au DSFR. Le front n’est pas un thème plaqué : c’est une base de composants Twig et de styles SCSS compilés par une chaîne d’outillage, adossée à un styleguide qui documente les composants. Reprendre proprement, c’est d’abord comprendre ce modèle : où vivent les composants, comment ils sont mappés sur les champs Drupal, comment le DSFR est versionné. Une fois cette carte établie, faire évoluer une page ou en créer une nouvelle devient sûr et rapide — pas un pari.

La qualité, outillée à chaque commit

Sur un projet qu’on reprend à plusieurs mains, la qualité ne peut pas reposer sur la discipline individuelle : elle doit être automatique. Chaque commit déclenche une batterie de contrôles orchestrés par GrumPHP : PHPCS aux standards Drupal (Coder), PHPMD (complexité, code mort), détection de copier-coller (PHPCPD), lint PHP / YAML / JSON, normalisation du composer.json, et même des règles d’hygiène — interdiction des var_dump, dd() ou console.log oubliés, convention de nommage des branches, message de commit qui doit référencer un ticket. Le seuil est clair : zéro erreur de style tolérée. Résultat : un code homogène quel que soit l’auteur, et des revues qui parlent du métier plutôt que des points-virgules.

Tests et intégration continue

Reprendre un site sans filet, c’est déployer à l’aveugle. On s’appuie sur des tests automatisés — PHPUnit pour la logique, Behat pour les parcours fonctionnels — exécutés en intégration continue (GitLab CI) avec suivi de la couverture. Chaque branche passe le pipeline avant fusion : la CI est le garde-fou qui transforme « ça marche chez moi » en « c’est vérifié ». C’est aussi ce qui rend une TMA soutenable dans la durée : on peut corriger et faire évoluer sans craindre de casser un parcours existant à l’autre bout du site.

Déployer sans surprise : la configuration par environnement

Un site public vit sur plusieurs environnements — développement, recette, production — et se gère à plusieurs mains. La configuration est versionnée et pilotée par environnement (config_split / config_ignore) : ce qui doit différer entre la recette et la prod est isolé proprement, le reste est déployé de façon reproductible. L’environnement local est conteneurisé (Docker) et outillé par des tâches automatisées (Phing) — import de base, synchronisation des fichiers, réinitialisation — pour qu’un nouveau développeur soit opérationnel en minutes, pas en journées. Déployer cesse d’être un moment de tension.

Maintenir les dépendances : montées de version et patchs tracés

Le cœur d’une TMA, c’est de garder le socle à jour — pour la sécurité comme pour la pérennité. Les dépendances sont gérées par Composer, et quand un module de la communauté présente un défaut, on n’édite jamais son code « dans le tas » : on applique un patch tracé (composer-patches), documenté et rejouable à chaque installation. C’est ce qui distingue un site maintenable d’une boîte noire : une montée de version ne fait pas disparaître les correctifs, et n’importe quel développeur peut comprendre pourquoi tel patch est là. Les correctifs utiles sont, quand c’est possible, remontés en amont à la communauté.

Accessibilité DSFR, RGPD et observabilité

Trois exigences non négociables sur un site public, tenues par le socle plutôt que rattrapées à la fin. Accessibilité (RGAA) : le markup vient de composants DSFR normalisés et documentés dans le styleguide, l’accessibilité est donc produite à la source. RGPD : gestion du consentement (bandeau et préférences), politique de mots de passe, protection anti-spam des formulaires, envoi d’e-mails maîtrisé (et neutralisé hors production pour ne jamais écrire à un vrai usager par erreur). Observabilité : les erreurs de production sont remontées en continu vers Sentry et journalisées, pour être vues et corrigées avant que l’usager ne les subisse.

Recherche et éditorialisation

Un site institutionnel riche doit rester navigable. La recherche s’appuie sur Search API et des facettes pour filtrer de gros volumes de contenu, avec une page de résultats dédiée. Côté édition, le contenu est monté à partir de composants réutilisables (Paragraphs), de listes d’entités configurables et d’un affichage maîtrisé — l’équipe éditoriale assemble ses pages à partir de blocs validés, sans redemander du développement à chaque campagne. Le référencement technique (métadonnées, URL propres, redirections, plan de site) est intégré au socle, pas ajouté après coup.

Reprendre ou faire évoluer votre Drupal DSFR

C’est la question qui intéresse une agence : peut-on confier un Drupal DSFR existant et le voir tenu proprement ? Oui — parce que la reprise est outillée. On audite la version réelle, les patchs, la configuration et la dette d’accessibilité ; on livre un plan priorisé ; puis on prend la main sur la maintenance et les évolutions, sous votre marque. Le site reste reprenable après nous : code homogène, configuration versionnée, tests, CI, dépendances tracées. C’est exactement ce que cherche une agence qui délègue une TMA.

Questions fréquentes

En clair : reprendre un Drupal DSFR existant, ce n’est pas « bidouiller » un site livré par d’autres. C’est de l’ingénierie : audit, qualité outillée, tests, configuration maîtrisée et dépendances tracées. Fait proprement, le site reste sûr, à jour et — surtout — reprenable.