Quatre briefs en entrée, un seul système de design en sortie

ux-skill est mon moteur de design open source. On lui donne une couleur de marque et un brief, et il construit un système de design : couleurs, typographie, espacements, angles, mouvement. Je l’ai créé parce que les pages construites par les outils d’IA se ressemblent toutes, et je voulais que cela cesse.

Le 25 septembre 2026, la version 4.0 était proche. Le moteur construisait des systèmes, et chacun passait les 324 contrôles de contraste, qui vérifient que le texte reste lisible sur son fond. Les démonstrations étaient jusque-là modestes : le moteur appliqué à une seule carte. Une carte ne prouve rien sur une marque.

J’ai donc fait tester le moteur sur de vrais sites avant d’aller plus loin. Voici l’essai, sous forme de consigne à reprendre pour votre propre outil :

Avant la publication, construis quatre systèmes de design à partir de quatre briefs qui ne devraient rien avoir en commun : une application de paiement destinée aux commerçants, avec l'arabe en première langue, un outil de base de données pour les développeurs backend, sombre par défaut, un restaurant familial chaleureux et ludique, et une clinique où beaucoup de patients ont plus de 60 ans. Place les quatre côte à côte et liste tout ce qui est identique.

Ce texte s’adresse à toute personne qui construit un outil générant quelque chose : systèmes de design, mises en page, textes, code. Pas besoin de savoir coder pour le suivre.

Qu’est-ce qui était identique ?

Presque tout.

J’ai mesuré les quatre systèmes que cette version construit :

La clinique pour les plus de 60 ans a reçu le même texte en 16px que l’outil pour développeurs. Le restaurant ludique a reçu la police de l’application de paiement. Chaque système utilisait une seule police pour les titres et le texte courant. Le bleu des messages d’information était identique dans les quatre.

C’était pire que ce que montre le tableau :

• Le brief était lu puis écarté. Le moteur indiquait qu’il ne reconnaissait pas « beaucoup de plus de 60 ans », l’ignorait, puis annonçait qu’il n’y avait rien à faire.
• Les polices n’étaient que des noms. Chaque système nommait une police sans fournir de moyen de la charger. Une vraie page utilisait donc ce qui se trouvait sur l’ordinateur. Voilà pourquoi les quatre pages ci-dessus ont la même police.
• La couleur de marque était modifiée. L’orange du restaurant, #E85D04, devenait #BB4900 sur le bouton pour que le texte blanc passe le contrôle de contraste. Du texte sombre sur le vrai orange l’aurait aussi passé.

Les quatre systèmes passaient tous les contrôles de contraste. Ces contrôles demandaient si chaque système était correct. Aucun ne demandait si deux systèmes étaient différents.

Quelle est la mauvaise correction ?

La correction rapide est un tableau. Restaurant signifie angles arrondis et police accueillante. Clinique signifie grand texte. Outil pour développeurs signifie angles vifs et fond sombre.

C’est une impasse. Un tableau est un modèle avec davantage de lignes. Il échoue au premier brief que personne n’a répertorié et donne à tous les restaurants du monde le même restaurant. C’est précisément cette uniformité que l’outil doit combattre.

On m’a présenté la liste des constats. Ma décision tenait en une ligne :

Tout est juste. Corrige intelligemment, sans règles figées.

Les règles figées, c’est le tableau. Corriger intelligemment signifie déduire chaque valeur de ce brief et de cette marque, sur une plage assez large pour qu’une personne voie la différence. Voici la même règle détaillée, prête à donner à votre propre outil :

N'ajoute pas de tableau de correspondance par secteur ou par catégorie. Déduis chaque valeur de ce brief et de cette marque : taille du texte, police, angles, espacements, rôles des couleurs, mouvement. Utilise une plage assez large pour que les différences se voient à l'œil. Lis à qui s'adresse le produit : âge, langues, écriture prioritaire, mode clair ou sombre par défaut, lecture au bureau ou en déplacement. Écris la raison de chaque valeur dans le rapport. Si tu n'as pas compris un élément du brief, dis lequel et comment te le fournir. N'annonce jamais qu'il n'y a rien à faire.

Comment tester la différence ?

« Rends-les différents » n’est pas un critère qu’un outil peut réussir ou rater. Un nombre, oui.

