Tableau de bord Airtable : KPI, méthode et exemple

À quoi sert un tableau de bord Airtable ?

Un tableau de bord sert à repérer une situation qui demande une décision. Dans une agence, il peut montrer les projets en retard, les validations qui bloquent la production ou les budgets qui nécessitent une revue.

Le bon point de départ est une question : « Quels dossiers faut-il traiter cette semaine ? » Elle détermine les données à montrer et le niveau de détail nécessaire. Un total de tâches terminées répond rarement, à lui seul, à cette question.

Airtable propose un layout Dashboard dans Interface Designer. Il rassemble notamment des nombres, des graphiques et des listes, avec un accès au détail des enregistrements selon la configuration. Notre guide des Interfaces Airtable explique la conception de l’espace de travail par rôle ; cet article se concentre sur les indicateurs et leur fiabilité.

Choisir les KPI à partir des décisions

Un KPI est un indicateur clé de performance. Pour le rendre utilisable, préciser son périmètre, son calcul, sa date de référence et la personne qui doit agir. Le libellé « Projets en retard » est insuffisant si chacun interprète différemment le retard ou le statut terminé.

Dans l’exemple ci-dessous, un projet actif exclut les projets clôturés et annulés. Une date d’échéance absente produit une anomalie à traiter ; elle ne classe pas automatiquement le projet parmi les dossiers à jour.

Le délai de cinq jours est un choix pédagogique à adapter au fonctionnement de l’équipe. Les seuils doivent traduire une règle connue, pas une couleur choisie pour embellir la page.

Un budget consommé à 80 % ne signifie pas que le projet est réalisé à 80 %. Le premier mesure une dépense ; le second suppose une définition de l’avancement. Les confondre peut masquer un dépassement à venir.

Structurer les données avant les graphiques

Pour une agence, trois tables peuvent suffire au départ :

• Projets : un enregistrement par projet, avec client, responsable, statut, échéance et budget de coût.

• Livrables : un enregistrement par livrable lié à son projet, avec statut de validation et date de soumission.

• Coûts constatés : une ligne par coût attribué à un projet, avec date, montant et référence permettant de le vérifier.

Si les coûts proviennent des temps saisis, définir comment ils sont valorisés et traiter les saisies manquantes. Une formule appliquant le taux actuel à tout l’historique peut réécrire les anciens résultats après un changement de taux. Conserver la valeur pertinente au moment de l’enregistrement lorsque l’historique doit rester stable.

La table Clients peut compléter ce modèle si les informations client sont déjà structurées séparément. Inutile de recopier ces données dans chaque projet.

Les projets et leurs livrables relèvent du modèle décrit dans notre guide de gestion de projet avec Airtable. Le dashboard vient utiliser ce socle, sans créer une deuxième source de vérité.

Agréger au bon niveau

Le coût total d’un projet peut être calculé dans Projets par un champ Rollup, qui agrège les montants des coûts liés avec SUM(values). Les Rollups Airtable reposent sur une relation entre les enregistrements.

Compter les projets dans Projets et les livrables dans Livrables. Si un projet possède dix lignes de coût, recopier son budget sur chacune puis additionner la colonne multiplie artificiellement le budget par dix.

Pour ne compter que certains livrables, un Count ou Rollup conditionnel peut limiter les enregistrements liés pris en compte. Un filtre appliqué dans une vue ne modifie pas, à lui seul, le périmètre d’un Rollup.

Exemple : lire le budget de trois projets

Voici un exemple fictif destiné à expliquer les calculs, sans résultat client associé. Tous les montants représentent ici des coûts de production prévus ou constatés sur la durée des projets, dans une même devise.

Les consommations individuelles sont de 80 %, 90 % et 20 %. Pour l’ensemble des trois projets, le ratio correct est 13 500 / 20 000 = 67,5 %.

La moyenne simple des trois pourcentages donne 63,3 %. Elle accorde le même poids à un projet de 10 000 € et à un projet de 5 000 €. Pour présenter la consommation globale de ce portefeuille, il faut donc diviser la somme des coûts par la somme des budgets.

Ce total ne suffit pas à décider. Atlas demande une revue du retard ; Boréal demande de débloquer la validation et d’estimer le coût restant. Le chiffre agrégé et la liste des exceptions doivent rester accessibles ensemble.

Ce ratio n’est ni une marge, ni un chiffre d’affaires, ni un avancement. Et si des temps restent à saisir, les coûts constatés sont incomplets : le tableau de bord doit le signaler.

Construire le Dashboard dans Airtable

Dans l’éditeur d’Interfaces, ajouter une page, choisir le layout Dashboard, puis la table source. Le guide officiel Airtable présente ce parcours.

Pour notre exemple, commencer avec un groupe lié à Projets. Ajouter un groupe distinct pour les indicateurs provenant de Livrables : chaque groupe utilise une table source de la base.

La documentation du layout Dashboard détaille les options. Une première page peut rester très simple :

