toothpick

Toothpick : retirez le goût IA, livrez une interface qui tient la route

Ce qu'est ce guide

Il n'y a ici aucune règle du type "toujours utiliser cette police" ou "ne jamais utiliser cette couleur". Vous pouvez utiliser n'importe quelle couleur, police ou mise en page.

Il fait deux choses :

1. Vous aide à reconnaître le goût IA : quels choix sont les valeurs par défaut irréfléchies d'une IA, et pourquoi les gens les repèrent instantanément.
2. Vous aide à éviter les défauts courants : les erreurs qui rendent une interface grossière, bon marché ou non professionnelle.

Il y a un seul test : ce choix a-t-il été fait pour ce produit, ou l'auriez-vous fait pour n'importe quel produit ? Le second cas est le goût IA.

Le style explicite de l'utilisateur, ses directives de marque et le code existant prévalent toujours, même si ce qu'il demande est l'un des "goûts IA" listés ci-dessous.

---

Ce qu'est le goût IA

Sur chaque décision de design, une IA dérive vers l'option la plus courante. Il se manifeste en deux couches.

Couche un, les vieux clichés : dégradés violet-bleu, émojis en guise d'icônes, cartes arrondies identiques avec des ombres grises, page d'atterrissage "titre centré plus trois cartes de fonctionnalités", texte comme "libérez des possibilités illimitées". Beaucoup de gens les reconnaissent déjà.

Couche deux, faire semblant d'avoir du goût : une fois qu'on lui dit "ne fais pas ça ressembler à de l'IA", une IA passe à une autre tenue tout aussi fixe :

• Fond crème, grand titre serif, accent terracotta ou rouge foncé, se faisant passer pour "chaleureux et de bon goût"
• Fond presque noir, un accent vert néon, ambre ou vermillon, monospace partout, se faisant passer pour "hacker"
• Fins traits noirs façon journal, rayon de bordure nul, colonnes denses, se faisant passer pour "suisse et professionnel"
• Une étiquette en majuscules au-dessus de chaque titre, chaînes de points "A · B · C" partout, "→" après chaque lien, monospace pour chaque petite donnée, "01 / 02 / 03" pour du contenu qui n'est pas une séquence
• Grands nombres décoratifs, asymétrie pour l'asymétrie, une invite "$" de terminal ou un point de statut "●" utilisé comme décoration

La couche deux est plus difficile à remarquer car elle a l'air "designée". C'est le même problème que la couche un : le style a été plaqué, pas issu du produit.

La liste complète, avec pourquoi chaque élément ressemble à de l'IA et quand il est en fait correct, se trouve dans references/ai-tells.md.

À quoi ressemblent les bonnes interfaces

references/benchmarks.md contient les mesures de Vercel, GitHub, ChatGPT, Google et Linear, ainsi que les produits chinois DingTalk, Juejin, WeChat Read et sspai, et comment les interfaces chinoises diffèrent (titres plus lourds, hauteur de ligne plus grande, tailles plus petites). Ce que les références anglaises partagent :

• Très peu de couleurs : presque entièrement noir, blanc et gris, plus une couleur fonctionnelle
• Une seule famille de polices ; les titres sont grands mais pas lourds
• Séparation légère : espaces blancs, contours pâles et fins, ombres très faibles, pas de règles noires ni d'ombres lourdes
• Le produit lui-même est le héros ; la décoration est quasi nulle
• Un point focal par écran

Ce sont des références, pas un template. Un café ne devrait pas ressembler à Vercel, mais il devrait être tout aussi retenu et précis, avec le contenu en avant.

La référence peut elle-même devenir la nouvelle valeur par défaut. Si vos derniers projets, une fois leurs noms cachés, ressemblent tous à du blanc, gris neutre, boutons en pilule et panneaux à bords fins, la référence est devenue un template. Utilisez-la pour calibrer le savoir-faire : quelle légèreté pour une ligne, quelle douceur pour une ombre, quelle finesse pour un titre. La couleur, le matériau et le héros viennent de la liste de l'étape 2.

---

Workflow

0. D'abord, évaluez l'ampleur du changement

