On a plusieurs projets sérieux, des widgets Grist au MEAE, Démarches Numérique à la DINUM, Odyssée à la DGFIP, qui butent sur le même mur : le DSFR bloque la réutilisation de leur code open source pour ne pas risquer de falsifier l’apparence d’un site officiel.
Pour les équipes qui ont déjà creusé ce sujet au MEAE, chez Démarches Numérique, à l’ANCT ou à la DGFIP, comment avez vous abordé le problème ? Vous avez essayé de séparer les feuilles de style ? Négocié une exception ? Envisagé un fork ? Vibe-codé un truc viable ? Abandonné ?
Et pour celles et ceux qui ont trouvé une piste, même partielle — on est preneurs.
On veut construire un dossier concret pour analyser le problème et explorer les solutions. Vos retours d’expérience sont exactement ce qu’il nous faut pour lancer cette discussion.
Pour l’instant… on ne gère pas. Du moins de ce que je vois. Et c’est vraiment une épine dans le pied. L’idéal a priori serait de faire en sorte que le DSFR soit personnalisable. Oui ça va un peu à l’encontre même de l’idée de ce que je comprends, mais fournir une API, ne serait-ce que pour les couleurs et supprimer la Marianne, ça changerait beaucoup la donne, sans pour autant changer radicalement de système de design pour l’outil. Plus encore, ça permettrait certainement une adoption plus facile et massive pour les outils internes qui n’ont pas l’obligation légale d’utiliser le DSFR, puisque l’on pourrait reprendre système de design français, mais le personnaliser aux goûts et couleurs des projets…
Bon, c’est vraiment ma réflexion très basique telle quelle, peut-être trop lourde, peut-être qu’il a mieux et plus simple.
Côté Démarche Numérique, on en est au même point que @louis_vigneras
On imagine que pour pas trop cher, on doit pouvoir changer le logo, les couleurs, et la fonte.
le dsfr permet nativement déjà de changer les couleurs et plein d’autres choses… Car tout est variabilisé, même le namepsace fr- pour être changé au build time. Sauf que nous, on prend directement leur propre build, plutôt que faire le notre pour en tirer profit car nous n’avons rien à personnaliser.
La piste qu’on va suggérer aux instances de DN est la suivante.
Ils explorent cette idée :
Ce que j’avais comme idée c’était de créer une feuille de style spécifique, diffusée pourquoi pas via un paquet npm, pour facilement avoir un DSFR en marque blanche, sans devoir toucher de build.
Par exemple ici, j’utilise le DSFR normalement, depuis la build zippée conseillée dans la doc. Je rajoute une feuille de style faite pour « dé-dsfr-iser » le tout. Et voilà, à gauche le DSFR, à droite un pas-DSFR tout moche. Le code HTML est le même des deux côtés.
Ici, l’idée est de rajouter un attribut no-dsfr autour du contenu où on souhaite « annuler » le DSFR.
J’imagine qu’une telle solution fait le travail ?
L’idée est de bosser un peu une feuille de style de façon un peu plus poussée, pour pourquoi pas permettre qq modifs facilement. Mais dans l’idée ça me parait résoudre les problèmes sans trop de complexité technique. La feuille de style peut s’occuper de ne pas afficher la Marianne dans le header ou le footer.
Chaque projet peut donc utiliser cette feuille de style via npm facilement. Et voit ensuite comment proposer cette version « non-dsfr ». Typiquement un projet open-source qui utilise le DSFR pourrait inclure ou non cette feuille de style dédiée, et ajouter ou non un attribut no-dsfr sur la balise html, via une variable d’environnement.
Pas une réponse directe à la question posée, mais sur sujet un peu connexe: la licence de la police de caractères Marianne.
Pour celles et ceux qui sont confrontés à un problème de formalisme des informations juridiques, voici des approximations qui semblent acceptables pour l’adaptation de la réalité juridique au formalisme imposé techniquement.
Le principal concept à comprendre ici est que la restriction d’usage de la police Marianne ne s’appuie pas sur des considérations de propriété intellectuelle, mais sur le respect du code pénal.
Pour la licence, vous pouvez indiquer un identifiant SPDX ad hoc LicenseRef-Police-Marianne renvoyant au texte ci-dessous.
La police de caractères Marianne peut être réutilisée librement selon les termes des articles L321-1 à R321-8 du Code des relations entre le public et l’administration. Toute réutilisation doit s’effectuer selon les limites et conditions précisées par les Articles L322-1 à R322-7 du même code.
La licence Ouverte dans sa version 2.0 (Etalab-2.0) expose de façon pédagogique des modalités possibles de mise en œuvre de ces droits et de ces contraintes.
Cette police de caractères faisant partie de l’identité graphique des documents officiels du gouvernement, il est rappelé que sa réutilisation doit se faire en conformité avec l’article 433-13 du Code pénal, qui proscrit d’« user de documents ou d’écrits présentant, avec des actes judiciaires ou extrajudiciaires ou avec des documents administratifs, une ressemblance de nature à provoquer une méprise dans l’esprit du public. »
Le champ Copyright devrait, lui, contenir l’expression Source - SIG {date de dernière mise à jour} ({date de dernière mise à jour} étant à remplacer par la valeur de la date effective) .
A l’ANCT nous avons été confronté au même problème puisque La suite territoriale est une Suite d’outils pour les collectivités territoriales et non l’Etat. Nous passons pas le kitUI de LaSuite qui a une option « open source » qui :
ne reprend pas les composant DSFR
change les couleurs (notamment le bleu spécifique du dsfr)
transforme la police marianne en Hanken Grostesque
=> la doc de l’UI KIT : Docs
Je suis d’accord. Il faudrait que le SIG accepte de ne pas faire porter sur la licence les restrictions d’usage - fondamentalement contraire au principe des licences libres - mais rappelle simplement le risque à utiliser le DSFR pour tromper le public comme cela est fait pour la police Marianne. L’infraction pour tromperie serait tout aussi efficace pour poursuivre des faussaires qu’une atteinte au droit d’auteur, il me semble.
Quand on fait un commun qui n’est pas exclusivement destiné à l’Etat, je pense qu’il faut éviter d’utiliser le DSFR, jusqu’à ce que le SIG fasse éventuellement une nouvelle version qui intègre nativement une logique de thèmes, dont un serait avec la Marianne et un autre serait plus neutre et sans restrictions.
Ce n’est pas encore le cas malheureusement et du coup les 2 seules solutions sont effectivement :
Utiliser l’UI-kit de LaSuite qui a été conçu exactement pour ce cas d’usage et supporte déjà des déclinaisons « Marianne » ou « Neutre » comme le précisait Manon : @storybook/core - Storybook
Faire un override no-dsfr.css comme le suggère Manu, mais ça ne plaira probablement pas au SIG (ils pourraient le confirmer ici?) et ca risque de casser à chaque nouvelle version du DSFR.
