Gouvernance DSFR

Une intégration DSFR réussie n'est pas seulement une question de classes CSS. Elle repose sur une gouvernance claire : qui choisit les composants, qui valide l'accessibilité, qui maintient les layouts, qui contrôle les écarts.

Rôles

Rôle	Responsabilité
Product owner	arbitrer les parcours et prioriser les écrans
Designer	vérifier l'usage DSFR et les variantes
Lead développeur	définir les layouts, conventions Twig et règles de composition
Référent accessibilité	contrôler les parcours clavier, noms accessibles et contenus
DevOps	sécuriser assets, cache, licence et déploiement

Règles de standardisation

• Un composant DSFR du bundle doit être utilisé avant d'écrire du HTML DSFR manuel.
• Les layouts partagés sont versionnés et revus comme du code produit.
• Les exceptions sont documentées avec une raison métier ou technique.
• Les composants Pro sont suivis dans le profiler pour éviter les surprises de licence.
• Les pages critiques ont une checklist accessibilité dédiée.

Catalogue interne

Pour une DSI ou une ESN, créez une page projet qui référence :

• les layouts validés ;
• les composants autorisés par type d'écran ;
• les exemples Twig de l'application ;
• les conventions d'ids ;
• les règles de contenu et de libellés ;
• les exemples de référence.

Réduction du risque

Risque	Réponse avec le bundle
divergence HTML entre équipes	API Twig commune
dette CSS locale	props et classes générées
oubli accessibilité mécanique	validations, checklists, profiler
onboarding lent	documentation et exemples prêts
dépendance à une personne	conventions explicites et composants nommés