Icônes dans Drupal : qui décide, le thème ou l'éditeur ? La méthode pour un design system robuste

Un détail qui devient un problème d'architecture

Les icônes semblent être un détail d'implémentation, jusqu'à ce qu'un site combine un large design system, plusieurs workflows de contribution et des contenus qui évoluent indépendamment du thème. C'est le constat de départ de James Nettik, développeur senior chez Aten Design Group, dans un article consacré à la conception de systèmes d'icônes dans Drupal. La question centrale qu'il pose est simple : à qui appartient l'icône ?

Sa réponse tient en une distinction fondamentale. Certaines icônes appartiennent à des motifs d'interface stables : les états d'alerte, les métadonnées d'événement (date, heure, lieu) ont une signification fixe au sein d'un composant. Ces icônes doivent rester codées en dur dans le thème, car ce couplage protège la cohérence visuelle du site. D'autres icônes se comportent en revanche comme du contenu : lorsqu'un éditeur choisit une icône pour un élément de menu, une carte ou une bannière, cette décision visuelle doit voyager avec le contenu, pas avec sa position dans un template.

La plupart des interfaces mélangent d'ailleurs les deux modèles. Une carte peut porter une icône choisie par l'éditeur et une flèche codée en dur qui signale qu'elle est cliquable. La frontière utile n'est donc pas « Drupal contre le thème », mais bien : quelle partie du système possède chaque décision.

Quand les icônes éditoriales vivent dans le code, tout devient fragile

Les menus rendent le problème particulièrement visible. Un développeur peut attacher une icône au deuxième élément d'un menu via le CSS, mais cette relation casse dès qu'un éditeur insère un lien au-dessus. Cibler l'identifiant d'un élément de menu est plus stable, mais crée toujours une dépendance maintenue par les développeurs entre le contenu et le code du thème.

Autre approche courante : la liste déroulante de noms de fichiers. Elle fonctionne pour un petit jeu d'icônes, mais devient problématique quand la bibliothèque grossit. On demande alors aux éditeurs de comprendre le design system à travers des noms de fichiers — la différence entre calendar, calendar-outline et calendar-filled est évidente pour le développeur qui les a ajoutés, beaucoup moins pour la personne qui construit une page plus tard. Ajouter une option peut en outre exiger une modification du thème et un déploiement. Résultat : du point de vue de l'éditeur, c'est un problème de contenu ; du point de vue du développeur, c'est un problème de thème.

Traiter les icônes éditoriales comme des Media

Drupal dispose déjà d'un meilleur modèle d'interaction pour choisir des ressources visuelles : la Media Library (bibliothèque de médias native de Drupal), qui offre aperçus visuels, recherche, filtrage, réutilisation et gestion des ressources. Cette interaction convient parfaitement aux icônes. Grâce au module SVG Image, les fichiers SVG peuvent participer à l'écosystème des champs image de Drupal et être rendus comme éléments image ou comme SVG inline (intégré directement dans le HTML).

Une fois les icônes transformées en entités Media, elles bénéficient du modèle de contenu standard de Drupal :

• des noms explicites, des catégories et des indications d'usage ;
• des permissions pour contrôler qui peut faire quoi ;
• des Vues et une configuration des références pour limiter les icônes visibles selon le contexte.

Ce dernier point compte : une bibliothèque d'icônes est rarement une collection homogène. Les icônes d'interface utilisées dans les menus ou les appels à l'action n'ont pas le même usage que des accents décoratifs. Décider quel type d'icône convient à quel contexte ne doit pas reposer sur l'éditeur si le système peut fournir des garde-fous clairs. Media devient ainsi bien plus qu'un sélecteur agréable : c'est un modèle de gouvernance.

Concrètement, plusieurs outils permettent d'exposer ces choix : Menu Item Extras pour ajouter des champs de référence Media aux menus, les Paragraphs pour attacher un choix d'icône directement au composant structuré, ou encore Style Options - Media Reference pour la configuration de composants. L'implémentation exacte varie selon le projet, mais le principe reste le même : une fois l'icône devenue entité, les champs, permissions et filtres existants de Drupal suffisent à la gérer, sans sélecteur d'icônes sur mesure.

Garder un rendu prévisible : le HTML choisit, le CSS habille

Déplacer les icônes dans Media améliore l'expérience de contribution, mais le thème doit conserver un modèle de rendu fiable. La règle proposée par l'auteur est limpide : le HTML choisit l'icône, le CSS la style. Drupal ou Twig (le moteur de templates de Drupal) déterminent si une icône existe et laquelle ; le CSS gère la taille, l'espacement, l'alignement, la couleur et les états d'interaction.

Cette séparation fonctionne particulièrement bien avec le SVG inline : l'icône peut hériter de la couleur du composant, réagir aux interactions et rester dans le balisage plutôt que d'être cachée dans une feuille de style. Elle rapproche aussi les décisions d'accessibilité de l'interface rendue : les icônes décoratives peuvent être masquées aux technologies d'assistance, tandis que les contrôles porteurs de sens s'appuient sur des noms accessibles appropriés plutôt que de demander à l'icône de porter tout le sens.

L'Icon API de Drupal 11.1 : vers une standardisation

Drupal 11.1 a introduit une Icon API, qui permet aux thèmes et modules d'exposer des packs d'icônes via un système de rendu commun. Des projets contribués comme Icon Media Pack explorent la façon dont les bundles Media peuvent s'intégrer à ce modèle. Cela dessine une répartition intéressante des responsabilités : Media assure la gouvernance côté éditeurs, l'Icon API fournit aux développeurs un chemin de rendu prévisible.

Des exceptions subsistent : certains contrôles de formulaire natifs nécessitent des icônes en arrière-plan ou en masque CSS, car leur balisage ne peut pas facilement contenir de SVG rendu. Conserver quelques ressources dupliquées dans le thème est alors un compromis raisonnable. L'objectif n'est pas d'éliminer toute exception, mais de rendre la frontière intentionnelle.

Donner à chaque partie du système le contrôle dont elle a besoin

Un système d'icônes adapté aux éditeurs n'est pas un système où ils peuvent tout changer : c'est un système où les décisions qui leur reviennent sont réellement éditables. Si une icône appartient à un motif d'interface stable, cette relation reste dans le thème. Si elle représente quelque chose que l'éditeur crée ou organise, elle mérite d'être modélisée dans Drupal. Cette division est plus maintenable que de traiter les icônes entièrement comme du code de thème ou entièrement comme du contenu — et elle reflète mieux la façon dont fonctionnent réellement les sites Drupal complexes.