Refonte d’un site de service public sous Drupal 10 et Système de Design de l’État

Le contexte : un service public, une obligation

Un site de l’État n’a pas le choix : il doit respecter le Système de Design de l’État (DSFR) et le RGAA (Référentiel Général d’Amélioration de l’Accessibilité). Ce ne sont pas des options de fin de projet, mais des contraintes structurantes qui décident de la façon dont on modélise le contenu, dont on assemble les pages et dont on outille la rédaction. La refonte portait sur un site institutionnel riche — pages éditoriales, moteur de recherche, et plusieurs simulateurs d’éligibilité à des dispositifs publics.

Ce que le DSFR impose vraiment à l’architecture Drupal

La bonne façon d’intégrer le DSFR sous Drupal n’est pas de recopier son CSS dans un thème maison, mais de traiter chaque composant de l’État comme un pattern réutilisable. Nous avons bâti le rendu sur une approche component-driven (UI Patterns / UI Styles couplés à ui_suite_dsfr) avec la librairie officielle DSFR 1.11.2 gérée par Composer et versionnée. Concrètement : un composant DSFR = un pattern, mappé sur les champs Drupal, réutilisé partout. Le balisage reste conforme par construction, et une montée de version du DSFR se fait au niveau de la dépendance, pas fichier par fichier.

L’accessibilité RGAA tenue par construction

Parce que le markup vient de composants normalisés, l’accessibilité n’est pas rattrapée à la fin : elle est produite à la source. Là où le composant amont présentait un défaut — pagination, menu de pied de page — nous avons corrigé et remonté les correctifs en amont à la communauté (patchs Composer tracés sur ui_suite_dsfr). Côté formulaires : validation côté client et côté serveur, captcha, messages d’erreur explicites. L’accessibilité devient une propriété du socle, pas un audit de dernière minute.

Les développements sur-mesure : simulateurs, référentiels, exports

Le cœur métier, ce sont des simulateurs d’éligibilité multi-étapes. Nous les avons architecturés proprement : un pattern Step / StepManager (étapes typées, navigation avant/arrière), une couche de services référentiels (zonage commune / code postal, plafonds de ressources par zone, requêtés en base dédiée), des validateurs réutilisables, un endpoint AJAX d’autocomplétion renvoyant du JSON filtré (protection XSS), le tout exposé en blocs Drupal réutilisables avec templates Twig. À côté : recherche Solr, cartographie Leaflet, graphiques Highcharts, mini-applications Vue.js, et des exports PDF et tableur (wkhtmltopdf, PhpSpreadsheet) pour les usages administratifs.

Sécurité, gouvernance éditoriale et configuration multi-environnements

Un site public se gère à plusieurs mains et se déploie sur plusieurs environnements. Nous avons mis en place l’authentification centralisée (CAS), une politique de mots de passe, la délégation de rôles et un cloisonnement éditorial par section (workbench_access) pour que chaque service ne gère que son périmètre. La configuration est pilotée par environnement (config_split / config_ignore), la publication est programmable (scheduler, date de publication), et la consultation reste maîtrisée (indicateur d’environnement, prévisualisation, gestion fine du cache).

Tenir la conformité dans la durée

La vraie difficulté d’un projet DSFR n’est pas de le livrer conforme : c’est qu’il reste conforme après des mois d’évolutions. D’où une industrialisation complète : environnement local reproductible (DDEV), intégration continue (GitLab CI), et une chaîne qualité systématique — GrumPHP, PHPCS (Drupal Coder), PHPMD, détection de copier-coller, PHPUnit, SonarQube. Les correctifs de dépendances sont tracés (une trentaine de patchs Composer documentés), le respect de la vie privée est intégré (gestion de consentement thémée DSFR + analytics souverain), et les erreurs de production sont remontées en continu via Sentry. La conformité n’est pas un état, c’est un processus outillé.

Reprendre un projet DSFR existant : ce qu’on regarde d’abord

Beaucoup d’agences ont un projet DSFR déjà en ligne et cherchent un renfort capable de le reprendre sans casse. C’est précisément ce que ce socle nous permet de faire. À la reprise, on regarde d’abord : la version réelle du DSFR et l’écart avec ui_suite_dsfr ; les patchs en place et leur traçabilité ; la gestion de configuration (peut-on déployer sans surprise ?) ; la dette d’accessibilité (composants détournés, markup dégradé) ; et l’existence d’une chaîne qualité. En quelques jours, on livre un diagnostic priorisé et on peut prendre la main.

Questions fréquentes

En clair : sur un site de service public, le DSFR et le RGAA se gagnent dans l’architecture et se tiennent avec une chaîne qualité. C’est ce socle que nous concevons — et que nous savons reprendre sur l’existant.