5 min de lecture - Construire un design system Angular : les leçons de SoarUI

Construire un design system consiste moins à produire une longue liste de composants qu'à décider quelles décisions d'interface doivent être partagées. SoarUI, le design system Angular et Tailwind d'Exceev, est toujours en cours de développement actif. Son utilisation dans FormAI donne à l'équipe un contexte concret pour tester ces décisions.

Les enseignements ci-dessous sont des principes d'ingénierie, pas le compte rendu d'économies non documentées ni l'annonce d'une disponibilité générale de SoarUI.

Partir des décisions répétées

Un composant a sa place dans un système partagé lorsque plusieurs surfaces produit ont besoin du même comportement et que l'organisation est prête à lui attribuer un responsable. Une simple ressemblance visuelle ne suffit pas.

Avant d'extraire un composant, comparez les implémentations existantes. Notez les états, le comportement au clavier, les règles de validation, les contraintes responsive et les besoins de traduction. Si les différences correspondent à de vraies exigences produit, les forcer dans une seule API produira plus de contournements que de réutilisation.

Un petit socle bien maintenu est donc plus utile qu'un vaste catalogue d'abstractions qui n'ont pas encore été confrontées à un produit.

Séparer les jetons, le comportement et la politique produit

Trois sujets sont souvent mélangés :

• Les jetons expriment les choix visuels, comme la couleur, l'espacement et la typographie.
• Le comportement du composant couvre l'interaction, le focus, la validation et les états.
• La politique produit décide ce qu'une application particulière autorise l'utilisateur à faire.

Séparer ces couches facilite l'adaptation. Un produit doit pouvoir modifier ses jetons de marque sans forker la logique d'interaction. Un champ de formulaire partagé ne doit pas intégrer une règle d'approbation métier propre à une seule application.

SoarUI est conçu pour s'adapter à différents produits et identités visuelles tout en maintenant des standards cohérents d'accessibilité et d'interaction. Cette intention doit encore être validée dans chaque produit consommateur.

L'accessibilité est un contrat, pas un badge

Un design system peut centraliser le comportement au clavier, la gestion du focus et le balisage sémantique. Il ne peut pas garantir à lui seul la conformité d'un écran consommateur à une norme d'accessibilité. Les libellés, l'ordre de lecture, les messages d'erreur, les couleurs et le contenu environnant comptent toujours.

Pour chaque composant partagé, documentez :

• les exigences de nom et de description accessibles ;
• les interactions attendues au clavier ;
• l'entrée, le déplacement et le retour du focus ;
• l'annonce des erreurs et changements d'état ;
• les choix de contraste qui appartiennent au thème de jetons ;
• ce que l'application consommatrice doit tester.

Les contrôles automatisés sont utiles, mais les tests manuels au clavier et avec des technologies d'assistance restent nécessaires avant une publication.

Laisser un vrai produit mettre l'API à l'épreuve

Une démonstration isolée peut masquer les difficultés. L'intégration produit fait apparaître les données asynchrones, les longues traductions, les permissions, la reprise après erreur et les contraintes de mise en page existantes.

FormAI est un utilisateur confirmé de l'interface SoarUI. Cette relation permet à l'équipe SoarUI de découvrir quelles abstractions résistent aux exigences pratiques. Elle ne prouve pas que chaque composant convient à toutes les applications Angular.

Lorsqu'un produit révèle une lacune, déterminez d'abord si elle est partagée. Un adaptateur propre au produit est souvent préférable à l'ajout d'un paramètre supplémentaire au composant central.

Versionner le contrat que vous pouvez tenir

Les consommateurs doivent savoir ce qui peut changer. Définissez les entrées, sorties, noms de jetons et comportements documentés qui sont publics. Considérez le balisage interne non documenté comme privé afin que les mainteneurs puissent l'améliorer sans créer d'engagement involontaire.

Avant une rupture, identifiez les consommateurs, fournissez une note de migration et testez la modification dans au moins une intégration réelle. Le mécanisme exact de publication dépend du mode de distribution du projet ; SoarUI n'a publié aucun engagement de distribution publique ni de licence.

Mesurer les résultats localement

Ne publiez pas l'affirmation générique qu'un design system économise un pourcentage fixe de temps. Établissez une référence dans l'équipe consommatrice et mesurez :

• le temps d'implémentation et de test d'un écran représentatif ;
• les défauts dus à des comportements incohérents ;
• les constats d'accessibilité avant publication ;
• l'effort nécessaire pour une évolution visuelle ou une mise à niveau d'Angular ;
• les contournements propres au produit qui échappent au système.

Si la réutilisation ne réduit pas le travail répété ou n'améliore pas la cohérence, il faut peut-être simplifier le composant plutôt qu'étendre le système.

La leçon durable

Un design system utile est un accord maintenu entre designers, ingénieurs et équipes produit. Partez des décisions répétées, excluez la politique produit des primitives partagées, documentez le contrat d'accessibilité et utilisez une vraie intégration produit pour tester chaque abstraction.

Pour les informations publiques actuelles, consultez la page du projet SoarUI et soarui.com.

Sources

• Site officiel de SoarUI, consulté le 27 août 2026
• Page du projet SoarUI chez Exceev, consultée le 27 août 2026