Accueil
Une par groupe d’utilisateurs. Actions principales et éléments nécessitant une attention.
Utilitaires
Connexion, inscription, réinitialisation du mot de passe, 404. Nécessaires, mais hors design.
Entité
Une par objet dans votre base de données. Liste les enregistrements, en crée de nouveaux.
Détail
Un enregistrement complet, ses actions et les enregistrements qui lui sont liés.
## 1. La page d’accueil, et d’abord la question du groupe d’utilisateurs
Avant de concevoir une page d’accueil, listez les groupes qui se connectent. Clients et personnel interne. Enseignants, parents et élèves. Employés et équipe financière. Cette décision prime sur tout le reste, car elle détermine si vous créez une seule page d’accueil ou plusieurs.
Ma règle empirique : si plus de la moitié des blocs de la page diffèrent entre deux groupes, donnez à chaque groupe sa propre page d’accueil. En dessous, utilisez une seule page avec des conditions de visibilité sur quelques blocs.
**Une page d'accueil partagée** (Les groupes se chevauchent largement)
- Quelques blocs affichés selon une condition
- Une seule page à modifier lors d'un changement de marque
- Devient vite illisible après quelques conditions
**Une page d'accueil par groupe** (Les groupes ont des besoins différents)
- Chaque page semble conçue spécifiquement pour eux
- Aucune logique conditionnelle à suivre
- Les changements communs doivent être faits deux fois
_La limite des 50 % est une habitude, pas une mesure exacte. C’est approximativement le point où une page conditionnelle devient illisible pour la personne qui devra la maintenir après moi._
Ce qu’on y trouve : les deux à quatre actions les plus fréquentes pour ce groupe, et l’élément sur lequel ils doivent agir maintenant. Pas plus. L’application a un périmètre étroit, la page d’accueil doit l’être aussi.
Un gestionnaire de notes de frais illustre bien le concept. Un employé se connecte pour soumettre une demande, le formulaire est donc accessible en un clic, et en dessous, ses demandes encore en attente. L’équipe financière se connecte pour approuver, elle voit donc les demandes qui attendent sa validation. Pas toutes les demandes jamais déposées, ni celles refusées en mars. Uniquement la liste sur laquelle elle doit agir.
Tout le reste peut figurer dans la barre de navigation, et devrait généralement y être.
## 2. Les pages utilitaires, sur lesquelles vous ne devriez pas perdre de temps
Connexion. Inscription, ou inscription désactivée s’il s’agit d’un outil interne avec invitations. Mot de passe oublié et réinitialisation. La page 404. Un flux d’intégration si vous voulez forcer l’utilisateur à compléter son profil avant d’accéder à l’application.
Tout cela est ennuyeux. Tout cela est indispensable. Mais c’est là que votre application ne tire pas sa valeur.
C’est la famille de pages que je préfère ne pas construire, et avec Softr, je ne le fais pas : elles sont livrées configurées, le travail consiste alors à soigner le style et le texte. Si vous construisez tout de zéro, prévoyez-les quand même, car elles existent dans chaque application. Oublier la 404, c’est condamner l’utilisateur à une impasse sans issue.
## 3. Les pages d’entité, une par objet
Une fois que votre base de données est bien structurée, elles s’écrivent presque toutes seules. Une page par table ayant une signification pour l’utilisateur. Un CRM comprend des contacts, des entreprises, des opportunités, des tâches. Connectez-vous à HubSpot et c’est exactement ce que vous trouverez dans la navigation.
La page liste les enregistrements, et le format est une décision à prendre par objet :
- **Un tableau** quand l’objectif est de trouver une ligne parmi beaucoup d’autres, et que la densité est un atout.
- **Un tableau kanban** pour tout ce qui possède un statut évolutif, comme des tâches ou des opportunités.
- **Un calendrier** quand la date est l’élément principal de navigation.
- **Une grille de cartes** quand un logo ou une photo permet de reconnaître un enregistrement.
Vous pouvez en proposer deux, sous forme d’onglets sur la même page, car chaque utilisateur travaille différemment. Dans mon CRM, la page des opportunités affiche le pipeline par défaut, avec une vue tableau juste à côté.
C’est aussi ici que se placent les actions. Ajouter un enregistrement. Exporter la liste en CSV, ce qui ne coûte rien et que quelqu’un demande toujours. Importer un CSV, si les données arrivent par lots.
**Toutes les tables ne méritent pas une page**
Dans ce CRM, il y a une table d’interactions, mais aucune page d’interactions. Une interaction n’a de sens que si elle est rattachée à un contact, elle vit donc sur la page de détails du contact et nulle part ailleurs. Une page par table est un point de départ, pas une règle. Demandez-vous si quelqu’un aurait besoin d’ouvrir une liste complète de ces éléments.
Parfois, la page d’entité constitue la fonctionnalité entière. Une table de documents avec un nom et un fichier, sans lien avec autre chose, peut simplement être une liste avec des options d’édition et de suppression sur chaque ligne. Aucune page de détails n’est alors nécessaire.
## 4. Les pages de détails, et ce qui se trouve en dessous
En général, on souhaite ouvrir un enregistrement. Une ligne de tableau n’offre pas assez d’espace de travail, et une entreprise possède une description, un site web et des notes qui doivent figurer quelque part.
Une page de détails se compose de trois parties.
L’enregistrement lui-même, avec les champs pertinents, soit plus d’informations que sur la page d’entité. Les actions associées : modifier, supprimer, changer le statut, assigner à quelqu’un. Les permissions s’appliquent individuellement : supprimer un contact peut être réservé à l’administrateur, alors que tout le monde peut le modifier.
Ensuite, la partie que j’ajoute systématiquement et qui donne l’impression qu’une application est terminée : les enregistrements liés, listés en dessous. Ouvrez une entreprise et vous verrez ses contacts, ses opportunités, ses interactions passées. Ouvrez une tâche et vous verrez le projet auquel elle appartient.
**Navigation d’une page d’entité vers la page de détail d’un enregistrement, puis vers la page de détail d’un enregistrement lié, chacune s’ouvrant dans un panneau latéral sur la liste.**
Contacts
Page d’entité, liste complète
Un contact, dans un panneau latéral
Champs, puis édition et suppression, puis l’entreprise liée et les interactions passées
Cette entreprise, dans un panneau latéral
Ses propres champs, ses contacts, ses opportunités
Ouvrez ces éléments dans une fenêtre modale plutôt que sur une page complète, centrée ou glissant depuis le côté. L’URL ne change pas, la liste reste en arrière-plan, et le retour se fait en fermant un panneau plutôt qu’en rechargeant une page. Sur une liste de travail, c’est cette différence qui crée la sensation de rapidité de l’application.
## Les deux pages supplémentaires à prévoir
**Un tableau de bord.** Graphiques et compteurs. Parfois, c’est la page d’accueil, parfois c’est une page distincte lorsque le contenu est suffisant.
**Un formulaire sur sa propre page.** C’est un argument de maintenance. Si quatre endroits différents permettent de créer une entreprise et que chacun a son propre formulaire de création, ajouter un champ signifie modifier quatre formulaires, au risque d’en oublier un. Créez le formulaire une seule fois sur sa propre page, et faites en sorte que chaque bouton ouvre cette page dans une fenêtre modale. Un seul formulaire à maintenir.
## Structurer un ERP de la même manière
Les quatre familles fonctionnent aussi pour les applications plus volumineuses, elles sont simplement regroupées. Pour un ERP, j’ai organisé la navigation par département plutôt que par objet : inventaire, ventes, finance. Derrière chacun d’eux, on retrouve les mêmes pages d’entités.
Deux choses que j’ai faites différemment et que je referais. Certaines pages consolident deux objets : la section ventes regroupe commandes et clients, car les équipes commerciales travaillent sur les deux. Et la page d’accueil ne liste pas tous les produits, mais seulement ceux dont le stock est inférieur à 100 unités, sous un titre indiquant qu’ils nécessitent une attention. Sur une page d’accueil, une liste filtrée selon les actions requises est préférable à une liste complète.
## Une base de données saine, et les pages suivent
1. **Définir le périmètre**. Ce que l’app permet de faire
2. **Lister les groupes d’utilisateurs**. Qui se connecte et quels sont leurs besoins
3. **Concevoir les tables**. Une par objet réel, avec les bons champs
4. **Déduire les pages**. Une page d’entité par objet, avec le détail derrière
_L’étape trois est la plus chronophage. La création des pages devient presque mécanique une fois que les objets sont corrects, c’est pourquoi une mauvaise structure de table se traduit par une application confuse._
Une table par objet réel, avec les champs qui lui appartiennent. Une tâche a une description, une date d’échéance, un responsable. Une entreprise a un nom, un site web, un secteur d’activité. Si vous vous trompez là-dessus, aucune mise en page ne pourra vous sauver.
L’IA est véritablement efficace pour cette partie. Décrivez le CRM que vous souhaitez et vous obtiendrez une première base de données cohérente, c’est ainsi que je démarre la plupart de mes projets désormais.
## Maîtriser le cadre pour mieux s’en affranchir
Le générateur d’IA de Softr produit des applications exactement selon ce modèle. Il en va de même pour les autres. Ce qui soulève une question légitime : si l’outil connaît déjà le schéma, pourquoi l’apprendre ?
Parce que la version générée est une valeur par défaut, et les valeurs par défaut sont la moyenne des applications de tout le monde, pas la vôtre. Ce qui rend une application excellente, ce sont les écarts : décider de ne pas créer la page d’interactions, ouvrir les détails dans un panneau latéral plutôt que sur une nouvelle route, filtrer la liste de la page d’accueil pour n’afficher que ce qui demande une action. Un générateur d’IA ne proposera pas cela, car rien dans votre prompt ne lui a indiqué que vos utilisateurs passent leur journée à traiter une liste.
Je constate la même chose avec les agents en général, que ce soit dans Claude Code ou dans un générateur d’app. Ils produisent rapidement la forme standard. Votre valeur ajoutée consiste à savoir quelle partie de cette forme standard ne convient pas à votre cas. Cela ne s’acquiert qu’en ayant construit l’objet à la main suffisamment souvent pour s’être forgé une opinion.
Utilisez donc le générateur. Puis ouvrez le résultat et modifiez les trois choses que vous auriez faites différemment.