La différence est donc devenue une mesure. Pour chaque paire de systèmes, le moteur compare ce qu’une personne voit d’un coup d’œil : couleurs, typographie, tailles, angles, ombres et espacements. Il renvoie une distance : 0 signifie identiques, 1 signifie différents en tout. Le seuil est fixé à 0.20. Si une paire des briefs d’essai est plus proche que ce seuil, la suite de tests échoue. Une modification qui échoue aux tests n’est pas intégrée.

Pour chaque paire de résultats, mesure leur écart sur ce qu'une personne voit d'un coup d'œil : couleurs, typographie, tailles, angles, ombres et espacements. Donne-moi un nombre par paire, où 0 signifie identiques et 1 signifie différents en tout. Fixe un seuil. Fais échouer les tests si une paire est plus proche que ce seuil.

Le travail sur le caractère des systèmes a été intégré le jour même : 44 modifications entre 09:22 et 16:31. Le reste de la version 4.0 a pris cinq semaines de plus.

À quoi ressemblent les quatre aujourd’hui ?

Le texte de la clinique est plus grand parce que le brief précisait qui le lit, et le rapport l’explique. L’outil de base de données s’ouvre en mode sombre parce que son brief le demandait. Chaque système a une police de titres distincte de celle du texte courant et fournit le moyen de charger les deux. Le bleu d’information est devenu quatre bleus différents, chacun accordé à sa marque.

Deux systèmes partagent encore le texte en 16px et les angles de 2px : l’outil de base de données et l’application de paiement. Ils diffèrent par la typographie, les couleurs et la mise en page, ce qui explique leur distance de 0.46 plutôt que zéro.

Les six distances dépassent le seuil de 0.20 :

Un point reste incorrect. Le bouton du restaurant est en #CA5000 dans la version 4.0.0. C’est plus proche du #E85D04 de la marque que le #BB4900 de septembre, mais ce n’est toujours pas son orange.

Les quatre pages sont correctes. Aucune n’est une page devant laquelle on s’arrête pour la contempler, et je l’ai accepté pour cette publication : 4.0 s’appelle Foundations parce qu’elle pose ces fondations. Le moteur avait 3,315 tests le matin de l’essai. La version 4.0.0 a été publiée avec 13,059 tests.

Était-elle publiée quand je l’ai annoncé ?

Non, et le même type de contrôle l’aurait détecté.

J’ai marqué la version 4.0.0 comme publiée le 2 novembre. Le 11 novembre, j’ai regardé ce qu’une personne qui ne connaît pas le projet reçoit en l’installant. Le registre public, l’endroit d’où une commande d’installation télécharge le paquet, fournissait toujours la version 3.2.0, publiée le 23 septembre. Les notes de version annonçaient 4.0. L’installation indiquait 3.2. Cela a duré dix jours, jusqu’à la mise à disposition de 4.0.0 le 12 novembre.

C’est à nouveau l’échec de septembre. J’avais vérifié mon côté : le code, l’étiquette de version, les notes. Je n’avais pas vérifié ce qu’une personne reçoit. Ce contrôle fait désormais partie de chaque publication :

Après chaque publication, installe le paquet depuis le registre public sur une machine propre, comme le ferait un nouvel utilisateur. Affiche la version. Si elle ne correspond pas à la version annoncée, celle-ci n'est pas disponible. Préviens-moi avant que quelqu'un d'autre ne le découvre.

Si vous construisez un outil qui génère quelque chose

• Au lieu de vérifier qu’un résultat est correct, comparez quatre résultats entre eux.
• Au lieu de choisir des entrées faciles à tester, choisissez des entrées qui ne devraient rien avoir en commun.
• Au lieu de corriger l’uniformité avec un tableau par catégorie, déduisez chaque valeur de l’entrée.
• Au lieu de demander « plus de variété », mesurez la distance entre les résultats et fixez un seuil.
• Au lieu de laisser l’outil ignorer ce qu’il n’a pas compris, faites-lui dire ce qu’il a ignoré.
• Au lieu de croire vos notes de version, installez votre propre produit comme le ferait un nouvel utilisateur.

La question que j’attends : quatre briefs, c’est un petit échantillon, alors pourquoi s’y fier ? Je ne m’en sers pas comme étalon. Quatre briefs qui ne devraient rien avoir en commun suffisent à repérer un outil qui rend tout semblable. Et ils sont assez peu nombreux pour tenir sur un écran et être jugés à l’œil. Le seuil couvre le reste : ce test s’exécute à chaque modification proposée au moteur.

ux-skill est gratuit et open source. La page du projet donne les détails et le lien vers le code.