La première slide de chaque diagnostic que nous menons porte la même phrase : le CRM n'est pas le système. La plupart des directeurs revenue hochent poliment la tête, puis passent les quatre-vingt-dix minutes suivantes à se contredire. Ils nous montrent le workflow construit dans HubSpot. La propriété personnalisée ajoutée pour corriger le dernier bug. Le Zap qui se déclenche au changement d'étape. Ils décrivent un moteur soudé à l'intérieur d'une armoire d'archives — et s'étonnent que l'armoire prenne feu.
Un CRM est un registre. Pas un moteur de workflows.
Le CRM a été conçu à l'origine pour bien faire une seule chose : tenir un journal fiable, en append-only, de chaque compte, chaque contact, chaque deal et chaque interaction. C'est un système de référence. C'est ennuyeux. C'est censé l'être. La valeur d'un système de référence, c'est qu'il ne ment pas, ne dérive pas et ne change pas sous vos pieds.
L'erreur que commettent presque toutes les équipes revenue — nous l'avons commise nous-mêmes — consiste à greffer le système d'action sur le système de référence. La logique de scoring atterrit dans une propriété personnalisée. Les règles de routage dans un constructeur de workflows. Les instructions de l'agent dans un champ de notes en texte libre. Le CRM passe du statut de registre à une sorte de système d'exploitation Frankenstein, et il fait mal les deux métiers : c'est désormais un mauvais registre, parce qu'il change en permanence, et un mauvais système d'exploitation, parce qu'il ne sait ni versionner, ni brancher, ni revenir en arrière.
Traitez le CRM comme une piste d'audit. Tout le reste — scoring, enrichissement, routage, rédaction — appartient à une couche qu'on peut démolir un mercredi et reconstruire un jeudi.
Quatre questions pour savoir si votre CRM est le système ou le dashboard.
Nous posons ces quatre questions avant de toucher au moindre champ. Moins de vingt minutes par équipe. Le profil des réponses nous dit en une heure si la mission sera une refonte d'architecture ou un simple réglage.
- Pouvez-vous supprimer un workflow sans casser le reporting ? Si la réponse s'accompagne d'une grimace, le CRM fait deux métiers à la fois.
- Où vit une nouvelle règle de scoring ? Si la réponse est « dans une formule de propriété », le système d'action vit à l'intérieur du système de référence.
- Comment A/B testez-vous un changement de routage ? Si la réponse est « on ne le fait pas », il n'y a aucune séparation entre staging et production — parce qu'il n'y a aucune séparation entre l'action et le registre.
- Qui est propriétaire des instructions de l'agent ? Si la réponse est « la dernière personne des ops qui a modifié la note », l'agent n'a pas de source de vérité.
Deux couches, un seul sens d'écriture.
L'architecture que nous déployons à chaque mission a la même allure au tableau blanc — et presque toujours la même neuf mois plus tard. Un système d'action se place devant le CRM. La couche d'action héberge tout ce qui doit rester peu coûteux à changer : l'agent de scoring, la cascade d'enrichissement, le rédacteur d'outbound, le routeur. Le CRM reste derrière, intouché par les humains, alimenté en écriture par la seule couche d'action.
La couche d'action a le droit d'être tranchée, fragile et éphémère. Nous réécrivons la logique de scoring environ une fois par trimestre. Nous changeons de fournisseur d'enrichissement deux fois par an. Nous ajustons la voix de l'agent d'outbound presque chaque mois. Rien de tout cela ne touche le CRM. Le CRM conserve la piste d'audit de tout ce que la couche d'action a décidé — et la couche d'action peut être rasée jusqu'aux fondations sans perdre un seul octet d'historique client.
Ce qui vit où
Une heuristique pratique : si vous pourriez supprimer l'artefact le mois prochain sans regret, il appartient à la couche d'action. Si sa suppression effaçait l'histoire de l'entreprise, il appartient au CRM. La plupart des équipes réussissent la seconde catégorie — et entassent beaucoup trop de la première dans leur CRM. C'est pour cela qu'elles n'avancent plus.
# Sens d'écriture — toujours à sens unique. action_layer.score(account) # peu coûteux à changer action_layer.enrich(account) # peu coûteux à changer action_layer.draft_message(...) # peu coûteux à changer # ↓ crm.append(account, score, draft, decision, ts) # append-only · audité · ennuyeux
Les équipes qui capitalisent ne sont pas celles qui ont le CRM le plus propre. Ce sont celles dont le CRM a le droit d'être simple, parce que tout ce qui est intéressant vit ailleurs.
Hugo Renault · Associé fondateur, Mercator AI
On ne reconstruit pas le CRM. On le rétrograde.
Personne n'a l'appétit pour une migration CRM complète, et tant mieux : personne n'en a besoin. Le changement n'est pas un remplacement — c'est une rétrogradation. Le CRM continue de faire ce qu'il fait bien : tenir le registre. Les agents, la logique de scoring et les règles de routage en sortent, un par un, vers une couche que l'équipe possède et peut casser sans conséquences.
Ce qui change après la rétrogradation
Le CRM n'est plus modifié par des humains. Les changements de propriétés passent par un script. Les workflows sont en lecture seule. Le reporting redevient fiable parce que le registre arrête de bouger.
Le scoring devient versionné. Chaque modèle vit dans le code ou dans une colonne Clay que l'équipe peut brancher. Le score d'hier est reproductible. Celui du trimestre dernier aussi.
Les agents ont une source de vérité unique. Les system prompts vivent dans un repo, pas dans une note CRM. Les instructions de chaque agent peuvent être comparées, relues et annulées — comme le logiciel qu'elles sont.
Reconstruire devient bon marché. Quand le prochain fournisseur d'enrichissement gagne sur le prix, la bascule se fait un mardi après-midi. Le registre ne bouge jamais ; seule la couche au-dessus bouge.
Un CRM ennuyeux est la forme la plus aboutie du revenue ops.
Les CRM que nous admirons le plus sont ceux qui paraissent presque vides. Des propriétés standard. Des pipelines standard. Un seul utilisateur d'intégration qui écrit tout. Aucun humain n'y clique — parce que tout ce qui est intéressant se décide une couche au-dessus, là où est sa place.
Si votre CRM est palpitant, quelque chose ne va pas. Rétrogradez-le. Laissez-le redevenir un registre. Construisez le moteur là où vous pouvez le casser.
FIN · MERCATOR AI · 01