On en parle – Design System Public : cohérence, industrialisation, et maîtrise des coûts

Pourquoi un design system devient-il stratégique, précisément dans le secteur public ?

Parce que votre écosystème est un réseau, pas un site.
Portails, sites thématiques, intranet, extranet, applications, démarches, formulaires, mini-sites événementiels. L’Acteur Public ne produit plus un objet isolé, il produit une constellation. Sans design system, chaque étoile brille différemment : les parcours varient, les libellés changent, les erreurs se présentent autrement, l’accessibilité est inégale, et l’usager apprend plusieurs fois.

Avec un design system, l’usager retrouve des repères. Et l’organisation retrouve un levier de pilotage : elle impose des standards, sans empêcher l’évolution.

Pourquoi les projets digitaux peuvent-ils coûter si cher à long terme ?

Parce que la variabilité se transforme en maintenance, puis en dette.
Au lancement, tout va bien. Ensuite, les demandes arrivent : ajouter un champ, modifier un parcours, intégrer un nouveau service, faire évoluer une charte, corriger un bug, améliorer l’accessibilité.

Si chaque produit a ses propres composants, ses propres règles, ses propres exceptions, chaque évolution devient un mini-projet.

C’est ainsi que les coûts explosent : non pas à cause de la création, mais à cause de l’entretien.

À Stratis, nous constatons souvent que la “maîtrise des coûts” ne se joue pas sur la négociation d’un projet, mais sur la capacité à éviter de reconstruire la même chose dix fois.

Un design system, est-ce d’abord de l’UX, de l’UI, ou du développement ?

C’est d’abord une gouvernance de règles partagées, qui s’incarne ensuite en composants.
Un design system réellement utile n’est pas un catalogue figé. C’est un langage commun : des principes, une façon de structurer l’information, des comportements attendus, des composants réutilisables, et une documentation qui dit clairement comment et quand utiliser quoi. L’UX fixe les intentions, l’UI fixe la forme, le développement fixe la robustesse. Mais l’essentiel est ailleurs : l’alignement. Sans alignement, vous aurez un “kit UI” de plus. Avec alignement, vous aurez une industrie.

Astuce : si vous devez choisir un point de départ, commencez par les comportements, pas par les couleurs. Comment un formulaire se valide, comment une erreur se signale, comment une action se confirme, comment une navigation se parcourt au clavier. C’est là que la qualité se gagne.

Qu’est-ce que la “cohérence” apporte, au-delà de l’image ?

Elle réduit l’effort cognitif, donc elle réduit les erreurs et les renoncements.
La cohérence n’est pas une coquetterie. C’est une économie d’attention. Quand les composants se comportent de la même façon, l’usager n’a pas besoin de réapprendre. Quand les libellés suivent des règles, l’agent sait quoi écrire. Quand les messages d’erreur sont structurés, l’assistance baisse. Et quand tout cela est stable, la confiance augmente.

Dans le secteur public, où les publics sont divers, parfois fragiles, parfois pressés, la cohérence est une forme d’inclusion. Elle fait partie du service rendu.

Pourquoi l’accessibilité est-elle l’argument le plus solide en faveur d’un design system ?

Parce qu’on ne corrige pas l’accessibilité page par page, on la garantit composant par composant.
L’accessibilité est un travail de précision, mais aussi un travail de répétition. Les mêmes pièges reviennent : focus invisible, contraste insuffisant, navigation clavier cassée, libellés mal associés, erreurs non annoncées, composants interactifs “non standard”. Un design system permet de sécuriser ces sujets à la source. Vous construisez des composants conformes, vous les testez, vous les documentez, puis vous les réutilisez. Vous réduisez ainsi drastiquement le coût de la conformité, et surtout, vous stabilisez votre niveau RGAA dans le temps.

À Stratis, nous aimons une idée simple : une conformité durable ne s’obtient pas par un audit final, elle s’obtient par une bibliothèque fiable.

Comment le design system industrialise-t-il réellement la production ?

Il transforme la conception en assemblage, et le développement en réutilisation.
Sans design system, chaque projet commence par une redécouverte : quelles grilles : quels boutons : quelles cartes : quelles modales : quels tableaux : quels champs :”. Avec un design system, la conception devient une composition de briques connues. La discussion se déplace : on parle de l’utilité, de l’arbitrage, du contenu, plutôt que de réinventer la mécanique.

