Aller au contenu principal

Guide

Personnaliser le design de son application générée

« Générée » n'est pas synonyme de « figée ». Ce guide détaille ce qui se personnalise réellement dans une application Blueprint Maker — au-delà de la couleur d'accent — et pourquoi une partie du design reste volontairement hors de portée.

Le point de départ : un designer, pas une page blanche

Une application générée démarre sur l'un d'une centaine de profils de designers curatés — chacun une référence de design réelle citée comme telle, pas un thème générique. Choisir un profil au moment de la génération, c'est choisir une intention (dense et fonctionnelle, aérée et éditoriale, sombre et contrastée…) plutôt que de partir d'un formulaire de branding vide qu'il faut remplir champ par champ.

Ce choix reste modifiable après coup : dupliquer un profil curaté comme point de départ, puis l'ajuster, est le chemin normal — pas une exception.

Votre charte : couleurs, police, densité — et au-delà

Le premier niveau de réglage est celui qu'on attend : une palette de huit couleurs (accent, matières structurelles, encres, fonds), une police, un rayon de coin, une densité d'espacement. Ces jetons pilotent l'ensemble de l'interface générée, pas une page isolée.

Un second niveau, moins visible mais réel, va plus loin : l'échelle et la graisse de la typographie, la casse des titres, le traitement des surfaces (élévation, bordure, contraste), la composition des blocs structurants (carte, barre latérale, en-tête), le mouvement des transitions, la largeur de mise en page, une palette sombre dédiée, et des traitements de titre volontairement expressifs (bloc de couleur, ombre portée colorée, italique). Chaque réglage de ce second niveau est optionnel : ne rien renseigner revient exactement au comportement du profil de designer choisi, rien ne se dégrade par défaut.

La navigation se règle après coup, sans tout regénérer

Les libellés de la barre latérale, leur ordre, et les titres de page ne sont pas figés à la génération : ils se personnalisent depuis les réglages de l'application, une fois déployée, sans relancer une génération complète. C'est un réglage global à l'application, persisté, pas une préférence par utilisateur.

C'est une différence pratique avec « régénérer pour renommer un menu » : l'ajustement porte sur ce qui a réellement besoin de changer, au lieu de rouvrir tout le plan de l'application.

Ce qui ne se règle pas à la main, et pourquoi

Les propriétés des composants d'interface et la mise en page déterministe (quelle donnée va dans quel type d'écran, comment un tableau ou un tableau de bord s'assemble) ne sont pas des réglages exposés : ils sont posés par le générateur, pas par vous. Ce n'est pas une limite provisoire, c'est la même doctrine que le reste du produit : la conformité technique est garantie par construction, jamais laissée à un réglage qui pourrait produire un écran cassé.

Une garde existe aussi pour la couleur elle-même : une seule couleur d'accent est autorisée par application. Une deuxième couleur franche employée en aplat décoratif est détectée et corrigée automatiquement. Ce n'est pas une contrainte arbitraire — une charte à deux accents concurrents est le défaut visuel le plus fréquent d'une personnalisation improvisée, et l'application le évite par construction plutôt que de compter sur la vigilance de chacun.

Comment procéder, concrètement

Au moment de générer : choisissez un profil de designer proche de l'intention recherchée, ou laissez le profil par défaut si l'identité visuelle n'est pas encore une priorité — elle se règle après coup sans coût.

Une fois l'application déployée : ajustez la charte (couleurs, police, densité) pour l'identité de premier niveau, puis, si nécessaire, les réglages de structure pour les détails qui font la différence — sans jamais toucher au code des écrans eux-mêmes, qui reste celui que le générateur a validé.

À lire ensuite

Générez une application, choisissez un profil de designer, ajustez ensuite