La question qui revient dans chaque comité
Depuis que les outils génèrent des écrans complets à partir d'une phrase, une question revient dans les comités de direction : à quoi bon financer une équipe Design System si une IA produit des interfaces en quelques secondes ? La question est légitime. Elle repose pourtant sur une confusion entre produire une interface et produire une interface cohérente avec toutes les autres.
Une IA générative sait faire une page de connexion convaincante. Elle ne sait pas, sans qu'on le lui dise, que votre organisation a déjà un composant de champ avec une gestion d'erreur précise, un vocabulaire éditorial, une couleur réservée aux actions principales et des règles d'accessibilité validées par un audit. Ces décisions, c'est précisément ce que contient un Design System.
Ce que l'IA fait très bien
- Produire rapidement plusieurs pistes d'un même écran pour lancer une discussion.
- Assembler des composants connus dans une mise en page plausible.
- Rédiger des premières versions de libellés, de messages d'erreur, de textes d'aide.
- Traduire une maquette en code de départ, surtout quand le code cible est bien typé.
Sur ces tâches, le gain de temps peut être réel, à condition de le mesurer plutôt que de le supposer.
Ce qu'elle fait mal quand on la laisse seule
Sans contexte, un modèle invente. Il crée un bouton qui ressemble au vôtre sans en être un, choisit un gris proche du bon, place un libellé qui contredit la charte. Chaque écart est mineur. Multiplié par le nombre d'écrans que l'IA permet de produire, il devient une dette massive, et surtout invisible : la maquette passe la revue visuelle, puis diverge au moment du développement.
La vitesse sans cohérence est juste de la dette accélérée.
C'est le paradoxe de la génération : plus elle va vite, plus le coût d'un système absent augmente. L'IA ne rend pas le Design System obsolète. Elle rend son absence beaucoup plus chère.
Le Design System devient le contexte de l'IA
La bonne façon de poser le problème est de considérer le Design System comme le contexte que l'on donne au modèle. Un modèle à qui l'on fournit la liste des composants, leurs propriétés, leurs règles d'usage et les tokens sémantiques produit des interfaces qui restent dans le cadre. Cela suppose que ces informations existent sous une forme lisible par une machine : des composants typés, des tokens nommés par leur rôle, des règles écrites plutôt que transmises oralement.
Beaucoup d'équipes découvrent à cette occasion que leur système reposait sur des règles implicites. Le designer senior sait qu'on ne met jamais deux boutons principaux côte à côte ; le modèle, lui, ne le sait pas tant que personne ne l'a écrit. Rendre ces règles explicites profite aux machines autant qu'aux nouveaux arrivants.
Trois façons d'organiser la génération
Générer librement, corriger ensuite
C'est l'approche par défaut, et la moins efficace. Le temps gagné à la génération est perdu à la correction, et une partie des écarts passe entre les mailles.
Générer avec les composants du système
Le modèle ne peut assembler que des composants existants et ne peut utiliser que des tokens. Le résultat est moins surprenant, mais conforme par construction. C'est l'approche que j'ai retenue pour la génération de code : partir de l'UI Kit et des tokens sémantiques, jamais d'une page blanche.
Générer, puis vérifier automatiquement
Chaque sortie passe par des points de contrôle : composants reconnus, tokens existants, contraste, longueur des libellés, ton éditorial. La chaîne bloque toute maquette non conforme et explique la règle enfreinte. Combinée à la précédente, cette approche fait de l'IA un accélérateur plutôt qu'un générateur de dette.
Ce que cela change pour l'équipe Design System
L'équipe ne disparaît pas, son travail se déplace. Elle écrit davantage de règles, et les écrit pour deux publics : les humains et les modèles. Elle maintient des jeux d'exemples de référence, qui servent à la fois de documentation et de jeux d'évaluation. Elle mesure la conformité des sorties générées comme elle mesurait l'adoption des composants. Et elle participe à la gouvernance de l'IA, parce qu'une partie des risques de ces outils passe par l'interface.
Concrètement, trois chantiers deviennent prioritaires :
- Exposer le système sous une forme exploitable par les outils d'IA : signatures de composants, tokens au format standard, règles d'usage écrites.
- Construire les contrôles automatiques qui vérifient la conformité des sorties.
- Définir avec les équipes produit les cas d'usage autorisés et ceux qui restent réservés aux designers.
Cohabitation, à une condition
L'IA générative et le Design System ne sont pas en concurrence. L'une apporte la vitesse, l'autre la cohérence. Ensemble, ils permettent de produire plus vite des interfaces qui restent alignées. Séparés, l'une produit de la dette et l'autre devient un frein. La condition de la cohabitation tient en une phrase : l'IA travaille dans le système, jamais à côté.