Deux personnes ouvrent le même contact dans le même CRM. L'une voit la date du dernier appel, le propriétaire du deal et l'indicateur de renouvellement. L'autre n'en voit aucun, parce que les colonnes n'ont jamais été ajoutées à la mise en page qu'elle consulte. Elles ne débattent pas de stratégie. Elles débattent de ce que dit la fiche, et toutes deux ont raison, parce qu'elles lisent deux surfaces d'affichage différentes au-dessus du même jeu de données.
C'est le mode de défaillance silencieux derrière la plupart des conversations « nos chiffres ne concordent pas ». C'est rarement un problème de reporting. C'est presque toujours une question de qui a configuré quelle mise en page, et combien de ces mises en page existent désormais.
Autrefois, ce désaccord coûtait quelques minutes de confusion en réunion. Aujourd'hui, il s'accumule. Dès lors que les équipes GTM pointent des agents IA sur le CRM pour rédiger des relances, scorer des comptes et mettre à jour des fiches, le système de référence devient le substrat que tout le monde lit. L'argument de Jason Lemkin dans son article de 2026 sur le CRM agentique est que le CRM devient le hub central où plusieurs agents tirent l'historique et renvoient des signaux. Si vos propres commerciaux ne s'accordent pas sur ce qu'affiche une fiche, les agents qui lisent cette même fiche héritent de la confusion à la vitesse de la machine.
La discipline qui était autrefois un simple confort est donc désormais porteuse. Une couche d'affichage en désordre était supportable tant que seuls des humains la lisaient. Elle ne l'est plus quand des logiciels la lisent.
Le signe est simple. Demandez à deux personnes de la même équipe d'ouvrir le même compte et de décrire ce qu'elles voient. Si la réponse est « eh bien, dans ma vue », vous l'avez déjà trouvé. Les données en dessous sont identiques. Les mises en page au-dessus ne le sont pas.
Tout CRM moderne doté de vues enregistrées, qu'il s'agisse de HubSpot, de Salesforce ou de Pipedrive, traite une vue comme une configuration enregistrée de filtres, de colonnes triées et de propriétés visibles. C'est un confort. Le problème commence quand le confort devient propriété privée : chaque commercial, chaque manager et chaque équipe crée ses propres vues enregistrées, et personne ne supprime les anciennes.
Ce n'est pas de la négligence. C'est le comportement par défaut d'un outil flexible. Quelqu'un a besoin d'une colonne pour une campagne en mars, alors il l'ajoute à une vue personnelle. Un manager veut des deals triés par date de clôture pour un point de forecast, alors il l'enregistre. Une nouvelle recrue copie une vue existante et l'ajuste. Aucun de ces gestes n'est faux en soi. Six mois plus tard, il existe vingt vues enregistrées, la moitié appartenant à des personnes qui ont changé d'équipe, et deux d'entre elles n'affichent jamais les mêmes champs.
Le résultat est une couche d'affichage qui s'écarte de toute définition partagée de la fiche. Quand quelqu'un partage une information avec un collègue, ce collègue ne la trouve pas, parce qu'elle a été ajoutée à une vue et pas à l'autre. Les données étaient là depuis le début. Elles n'étaient simplement pas visibles depuis l'endroit où la personne se tenait.
Voici le recadrage qui corrige le raisonnement. Une vue enregistrée est un choix d'affichage. Ce ne sont pas les données, et ce n'est pas la vérité. Traiter les mises en page comme si elles portaient du sens, voilà comment les équipes finissent par réconcilier des tableaux de bord au lieu de réparer ce qui se trouve en dessous.
C'est la même leçon que Thomas Redman défend depuis des années à propos de la qualité des données : dans ses travaux pour la Harvard Business Review, l'argument est qu'on contrôle la qualité au point où les données sont créées, et que les nettoyer en aval coûte cher et ne passe pas à l'échelle. La prolifération des vues est un symptôme en aval. Chaque mise en page supplémentaire est un endroit de plus où l'image peut diverger de celle de tous les autres. Vous ne corrigez pas cela en construisant un meilleur tableau de bord par-dessus. Vous le corrigez en réduisant d'abord le nombre de surfaces.
L'instinct, quand les chiffres ne concordent pas, est de construire un nouveau tableau de bord « source unique de vérité » auquel tout le monde est censé se fier. Cela ajoute une surface. Cela ne retire pas les surfaces contradictoires, donc vous avez maintenant une chose de plus à maintenir synchronisée.
Jouez le coup inverse. Appliquez à vos vues enregistrées un passage garder, ajuster, supprimer, exactement comme vous le feriez pour un pipeline surchargé ou une liste de propriétés devenue envahissante. Gardez le petit nombre de vues partagées que toute l'équipe consulte. Ajustez la mise en page par défaut de la fiche pour qu'elle porte les champs dont les gens ont réellement besoin, afin que personne n'ait à créer une vue privée pour les voir. Supprimez le reste. L'objectif n'est pas la vue la plus puissante. Ce sont les vues partagées les moins nombreuses qui font encore le travail, propriété de l'équipe plutôt que des individus.
Ne compliquez pas à l'excès. La plupart des équipes de quelques centaines de sièges ont besoin d'une poignée de vues partagées, pas de vingt vues privées.
Nous avons récemment accompagné une équipe B2B SaaS de série B dans la région DACH qui consolidait sur un seul CRM. En cours de route, deux personnes en séance de travail ont ouvert ce que chacune appelait « la vue contacts » et se sont parlé sans se comprendre, parce que les champs ne correspondaient pas. Nous avons compté les vues enregistrées sur les objets principaux. Rien que sur les contacts, il y en avait plus d'une douzaine, plusieurs appartenant à des personnes qui avaient changé de rôle, chacune montrant une tranche légèrement différente.
La solution n'a pas été un projet de migration à part entière. Nous avons fait en sorte que la mise en page par défaut des contacts porte tout ce que contenait la vue personnalisée de l'équipe service, obtenu l'accord pour supprimer les vues redondantes, et posé l'attente que l'équipe travaille à partir de vues partagées plutôt que personnelles. Le problème de réconciliation a disparu, parce qu'il n'y avait plus rien à réconcilier. Tout le monde regardait enfin la même fiche de la même façon.
- Inventoriez chaque vue enregistrée sur vos objets principaux. Listez chacune avec son propriétaire et la dernière fois où elle a réellement servi. Vous ne pouvez pas décider de ce que vous coupez tant que vous ne voyez pas toute la prolifération au même endroit.
- Démantelez les vues orphelines. Tout ce qui appartient à quelqu'un qui a changé d'équipe ou qui est parti est un candidat à la suppression. Personne ne les défend, et ce sont les gains les plus faciles.
- Définissez les vues partagées que toute l'équipe consulte. Un petit ensemble, par objet et par rôle, pas par individu. L'unité de propriété est l'équipe, de sorte qu'une nouvelle recrue hérite dès le premier jour de la même vue que tout le monde.
- Déplacez les champs nécessaires dans la mise en page par défaut de la fiche. La plupart des vues privées existent parce qu'il manquait une colonne dans la vue par défaut. Mettez ces colonnes dans la vue par défaut et la raison de créer une vue personnelle disparaît.
- Supprimez les vues redondantes, et encadrez les nouvelles. Posez la norme que les nouvelles vues partagées passent par la personne qui possède le CRM, afin de ne pas reproliférer aussitôt jusqu'au point de départ.
- Pointez vos automatisations et vos agents sur les mêmes vues partagées. Ce que lisent vos workflows et vos agents IA doit être la même image que celle que lisent les humains, pour que logiciels et personnes travaillent à partir d'une seule fiche, pas de deux.
Vous ne pouvez pas faire confiance à un forecast, à une automatisation ou à un agent qui tourne sur des données que votre propre équipe ne peut pas voir de manière cohérente. Se standardiser sur des vues partagées est peu spectaculaire, mais c'est le gain de fiabilité le moins cher du CRM, et faire basculer une équipe sur des vues partagées prend généralement une demi-journée de travail, pas un projet. Si vous voulez une seconde paire de mains pour le nettoyage, c'est précisément le type de chose pour lequel notre travail en Revenue Operations et en implémentation HubSpot est conçu. Pour le problème voisin consistant à standardiser cela avant une mise en production, lisez l'article compagnon sur la répétition avant la mise en production du CRM.
- Thomas Redman. « To Improve Data Quality, Start at the Source. » Harvard Business Review, février 2020. hbr.org
- Jason Lemkin. « Which CRM Should You Use in 2026/2027? Follow the Agents. » SaaStr, 2026. saastr.com