Construisez une interface pour vos utilisateurs
Votre base CRM sait maintenant modéliser, calculer et signaler. Mais tout ce travail reste enfoui dans des tables et des vues pensées pour la saisie, pas pour la décision. Dans ce dernier chapitre, vous allez construire une interface : une vue métier qui présente vos données à ceux qui les pilotent, sans les noyer sous les champs techniques. À la fin, votre base CRM fil rouge sera complète, avec un pipeline visuel et un tableau de bord prêts à l’emploi.
Comprenez l’utilité d’une interface
Regardez la vidéo suivante pour découvrir l’utilité d’une interface. Une version écrite est également disponible ci-dessous pour vous servir de référence.
Jusqu’ici, vous avez travaillé directement dans la base : des tables, des champs, des vues. C’est l’espace de la saisie et de la structure, celui où vous configurez cumuls, recherches et formules. Le problème, c’est qu’une personne qui doit simplement piloter un portefeuille de prospects n’a pas besoin de voir tous ces champs techniques. Elle a besoin de l’essentiel, présenté clairement.
C’est le rôle d’une interface : une vue métier qui sépare la saisie brute de la présentation. La donnée reste dans la base, mais l’interface choisit ce qu’elle montre, à qui, et sous quelle forme. On consulte et on décide dans l’interface ; on ne modifie pas la structure de la base à travers elle.
Airtable propose un outil dédié pour cela, l’Interface Designer. Il met à disposition quelques briques de construction que vous assemblez dans des pages :
la Liste affiche plusieurs enregistrements sous forme de tableau ou de colonnes, avec les seuls champs utiles ;
le Kanban organise les enregistrements en colonnes selon un champ de type sélection unique, comme Statut, pour visualiser une progression d’un coup d’œil ;
le Détail affiche un enregistrement unique et ses informations complètes ;
le Tableau de bord regroupe des indicateurs de synthèse, comme un décompte ou un total ;
les Filtres restreignent ce qui s’affiche selon une règle métier, sans toucher aux données.
Le point clé n’est pas technique, il est méthodologique : on conçoit une interface par profil utilisateur, pas par table. Un Chef de Projet veut un pipeline visuel, des statuts et un chiffre d’affaires consolidé. Un Commercial veut d’abord ses prospects assignés et leurs contacts. La même base peut donc alimenter deux interfaces très différentes, chacune ajustée à un besoin.
Regardez la vidéo ci-dessous pour voir ces idées en situation. Fixez-vous trois objectifs d’observation : distinguer nettement la base (la saisie) de l’interface (la consultation et la décision), associer chaque brique — Liste, Kanban, Détail, Tableau de bord, Filtres — à un usage concret, et saisir pourquoi on conçoit une interface par profil utilisateur plutôt que par table. À la fin, vous devriez pouvoir choisir quelle brique répond à un besoin métier donné.
Créez une interface de pilotage pas à pas
Vous allez maintenant suivre une démonstration commentée dans l’Interface Designer. La vidéo décrit chaque action à l’écran et chaque décision de conception. Une version écrite est également disponible ci-dessous pour vous servir de référence.
L’objectif est une interface de pilotage lisible pour un Chef de Projet, construite en quatre étapes.
Étape 1 : créez une page Liste
Dans l’Interface Designer, créez une page Liste appuyée sur la table Prospects. N’affichez que les champs utiles au pilotage : Nom, Statut, CA (le cumul Total CA construit en chapitre 2) et Dernier contact. Triez la liste par Statut pour regrouper les prospects par étape. Décision de conception : vous excluez volontairement les champs techniques (identifiants, champs de calcul intermédiaires) parce qu’ils n’aident pas à décider.
Vous pouvez aussi créer une page Kanban sur la même table : au lieu de trier par Statut, vous regroupez les cartes par Statut, et chaque carte n’affiche que Nom, CA et Dernier contact. La Liste et le Kanban partent des mêmes données ; ils ne diffèrent que par la présentation. Vous choisirez l’un ou l’autre pour la page Pipeline de l’activité.
Étape 2 : construisez le Tableau de board
Ajoutez une page Tableau de bord avec trois widgets de synthèse :
un widget Quantité Prospects qui compte les enregistrements de la table Prospects ;
un widget Sum CA qui totalise le cumul Total CA hérité de chapitre 2 ;
un widget Répartition statuts qui visualise la distribution du champ brut Statut (Nouveau, En discussion, Perdu…).
Décision de conception : ce tableau de bord ne crée aucune donnée nouvelle. Il rend visuel et actionnable le cumul Total CA de chapitre 2. Pour la répartition, vous regroupez sur le champ brut Statut, plus riche que le champ formule Statut prospect dynamique de chapitre 3, qui ne prend que deux valeurs (« Urgent » ou « À jour »). La formule de chapitre 3, elle, redevient visible et actionnable dans l’interface à l’étape suivante, à travers le filtre de priorité.
Étape 3 : ajoutez un filtre de priorité
Ajoutez un filtre pour ne conserver que les prospects à traiter en priorité : Statut prospect dynamique = « Urgent » ou Statut = « Nouveau ». Le filtre combine ici deux champs différents qui désignent deux groupes distincts : la valeur « Urgent » est produite par la formule de chapitre 3 (un prospect « En discussion » sans contact depuis plus de dix jours), tandis que « Nouveau » est une valeur brute du champ Statut (un prospect encore à qualifier). Comme « Urgent » n’inclut jamais les prospects « Nouveau », le « OU » élargit réellement la sélection à deux besoins de suivi complémentaires. Le filtre masque les autres enregistrements dans l’interface, sans jamais les supprimer de la base.
Étape 4 : configurez la vue pour le Chef de Projet
Enfin, ajustez la vue pour le profil Chef de Projet : ordre des pages, champs visibles, intitulés clairs. Vérifiez la cohérence d’ensemble, le Tableau de board doit refléter les mêmes prospects que ceux visibles après filtrage, et les totaux doivent correspondre aux cumuls de votre base.
Analysez une interface de pilotage existante
Savoir cliquer les briques ne suffit pas : l’essentiel est de savoir pourquoi on assemble telle brique pour tel profil. Décortiquons une interface CRM professionnelle complète, organisée en trois pages, en lisant chaque page selon la même grille : quel besoin utilisateur, quelles briques et pourquoi, quel filtre et pourquoi.
Page 1 : Pipeline Prospects
Besoin utilisateur : le Chef de Projet veut visualiser l’avancement de ses prospects et repérer d’un coup d’œil ceux qui stagnent. Briques : une page en Kanban regroupée par Statut, où chaque prospect est une carte qui affiche Nom, CA et Dernier contact. Filtre : on masque les prospects perdus ou archivés pour ne garder que le pipeline actif.
Arbitrage clé : pourquoi un Kanban plutôt qu’une liste ? Parce que le besoin est de suivre une progression par étapes. Un Kanban montre visuellement le passage d’un statut à l’autre, là où une liste triée demande un effort de lecture pour reconstituer la même information. Autre arbitrage : on n’affiche sur la carte que trois champs, car une carte surchargée redevient aussi illisible que la base brute.
Page 2 : Clients actifs
Besoin utilisateur : suivre les clients déjà convertis, distincts des prospects. Briques : une Liste avec les champs de suivi client et un petit Tableau de bord de synthèse (nombre de clients actifs, CA consolidé). Filtre : ne conserver que les enregistrements dont le statut correspond à un client actif.
Arbitrage clé : pourquoi une liste ici et un Kanban page précédente ? Parce que le besoin n’est plus de suivre une progression par étapes mais de consulter un portefeuille stable. La brique suit le besoin, pas l’habitude.
Page 3 : Contacts
Besoin utilisateur : retrouver rapidement la bonne personne chez un prospect ou un client. Briques : une Liste des contacts avec nom, rôle et coordonnées, éventuellement doublée d’une vue Détail pour afficher la fiche complète d’un contact. Filtre : aucun filtre restrictif, car on veut pouvoir chercher n’importe quel contact.
Arbitrage clé : pourquoi exclure certains champs ? Les champs internes (notes privées, champs de calcul) n’ont pas leur place dans une page de consultation partagée. On expose ce qui sert à contacter, on garde le reste dans la base.
À vous de jouer !
Inès,Chef de Projet de l’équipe fictive, veut consulter le pipeline des prospects retenus par la règle du chapitre, puis leur nombre, leur CA associé et leur répartition entreUrgentetÀ jour. Reprenez les configurations étudiées pour lui préparer deux pages cohérentes, Pipeline et Dashboard.
Étape 1 : Repartez de vos données vérifiées
Utilisez CRM d’entraînement, construit en C2 et enrichi en C3. Vérifiez les quatre totaux 2000, 600, 400 et 1000, le lien S02 vers Aster et l’e-mail initial de Lina. Si vous reprenez un autre jour, utilisez temporairement Jour de contrôle comme en C3 pour recaler les quatre dates sur J. Seul Aster doit êtreUrgentau départ. Supprimez ce champ temporaire après contrôle.
Travaillez dans l’Interface Designer avec les droits de création nécessaires sur votre base. Les essais se font dans l’aperçu interne du brouillon : aucune publication, invitation, capture ou lien à remettre. La table Commandes reste un espace d’essai séparé et n’alimente pas l’interface.
Étape 2 : Configurez les deux pages
Créez une page Pipeline avec Prospects comme source et un rendu Kanban, regroupé par le champ de sélection unique Statut, pas par le champ formule. Affichez Nom, Total CA et Dernier contact sur les cartes. Si vous utilisez l’intitulé d’affichage « CA », il doit toujours désigner Total CA, pas un nouveau champ source.
Dans les paramètres de données de Pipeline, appliquez cette règle : Statut prospect dynamique = Urgent OU Statut = En discussion.
Ajoutez une page Dashboard avec un seul groupe de données, de source Prospects. Configurez séparément sur ce groupe la même règle : Statut prospect dynamique = Urgent OU Statut = En discussion. Ne supposez pas que le filtre de Pipeline s’y répercute automatiquement.
Ajoutez les trois éléments ci-dessous dans ce groupe, sans filtre individuel supplémentaire ni filtre utilisateur déroulant.
Élément | Configuration |
|---|---|
Quantité Prospects | Number, mode Quantité : nombre d’enregistrements de Prospects retenus par le groupe |
Sum CA | Number, mode Summary : champ Total CA, agrégation Sum |
Répartition statuts | Chart en barres : catégories Statut prospect dynamique, mesure nombre d’enregistrements |
Le décompte porte sur les prospects, pas sur Nb de contacts. Gardez les libellés des statuts et les valeurs lisibles, sans dépendre uniquement des couleurs. Placez Pipeline avant Dashboard et laissez les champs techniques hors des cartes.
Étape 3 : Testez les données et leur présentation
Dans l’aperçu, comparez les cartes aux trois éléments du Dashboard. Après une modification dans la base, rouvrez ou actualisez l’aperçu.
Identifiez les prospects retenus par le filtre et calculez leur CA total avant de consulter le corrigé. Vérifiez la catégorie de chaque carte et la répartition des statuts calculés.
Dans Services, passez temporairement Montant de S03 de 600 à 700. Suivez le changement dans Total CA de Boreal, sa carte et Sum CA. Le décompte et la répartition doivent-ils changer ? Restaurez 600 avant le test suivant.
Passez temporairement Dernier contact d’Aster à J-10. Comparez la répartition, le nombre de prospects et la somme. Aster doit-il disparaître du Pipeline ? Restaurez J-12, puis vérifiez de nouveau les deux pages.
Retournez dans Prospects : Corail et Delta doivent toujours exister dans la base, même s’ils ne sont pas affichés dans l’interface.
Étape 4 : Corrigez votre travail
Prenez quelques minutes pour essayer de vérifier votre travail vous-même avant de consulter le corrigé.
En résumé
Une interface sépare la saisie, qui reste dans la base, de la consultation, qui se fait dans une vue métier dédiée.
On conçoit une interface par profil utilisateur, en partant du besoin, et non table par table.
Le tableau de bord rend le cumul de chapitre 2 visuel, et le filtre rend la formule de chapitre 3 actionnable, sans créer aucune donnée nouvelle.
Un filtre ajuste la pertinence métier de ce qui s’affiche sans jamais modifier les données de la base.
Ce cours est arrivé à son terme : la base CRM est modélisée, calculée et pilotable depuis une interface claire. Maintenant, complétez le quiz qui suit pour vérifier vos connaissances.
