Design Systems 2026 : de Figma à la production au Qatar

La dynamique de transformation numérique du Qatar — de l'agenda Qatar National Vision 2030 à la vague de lancements fintech à Lusail, jusqu'aux ambitions de ville intelligente de Msheireb Downtown Doha — a provoqué une explosion des fichiers Figma. Les banques repensent leurs applications de mobile banking pour se conformer à l'open banking, les opérateurs télécoms reconstruisent leurs portails self-service, et les entités gouvernementales unifient leurs services aux citoyens sous des initiatives comme Hukoomi. Pourtant, projet après projet, nous observons le même schéma d'échec : une bibliothèque Figma parfaitement organisée qui ne survit jamais au passage en production. Les développeurs reconstruisent les composants de zéro. Les versions arabe et anglaise divergent. Six mois plus tard, trois équipes ont trois « boutons primaires » légèrement différents. Cet article est la méthode que nous appliquons chez FOCUS POINT pour combler cet écart : tokens, gouvernance et adoption, dans cet ordre.

Le vrai problème : votre fichier Figma n'est pas votre design system

Un design system n'est pas un ensemble de jolis composants dans une bibliothèque partagée — c'est un produit doté d'une roadmap, d'un propriétaire, de notes de version et d'une boucle de feedback. Lorsque les équipes à Doha considèrent Figma comme la ligne d'arrivée, trois symptômes apparaissent presque immédiatement : des composants dupliqués aux incohérences subtiles (un espacement décalé de 2 px, quatre nuances du même « bleu de marque »), un fossé grandissant entre ce que les designers livrent et ce que les développeurs construisent réellement, faute d'un mécanisme de handoff fiable, et — spécificité du marché qatari — une typographie arabe jamais correctement tokenisée, qui oblige les développeurs à coder en dur les tailles de police et les interlignes des mises en page RTL sur chaque projet. La solution commence en amont, avec les tokens.

Les design tokens : la source de vérité qui survit à chaque handoff

Les design tokens sont les décisions atomiques de votre marque et de votre produit — couleur, espacement, rayon, typographie, élévation, durée d'animation — exprimées sous forme de variables nommées plutôt que de valeurs codées en dur. Correctement structurés (idéalement selon le format du W3C Design Tokens Community Group), les tokens deviennent agnostiques de la plateforme : une même source alimente votre application web, votre app iOS, votre app Android et jusqu'à votre borne Flutter dans une agence bancaire de West Bay.

• Tokens globaux : valeurs brutes (codes hexadécimaux, échelles de pixels, familles de polices) qui changent rarement.
• Tokens alias/sémantiques : noms orientés usage comme 'color.background.critical' ou 'spacing.card.padding' qui référencent les tokens globaux.
• Tokens de composant : la couche la plus fine, propre à un composant précis (ex. 'button.primary.background.hover').
• Utilisez les Variables Figma avec des modes pour gérer Light/Dark et LTR/RTL simultanément, au lieu de dupliquer les cadres.
• Exportez les tokens via Tokens Studio ou l'API native de Figma, puis transformez-les avec Style Dictionary en propriétés CSS, Swift, Kotlin ou configuration Tailwind.

Gouvernance : transformer un kit de composants en produit vivant

La gouvernance est ce qui maintient la cohérence d'un design system à mesure que des dizaines de contributeurs — designers au siège, développeurs d'une équipe externalisée, équipe marketing produisant le microsite d'une campagne — le tirent dans des directions différentes. Le modèle qui fonctionne le mieux pour les organisations qatariennes que nous avons accompagnées, qu'il s'agisse d'une banque basée à Doha ou de l'unité numérique d'un ministère, est hybride : une petite équipe cœur (2 à 4 personnes) est propriétaire de l'architecture, des tokens et du rythme des versions, tandis que les équipes produit proposent de nouveaux composants via un processus léger de RFC (request for comment). Chaque composant proposé doit être accompagné d'un cas d'usage documenté, d'une revue d'accessibilité et d'exemples de contenu en arabe et en anglais avant d'être fusionné. Le versioning sémantique (majeur.mineur.correctif) et un changelog public mettent fin à la paralysie classique du « personne ne sait s'il est risqué de mettre à jour ».

• Définissez une matrice RACI : qui est Responsable, Approbateur, Consulté, Informé pour chaque catégorie de tokens et famille de composants.
• Publiez des guides de contribution en arabe et en anglais — cela seul lève un frein majeur à l'adoption dans les équipes multiculturelles au Qatar.
• Fixez une politique de dépréciation : minimum 2 cycles de release avant de retirer un composant, avec des codemods automatisés si possible.
• Organisez un conseil mensuel du design system avec des représentants de chaque unité métier (banque de détail, corporate, canaux digitaux) pour arbitrer les conflits.

L'adoption dans les organisations qataries : du mandat au réflexe

