La première chose que nous exportons sur une mission RevOps, ce n'est pas le pipeline. C'est la liste des champs. Triez-la par taux de remplissage et la même forme apparaît à chaque fois : trois à quatre cents champs personnalisés, quarante remplis sur plus de la moitié des enregistrements, et une douzaine que quelque chose en aval lit réellement. Personne n'a décidé cela. Cela s'est sédimenté, un mardi urgent après l'autre, et c'est aujourd'hui ce qui casse silencieusement tous les dashboards de l'entreprise.
Un schéma, c'est ce que votre CRM possède. Un modèle de données, c'est ce qu'une équipe écrit volontairement — et la plupart des entreprises ne l'ont jamais écrit.
Un modèle de données, c'est quatre décisions. La plupart des équipes n'en ont pris aucune.
Dites modèle de données et chacun imagine un diagramme entité-relation que personne n'ouvrira deux fois. En pratique, ce sont quatre phrases par objet, rangées là où une nouvelle recrue ops peut les lire dès le premier jour.
- Grain. Que signifie exactement une ligne ? Un compte est une entité juridique, un domaine racine, un groupe d'achat ou une relation de facturation — et il est exactement l'un des quatre, partout, pour toujours.
- Identité. Quelle clé survit à un changement de nom, à une fusion, à un rebranding, à quelqu'un qui change de poste ? Le nom d'entreprise n'est pas une clé. L'email est une clé avec une date de péremption. Choisissez des clés sur lesquelles le monde extérieur est d'accord.
- Propriété. Qui a le droit d'écrire ce champ ? Exactement un rédacteur : un humain, une source d'enrichissement ou un agent. Pas deux, et surtout pas « le dernier qui passe ».
- Cycle de vie. Qu'est-ce qui crée la valeur, et qu'est-ce qui la tue ? Chaque champ a besoin d'une condition de naissance et d'une condition de mort, sinon il vivra éternellement à 4 % de remplissage.
Quatre phrases par objet. La plupart des entreprises sont incapables de les produire — et c'est précisément pour cela que leur reporting se contredit, et que la réponse à combien de comptes avons-nous dépend de la personne à qui l'on pose la question.
Un champ est facile à créer et impossible à tuer. Cette asymétrie explique à elle seule l'état de votre CRM.
L'objet compte casse en premier.
Demandez à cinq personnes de la même entreprise ce qu'est un compte. Vous obtiendrez le domaine, l'entité juridique, le groupe, la filiale qui signe, et le logo sur la slide. Chaque réponse se défend — c'est bien le problème : le marketing compte des domaines, les sales comptent des opportunités, la finance compte des entités de facturation, et les trois chiffres du board deck n'avaient aucune chance de se réconcilier.
Le domaine racine est généralement le bon grain, parce que c'est la seule clé sur laquelle le monde extérieur est d'accord : fournisseurs d'enrichissement, régies publicitaires et votre propre analytics la parlent nativement. Ensuite, tenez la hiérarchie explicitement plutôt que par convention : un champ parent, rempli par l'enrichissement, jamais à la main. Et aucun humain ne tape un nom d'entreprise dans un formulaire de création. Jamais. La création en texte libre, c'est ainsi que Société Générale, Societe Generale, SocGen et SG finissent en quatre comptes dans le même funnel, trois d'entre eux portant du pipeline.
Un seul rédacteur par champ
La pathologie la plus fréquente n'est pas la donnée manquante. Ce sont deux systèmes qui se battent. L'enrichissement écrase la recherche du commercial le lundi ; le commercial la réécrit le mardi ; l'agent, qui lit ce qu'il trouve, écrit une troisième valeur le mercredi et la cite dans un email le jeudi. Personne n'a tort, et le champ est devenu du bruit.
Si deux systèmes peuvent écrire un champ, sa valeur est une rumeur. Chaque champ reçoit donc un propriétaire unique et un tampon source enregistré à l'écriture. Quand la recherche humaine doit primer sur l'enrichissement, c'est une règle appliquée par le rédacteur — pas une course arbitrée par l'ordre de passage.
Les champs calculés n'ont pas leur place dans le CRM. Leur résultat, si.
Score, tier, segment, ICP fit, propension : ce ne sont pas des propriétés du compte. Ce sont les sorties d'un modèle, et les modèles changent. Garder la formule dans le CRM, c'est renoncer à expliquer le score d'hier et à reproduire celui du trimestre dernier. Gardez la logique dans la couche d'action, écrivez le résultat dans le CRM, et tamponnez-le avec la version du modèle qui l'a produit. Personne ne modifie un score à la main : on change le modèle et on recalcule. C'est exactement la rétrogradation décrite dans le CRM n'est pas le système — appliquée champ par champ.
# Le contrat derrière un champ. champ: account.tier grain: compte = domaine racine ecrit_par: scoring_service # exactement un source: icp_model v4.2 # tamponné à chaque écriture naissance: enrichissement terminé mort: réécriture du modèle → recalcul, jamais d'édition manuelle
Trente contrats de ce type dans un document, c'est un modèle de données. Cela prend quinze jours à écrire et cela survit à trois CRM.
On peut prédire comment une entreprise va scaler en demandant ce qu'est un compte. Si la réponse prend plus d'une phrase, le reporting est déjà faux — il n'est simplement pas encore arrivé dans un board deck.
Hugo Renault · Associé fondateur, Mercator AI
La meilleure migration commence par des suppressions.
Personne n'a l'appétit pour un changement de plateforme, et personne n'en a besoin. La première passe est une soustraction : archiver tous les champs sous 5 % de remplissage qu'aucun rapport, aucune automatisation et aucune intégration ne référence. La moitié du schéma y passe généralement. Archiver n'est pas supprimer — la donnée reste, le champ quitte l'interface — et c'est précisément pour cela que c'est le bon premier geste : c'est réversible, et c'est la seule intervention qui rend la deuxième passe abordable.
Ensuite, écrivez le contrat des trente champs survivants. Grain, rédacteur, source, naissance, mort. Le document demande deux semaines et une personne, sans migration ni interruption — et il change la réponse à toutes les questions dont l'équipe débat depuis un an.
Ce qu'un modèle écrit apporte aux agents.
Cela cesse d'être un exercice d'hygiène à la seconde où un agent touche au CRM. Un humain qui lit un champ contradictoire hausse les épaules et demande à un collègue. Un agent le lit, le croit, et l'écrit dans un email adressé à votre meilleur prospect. La propriété au niveau du champ et les tampons de source sont ce qui rend acceptable de laisser un logiciel écrire dans le registre : le modèle est le contrat entre les deux.
Un modèle de données est un ensemble de promesses sur ce que signifie une ligne.
Toutes les entreprises que nous accompagnons ont plus de données qu'elles ne peuvent en exploiter et moins d'accord qu'il ne leur en faudrait. Les équipes qui scalent ne sont pas celles qui ont le plus de champs. Ce sont celles qui savent dire, en une phrase et sans vérifier, ce que signifie une ligne et qui a le droit de la modifier.
Écrivez les quatre phrases. Archivez le reste. Tout ce qui vient après — routage, scoring, reporting, agents — découle de cette page.
Ce qu'un modèle de données écrit vous rapporte
Le reporting cesse de se contredire. Un grain par objet et une clé d'identité unique : deux dashboards qui posent la même question renvoient le même chiffre.
Chaque champ a un propriétaire et un tampon. Un seul rédacteur, avec la source enregistrée à l'écriture. L'enrichissement et les commerciaux cessent de s'écraser mutuellement dans une boucle que personne ne voit.
Les scores deviennent reproductibles. Les valeurs calculées sont écrites par la couche d'action avec la version du modèle attachée : le tiering du trimestre dernier s'explique au lieu de se raconter.
Le schéma arrête de grossir. Un champ a besoin d'une condition de naissance et d'une condition de mort pour exister. Tout le reste est archivé — et rien en aval ne s'en aperçoit.
END · NAMIA