Design system au Maroc : unifier web et mobile sans figer le produit

Un design system au Maroc devient utile lorsque plusieurs produits, équipes ou canaux doivent évoluer sans recréer les mêmes décisions à chaque écran. Il ne s’agit pas seulement d’une bibliothèque de boutons : c’est un accord partagé entre design, développement et métier pour rendre une expérience cohérente, accessible et maintenable.

Un design system au Maroc, au-delà du simple UI kit

Un UI kit rassemble surtout des éléments visuels dans un outil de conception. Un design system relie ces éléments à des règles, des composants codés, des usages documentés et un mode de gouvernance. Il doit servir les parcours d’une application web ou mobile, pas seulement produire des maquettes homogènes.

Cette distinction est importante : la couleur d’un bouton ne suffit pas à garantir son comportement au clavier, ses états de chargement, son libellé en arabe ou sa compatibilité avec une évolution de marque. La valeur vient de la continuité entre intention, code et usage.

Commencer par l’inventaire du produit

La première étape consiste à examiner les interfaces existantes : écrans, composants, variantes, erreurs, formulaires et parcours fréquents. L’objectif n’est pas de tout normaliser immédiatement, mais d’identifier les répétitions coûteuses et les incohérences qui perturbent les utilisateurs.

• recenser les composants réellement utilisés et leurs variantes ;
• repérer les doublons qui répondent au même besoin ;
• prioriser les parcours métier les plus fréquents ou sensibles ;
• documenter les exceptions avant de décider de les conserver ;
• associer chaque composant à un responsable et à un contexte d’usage.

Sur une application métier ou un portail client B2B, cet inventaire révèle souvent que le même statut, le même tableau ou le même champ existe sous plusieurs formes. Le design system transforme alors ces écarts en décisions explicites.

Définir des fondations sémantiques

Les fondations couvrent la couleur, la typographie, les espacements, les grilles, l’iconographie et le mouvement. Elles gagnent à être décrites par leur rôle plutôt que par une valeur brute. Un jeton nommé « texte secondaire » résiste mieux à une évolution qu’un nom lié à une nuance précise.

Ces jetons partagés facilitent la synchronisation entre Figma et le code. Ils ne remplacent pas le jugement : ils rendent les décisions visibles, versionnables et réutilisables. Les équipes peuvent alors faire évoluer un thème ou un contraste sans corriger manuellement chaque écran.

Distinguer composants et patterns

Un composant est une unité réutilisable qui encapsule une structure, un comportement et des états. Un pattern décrit comment plusieurs composants répondent à une tâche : demander une adresse, filtrer une liste, confirmer une action ou gérer une erreur. Le GOV.UK Design System distingue précisément ces niveaux pour aider les équipes à construire des services cohérents.

Chaque composant devrait documenter son objectif, ses variantes autorisées, ses états, ses règles de contenu, ses limites et ses exemples. Pour une intégration fiable, le contrat du composant doit aussi préciser les propriétés attendues et les événements produits, comme dans une intégration API.

Maintenir la parité entre Figma et le code

La parité ne signifie pas que les deux environnements sont identiques à chaque seconde. Elle exige un flux clair : noms partagés, versions, journal de changements, critères d’acceptation et revue croisée. Lorsqu’une variante apparaît dans une maquette, l’équipe décide si elle enrichit le système ou reste propre au produit.

Storybook permet de construire, tester et documenter les composants dans des états isolés. Reliée aux maquettes, cette documentation réduit les ambiguïtés : chacun peut vérifier le rendu, le comportement et les cas limites avant l’intégration dans une page complète.

Intégrer l’accessibilité dès la conception

L’accessibilité ne doit pas être une vérification tardive. Les composants partagés doivent intégrer la navigation au clavier, un focus visible, des libellés compréhensibles, des contrastes suffisants, des messages d’erreur associés aux champs et une structure compatible avec les technologies d’assistance.

Les WCAG 2.2 du W3C constituent la référence pour définir et tester ces exigences. Une correction apportée au composant commun bénéficie à tous les produits qui l’utilisent, à condition que la version soit effectivement adoptée.

Concevoir pour le français, l’anglais et l’arabe

Au Maroc, une interface multilingue ne peut pas être traitée comme une simple traduction. L’arabe implique une lecture de droite à gauche, des choix typographiques adaptés, la gestion des icônes directionnelles et des tests sur les nombres, dates, tableaux et textes longs.

• prévoir des composants capables de changer de direction ;
• tester les libellés longs sans troncature critique ;
• séparer le sens de l’alignement visuel ;
• valider les formulaires et messages d’erreur dans chaque langue ;
• tester les parcours sur des écrans étroits et en mode déconnecté.

Cette approche complète les principes d’une application mobile offline-first : le composant doit rester compréhensible dans les conditions réelles, quelle que soit la langue ou la qualité du réseau.

Organiser une gouvernance légère

Un design system sans gouvernance finit par devenir une archive. Une petite équipe transverse peut définir les règles de contribution, relire les propositions, publier les versions et annoncer les dépréciations. Les équipes produit doivent, elles, pouvoir signaler les besoins sans attendre un cycle lourd.

• un responsable fonctionnel et un responsable technique identifiés ;
• un modèle de contribution avec preuve du besoin ;
• des critères de qualité pour design, code, contenu et accessibilité ;
• un versionnement clair et un guide de migration ;
• un calendrier de revue fondé sur les usages réels.

La publication des composants peut rejoindre les pratiques DevSecOps : revue de code, tests automatisés, contrôle des dépendances et déploiement traçable.

Déployer progressivement et mesurer l’adoption

Un remplacement global crée souvent plus de risque que de valeur. Il est préférable de commencer par un parcours pilote, de mesurer les écarts, puis d’étendre le système aux nouveaux écrans et aux zones fréquemment modifiées. Les anciens composants peuvent être dépréciés avec un chemin de migration explicite.

Les indicateurs utiles dépendent du contexte : taux d’adoption des composants, nombre de variantes dupliquées, problèmes d’accessibilité ouverts, dispersion des versions et temps de résolution des défauts partagés. Ils servent à orienter le travail, pas à promettre un résultat universel.

Les erreurs courantes à éviter

• construire une bibliothèque idéale sans partir des produits existants ;
• confondre cohérence et uniformité absolue ;
• documenter le rendu sans les règles de contenu ni les comportements ;
• ignorer l’arabe et le RTL jusqu’à la fin du projet ;
• ajouter des composants sans stratégie de version ni de retrait ;
• mesurer le volume livré plutôt que l’usage réel.

Une feuille de route concrète

Un pilote peut se concentrer sur les fondations, les formulaires et un parcours métier représentatif. Il faut ensuite relier les composants de conception aux composants codés, ajouter les tests d’accessibilité, documenter les décisions et définir le processus de contribution.

Un design system au Maroc est réussi lorsqu’il aide les équipes à décider plus vite tout en laissant le produit évoluer. Échangez avec Kanteek pour cadrer un inventaire, un pilote et une gouvernance adaptés à vos produits web et mobiles.