Trois équipes construisent le même sélecteur de client. Les libellés, la navigation clavier et les erreurs divergent ; une correction exige trois pull requests. Le problème devient visible quand cette duplication ralentit chaque livraison et propage les mêmes défauts. Le design system promet d’éliminer ce gaspillage. Six mois plus tard, la moindre règle métier attend la réunion des mainteneurs et les produits contournent la bibliothèque en silence.
Le vrai enjeu est de stabiliser les décisions d’interface répétées sans centraliser toutes les décisions produit. Le système partagé prend en charge accessibilité, états, contenu et intégration technique. Chaque application reste responsable de son workflow, de ses données et des exceptions qui font son métier.
Contre-intuitivement, un design system accélère davantage quand il dit clairement ce qu’il ne standardise pas. Une frontière explicite évite les composants universels à cinquante propriétés, les variantes locales invisibles et la gouvernance qui devient un guichet obligatoire.
Dans un développement web métier sur mesure, l’objectif n’est pas une galerie parfaite. Il consiste à rendre les parcours fréquents cohérents, testables et évolutifs, puis à offrir une sortie gouvernée lorsque le standard ne suffit pas.
Définir ce que le design system doit accélérer
Partir des frictions de livraison
L’inventaire recense composants dupliqués, défauts récurrents, temps de correction, écarts d’accessibilité et migrations difficiles. Il ne compte pas seulement les maquettes. Un bouton partagé crée peu de valeur si les équipes perdent surtout du temps sur tables, filtres et validations.
La promesse associe une population et une décision : réduire la relecture des états de formulaire, rendre les corrections clavier disponibles dans tous les produits, ou livrer un écran courant sans reconstruire ses fondations. La baseline locale précède toute cible.
Refuser le taux de couverture décoratif
Dire que 80 % des écrans utilisent la bibliothèque ne prouve ni cohérence ni vitesse. Le même composant peut être mal configuré. L’équipe mesure usages supportés, défauts évités, délai de migration et exceptions, puis relie ces signaux aux releases.
Séparer fondations, composants et parcours
Les fondations regroupent couleurs sémantiques, espacements, typographie, focus et mouvements. Les composants implémentent bouton, champ, alerte, dialogue ou table. Les patrons assemblent plusieurs composants pour une tâche, sans devenir automatiquement une règle métier universelle.
Un composant partagé doit posséder un comportement réutilisable. La clôture comptable ou la validation d’un sinistre appartient au produit, même si elle compose des étapes partagées. Cette distinction garde le domaine dans l’application et évite de transformer le système visuel en moteur de workflow.
Choisir une frontière de code
Les composants primitifs ne dépendent pas des modèles Doctrine ni des permissions applicatives. Ils reçoivent données et états via un contrat documenté. Les adaptateurs locaux traduisent les objets métier. Une migration de backend ne devrait pas obliger à refondre la bibliothèque frontend.
Écrire un contrat plutôt qu’une capture
La fiche décrit intention, anatomie, propriétés, événements, états, clavier, contenu, exemples et contre-exemples. Elle indique ce que le composant ne fait pas. Une capture ne montre ni chargement, ni erreur, ni texte long, ni absence de donnée.
Le contrat précise contrôlé ou non contrôlé, comportement asynchrone, gestion du focus et responsabilité de validation. Les valeurs arbitraires restent limitées. Une propriété libre de style peut contourner les invariants et recréer une API CSS privée.
Maintenir le vocabulaire public
Les noms reflètent l’intention, pas l’implémentation. status="critical" résiste mieux que red=true. Une dépréciation annonce remplacement, aide de migration et date. Les exemples compilés font partie du contrat observable.
Intégrer l’accessibilité dans le composant
Le composant partagé peut garantir structure, ordre de focus, nom accessible, contraste des tokens et état désactivé. Il ne garantit pas que le produit choisit le bon libellé ou place le dialogue au bon moment. La responsabilité est partagée et documentée.
Les ARIA Authoring Practices du W3C décrivent comportements clavier et sémantiques de patrons interactifs. Elles servent de référence à vérifier avec HTML natif, technologies d’assistance et contexte réel, pas de recette pour ajouter ARIA partout.
Tester plusieurs modes d’usage
La recette couvre clavier seul, zoom, lecteur d’écran sur un périmètre représentatif, contraste et réduction des animations. Les exigences sont reliées aux WCAG 2.2. Un audit automatique détecte une partie des défauts ; il ne valide pas la compréhension du parcours.
Gouverner contenu, états et erreurs
Les composants portent une structure de message : titre, explication, action et détail facultatif. Ils ne fabriquent pas une phrase générique à partir d’un code. Le produit sait si une erreur exige correction, attente, nouvelle authentification ou support.
Chargement, vide, partiel, erreur récupérable, refus et succès sont des états distincts. Les masquer derrière un spinner produit une interface indécidable. Le contrat montre chaque état avec longueur réaliste et traduction, y compris une langue plus longue.
Préserver la continuité du travail
Une erreur ne doit pas effacer les saisies valides. Le champ en faute reçoit une association explicite au message, tandis que le résumé mène au premier problème lorsque le contexte le justifie. Le focus ne saute pas à chaque validation locale.
Traiter les exceptions sans fork permanent
Une demande d’exception décrit tâche, utilisateurs, contrainte et raison pour laquelle composition et variante existantes échouent. Le mainteneur ne juge pas le métier à partir d’une maquette. Produit et design testent d’abord une solution locale bornée.
Trois sorties existent : corriger le composant si son contrat est faux, ajouter une variante si plusieurs produits partagent le besoin, ou garder une composition locale si le cas reste spécifique. La quatrième, copier le composant puis le renommer, crée une dette de migration.
Donner une date aux dérogations
L’exception documente propriétaire, motif, version et prochaine revue. Elle n’est pas forcément temporaire, mais son statut reste visible. Une télémétrie peut mesurer son usage sans collecter les données de l’utilisateur.
Versionner et migrer sans bloquer les équipes
La version suit l’API publique, les comportements et les tokens consommés. Une correction visuelle peut être rompante si elle modifie le contraste d’un libellé superposé par le produit. La note de version décrit impact et action, pas seulement les fichiers.
Une dépréciation fournit codemod ou exemple avant suppression. Les applications publient leur version installée et leurs écarts. La compatibilité de deux versions pendant une fenêtre locale permet de migrer sans gel global, à condition que la sécurité et l’accessibilité soient maintenues.
Préparer le retour arrière
Le package précédent reste disponible, mais un rollback n’est sûr que si l’API de l’application reste compatible. Le pilote vérifie installation, build, rendu et tests. Une correction critique peut nécessiter un patch sur plusieurs branches plutôt qu’une migration forcée.
Mesurer adoption, couverture et valeur
L’adoption technique combine applications, versions et composants utilisés. La couverture fonctionnelle indique combien de besoins fréquents possèdent un patron supporté. La valeur examine délai de livraison, corrections réutilisées, tickets et autonomie.
Un seuil local peut viser la migration de trois parcours pilotes avant extension. Il n’est pas universel. Si les équipes contournent un champ parce que sa validation ne convient pas, alors augmenter le taux d’import ne résout pas l’écart.
Observer les sorties autant que les entrées
Les dépréciations encore actives, forks, propriétés de style et exceptions vieillissantes révèlent la rigidité. La revue associe chacune à un besoin. Une suppression n’est validée qu’après recherche des consommateurs et recette sur leurs parcours.
Un rapport mensuel croise version installée, date du dernier build, dépréciations et incidents attribués. Il n’envoie pas automatiquement une équipe en migration. Il permet de distinguer application stable, dépendance bloquée et produit qui ne reçoit plus les correctifs critiques.
La contribution mesure aussi le délai entre une demande complète et une décision motivée. Un temps long peut signaler une capacité insuffisante ; un refus fréquent peut révéler un périmètre mal compris. Les commentaires sont classés par mécanisme, pas transformés en score de satisfaction du noyau.
Quand une variante locale devient répétée, le noyau vérifie ses consommateurs et son coût de maintenance. La promotion vers le système partagé exige au moins une API cohérente, un test dans deux contextes et un responsable. Une popularité brute ne garantit pas un invariant durable.
Installer une gouvernance proportionnée
Un petit noyau maintient vision, qualité et releases. Les contributeurs produit proposent correctifs et variantes avec exemples. Le métier valide les tâches ; l’accessibilité contrôle les patrons risqués ; la plateforme tient build et distribution.
Le niveau de revue dépend du risque. Corriger une faute documentée ne requiert pas le même comité qu’un dialogue destructif ou un changement de focus. Des créneaux courts et un journal public évitent la file opaque.
Financer la maintenance
Support, migrations, documentation et tests consomment une capacité explicite. Un design system sans temps de maintenance ralentit après son lancement. Les produits contribuent par budget, personnes ou objectifs partagés selon l’organisation.
Tester le système comme un produit partagé
Les tests unitaires couvrent états et événements. Les tests d’intégration contrôlent clavier, focus et formulaire. Les captures visuelles détectent une dérive, sans décider seules si elle est incorrecte. Les tests d’accessibilité automatisés complètent une recette humaine ciblée.
La matrice couvre navigateurs, thèmes, tailles, contenu long et erreur. Un consommateur de référence compile la version publiée, pas seulement le monorepo. Cette étape détecte dépendance manquante, CSS global et différence de build.
Rendre un échec actionnable
La CI indique composant, état, navigateur et changement attendu. Une capture entière sans zone explique mal le défaut. Le mainteneur peut accepter une baseline seulement avec motif et revue, afin de ne pas transformer le test visuel en bouton de validation automatique.
Le pipeline publie aussi la version du navigateur, du moteur de rendu et du package testé. Une différence intermittente est isolée avant d’être ignorée. La quarantaine possède un responsable et une échéance ; elle ne doit pas devenir un moyen permanent de livrer malgré un test instable.
Cas concret : la table de dossiers experts
Cas concret hypothétique. Le système propose une table responsive simple. Les gestionnaires traitent pourtant deux cents dossiers, comparent six colonnes et utilisent le clavier. Le produit réduit les colonnes pour respecter le composant ; le temps de traitement augmente.
L’équipe observe la tâche, puis compose table, barre d’actions, préférences de colonnes et vue de détail. Elle ajoute une variante dense avec focus et libellés testés, car un second produit partage le besoin. Le mobile offre une vue de consultation distincte au lieu de compresser toutes les actions.
Le pilote compare erreurs, durée et satisfaction sur les tâches réelles. La densité améliore les experts mais nuit aux occasionnels ; le rôle et la préférence choisissent le mode, sans déduire un droit. La variante rejoint la bibliothèque après recette dans deux contextes.
Pour qui un design system interne est utile
Il devient pertinent lorsque plusieurs équipes maintiennent les mêmes comportements, que les corrections doivent se propager ou que les parcours partagent une identité et des exigences. Un seul produit jeune peut commencer par une bibliothèque locale documentée.
Il ne résout pas un domaine instable ni une organisation qui ne finance aucune maintenance. Dans quels cas attendre ? Lorsque l’équipe ne connaît pas encore ses patrons, qu’elle change de stack immédiatement ou que la duplication coûte moins qu’une gouvernance centrale.
Éviter les erreurs fréquentes de standardisation
Construire depuis la charte seule
Couleurs et boutons ne couvrent pas les décisions métier. L’inventaire doit partir des tâches et défauts. La charte devient une fondation, pas la roadmap complète.
Ajouter une propriété pour chaque demande
L’API devient illisible et les combinaisons non testées explosent. Composition, variante cohérente ou solution locale sont préférées selon la répétition du besoin.
Forcer une migration sans aide
Les produits figent leur version ou copient le code. Une fenêtre de migration, une documentation ciblée et un test de consommateur rendent le changement absorbable. L’urgence critique reste traitée séparément.
Arbitrer standard, variante et composition
Si le comportement corrige une règle commune ou une exigence d’accessibilité, alors le standard doit évoluer. En revanche, si plusieurs tâches partagent une différence stable, une variante nommée peut convenir. Dans ce cas, elle reçoit un contrat et des tests complets.
Si le besoin assemble des composants sans modifier leurs invariants, alors la composition reste dans le produit ou dans un patron. Plutôt que créer un composant métier universel, l’équipe documente l’assemblage et observe sa répétition. L’exception ne doit pas être cachée dans du CSS.
- Si l’invariant commun est faux, alors corriger le composant partagé.
- En revanche, si le besoin se répète, évaluer une variante stable.
- Dans ce cas, tester la variante dans deux contextes distincts.
- Plutôt que forcer le standard, conserver une composition locale documentée.
Industrialiser le package et ses migrations
Les entrées sont besoin, contenu, états et contraintes. Les sorties sont package, documentation et résultats de recette. Les dépendances couvrent framework, build et tokens. Les responsabilités nomment maintien, contribution et adoption.
Le monitoring suit versions, erreurs de build et composants dépréciés. La journalisation conserve décisions et migrations. Le rollback repasse au package précédent lorsque l’application reste compatible. Le runbook décrit le retrait d’une release et la réponse à une régression critique.
Valider un consommateur réel
La recette installe le package publié dans une application pilote. Elle joue nominal, vide, chargement, erreur, texte long et clavier. Un contributeur extérieur au noyau suit la documentation et signale tout savoir oral.
Le build mesure poids et régression de performance sur le parcours, pas seulement taille du package. Les seuils viennent de la baseline du produit. Un composant peut être techniquement léger et ralentir la tâche par son interaction.
Plan d’action : faire émerger le système en six semaines
Semaines 1 et 2 : inventorier les décisions répétées
Les équipes recensent composants, forks, défauts, tickets et tâches. Elles choisissent trois patrons dont la duplication coûte réellement. Chaque patron reçoit états, contenu, exigences d’accessibilité et propriétaire.
Le pilote définit baseline de livraison, défauts et corrections. Il fixe la frontière entre composant et métier, puis publie une demande d’exception légère. Une application consommatrice et une équipe non mainteneuse participent dès le début.
Chaque fork est relié à un besoin et à une version. Le groupe retient un scénario nominal, une erreur, une navigation clavier et un contenu long par patron. Il écarte les composants choisis seulement parce qu’ils sont visibles dans toutes les maquettes.
Semaines 3 et 4 : construire et migrer
Fondations et composants sont implémentés avec exemples réels. La CI couvre états, clavier, rendu et package. Les produits migrent un parcours sans mélanger refonte métier et changement de bibliothèque.
Les écarts deviennent correction, variante ou composition locale, avec motif. La documentation est suivie par une seconde équipe. La release pilote possède notes, dépréciations éventuelles et retour arrière exercé.
Le package est installé depuis le registre cible dans un build propre. Une matrice vérifie navigateur, thème, zoom et dépendances. Les mainteneurs chronomètrent la migration uniquement pour repérer les étapes inutiles, sans promettre un délai universel aux autres produits.
Semaines 5 et 6 : mesurer et décider
Les utilisateurs jouent des tâches fréquentes et une exception. L’équipe compare temps, erreurs et compréhension avec prudence. Elle observe aussi effort de contribution, poids, tickets et adoption par version.
La revue étend seulement les patrons qui ont propagé une correction ou réduit une friction. Elle corrige le premier blocage de migration, finance la maintenance et retire les composants décoratifs. La roadmap suivante part des besoins partagés observés.
Une équipe non auteure soumet enfin une exception et applique une dépréciation. Si elle dépend d’une explication orale, alors documentation ou API reste incomplète. La sortie du pilote comprend propriétaires, capacité de support et calendrier de revue, pas seulement une démonstration.
Relier composants, workflows et maintenance
Découper un workflow complexe aide à garder la règle dans le produit, tandis que rendre les droits compréhensibles évite qu’un composant visuel devienne une autorisation.
Le cadre de migration Symfony prépare versions et retour arrière lorsqu’un système partagé traverse plusieurs applications.
- Standardiser fondations, états et comportements répétés.
- Gouverner les exceptions avec besoin, propriétaire et revue.
- Mesurer livraison, qualité et migration avant extension.
Conclusion : standardiser ce qui mérite de durer
Un design system interne accélère lorsque ses composants portent des décisions répétées et vérifiées. Il ralentit lorsqu’il absorbe chaque exception métier dans une API universelle.
La frontière entre fondation, composant, patron et workflow protège l’autonomie. Les dérogations visibles fournissent une sortie sans créer des forks silencieux.
La valeur apparaît dans les corrections propagées, les migrations absorbables et les tâches mieux exécutées. La quantité de composants reste un indicateur secondaire.
Dawap peut bâtir cette capacité dans une mission de développement web métier, avec un accompagnement expert du premier inventaire jusqu’à la bibliothèque versionnée et à son adoption.
