La galaxie
ORBITE II · CONSTELLATION

Brand & Surface

Marque et surface

Ce qu'on voit et comment ça sonne. Minimalisme radical, typographie, voix de studio et traduction qui préserve le sens. Le sens esthétique de XNLAB appliqué à tout.

Alimente XNLABTous les projets
5 modules · 5 leçons
MODULES DE LA CONSTELLATION Ouvre chaque module pour le cours complet
BS-01

Minimalisme radical

leçon

Auditer un écran réel et livrer un avant/après où chaque élément supprimé est justifié par une décision, pas par goût.

Le minimalisme radical de XNLAB n'est pas une esthétique : c'est une méthode de décision. La plupart des opérateurs croient que « nettoyer » une interface, c'est baisser les opacités et ajouter de l'air. En réalité, c'est l'inverse : chaque élément qui survit doit mériter sa place en répondant à une question concrète (que fait l'utilisateur ici ? quelle décision prend-il ?). De la chirurgie, pas de la décoration. Sans méthode explicite, « minimaliste » dégénère en « vide et arbitraire », ce qui est pire que surchargé : ça a l'air négligé. L'antidote, c'est un audit avec un critère écrit, où retirer est une action défendable et réversible, pas une impulsion.

LA LEÇON

Le minimalisme radical est une méthode d'élimination, pas un style visuel. Par défaut on retire ; ajouter est l'exception qui doit faire la preuve.

Chaque élément d'un écran doit répondre à une question que l'utilisateur se pose à cet instant. S'il ne répond à aucune, c'est du bruit, même s'il est joli.

Un avant/après sans justification écrite est une opinion. Avec justification, c'est un audit : défendable devant un client, reproductible par quelqu'un d'autre, réversible si les données le contredisent.

Le vide arbitraire (baisser l'opacité, mettre de l'air sans raison) se lit comme de la négligence, pas comme de la sophistication. Un minimalisme mal fait ressemble à une page cassée.

La règle XNLAB est conservatrice mais pas dogmatique : le défaut, c'est l'édition chirurgicale, révisable avec des données de conversion, pas une loi morale.

EXERCICE

Prends un écran dense déjà existant (une landing, un dashboard, un formulaire ; celui de MOONKEY lui-même fait l'affaire). Capture l'état actuel comme « before ». Liste chaque élément visible dans un tableau. Pour chacun, réponds en une ligne : quelle décision de l'utilisateur sert-il ici et maintenant ? Marque comme candidat à la suppression tout ce qui ne répond à rien. Applique les coupes et capture l'« after ». Écris à côté de chaque suppression la raison (redondant / ne répond à aucune décision / déplaçable vers une autre vue / décoratif sans fonction). Vérifie qu'aucune coupe n'a cassé une tâche que l'utilisateur a réellement besoin d'accomplir.

LIVRABLE

Un audit avant/après d'un écran réel : les deux captures, le tableau des éléments avec leur question-utilisateur, et la liste des suppressions avec leur justification écrite, une ligne chacune. Réversible : n'importe qui peut lire pourquoi chaque chose a été retirée et l'annuler si une donnée le contredit.

CLÉ ESSENTIELLE

Retirer est la décision la plus difficile à défendre parce qu'elle ne laisse aucune trace ; c'est pour ça qu'il faut écrire la raison avant d'effacer, pas après. L'audit transforme le minimalisme d'opinion en méthode.

ERREURS À ÉVITER

  • ×Confondre minimalisme avec baisser les opacités et mettre de l'air : ça, c'est du vide arbitraire, pas de la chirurgie. Le résultat a l'air négligé, pas premium.
  • ×Retirer des éléments qui soutiennent réellement une tâche de l'utilisateur et casser le flux pour courir après la propreté visuelle.
  • ×Ne pas documenter la raison de chaque coupe : sans justification écrite, l'audit est irréversible et indéfendable devant le client.
  • ×Traiter la règle comme une loi morale inébranlable au lieu d'un défaut révisable avec des données de conversion.
BS-02

Typographie avec intention

leçon

Construire une paire de titres qui mêlent l'Inter sans aux spans en italique serif (Cormorant) sans que l'œil détecte le saut, et documenter la correction de taille qui rend ça possible.

Mêler une sans (Inter) à une italique serif (Cormorant) à l'intérieur d'un même titre est l'un des gestes typographiques les plus rentables et les plus piégés. Le piège concret, vérifié chez XNLAB : la serif italique a une x-height plus basse, donc au même font-size elle paraît optiquement plus petite et le titre semble cassé, comme si la cursive s'enfonçait. L'opérateur qui ne connaît pas l'ajustement laisse ça tel quel et le résultat grince sans qu'il sache pourquoi. La correction n'est pas théorique : c'est un bump explicite de font-size sur le span italique (~1.18–1.2em) pour égaliser la hauteur perçue. Le savoir, c'est la différence entre une typographie avec intention et deux fontes qui se disputent.

LA LEÇON

Le font-size nominal n'est pas la taille perçue. Ce que l'œil mesure, c'est la x-height, et l'italique serif l'a plus basse que la sans : au même px, elle paraît plus petite.

L'ajustement vérifié pour Inter + Cormorant italique est un bump de fontSize à 1.18-1.2em sur le span serif. Ce n'est pas optionnel : sans lui, le titre se lit cassé.

L'italique serif s'emploie pour un mot ou une expression au poids sémantique à l'intérieur d'un titre sans, pas pour décorer au hasard. Le contraste doit signaler quelque chose, pas juste faire joli.

L'intention typographique se démontre : le span corrigé et le span non corrigé, côte à côte, rendent le problème visible et la solution indéniable.

EXERCICE

Écris deux titres XNLAB où un mot-clé passe en italique serif au milieu d'un texte sans (ex. : un substantif qui porte le sens). Rends chacun deux fois : une avec le span italique au même font-size que la sans, une autre avec fontSize:'1.18em' sur le span. Compare les deux versions côte à côte et confirme à l'œil (pas au chiffre) laquelle égalise la hauteur perçue. Note la valeur exacte qui colle pour ta paire typographique. Si le saut reste visible, monte vers 1.2em et revérifie.

LIVRABLE

Une paire de titres italic-mix qui fonctionnent, chacun accompagné de sa comparaison « non corrigé / corrigé » qui rend visible le problème de x-height, plus la ligne de CSS exacte (fontSize:'1.18em' ou la valeur qui colle) documentée comme décision réutilisable.

CLÉ ESSENTIELLE

La typographie avec intention se remarque justement quand elle ne se remarque pas : si le lecteur perçoit le saut entre sans et serif, tu as raté. L'ajustement de x-height est invisible bien fait et évident mal fait.

ERREURS À ÉVITER

  • ×Supposer que même font-size signifie même taille visuelle : ça ignore la x-height et laisse le titre enfoncé dans la cursive.
  • ×Utiliser l'italique serif comme décoration sans poids sémantique : le contraste typographique doit signaler quelque chose, pas remplir.
  • ×Vérifier l'ajustement au chiffre (1.18em) et non à l'œil : la valeur exacte dépend de la paire de fontes et de la taille ; il faut la regarder.
  • ×Appliquer le bump globalement au lieu du span concret, et casser le reste de la hiérarchie.
BS-03

Voix de studio

leçon

Écrire un copy deck de page réelle (hero + trois sections) en voix de studio anonyme qui passe le test « vérité ou marketing ? » : chaque phrase est vérifiable, ou elle s'efface.

La voix de XNLAB est anonyme par conception : studio, jamais personne. Pas de fondateur avec un nom, ni bio, ni photo, ni « je crois que ». Ça paraît facile et c'est le plus difficile : sans un « je » à qui faire appel, la seule autorité qui reste est la précision. L'erreur typique de l'opérateur, c'est de remplir le vide avec de la fumée — « nous transformons ton activité », « résultats exceptionnels », « passion du détail » — des phrases qui ne disent rien de vérifiable. La voix de studio tient sur l'inverse : des affirmations qui sont une vérité vérifiable, ou qui ne s'écrivent pas. L'état légal de XNLAB l'exige littéralement : ne pas inventer de NIF, d'adresse ni de données d'enregistrement ; marquer comme non enregistré ce qui ne l'est pas. Le copy deck est l'artefact où cette discipline devient testable.

LA LEÇON

La voix de studio est anonyme : jamais de première personne du singulier, jamais de nom de fondateur, jamais de bio. L'autorité vient de la précision, pas de qui parle.

Le test « vérité ou marketing ? » : chaque phrase reçoit une étiquette. Si elle est vérifiable, elle reste. Si c'est une promesse vide ou un adjectif sans appui, elle s'efface ou se réécrit en fait.

Les promesses vides (« nous transformons », « exceptionnel », « leader ») sont du bruit qui fait baisser la crédibilité de tout ce qui les entoure, y compris ce qui est vrai.

L'honnêteté légale fait partie de la voix : ne pas inventer de données d'entité. Ce qui n'est pas enregistré est marqué comme non enregistré ; le cycle est décrit tel qu'il est (« Open. »), pas tel que ça arrange.

Anonyme n'est pas froid. La voix est directe et concrète — la chaleur vient de la rigueur et du fait de parler de choses réelles, pas de confessions personnelles.

EXERCICE

Choisis une page (home ou /contact). Écris le hero et trois sections en voix de studio. Ensuite, passe chaque phrase au test : dans une colonne tu colles la phrase, dans l'autre tu écris « vérité » (et comment ça se vérifie) ou « marketing » (et pourquoi c'est de la fumée). Toute phrase marquée « marketing » se réécrit en fait vérifiable ou se supprime. Vérifie qu'aucun « je » ne s'est glissé, aucun nom propre, aucune donnée d'entité inventée. Confirme que l'état du cycle est décrit tel qu'il est réellement, pas tel qu'il se vendrait le mieux.

LIVRABLE

Un copy deck d'une page réelle (hero + 3 sections) avec son tableau de test « vérité ou marketing ? » à côté : chaque phrase finale classée comme vérité-vérifiable, sans une seule promesse vide survivante et sans aucune donnée d'entité inventée. Prêt à coller dans la page.

CLÉ ESSENTIELLE

Retirer le « je » oblige chaque phrase à porter elle-même la preuve, pas la personne ; c'est pour ça que la voix anonyme est le détecteur de fumée le plus sévère qui existe. Si une affirmation a besoin d'un nom derrière elle pour tenir, ce n'était pas une vérité : c'était du marketing.

ERREURS À ÉVITER

  • ×Combler l'absence de fondateur avec des superlatifs (« exceptionnel », « leader », « transformateur ») au lieu de faits vérifiables.
  • ×Glisser une première personne ou un nom propre et casser l'anonymat du studio.
  • ×Inventer des données d'entité (NIF, adresse, enregistrement) pour paraître établi : ça viole l'état légal réel et ça se détecte.
  • ×Confondre anonyme avec froid et écrire un copy sans vie : la chaleur vient de la rigueur et du concret, pas d'un « je ».
  • ×Décrire le cycle selon ce qui arrange commercialement (« une place reste ») au lieu de tel qu'il est (« Open. »).
BS-04

Traduire en préservant le sens

leçon

Produire une paire EN/ES d'un bloc de copy où l'espagnol dit la même chose que l'anglais — pas le littéral — et livrer les notes de chaque décision de sens.

Traduire le copy de XNLAB, ce n'est pas substituer des mots : c'est préserver le sens à travers deux langues aux grammaires différentes. L'erreur documentée et récurrente, c'est le miroir lexical : traduire « Not X » par « Sin X » alors que l'anglais marquait une comparaison (pas une absence), et l'espagnol la transforme en autre chose. Pareil avec le passage du passif anglais au réfléchi espagnol, ou avec des modificateurs et des verbes qui tombent sans que personne ne le remarque. Chacun de ces dérapages décale le sens d'un cran, et trois crans plus loin la page en espagnol dit quelque chose que l'anglais n'a jamais dit. La seule défense, c'est de lire chaque ligne en espagnol comme un natif — pas comme un traducteur — et de vérifier que l'affirmation est la même, pas que les mots coïncident.

LA LEÇON

Traduire, c'est préserver le sens, pas calquer le lexique. La bonne question n'est pas « ce mot existe-t-il en espagnol ? » mais « cette phrase affirme-t-elle la même chose ? ».

« Not X » → « Sin X » est le piège vedette : absence vs comparaison. L'anglais parfois compare, et « Sin X » le transforme en une carence que l'original ne disait pas.

Le passif anglais qui devient réfléchi en espagnol peut changer qui fait l'action et la responsabilité implicite. Il faut vérifier l'agent, pas seulement la forme.

Modificateurs et verbes tombent dans la traduction sans prévenir. Un adjectif perdu ou un verbe aplati fait baisser la température ou change la force de l'affirmation.

Le contrôle qualité, c'est lire chaque ligne ES comme un natif, pas la confronter mot à mot à l'EN. Si ça sonne comme une traduction, c'est une traduction ; si ça sonne comme un original, c'est bon.

EXERCICE

Prends un bloc EN réel (hero ou section avec des affirmations chargées). Traduis en espagnol en priorisant le sens. Puis audite ligne à ligne : un « Not X » est-il devenu un « Sin X » en changeant comparaison en absence ? un passif est-il passé au réfléchi en déplaçant l'agent ? un modificateur ou un verbe est-il tombé ? Pour chaque trouvaille, note la décision : ce que disait l'anglais, ce que disait ton premier jet, ce que tu as mis et pourquoi ça préserve le sens. Lis la version finale en espagnol à voix haute comme un natif et confirme qu'elle affirme exactement la même chose que l'anglais.

LIVRABLE

Une paire EN/ES d'un bloc réel avec ses notes de traduction : pour chaque ligne à risque (Not X / passif-réfléchi / modificateur tombé), la décision documentée de la façon dont le sens a été préservé. L'ES passe la lecture de natif sans sentir la traduction.

CLÉ ESSENTIELLE

Une traduction correcte mot à mot peut être un mensonge phrase à phrase ; le miroir lexical est le chemin le plus rapide pour dire quelque chose que l'original n'a jamais affirmé. Préserver le sens exige parfois de s'éloigner des mots.

ERREURS À ÉVITER

  • ×Miroir lexical : « Not X » → « Sin X » en transformant une comparaison en une absence que l'anglais n'énonçait pas.
  • ×Laisser le passif anglais devenir réfléchi espagnol et déplacer l'agent ou la responsabilité implicite.
  • ×Perdre des modificateurs ou des verbes dans le transfert et aplatir la force de l'affirmation sans s'en rendre compte.
  • ×Vérifier en confrontant mot à mot à l'EN au lieu de lire l'ES comme un natif : le miroir lexical passe ce test et ment quand même.
BS-05

Couleur et profondeur

leçon

Documenter un système de couleur et de profondeur (glass, bandes, champs de couleur) comme un ensemble de règles et de tokens réutilisables, avec des échantillons qui prouvent qu'il donne de la vie sans introduire de bruit.

La couleur et la profondeur, c'est là qu'une surface minimaliste gagne en vie ou se casse. Glass, bandes de couleur et champs de fond peuvent faire respirer une page plate — ou la transformer en carnaval qui contredit le minimalisme radical de BS-01. La différence entre les deux résultats n'est pas le goût : c'est un système. Sans règles écrites (quand glass, quelle intensité, quelle profondeur de champ, ce qui s'anime et ce qui ne s'anime pas), chaque écran improvise et l'ensemble perd sa cohérence. Il y a en plus un piège de vérification documenté chez XNLAB : les animations de fond se mettent en pause quand l'onglet n'est pas actif, donc un read d'opacité ment ; la profondeur animée se vérifie par capture visuelle, pas en lisant des valeurs. Le livrable, c'est le système écrit : tokens, règles et échantillons que n'importe qui peut appliquer sans le réinventer.

LA LEÇON

Couleur et profondeur donnent de la vie seulement à l'intérieur d'un système. Glass, bandes et champs sans règles dégénèrent en bruit qui contredit le minimalisme.

Le système s'écrit en tokens et en règles : quand utiliser glass, quelle intensité, quelle profondeur de champ, ce qui bouge et ce qui reste immobile. Réutilisable, pas improvisé écran par écran.

Ne jamais interpoler de classes de couleur dynamiques (bg-${theme}) : ça casse le JIT de Tailwind. Les thèmes se déclarent comme des entrées explicites dans la map de THEME.

Les animations de fond se mettent en pause sur un onglet inactif : un read d'opacité renvoie une valeur fausse. La profondeur animée se vérifie par capture d'écran, pas en lisant le DOM.

Le critère, c'est « de la vie sans bruit » : si un champ de couleur ou un glass n'apporte ni hiérarchie ni respiration, il est de trop. La profondeur sert la lecture, elle ne s'exhibe pas.

EXERCICE

Inventorie les ressources de profondeur que la surface utilise déjà (glass, bandes, blobs, champs de fond). Pour chacune, écris la règle : quand on l'utilise, à quelle intensité, quelle hiérarchie elle sert, si elle s'anime ou non. Transforme-les en tokens nommés. Rends un échantillon avec le système appliqué et un autre sans, côte à côte, pour prouver que la version avec système donne de la vie sans monter le bruit. Vérifie toute couche animée par capture d'écran sur onglet actif, pas en lisant l'opacité (qui ment quand l'onglet est en arrière-plan). Confirme qu'aucune couleur n'est interpolée dans une classe dynamique.

LIVRABLE

Un système documenté de couleur et de profondeur : tokens nommés + règles d'usage (quand / quelle intensité / ce qui s'anime) + une paire d'échantillons avec-système / sans-système qui prouve « de la vie sans bruit », vérifiés par capture visuelle. Réutilisable par n'importe quel écran sans réinventer le critère.

CLÉ ESSENTIELLE

La profondeur bien faite se ressent comme de l'air et mal faite comme du bruit, et la seule façon de rester du bon côté à l'échelle, c'est un système écrit, pas du bon goût écran par écran. Et ne te fie jamais à un read d'opacité : l'onglet endormi te mentira.

ERREURS À ÉVITER

  • ×Improviser glass, bandes et champs écran par écran sans règles : l'ensemble perd sa cohérence et le minimalisme se casse.
  • ×Interpoler des classes de couleur dynamiques (bg-${theme}) et casser le JIT de Tailwind, en laissant des styles qui ne compilent pas.
  • ×Vérifier la profondeur animée en lisant l'opacité dans le DOM : l'animation se met en pause sur un onglet inactif et la valeur lue ment. Il faut faire une capture d'écran.
  • ×Mettre des champs de couleur ou du glass qui n'apportent ni hiérarchie ni respiration : de la décoration qui monte le bruit et trahit « de la vie sans bruit ».

Constellation suivante

Ops & Security

La discipline