Sur l’écran, la même annonce doit inspirer confiance qu’elle soit consultée au bureau, dans un train ou depuis un canapé. Une photo pleine largeur, un calendrier, un prix, un bouton de réservation : chacun de ces éléments paraît banal. Pourtant, lorsqu’une plateforme compte des milliers d’écrans, plusieurs équipes et des usages très différents, ce banal devient un problème d’organisation. C’est dans cette zone, entre l’interface et la stratégie, qu’Airbnb a mené son projet Blanche-Neige, connu en interne sous le nom de Snow White.

L’expression pourrait faire croire à une opération cosmétique, à une nouvelle couche de peinture sur une marque déjà installée. Elle désigne plutôt une ambition plus profonde : reconstruire une expérience cohérente sur l’ensemble des produits Airbnb. Le cas mérite encore l’attention, non parce qu’il faudrait imiter l’esthétique de la plateforme, mais parce qu’il éclaire une question durable : comment une entreprise qui grandit évite-t-elle que son produit ne se transforme en assemblage de décisions locales ?

Quand l’interface commence à parler plusieurs langues

À ses débuts, une entreprise numérique peut avancer avec une certaine désinvolture. Une équipe ajoute une fonctionnalité, une autre modifie un parcours, une troisième corrige une page mobile. Le produit évolue vite. Mais cette vitesse laisse souvent une trace : des boutons qui ne se ressemblent pas, des comportements différents selon les appareils, des formulations incohérentes et, surtout, une expérience dont personne ne tient plus vraiment la carte complète.

Le projet Blanche-Neige est né de ce type de tension. Airbnb devait faire cohabiter la recherche de logements, la publication d’annonces, la messagerie, le paiement, les évaluations et l’accompagnement des hôtes. Ces actions ne relèvent pas du même état d’esprit. Chercher un lieu où dormir suppose de se projeter ; réserver demande de lever des doutes ; devenir hôte exige de comprendre des règles et de fournir des informations. Une interface unifiée ne signifie donc pas une interface uniforme.

La difficulté centrale n’était pas seulement graphique. Elle consistait à établir un langage de conception commun : une grammaire visuelle et comportementale permettant aux équipes de construire des écrans différents sans repartir de zéro. Couleurs, typographies, espacements, icônes, cartes, formulaires, états d’erreur, règles de navigation : tout ce qui semble secondaire devient décisif dès lors que le produit se déploie à grande échelle.

Le projet a aussi accompagné l’affirmation d’une identité de marque plus reconnaissable, notamment à travers le symbole Bélo. Mais réduire Blanche-Neige à un logo serait manquer son intérêt. Un signe peut être mémorable tout en restant isolé. Le véritable enjeu était de faire en sorte que l’utilisateur reconnaisse Airbnb dans le rythme d’un parcours, la clarté d’une information et la continuité entre les écrans.

Un système n’est pas une bibliothèque de jolies pièces

Le mot design system est aujourd’hui partout. Il évoque volontiers une bibliothèque de composants : boutons, champs, menus, alertes. C’est utile, mais incomplet. Une bibliothèque répond à la question « que peut-on réutiliser ? ». Un système répond aussi à une autre question : « selon quels principes doit-on décider ? »

Dans le cas d’Airbnb, le projet Blanche-Neige a contribué à poser des fondations partagées pour les produits web et mobiles. L’objectif n’était pas de contraindre chaque écran à une répétition mécanique, mais d’éviter que chaque équipe ne réinvente sa propre logique. Sans ces fondations, une plateforme finit par accumuler une dette visuelle et fonctionnelle comparable à la dette technique : chaque petite exception semble acceptable ; leur somme rend toute évolution plus lente et plus risquée.

Un bon système donne paradoxalement davantage de liberté. Il libère les équipes des questions résolues — la forme d’un champ, le comportement d’une fenêtre, la hiérarchie d’un bouton — pour les ramener vers les questions réellement difficiles : quelle information rassure un voyageur ? À quel moment demander une donnée personnelle ? Comment aider un hôte sans le noyer sous les options ?

La cohérence n’est pas l’art de tout rendre identique ; c’est l’art de rendre chaque différence intelligible.

Cette nuance est essentielle. Beaucoup d’organisations lancent un design system dans l’espoir d’obtenir une homogénéité immédiate. Elles produisent alors un catalogue rigide, bientôt contourné par les équipes. Un système vivant accepte les cas particuliers, mais leur impose un coût de discussion. L’exception n’est pas interdite ; elle doit être justifiée, documentée et, si elle se répète, intégrée au langage commun.

La grande bascule : traiter le produit comme une expérience continue

Le projet Blanche-Neige est intéressant parce qu’il déplace le regard. Au lieu de considérer le site, l’application mobile et les outils internes comme des territoires séparés, il invite à penser une expérience multiplateforme. L’utilisateur, lui, ne se soucie guère de l’organigramme. Il peut découvrir un logement sur son téléphone, comparer des options sur un ordinateur, recevoir des messages sur une tablette et finaliser une action plus tard. Il n’interagit pas avec des canaux : il poursuit une intention.