Astuce : une bonne industrialisation commence par un périmètre étroit mais fréquent. Les formulaires, la recherche, l’annuaire, la navigation, les messages d’erreur. Ce sont des zones à fort rendement : elles existent partout, elles coûtent cher quand elles varient.

Pourquoi les design systems échouent-ils parfois, malgré de bonnes intentions ?

Parce qu’ils sont conçus comme des livrables, pas comme des produits.
Un design system n’est pas un PDF. Ce n’est pas non plus une librairie qu’on livre une fois. C’est un produit interne, avec des utilisateurs (équipes projet), un backlog, des versions, une documentation, et une gouvernance de contribution.

Sans cette logique produit, il s’érode : les équipes contournent, recréent, divergent. Et bientôt, vous avez deux design systems, puis trois.

À Stratis, nous recommandons de nommer un pilote, d’organiser la contribution, et de publier des versions.

La version est un outil de paix : elle dit ce qui est stable, ce qui évolue, et comment on migre.

Comment concilier design system et autonomie des équipes, sans rigidifier ?

En standardisant le “socle”, et en laissant respirer le reste.
Le design system ne doit pas étouffer les spécificités. Il doit sécuriser les fondamentaux. Il standardise ce qui doit être stable : accessibilité, composants critiques, typographie, grilles, comportements. Et il laisse de la place à l’expression là où elle a du sens : contenus, tonalité, illustrations, priorités, scénarios.

Astuce : distinguez clairement “obligatoire”, “recommandé”, “optionnel”. Le flou est l’ennemi. Quand c’est clair, les équipes ne vivent pas le design system comme une contrainte arbitraire.

Comment le design system aide-t-il à maîtriser les coûts, de manière démontrable ?

En faisant baisser le coût marginal de chaque nouveau projet.
La question des coûts se joue dans la répétition. Un composant conçu, développé, testé, documenté une fois, puis réutilisé dix fois, amortit votre investissement. Un correctif appliqué au composant se propage partout. Une mise à jour de style devient un chantier centralisé, pas dix chantiers dispersés. C’est là que vous maîtrisez : vous réduisez le coût des évolutions, vous diminuez la maintenance corrective, vous stabilisez les délais.

À Stratis, nous aimons parler de “coût marginal” : combien coûte un nouveau service, une nouvelle page, un nouveau module, une fois le socle en place :”. Plus votre design system est mûr, plus ce coût marginal baisse.

Pourquoi le contenu fait-il partie du design system, même si on l’oublie souvent ?

Parce que les incohérences viennent autant des mots que des écrans.
Le design system ne doit pas se limiter aux composants. Il doit aussi embarquer des règles de rédaction : conventions de libellés, messages d’erreur, tonalité, titres, microcopie, formulations inclusives, langage clair. Dans le service public, la compréhension est un enjeu majeur. Un design system qui standardise les composants mais laisse les mots dériver perd une partie de sa valeur.

Astuce : créez un “kit de microcopie” : modèles de messages d’erreur, confirmations, aides contextuelles. Vous réduisez les débats, et vous augmentez la qualité.

Quelle est la meilleure manière de démarrer sans se perdre dans un chantier trop vaste ?

Commencer petit, mais sur le plus répétitif, puis élargir par itérations.
Un design system total, parfait, livré d’un bloc, est rare. Et souvent, il arrive trop tard. Une trajectoire réaliste consiste à choisir un périmètre à fort rendement : quelques composants critiques, une grille, une typographie, des règles de contenu, et une documentation minimale. Ensuite, on publie, on utilise, on corrige, on étend. La valeur vient de l’usage.

À Stratis, nous recommandons un démarrage en “noyau dur” : formulaires, boutons, champs, erreurs, navigation, tableaux. Vous verrez tout de suite l’effet sur les projets.

Comment s’assurer qu’il sera réellement adopté, et pas seulement “approuvé” ?

L’adoption vient quand le design system fait gagner du temps, pas quand il est beau.
Les équipes adoptent ce qui leur simplifie la vie. Une documentation claire, des exemples, des gabarits prêts, des composants faciles à intégrer, des règles nettes : voilà ce qui crée l’usage. À l’inverse, un design system difficile à consommer, trop théorique, ou trop éloigné des contraintes projet, sera contourné.

À Stratis, nous cherchons une promesse simple : “Ce que vous faites souvent doit devenir plus rapide.” Si cette promesse est tenue, le reste suit.