Nous avons vu des initiatives de design system pourtant bien financées échouer à Doha, non pas parce que les composants étaient mauvais, mais parce que l'adoption a été traitée comme une annonce ponctuelle plutôt que comme un programme continu. Imposer l'usage par le haut assure une conformité initiale ; cela ne produit jamais une véritable adoption. Ce qui fonctionne, c'est de faire du design system la voie de moindre résistance : plus rapide que de tout reconstruire, mieux documenté que les anciens fichiers Sketch, et visiblement maintenu.

• Nommez des 'ambassadeurs du design system' dans chaque squad — souvent le moyen le plus rapide de diffuser les bonnes pratiques bilingues dans des équipes distribuées.
• Organisez des permanences hebdomadaires (en présentiel dans les bureaux à Doha ou via Teams) où tout designer ou développeur peut venir avec un blocage.
• Suivez les analytics de la bibliothèque Figma et l'usage des composants dans le code (via des règles ESLint ou un scan des imports) pour identifier quelles équipes ont adopté et lesquelles pas.
• Intégrez l'onboarding à la formation des nouveaux arrivants — crucial sur un marché comme le Qatar où les équipes mélangent souvent talents locaux, régionaux et internationaux aux habitudes d'outils différentes.

RTL et bilinguisme dès la conception : l'impératif qatari

Tout produit numérique lancé au Qatar — application bancaire, portail self-care télécom ou e-service gouvernemental — doit gérer l'arabe RTL et l'anglais LTR sans faille, souvent au sein d'une même session lorsque les utilisateurs changent de langue. Intégrer cela au niveau du composant, plutôt que de le rustiner après le lancement, c'est précisément là que les design systems prennent toute leur valeur. Utilisez les propriétés logiques CSS (margin-inline-start au lieu de margin-left) pour que les composants basculent automatiquement sans base de code RTL séparée. Les icônes porteuses de sens directionnel (flèches, boutons retour, chevrons) ont besoin d'un token de variante en miroir, tandis que celles qui n'en ont pas (une loupe de recherche, une coche) ne doivent jamais être inversées — une erreur que l'on voit encore dans des apps en production à travers la région. Les chiffres sont une autre subtilité : décidez tôt si votre produit utilise les chiffres arabes occidentaux (0-9) ou les chiffres arabo-indiens orientaux, et encodez ce choix dans un token pour qu'il reste cohérent sur chaque écran.

De Figma au code : le pipeline qui livre vraiment

Le pipeline technique que nous mettons en place pour nos clients ressemble généralement à ceci : les designers gèrent les tokens sous forme de Variables Figma, synchronisées vers un dépôt Git grâce au plugin Tokens Studio. Un workflow GitHub Actions exécute Style Dictionary à chaque merge pour transformer les tokens en sorties spécifiques à chaque plateforme — custom properties CSS pour le web, XML/Kotlin pour Android, Swift pour iOS. Les composants sont documentés et testés visuellement dans Storybook, qui devient la source de vérité partagée entre designers et développeurs (bien plus fiable qu'un fil de commentaires Figma). Les outils de test de régression visuelle comme Chromatic détectent les changements involontaires avant qu'ils n'atteignent la préproduction. Point crucial : une étape de QA design — un designer qui compare le composant construit à la spec Figma — a lieu avant chaque version, et non après l'arrivée des plaintes utilisateurs.

Mesurer ce qui compte : les KPIs pour les dirigeants à Doha

• Taux d'adoption des composants : % d'écrans en production construits avec des composants du système vs des créations sur-mesure.
• Délai de livraison : temps moyen entre le handoff design et la mise en production, avant et après l'implémentation du système.
• Taux de conformité accessibilité : % de composants conformes au WCAG 2.2 AA, particulièrement important pour les services numériques gouvernementaux au Qatar.
• Score de cohérence design-dev : taux d'écart visuel entre la spec Figma et l'UI livrée, suivi via comparaison automatisée de captures d'écran.
• Réduction des tickets support liés à l'incohérence UI entre les versions bilingues (AR/EN) du produit.

Un scénario fintech à Doha : à quoi ressemble le succès

Imaginez une équipe de services financiers digital-first à Doha lançant un nouveau produit d'épargne sur le web, iOS et Android, en arabe et en anglais, dans un calendrier réglementaire serré lié aux exigences de l'open banking. Avec les tokens comme source de vérité, le rafraîchissement de la marque (une nouvelle couleur primaire et une échelle typographique mise à jour) se propage aux trois plateformes en une seule pull request, au lieu de trois mises à jour manuelles distinctes. Avec une gouvernance en place, un composant de bannière promotionnelle piloté par le marketing passe par une RFC de deux jours au lieu d'être codé en dur hors du système et de casser à la refonte suivante. Avec l'adoption ancrée dans les usages, les nouveaux arrivants montent en compétence grâce à la documentation du système plutôt qu'en rétro-concevant d'anciens écrans. Le résultat n'est pas seulement un lancement plus rapide — c'est un produit qui reste cohérent à mesure que l'organisation déploie ses ambitions numériques d'ici 2030.