Cette idée paraît évidente, mais elle bouscule les habitudes de production. Les équipes sont souvent découpées par appareil, par fonctionnalité ou par étape du tunnel. Chacune optimise sa portion. Une amélioration locale peut alors détériorer le voyage global : un écran très efficace pour collecter une information peut sembler abrupt après une phase de découverte plus inspirante ; une notification peut relancer l’attention tout en créant une impression de pression.

Airbnb a toujours eu une particularité : son produit organise une rencontre entre des personnes qui ne se connaissent pas. Cette situation rend la confiance concrète. Elle ne dépend pas seulement d’un discours de marque ou d’une promesse de sécurité. Elle se construit dans la lisibilité des règles, la qualité des photos, la façon de présenter les avis, l’explication des conditions et la stabilité des interactions. Une interface confuse ne produit pas seulement de la friction : elle peut produire du doute.

La leçon dépasse largement le voyage. Toute plateforme qui met en relation, accompagne une décision coûteuse ou demande un engagement personnel devrait considérer le design comme une infrastructure de confiance. Dans ces contextes, le détail n’est jamais tout à fait décoratif.

Ce que la métaphore du conte révèle — et masque

Le nom Blanche-Neige a quelque chose de révélateur. Il évoque une page blanche, une refonte radicale, peut-être aussi l’idée d’un monde cohérent. Les grands projets de design aiment les noms simples : ils permettent de rassembler des métiers différents autour d’un récit. Un développeur, une chercheuse utilisateur, un responsable produit et un designer ne partagent pas toujours le même vocabulaire ; ils peuvent néanmoins se retrouver dans une ambition lisible.

Mais la métaphore a son danger. Elle peut faire croire qu’une grande refonte est un acte héroïque, une nuit de bascule après laquelle le désordre disparaît. Dans la réalité, un système de conception n’est jamais achevé. Les produits changent, les réglementations évoluent, les usages se déplacent, de nouveaux formats apparaissent. Ce qui a été harmonisé doit être entretenu, corrigé et parfois abandonné.

Les récits rétrospectifs autour des transformations célèbres tendent à simplifier ce travail. Ils mettent en scène une vision claire, une équipe inspirée, un résultat immédiatement visible. Or le cœur du chantier est souvent moins spectaculaire : aligner les nomenclatures, documenter les composants, arbitrer les contradictions, faire migrer progressivement les anciens écrans, écouter les retours des équipes. Cette discipline de maintenance est la part la moins glamour et la plus précieuse de l’innovation organisationnelle.

Trois questions à emprunter au projet Blanche-Neige

Pour une équipe produit, l’intérêt du cas Airbnb n’est pas de reproduire une refonte totale. Il est d’adopter quelques questions exigeantes avant que la dispersion ne devienne coûteuse.

• Quelles décisions sont prises trop souvent ? Si chaque équipe rediscute de la hiérarchie d’un formulaire, du vocabulaire d’une action ou de l’apparence d’une notification, ces choix devraient probablement devenir des règles partagées.
• Où l’utilisateur ressent-il nos frontières internes ? Un changement de ton, une navigation rompue ou une information répétée signalent fréquemment un problème d’organisation avant d’être un problème d’interface.
• Quel principe protège la confiance quand le parcours se complique ? Dans un service financier, éducatif, médical ou collaboratif, la simplicité ne consiste pas à cacher la complexité. Elle consiste à l’expliquer au bon moment, avec des conséquences compréhensibles.

Ces questions conduisent à une pratique souvent négligée : cartographier les parcours avant de dessiner les écrans. Il ne s’agit pas de produire un schéma figé, mais d’observer les moments de bascule : découverte, hésitation, engagement, erreur, attente, retour. C’est là que se décide la qualité perçue d’un produit.

Refondre sans effacer ce qui fonctionne

La tentation de la page blanche est forte lorsque le produit paraît incohérent. Pourtant, la refonte intégrale peut devenir un refuge : elle promet de régler demain ce que l’on ne parvient pas à arbitrer aujourd’hui. Le projet Blanche-Neige rappelle plutôt qu’une transformation réussie combine vision globale et déploiement patient.

Il faut distinguer ce qui relève du socle — les composants, les principes d’accessibilité, les règles de contenu, les comportements récurrents — de ce qui relève de l’expérimentation. Le socle doit être fiable, documenté et partagé. L’expérimentation doit rester possible, car un produit qui ne teste plus ses hypothèses finit par confondre cohérence et immobilité.

La meilleure postérité de Blanche-Neige tient peut-être dans cette idée : le design n’est pas la finition d’un produit. C’est une manière de rendre une organisation lisible, pour ses utilisateurs comme pour ses propres équipes. Quand chaque nouvelle fonctionnalité s’inscrit dans un langage commun, l’entreprise ne gagne pas seulement en élégance. Elle gagne en capacité à changer sans se perdre.