Comment structurer les données d'un tableau de bord dans Excel ou Google Sheets ?

Mis à jour le 25/10/2026

Au démarrage, quelques exports collés dans un tableur suffisent pour suivre l'activité. Mais dès que les sources se multiplient (un CRM, un outil d'appels, un logiciel de facturation), le classeur devient fragile, et plus personne ne sait quel chiffre croire. Le problème ne vient alors ni d'Excel ni de Google Sheets, mais de la façon dont la donnée circule dans le classeur.

Nous suivrons un seul cas tout au long de cet article : une fintech dont les commerciaux déroulent des listes d'appels préconstruites. Certaines listes sont régulières, comme la cohorte de la semaine précédente, générée chaque lundi matin. D'autres sont ponctuelles et servent à cibler un segment précis. Pour chaque liste, la direction voulait connaître le pourcentage de personnes jointes, le nombre moyen de tentatives, et, au bout du compte, les signatures obtenues.

La réponse courte

Séparez votre classeur en cinq onglets qui ont chacun un seul rôle : les données importées brutes, les données saisies à la main, une table de travail qui fait les jointures, un onglet de calculs, puis l'affichage. La donnée circule dans un seul sens, de l'import vers l'affichage. Cette structure est la même dans Excel avec Power Query, dans Google Sheets et dans une base SQL : vous savez ainsi d'où vient chaque chiffre, et où chercher quand l'un d'eux est faux.

Pourquoi séparer les données de l'affichage ?

Parce qu'un classeur où l'on colle des exports, où l'on calcule et où l'on affiche des graphiques dans le même onglet ne résiste pas au premier changement de format. Le principe est donc de faire circuler la donnée dans un seul sens : elle est importée, puis assemblée, puis calculée, et enfin affichée. Chaque étape a son onglet, et chaque onglet ne fait qu'une chose. Une donnée brute, en particulier, ne se retouche jamais : elle arrive telle qu'elle est dans la source, et toute transformation se fait plus bas. C'est ce qui permet de la recharger à tout moment sans rien perdre. Cette logique n'a d'ailleurs rien de propre au tableur : c'est un standard, que l'on retrouve dans les bases SQL sous le nom de data marts.

Quels onglets créer, et que mettre dans chacun ?

Il en faut cinq. Voici leur rôle, appliqué au cas de la fintech.

1. import_data_xxxx : un onglet par table source, importée brute. Pour la fintech, ce sont les appels, les listes d'appels, les commerciaux qui appellent et les personnes appelées, telles qu'elles sont dans le CRM. La table des appels, seule, est illisible : elle ne contient que des identifiants (les record ID du CRM) à la place des noms.
2. manual_data_xxxx : la donnée saisie à la main, pour historiser une valeur que la source ne conserve pas ou quand le flux automatique n'est pas encore branché. L'idéal est toutefois de la stocker à un endroit central et de l'importer, car d'autres fichiers en auront probablement besoin.
3. mart_data : la table de travail principale, où se font les jointures. Grâce aux identifiants, chaque appel retrouve sa liste, son commercial et la personne appelée. Chez la fintech, chaque ligne du mart est donc un appel complet : qui a appelé, qui a été appelé, le résultat, l'heure de début, l'heure de fin et la durée.
4. calc : les calculs faits à partir du mart. Pour chaque liste, on y trouve le pourcentage de personnes jointes, le nombre moyen de tentatives avant de joindre quelqu'un, et le nombre moyen de tentatives sans jamais joindre la personne. Ce dernier indique à quel point la liste a été travaillée : à cinq ou six tentatives en moyenne, elle a été épuisée.
5. dashboard : l'affichage, et rien d'autre. Il lit calc et mart_data, jamais une donnée brute directement.

Comment relier un appel à une signature ?

Joindre beaucoup de monde ne rend pas une liste pertinente : son but est d'obtenir des signatures, et c'est donc cela qu'il faut mesurer au bout du compte. Or cette mesure est, elle aussi, une jointure dans le mart, entre les personnes de la liste et les signatures enregistrées dans le CRM.