1. Quelques indicateurs pour repérer les situations à revoir.

2. Un graphique par responsable ou par statut pour comprendre leur répartition.

3. Une liste des projets concernés, avec responsable, échéance et prochaine action.

4. Un accès aux enregistrements qui expliquent chaque chiffre.

Configurer les filtres du groupe, ceux des visualisations et les filtres disponibles pour les utilisateurs en vérifiant leurs effets respectifs. Nommer explicitement les populations : « Projets actifs à la date de revue » est plus précis que « Tous les projets ».

Éviter de présenter un budget portant sur tous les projets à côté de coûts filtrés sur un seul responsable. Les blocs peuvent être justes individuellement et produire ensemble une lecture trompeuse.

Donner un chemin vers l’action

Une personne qui voit deux projets en retard doit pouvoir retrouver lesquels, comprendre le blocage et identifier qui le traite. Prévoir la liste correspondante et, lorsque cela sert l’usage, activer l’accès aux enregistrements sous-jacents.

Le dashboard direction peut privilégier la synthèse. L’équipe projet aura besoin du contexte et des actions de suivi. Une page saturée de métriques pour satisfaire tous les rôles devient vite difficile à utiliser.

Distinguer suivi courant et reporting mensuel

Un dashboard courant répond à « Où en sommes-nous maintenant ? ». Un rapport mensuel doit pouvoir répondre à « Quelle était la situation à la clôture du mois ? ».

Filtrer aujourd’hui les projets créés en septembre n’indique pas combien étaient en retard le 30 septembre. Leur statut, leur échéance ou leur budget ont pu changer depuis.

Lorsque l’historique importe, définir ce qui doit être conservé. Une table de snapshots, ou états figés datés, peut stocker pour chaque période les indicateurs retenus, leur périmètre et la date de clôture. Un historique d’événements permet une reconstruction plus détaillée, avec davantage de travail de conception.

Préciser aussi la politique de correction. Si une saisie tardive modifie un rapport clos, faut-il conserver l’ancienne version, publier une correction ou recalculer la période ? La réponse dépend de l’usage du rapport ; elle doit être connue de ses lecteurs.

Pour un besoin ponctuel, un export contrôlé et daté peut suffire. Une synchronisation vers une autre base reste un mécanisme d’échange : elle ne constitue pas automatiquement un historique figé. Notre guide de synchronisation Airtable développe cette distinction.

Vérifier les chiffres, les filtres et les accès

Avant de diffuser le tableau de bord, retrouver quelques dossiers à la main et comparer leurs valeurs aux résultats affichés. Inclure des cas ordinaires et des exceptions :

• un projet sans échéance ;

• un projet terminé après la date prévue ;

• un livrable soumis puis rouvert ;

• un projet sans budget ou avec un budget nul ;

• un coût rattaché au mauvais projet ;

• un utilisateur qui ne doit consulter qu’une partie des données.

Un budget nul ne doit pas provoquer une division invalide, ni être remplacé silencieusement par 100 %. Une valeur manquante ne vaut pas zéro. Afficher « à compléter » peut être plus utile qu’un pourcentage artificiellement rassurant.

Vérifier également les permissions d’Interface Designer. Les possibilités de partage dépendent des accès et du plan ; un filtre choisi pour analyser les données n’est pas une politique de sécurité à lui seul. Tester avec le rôle réel du lecteur.

Pour une diffusion à des clients, notre guide du portail client Airtable aide à cadrer les accès externes. Le besoin de consulter un rapport et celui de modifier ou valider un dossier ne demandent pas forcément la même expérience.

Quand Airtable suffit-il pour le reporting ?

Airtable est pertinent lorsque les données utiles sont proches du travail quotidien et que le lecteur doit agir sur les dossiers. Un tableau de bord intégré peut alors éviter un export manuel qui sépare le chiffre de son contexte.

Un outil de business intelligence, spécialisé dans l’analyse de données, devient plus intéressant lorsque le reporting doit croiser de nombreuses sources, gérer des calculs analytiques complexes ou conserver un historique volumineux avec des exigences propres.

Le problème doit guider ce choix. Ajouter un outil de reporting ne corrige pas un statut ambigu, des coûts incomplets ou un budget dupliqué. À l’inverse, forcer toutes les analyses dans Airtable peut alourdir un système opérationnel qui fonctionnait bien.

Commencer par une revue utile

Le meilleur premier dashboard est celui qu’une équipe utilise pour prendre une décision et suivre son effet. Commencer avec quelques indicateurs définis, des données vérifiables et une liste de dossiers à traiter ; faire évoluer la page à partir des questions réellement posées.

HyperOps accompagne la conception d’outils métier Airtable, du modèle de données aux Interfaces et à l’adoption. Le tableau de bord devient ainsi une partie du système de travail, avec des règles que l’équipe comprend et peut maintenir.

Questions fréquentes sur les tableaux de bord Airtable