Toutes les applications métier que j'ai créées nécessitaient les quatre mêmes pages
1
Homepage
One per user group. Their top actions, and what needs them now.
2
Utility
Login, reset password, 404. Required, and not where the app gets good.
3
Entity
One per object. The list, the view that suits it, and adding a record.
4
Detail
One record in full, its actions, and everything related to it.
Four years of internal tools and portals, and about 90% of the pages were one of these.
J’ai conçu des dizaines d’applications métier ces quatre dernières années. Outils internes, CRM, ERP, intranets, portails clients, portails fournisseurs, data rooms. Des entreprises différentes, des données différentes, mais globalement le même ensemble de pages à chaque fois.
Quatre familles. Elles couvrent environ 90 % des besoins d’une application métier. Les connaître transforme la question la plus difficile au début d’un projet, « de quelles pages ai-je réellement besoin ? », en une simple liste de vérification.
Je parle d’applications avec connexion utilisateur. Les annuaires publics et les sites marketing fonctionnent différemment. Une application métier a un périmètre étroit et défini : un portail client existe pour que les clients voient leurs projets et tâches, et pour que votre équipe puisse tous les visualiser. C’est cette précision qui rend un petit nombre de pages suffisant.
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éeLes 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 groupeLes 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
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.
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.
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
- 1Définir le périmètreCe que l’app permet de faire
- 2Lister les groupes d’utilisateursQui se connecte et quels sont leurs besoins
- 3Concevoir les tablesUne par objet réel, avec les bons champs
- 4Déduire les pagesUne page d’entité par objet, avec le détail derrière
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.