Encore faut-il respecter la chronologie. D'abord, on ne retient que les personnes effectivement jointes : celles qui ont signé sans jamais avoir été eues au téléphone n'ont aucun lien avec la liste. Ensuite, si la liste cible un produit précis, on regarde la signature de ce produit, plutôt que le fait de devenir client en général. Enfin, grâce à la date de signature, on vérifie qu'elle est postérieure à l'appel, et on peut se donner une fenêtre, par exemple deux semaines.

Comment construire ces onglets dans Excel avec Power Query ?

Power Query est l'outil d'Excel qui va chercher la donnée lui-même (menu Données, puis Obtenir des données). Vous lui indiquez où trouver chaque table : un autre classeur, un fichier CSV ou une base SQL, que vous interrogez directement avec votre propre requête SQL. Chaque requête d'import charge une table telle quelle : ce sont vos onglets import_data.

Ensuite, vous créez une autre requête qui part des tables importées (par référence, puis en fusionnant les requêtes) : c'est votre mart_data. Les données manuelles suivent le même chemin, puisqu'elles s'importent depuis leur fichier central comme n'importe quelle source. Enfin, la commande Actualiser tout recharge l'ensemble, de la source jusqu'à l'affichage.

Et dans Google Sheets ?

Google Sheets n'a pas d'équivalent intégré à Power Query. La donnée y arrive donc le plus souvent poussée de l'extérieur, par exemple par un workflow n8n qui réécrit une feuille par table source : c'est ce que nous avons mis en place pour la fintech, et nous le détaillons dans Comment envoyer automatiquement vos données Attio vers Google Sheets ou une base SQL ? La fonction IMPORTRANGE fait ensuite entrer ces feuilles dans vos onglets import_data.

Les jointures du mart se font alors en une seule formule pour toute la table : soit avec ARRAYFORMULA, soit avec une formule sur mesure construite avec LET, qui définit d'abord chaque table puis fait les jointures avec VLOOKUP ou XLOOKUP. Ces formules sont longues à écrire, mais Gemini, intégré à Google Sheets, les rédige très bien à partir d'une description.

Et dans une base SQL ?

La structure reste la même : les tables de la base, une par objet, jouent le rôle des onglets import_data, des vues ou des fonctions construisent les marts par jointure, et le tableau de bord interroge ces marts. Les données manuelles y sont rares, car une base SQL ne se modifie pas facilement à la main. C'est l'étape que nous décrivons dans Tableur, CRM, base SQL : comment faire grandir la donnée de votre entreprise ?

Comment retrouver l'origine d'un chiffre faux ?

Vous remontez le chemin de la donnée, un onglet après l'autre. Supposons que le pourcentage de personnes jointes d'une liste paraisse anormal. Vous vérifiez d'abord la formule dans calc. Si elle est juste, vous regardez dans le mart si tous les appels de la liste y figurent. S'il en manque, le problème est en amont : vous comparez alors le nombre de lignes de l'onglet import_data des appels avec le nombre d'appels dans le CRM.

Cette structure n'est pas une fin en soi : c'est elle qui permet ensuite de piloter et de décider, parce que chacun sait d'où viennent les chiffres qu'il regarde.

Questions fréquentes

Faut-il choisir Excel ou Google Sheets ?

Les deux fonctionnent avec la même structure. Excel, avec Power Query, va chercher la donnée lui-même, y compris par une requête SQL. Google Sheets demande en revanche qu'un outil extérieur y pousse la donnée.

Pourquoi garder les identifiants dans les onglets d'import ?

Parce que ce sont eux qui permettent les jointures. Un nom peut s'écrire de deux façons ou changer, alors qu'un identifiant reste le même : c'est donc sur lui que le mart relie un appel à sa liste, à son commercial et à la personne appelée.

Comment bien structurer ses données dans le CRM avant de les exporter ?

Les jointures ne valent que ce que vaut la structure de vos sources. Si vos données sont rangées au mauvais endroit dans le CRM, le mart le sera aussi. Pour Attio, nous détaillons ce choix dans Attribut, liste ou objet custom dans Attio : comment choisir ?