Changement	Exemples	Étapes à suivre
Petit	Un changement de couleur, d'espacement ou de texte ; la correction d'un composant ; l'ajout d'un bouton	Lisez le code et les variables de style concernés, modifiez dans le style existant, vérifiez les quelques entrées pertinentes dans references/ai-tells.md, et livrez avec une ou deux phrases (une liste d'espaces réservés uniquement s'il y a des espaces réservés)
Moyen	Une nouvelle page ou les écrans d'une nouvelle fonctionnalité dans un produit existant	Étape 1, un plan de trois ou quatre lignes, puis les étapes 5 à 7. Conservez le style existant du produit ; sautez l'inventaire et l'argumentation
Grand	Un nouveau produit, un site web, une page d'atterrissage, une refonte	Les sept étapes

En cas de doute, choisissez la taille la plus petite ; l'utilisateur vous en demandera plus. N'écrivez pas un plan de design pour un seul bouton.

1. Comprenez ce que c'est : lisez d'abord le projet, puis le visiteur

• Dans un projet existant, lisez-le avant de toucher à quoi que ce soit. Avant tout plan ou code, découvrez :

  • Quelles sont les fonctionnalités réelles du projet (lisez le README, les routes, les pages et l'API ; ne devinez pas à partir des titres de page)
  • Les composants existants, les variables de style, le jeu d'icônes et les polices. La nouvelle UI les utilise ; ne démarrez pas un système parallèle
  • Le modèle de données et les champs réels que l'API renvoie. Construisez l'UI sur ces champs
  • Le vocabulaire existant dans le texte. Continuez à appeler la même chose par le même nom

  Notez en quelques lignes "ce que le projet a", et basez le plan là-dessus. Pour tout ce que vous ne pouvez pas lire (par exemple, le backend n'est pas dans le dépôt), demandez à l'utilisateur ou indiquez clairement votre hypothèse.

• Quel est le produit ou le contenu ? À qui est-il destiné ? Si ce n'est pas clair, faites une hypothèse concrète, dites-la en une ligne, et passez à autre chose au lieu de demander constamment.

• Déterminez le mode de cette page (jugez la page, pas le produit : la page d'accueil d'un outil de développement est Persuader, son tableau de bord est Opérer) :

Mode	Ce que le succès signifie pour le visiteur	Exemples	Où va l'effort de design
Persuader	Décide et agit	Page d'accueil, page d'atterrissage, campagne, tarifs	Un point de vue et de l'impact ; convaincre avec des images réelles
Opérer	Accomplit une tâche	Administration, tableau de bord, éditeur, paramètres, outils	Scannable, cohérent, efficace ; la personnalité vit dans des détails précis
Lire	Comprend le contenu	Documentation, articles, centre d'aide, journal des modifications	Structure claire, expérience de lecture confortable
Présenter	Est immergé dans le travail	Portfolio, galerie, études de cas	Le travail mène, l'interface s'efface

Références correspondantes : Persuader et Présenter utilisent references/web.md, Opérer utilise references/app-desktop.md, le mobile utilise references/mobile.md. Les README de projet et les cartes mentales ou diagrammes qu'ils contiennent utilisent references/readme.md.

• Affinage ou refonte ? Un affinage conserve le style, le texte et le comportement existants et ne modifie que ce qui est dans le périmètre. Une refonte remplace l'apparence générale mais conserve les faits du produit, le contenu et les fonctionnalités. Ne rapiècez pas un nouveau style sur l'ancien à moitié.

2. Inventoriez ce qui n'appartient qu'à ce sujet

Notez 8 à 12 choses concrètes qui appartiennent à ce client et à aucun concurrent : le nom et sa signification, la rue et la ville, le numéro de porte et l'enseigne du magasin, les matériaux et les couleurs, ses chiffres (places assises, altitude, années d'activité), ses contraintes (un lot par mois, fermé en hiver), ses rituels (le four est allumé à cinq heures), les choses imprimées de son monde (reçus, étiquettes, horaires).

Les idées de design viennent de cette liste, pas de "ce à quoi les sites web de ce secteur ressemblent habituellement". Une compétence open source sur laquelle nous nous sommes appuyés a mené des tests en aveugle : les pages gagnantes utilisaient des éléments d'une telle liste ; les pages perdantes avaient de bonnes compositions construites sur des idées génériques du secteur.

3. Écrivez l'argument avant de choisir les sections

Chaque section d'une page marketing doit être une affirmation plus sa preuve, une ligne chacune :

Héros : trois torréfactions cette semaine, expédiées vendredi → preuve : trois sachets, la date de torréfaction
Cafés : chacun a une origine et un goût clairs → preuve : origine réelle, altitude, notes de dégustation
...

Supprimez toute section sans affirmation. Cela vous évite la structure standard "héros, mur de logos, trois fonctionnalités, témoignages, tarifs, FAQ".

4. Écrivez un plan court

• Couleur : 4 à 6 valeurs, chacune avec son utilisation
• Police : quelles polices et ce que chacune fait
• Mise en page : une phrase sur l'idée, un wireframe ASCII simple si utile, et l'alignement
• Héros : la chose la plus convaincante sur cette page, et les ressources que vous avez réellement (ne concevez pas autour d'images qui n'existent pas)
• Intensité : retenu (le défaut pour Opérer et Lire), un héros (le défaut pour Persuader : une image forte de l'inventaire, tout le reste sobre), ou un concept complet (voir "Quand s'engager sur un concept fort" ci-dessous)

5. Vérifiez le plan : défaut ou choix ?

• Pour un brief similaire, arriverais-je à peu près au même plan ? Si oui, cette partie est un défaut ; revenez à la liste de l'étape 2 pour des idées.
• Cela correspond-il à quelque chose dans references/ai-tells.md ? Si oui, changez-le, ou soyez capable de dire pourquoi ce produit en a besoin.
• Y a-t-il plus de décoration que de contenu ?

Dites brièvement dans votre réponse ce que vous avez changé et pourquoi.

6. Construisez

• Gérez les couleurs et l'espacement avec des variables CSS. Surveillez la spécificité des sélecteurs pour que les classes ne se surchargent pas (en particulier le padding des sections).
• Le contenu d'exemple est réel et spécifique, et les chiffres sont cohérents.
• Lorsque la page montre l'interface du produit (par exemple, l'emplacement de capture d'écran sur une page d'accueil SaaS), construisez-la comme un véritable fragment de ce produit : données réelles, chiffres cohérents, un résultat clair. Pas de blocs gris et de faux chiffres.
• Les détails de savoir-faire se trouvent dans references/craft-details.md.

7. Regardez le résultat, corrigez par lots, puis retirez une chose

• Regardez aux tailles réelles : ordinateur, téléphone (environ 375px), mode sombre si vous l'avez construit. Regardez une fois, corrigez tout ensemble ; ne faites pas de capture d'écran après chaque ajustement.
• Parcourez checklist.md.
• Comme vérifier le miroir avant de quitter la maison, enlevez un accessoire.
• Lorsque vous ne pouvez pas voir le résultat (le modèle ne peut pas lire les images, ou il n'y a pas de navigateur) : ne faites pas semblant d'avoir regardé. Examinez plutôt le code : le texte le plus long tient-il dans la colonne à chaque point d'arrêt, quel est le rapport de contraste calculé à partir des valeurs de couleur, tous les états d'interaction sont-ils écrits ? Dites dans votre livraison que vous ne l'avez pas vu dans un navigateur et demandez à l'utilisateur une capture d'écran sur ordinateur et une sur téléphone pour un autre passage.

La retenue n'est pas le vide

Supprimer la décoration n'est que la moitié du travail. Une page qui a perdu ses étiquettes, ses règles et ses cartes et n'a rien gagné à la place paraît maigre, et peut perdre face à une page plus riche qui a encore un peu de goût IA. L'autre moitié est la substance : une échelle typographique plus audacieuse, des champs de couleur entiers, de vraies images du monde de ce sujet, chaque section remplie de son contenu complet.

Quand s'engager sur un concept fort

La retenue est la valeur par défaut, pas le plafond. Un concept visuel de page entière (une bande dessinée, un journal, un dessin technique, un ticket) est approprié lorsque toutes ces conditions sont remplies :

• Il a une source : l'utilisateur l'a demandé, ou le monde du sujet lui-même parle ce langage (les dessins d'un architecte, les épreuves d'une imprimerie, un horaire de chemin de fer) et vous pouvez le trouver dans la liste de l'étape 2
• Chaque élément correspond à un contenu : notez la correspondance, par exemple "lignes de vitesse : les requêtes qui s'accumulent", "densité de tramage : la lourdeur du verrou". Abandonnez tout élément que vous ne pouvez pas faire correspondre
• Il reste lisible correctement : le code, les chiffres, les tableaux et les boutons peuvent toujours être lus et cliqués sans erreur. Le concept sert le contenu et n'induit jamais les gens en erreur de lecture
• Les faits ne changent pas : un nouveau style conserve tous les faits du produit, les fonctionnalités, les chiffres et la liste des espaces réservés
• Il sait où s'arrêter : utilisez-le pleinement sur la ligne principale et restez sobre dans les détails ; ne mettez pas d'élément de thème dans chaque coin

S'il échoue à l'un de ces points, revenez à un héros : n'utilisez le langage que dans le héros ou une section. La différence avec un costume de style : un costume s'adapte à n'importe quel produit (crème et serif, presque noir et néon, traits de cheveux de journal) ; un concept fort n'a de sens que pour celui-ci.

Lorsque vous livrez, expliquez l'idée de design en une ou deux phrases pour que l'utilisateur puisse facilement réorienter, et joignez la liste des espaces réservés (voir "Ne simulez rien, ne trompez aucun développeur").

Lorsque l'utilisateur demande des modifications

L'utilisateur dit	Cela signifie
Plus audacieux	Plus de contraste d'échelle, des champs de couleur entiers, un héros plus grand. Pas plus de décoration
Plus sobre / trop chargé	Moins de couleurs et moins d'animation, moins de tailles de police, supprimez les éléments secondaires
Simplifiez	Supprimez les sections et les éléments sans affirmation ; gardez l'essentiel
Plus de finition	Savoir-faire : alignement, espacement, rayon, ombres, états, parties natives du navigateur
Est-ce prêt à être livré ?	Erreurs, états vides, contenu très long, autres langues, cas limites

---

Ne simulez rien, ne trompez aucun développeur

Les utilisateurs et les développeurs doivent tous deux pouvoir dire ce qui est réel et ce qui n'est pas encore fait.

Rien de faux devant les utilisateurs finaux

• Pas de logos inventés, de murs de logos clients ou de badges de partenaires. Pas de faux logo assemblé à partir de symboles comme "$", "▲" ou "●" ; sans logo, le nom du produit en texte brut suffit.
• Pas de nombres d'utilisateurs inventés, de taux de satisfaction, de chiffres de croissance, de témoignages ou de mentions dans la presse.
• Vérifiez les faits professionnels (détails techniques, normes, réglementations, médecine, finances, statistiques). L'IA écrit ces choses avec aisance, et ses erreurs sont tout aussi fluentes :
  • Listez les affirmations professionnelles sur la page. Vérifiez ce que vous pouvez dans la documentation ou les normes, et citez la source dans un commentaire de code
  • Ce que vous ne pouvez pas confirmer, soit omettre, soit lister sous "Non vérifié" dans la liste des espaces réservés
  • Les chiffres sur la page doivent être cohérents entre eux (70 requêtes par seconde pendant 41 secondes, cela fait 2 870 requêtes)

Rien qui ne trompe le développeur

• Pas de fonctionnalités inventées : chaque fonctionnalité affichée dans l'interface existe dans le projet ou a été explicitement demandée. N'ajoutez pas de "recommandations intelligentes" ou d'"export en un clic" pour améliorer l'apparence de la page.
• Les données factices ne se font jamais passer pour des données réelles : connectez l'API réelle lorsque vous le pouvez. Lorsque vous ne le pouvez pas, gardez les données factices à un seul endroit (par exemple mock/), avec les mêmes champs que l'API réelle, et marquez-les comme factices dans le code. Ne codez pas en dur des chiffres attrayants dans les composants pour que la page ait l'air "terminée".
• Pas d'interactions factices : un bouton, un formulaire ou un lien qui n'est pas câblé ne doit pas avoir d'animation de clic qui prétend qu'il fonctionne. Désactivez-le et étiquetez-le "non connecté", ou listez-le dans les notes de livraison.
• Les démos et concepts construits à partir de zéro peuvent utiliser une marque et des données fictives, mais la page doit dire qu'il s'agit d'un exemple.

Joignez une liste d'espaces réservés

... [tronqué pour la traduction]