Deux objets, deux usages
Le rapport est une liste d'enregistrements filtrée, triée et regroupée. Il répond à « lesquels », il se lit ligne par ligne, et on peut agir depuis lui : ouvrir une fiche, exporter, modifier en masse.
Les tableaux de bord affichent une synthèse visuelle construite à partir de rapports. Ils répondent à « où en est-on », d'un coup d'œil, sans détail.
La règle pratique tient en une phrase : on travaille dans un rapport, on décide devant un tableau de bord. Un commercial qui prépare sa semaine ouvre un rapport. Un directeur qui prépare un comité ouvre un tableau de bord.
La confusion produit deux erreurs symétriques. Un tableau de bord bourré de détails que personne ne lit, ou un rapport de quatre cents lignes envoyé à un dirigeant qui voulait un ordre de grandeur.
Ce que sait faire un rapport
Beaucoup plus de choses que ce que la plupart des utilisateurs exploitent.
Les regroupements transforment une liste en analyse : par commercial, par étape, par mois. Deux niveaux suffisent presque toujours, au delà la lecture devient pénible.
Les filtres croisés répondent à des questions que l'on croit impossibles sans développement : les comptes sans opportunité ouverte, les opportunités sans activité récente, les contacts jamais sollicités. Ce sont souvent les rapports les plus utiles commercialement, et les moins connus.
Les formules de synthèse calculent un taux ou un écart directement dans le rapport, sans créer de champ dans l'org. C'est la bonne réponse à un besoin d'analyse ponctuel : inutile d'alourdir le modèle de données pour un calcul qui ne sert qu'au reporting.
Les abonnements enfin envoient le rapport par email à une fréquence choisie, éventuellement sous condition. C'est ce qui remplace avantageusement la personne qui exporte le même fichier tous les lundis matin.
Cette dernière fonction est de loin la plus sous-utilisée. Dans la plupart des organisations, quelqu'un consacre chaque semaine une heure à produire un fichier que Salesforce sait envoyer tout seul, avec les bons filtres et aux bonnes personnes. Quand je reprends une org, c'est souvent le premier gain de temps que je propose, parce qu'il se met en place en quelques minutes et qu'il se voit immédiatement.
L'erreur de droits qui fausse les chiffres
C'est le point technique le plus important de cet article, et la source d'incompréhension numéro un.
Un tableau de bord s'exécute avec les droits d'un utilisateur désigné. Deux réglages sont possibles, et ils donnent des résultats radicalement différents.
Avec un utilisateur fixe, tout le monde voit exactement les mêmes chiffres, ceux que cette personne a le droit de voir. C'est ce qu'il faut pour un tableau de direction, où l'on veut que chacun parle des mêmes nombres.
Avec un utilisateur dynamique, chacun voit le tableau de bord filtré par ses propres droits. C'est ce qu'il faut pour un tableau distribué aux commerciaux, où chacun doit voir son périmètre.
Se tromper de réglage produit soit des chiffres incohérents entre collègues, soit des données visibles par des personnes qui ne devraient pas y accéder. Et un tableau de bord dont l'utilisateur désigné a quitté l'entreprise cesse d'afficher les bons chiffres : c'est le lien direct avec un offboarding mal traité.
Les limites qu'il faut connaître
Le reporting standard couvre l'immense majorité des besoins, à condition de savoir où il s'arrête.
Un rapport travaille sur des objets liés entre eux. Croiser des données qui n'ont aucun lien dans le modèle demande une autre approche, souvent un champ de rattachement ou un objet intermédiaire.
Les comparaisons entre périodes sont possibles mais rigides. Dès que la logique se complique, il devient plus sûr de construire un champ dédié qui porte l'information, plutôt que d'empiler des filtres que personne ne pourra maintenir.
Enfin, un tableau de bord ne se substitue pas à un outil d'analyse. S'il vous faut recouper des sources externes et construire des modèles, la question n'est plus le reporting Salesforce, et il vaut mieux le dire tôt.
Le type de rapport, décision invisible mais structurante
Avant de construire, Salesforce demande sur quels objets porte le rapport. Ce choix paraît anodin et détermine pourtant ce que vous pourrez afficher.
Un rapport sur un seul objet montre les enregistrements de cet objet. Un rapport sur deux objets liés ne montre, par défaut, que les enregistrements du premier qui ont au moins un enregistrement lié. Autrement dit, un rapport « Comptes et opportunités » masque silencieusement les comptes sans aucune opportunité, qui sont souvent ceux qui vous intéressent le plus.
C'est la cause la plus fréquente des rapports dont le total ne correspond à rien de connu. Quand un chiffre paraît trop bas sans explication, c'est le premier point à vérifier, avant même les filtres.
Salesforce propose des variantes qui incluent les enregistrements sans lien, ainsi que la possibilité de créer vos propres types de rapport quand aucun modèle standard ne convient. Cette création est une opération d'administration simple, et elle débloque des analyses que beaucoup d'utilisateurs croient impossibles.
Retenez donc que la richesse de vos tableaux de bord dépend d'abord de la qualité des rapports qui les alimentent, et que la qualité de ces rapports se joue au moment du choix du type. Des tableaux de bord soignés bâtis sur un rapport mal typé affichent avec élégance des chiffres faux.
Garder un dossier lisible
Le vrai ennemi du reporting n'est pas la limite technique, c'est l'accumulation. Une org de quelques années contient des centaines de rapports dont la plupart sont des variantes créées pour un besoin ponctuel.
Quatre règles suffisent à tenir l'ensemble.
- Nommer par ce que le rapport répond, pas par son auteur ni par la date. « Opportunités sans activité depuis 30 jours » vaut mieux que « Rapport pipeline v3 ».
- Séparer les dossiers : ce qui est partagé et officiel d'un côté, les rapports personnels de l'autre.
- Une seule version officielle par question. Dès qu'il y a deux rapports du même nom, les chiffres divergeront un jour.
- Une revue annuelle pour archiver ce que plus personne n'ouvre. Une demi-journée, et le dossier redevient utilisable.
Comment je procède
Je pars toujours de la question de pilotage, jamais de l'objet Salesforce. Une fois la question posée, je construis le rapport qui y répond, je vérifie les chiffres à la main sur quelques enregistrements, puis seulement j'assemble les tableaux de bord.
Cette vérification manuelle est le seul moyen de détecter un filtre mal posé ou un champ mal choisi. Un rapport qui affiche un total plausible mais faux est plus dangereux qu'un rapport visiblement cassé.
Tout se construit dans une sandbox quand cela touche à des champs ou à des types de rapport nouveaux, et la validation se fait avec ceux qui utiliseront le résultat. Un reporting validé par son commanditaire est un reporting qui vit ; un reporting livré sans revue est un reporting qui sera refait dans six mois.
Questions fréquentes
Quelle différence entre un rapport et un tableau de bord Salesforce ?
Le rapport produit une liste d'enregistrements filtrée et triée, sur laquelle on peut agir. Le tableau de bord affiche une synthèse visuelle construite à partir de rapports, pour voir une situation d'ensemble. On travaille dans un rapport, on décide devant un tableau de bord.
Pourquoi mon tableau de bord n'affiche-t-il pas les mêmes chiffres qu'un collègue ?
Parce qu'un tableau de bord s'exécute avec les droits d'un utilisateur désigné. Selon le réglage, tout le monde voit les chiffres de cette personne, ou chacun voit les siens. C'est la première chose à vérifier quand deux personnes ne lisent pas le même total.