Réalisations anonymisées

Génération de maquettes IA conforme au Design System

Structuration des données pour entraîner le modèle, mise en place de points de validation et garde-fous, définition des cas d'usage et directives, conformité au tone of voice. Le défi : accélérer la conception sans créer de dette visuelle.

Contexte

Les équipes produit avaient commencé à utiliser des outils de génération d'interface pour produire des premières maquettes. Chaque outil produisait sa propre interprétation des écrans : des boutons proches de ceux du Design System sans en être, des couleurs approximatives, des libellés qui ne respectaient pas la charte éditoriale. Les designers passaient plus de temps à corriger ces maquettes qu'à les concevoir.

Le problème à résoudre

Les équipes utilisaient déjà l'IA. Il fallait garantir que ce qu'elle produit reste dans le cadre du système. Une maquette générée qui ressemble au Design System mais n'en utilise pas les composants crée une dette invisible : elle passe la revue visuelle, puis diverge au moment du développement.

Démarche

1. Structurer la connaissance du système

   Inventaire des composants, de leurs propriétés et de leurs cas d'usage, rédigé dans un format lisible par une machine : nom, rôle, variantes autorisées, combinaisons interdites, exemples de libellés.

2. Définir les cas d'usage et les directives

   Liste fermée des écrans que l'outil a le droit de générer (formulaires, listes, tableaux de bord simples) et directives explicites pour chacun. Ce qui sort de cette liste est renvoyé vers un designer.

3. Poser des garde-fous automatiques

   Chaque maquette passe par des contrôles avant d'être affichée : composants reconnus, tokens existants, contraste, longueur des libellés, termes interdits par la charte éditoriale.

4. Aligner sur le tone of voice

   La chaîne confronte les textes générés aux règles éditoriales (vouvoiement, verbes d'action, formulation des erreurs). Un écart bloque la maquette au même titre qu'une couleur hors palette.

5. Garder un humain au bon endroit

   Le designer reçoit des maquettes déjà conformes et se concentre sur ce que l'outil ne sait pas faire : arbitrer, simplifier, défendre l'utilisateur.

Ce qui a été livré

• Un référentiel des composants et des règles d'usage exploitable par l'outil de génération.
• Une chaîne de validation qui bloque toute maquette hors système, avec un message expliquant la règle enfreinte.
• Un guide des cas d'usage autorisés et une procédure d'escalade vers l'équipe Design System.

Ce que j'en retiens

L'IA amplifie la qualité de ce qu'on lui donne. Un Design System flou produit des maquettes floues plus vite. Le travail le plus rentable a été de rendre le système explicite : il a fallu écrire chaque règle implicite que les designers appliquaient « au feeling », pour que la machine puisse la vérifier. Les humains en ont profité autant que l'outil.

Génération de code Design System-first

Utilisation de l'UI Kit existant, des tokens sémantiques et des bibliothèques de dataviz comme base de génération. Code TypeScript adapté au stack technique de l'organisation, aucune génération from scratch.

Contexte

Les assistants de code produisaient des interfaces fonctionnelles, mais en réécrivant à chaque fois des boutons, des champs et des graphiques déjà disponibles dans la bibliothèque du groupe. Le code généré passait les tests, puis devait être refactoré pour respecter les standards. Le gain de temps disparaissait à la revue de code.

Le problème à résoudre

Faire en sorte que le code généré parte de l'existant : importer les composants de l'UI Kit, consommer les tokens sémantiques plutôt que des valeurs en dur, utiliser les bibliothèques de dataviz validées. Autrement dit, transformer le Design System en point de départ obligatoire de la génération.

Démarche

1. Cartographier le stack réel

   Frameworks, conventions de nommage, structure des dossiers, règles de lint, bibliothèques autorisées. Le code généré doit ressembler à celui qu'écrirait un développeur de l'équipe.

2. Exposer l'UI Kit comme contexte

   Signatures TypeScript des composants, propriétés obligatoires, exemples d'usage. L'assistant ne peut pas inventer un composant qui existe déjà.

3. Imposer les tokens sémantiques

   Aucune couleur, aucun espacement en dur : uniquement des références aux tokens. Une règle de lint rejette toute valeur brute.

4. Encadrer la dataviz

   Les graphiques passent par les bibliothèques validées et leurs palettes accessibles, pas par des solutions improvisées.

// Généré sans contexte : valeurs en dur, composant réinventé
<button style={{ background: "#3A48E0", borderRadius: 8 }}>Valider</button>

// Généré Design System-first : composant et tokens du système
import { Button } from "@groupe/ui-kit";
<Button variant="primary" size="md">Valider</Button>

Ce qui a été livré

• Un contexte de génération versionné avec l'UI Kit : quand la bibliothèque évolue, la génération suit.
• Des règles de lint qui refusent les valeurs brutes et les composants dupliqués.
• Des gabarits d'écrans typiques prêts à être assemblés.

Ce que j'en retiens

Le code produit est déjà conforme aux standards du Design System : zéro dette technique, zéro refacto post-génération. La condition, c'est un système stable et bien typé. Un composant mal documenté sera mal utilisé par une machine comme par un humain.

Bibliothèque de composants et patterns dans un CMS

Back-office gérant l'ensemble des propriétés, états et variants du Design System. Génération automatique des attributs hreflang sur tous les sites de marque locaux du groupe.

Contexte

Le groupe opérait des dizaines de sites de marque, un par marché, chacun maintenu par une équipe locale. Les composants existaient dans le Design System, mais chaque site les recopiait et les adaptait. Au fil du temps, les versions divergeaient et les déclinaisons linguistiques étaient mal reliées entre elles, ce qui pénalisait le référencement international.

Le problème à résoudre

Faire du CMS le point de distribution du Design System : les équipes locales composent leurs pages avec les composants officiels, sans pouvoir en modifier la structure, et le CMS génère automatiquement les relations entre langues.

Démarche

1. Modéliser les composants dans le back-office

   Le back-office décrit chaque composant avec ses propriétés, ses états et ses variants. Les contributeurs choisissent parmi des options valides au lieu de saisir des valeurs libres.

2. Séparer contenu et présentation

   Les équipes locales gèrent les textes et les images ; la présentation reste pilotée par le système. Une mise à jour du composant se propage à tous les sites.

3. Automatiser l'internationalisation

   Le CMS génère les attributs hreflang à partir des correspondances entre pages : plus personne ne les saisit à la main.

4. Gouverner les évolutions

   Toute demande de nouveau composant ou de variant passe par le processus de contribution du Design System, avec revue et documentation.

Ce qui a été livré

• Une bibliothèque de composants et de patterns administrable dans le CMS.
• Une génération automatique des hreflang pour l'ensemble des sites de marque locaux.
• Un circuit de contribution qui relie les équipes locales à l'équipe Design System.

Ce que j'en retiens

Le CMS déploie le système, le traduit et en gouverne les évolutions. Résultat : un seul point de vérité pour des dizaines de marchés. La distribution compte autant que la conception. Un composant parfait que personne ne peut utiliser dans son outil quotidien n'a aucune valeur.

Ce qui revient à chaque fois