Un fondateur m’a posé une question parfaitement légitime la semaine dernière : où en est ce projet, concrètement ? Personne dans la salle n’a pu répondre. Pas parce que la donnée manquait, mais parce qu’elle vivait dans deux systèmes et qu’aucun des deux n’était propriétaire de la réponse.
C’est la question la plus coûteuse dans une organisation revenue en croissance, et la solution vers laquelle les équipes se tournent est presque toujours la mauvaise. Elles entendent une demande de visibilité et se mettent à cadrer une intégration. Six semaines plus tard, une synchronisation tourne dans les deux sens et le fondateur ne peut toujours pas répondre à la question.
Pourquoi cela empire au lieu de s’améliorer
Si vous rencontrez ce problème en boucle, c’est que le marché n’a pas tranché où réside la vérité, alors chaque entreprise tranche en silence pour elle-même. En analysant le rachat de Momentum par Salesforce en février, Anthony McPartlin de Forrester a posé le choix auquel les acheteurs font désormais face : soit une approche CRM-as-a-platform, qui vous achète « simplicity, centralized governance, and a single point of accountability », soit une plateforme de vérité best-of-breed, qui vous achète « faster innovation and advanced specialization ». Sa prédiction : les suites continueront d’absorber ces couches d’orchestration plutôt que de laisser des spécialistes s’installer entre le CRM et le workflow.
C’est une bataille d’éditeurs. Votre version à vous est plus petite et plus urgente. Vous avez un CRM, vous avez un second système où se fait le vrai travail, et vous avez un dirigeant qui veut une seule phrase sur l’état d’avancement. Personne n’a décidé quel système a le droit de répondre.
L’erreur de diagnostic
Voilà le problème. Quand quelqu’un demande de la visibilité, le réflexe est de connecter les systèmes : synchronisation bidirectionnelle, mapping de champs, enregistrements dupliqués des deux côtés. C’est beaucoup de build, c’est honnêtement coûteux à maintenir, et le jour où la duplication dérive, vous avez créé un nouveau problème : deux équipes qui pointent la donnée de l’autre au lieu de pointer le travail.
Cela résout aussi la mauvaise chose. Le dirigeant qui demande de la visibilité ne veut pas les enregistrements de l’autre système. Il veut trois faits : à quelle étape on est, qui en est responsable en ce moment, et si c’est bloqué. C’est un problème de reporting à très petite surface, et vous pouvez y répondre sans déplacer un seul champ.
J’appliquerais ici le cadre keep / edit / delete avant que quiconque n’écrive une spec d’intégration. Keep : la donnée qui répond à la question du dirigeant. Edit : le journey, pour que la responsabilité soit explicite. Delete : l’hypothèse que chaque système doit savoir tout ce que sait l’autre. L’intégration est une façon d’acheter de la visibilité, et c’est la plus chère de la carte.
Construisez une couche de statut au-dessus du journey
Ce qui produit vraiment de la visibilité, c’est une couche légère posée au-dessus de votre customer journey et qui le résume. Pas une pipeline de plus. Un petit ensemble de propriétés sur l’objet qui constitue chez vous la véritable unité de travail : le compte, le projet, le portefeuille.
C’est la partie que tout le monde saute, parce qu’une couche de statut paraît trop simple pour répondre à un problème qui semblait architectural.
Quatre champs portent l’essentiel de la charge :
- Jalon actuel. Une valeur issue d’une liste courte, six à dix options, pas chaque micro-étape.
- Owner actuel. La personne nommée qui répond de l’avancement, et qui change quand le jalon change.
- Bloqué. Un booléen plus une ligne de motif.
- Date de prochaine action. La date à laquelle quelque chose est censé se produire ensuite.
Cette couche touche les jalons structurants et ignore délibérément le détail en dessous. Si le système opérationnel déroule une checklist de cinquante étapes, la couche de statut se moque des étapes onze à dix-neuf. Ce qui l’intéresse : que vous soyez en build, qu’une personne nommée en réponde, et que ce ne soit pas coincé. La granularité vit là où se fait le travail. Le résumé vit là où le dirigeant regarde.
Chaque étape déclare son système
La seconde moitié de la solution, c’est de la documentation, et elle coûte un ordre de grandeur de moins que l’intégration. Reprenez le journey étape par étape et écrivez explicitement dans quel système les gens travaillent à cette étape et ce qu’ils y font.
La majorité de la confusion inter-systèmes n’est pas du tout un problème de donnée. C’est que personne n’a écrit où se fait le travail, donc chacune des deux équipes a supposé que l’autre surveillait. Dès qu’une étape dit « à partir d’ici vous travaillez dans l’outil opérationnel, et la seule chose que le CRM attend de vous est la valeur du jalon », l’ambiguïté disparaît et la synchronisation que vous alliez construire se réduit à un champ.
Ensuite, jouez les forces de chaque plateforme au lieu de les aplatir. Le routage des cas, le ticketing et les e-mails entrants appartiennent au CRM, où cette mécanique existe déjà. L’exécution appartient au système construit pour l’exécution. Acceptez qu’une personne, en général un gatekeeper de routage, travaille sur les deux. C’est un rôle, pas un défaut.
Verrouillez le passage de relais au lieu de le synchroniser
Le passage de relais est l’endroit où la visibilité meurt vraiment, et les preuves sont inhabituellement directes. Un panel SaaStr sur la façon dont les entreprises IA les plus rapides ont reconstruit le customer success désigne le passage de relais comme « the place most failure and data loss happens ». Une des entreprises du panel a sorti le closed-won du sales pour en faire un seuil à l’intérieur de l’implémentation, de sorte qu’un deal signé mais jamais démarré n’était jamais comptabilisé. Leur churn est passé de 4 % par mois à environ un demi-pourcent pendant qu’elles passaient de 8 M$ à 200 M$ d’ARR.
Ce n’est pas une histoire d’intégration. C’est une histoire de définition. Ils ont changé ce que signifie une étape et qui a le droit de la déclarer.
Faites la même chose avec vos gates. Une étape doit avoir des critères d’entrée, et vous n’y entrez pas tant qu’ils ne sont pas remplis. Vous ne confiez jamais un client à une nouvelle équipe tant que l’équipe précédente a des points ouverts, parce que c’est précisément le moment où la responsabilité devient ambiguë et où la visibilité disparaît pour tout le monde au-dessus du travail. Si vous avez des points go/no-go binaires enfouis dans une phase, et la plupart des processus de vérification technique en comptent deux ou trois, promouvez chacun en étape nommée avec son propre owner. Un point de contrôle que personne ne voit est un point de contrôle dont personne ne répond.
Pipelines parallèles, responsabilités parallèles
Pour les équipes où le travail commercial et le travail opérationnel tournent réellement en même temps, une seule pipeline ne tiendra pas. Faites-en deux : une pipeline commerciale et une pipeline opérationnelle qui s’ouvre en parallèle, chacune avec ses propres étapes, toutes deux remontant vers la même couche de statut.
La responsabilité se découpe de la même façon. Sur le compte, portez des champs owner distincts pour la relation commerciale et la relation opérationnelle, plus qui possède l’onboarding et qui possède le compte après la vente. Cela ressemble à plus de champs. Ce sont moins de discussions, parce qu’à tout instant il y a exactement un nom en face de chaque type de question.
À quoi cela a ressemblé sur le terrain
Nous travaillons avec une petite équipe DACH, moins de vingt personnes, qui fait deux choses difficiles en même temps : migrer depuis un CRM historique et construire son propre outil opérationnel interne. Le critère de succès annoncé par le fondateur pour tout le programme : une vue unique montrant où en est chaque projet, du premier lead entrant jusqu’à la mise en exploitation.
La proposition sur la table était de connecter les deux systèmes. Le fondateur a répondu que cela ne suffirait pas, et il avait raison, mais pas pour la raison qu’il croyait. Le problème n’a jamais été que la donnée était à deux endroits. C’était qu’une phase de vérification technique en plusieurs étapes restait invisible pour tous ceux qui n’étaient pas dans l’équipe qui l’exécutait, et que personne n’avait écrit quel système possédait le statut d’un projet à un instant donné.
Ce que nous avons cadré à la place : huit jalons sur l’enregistrement du projet, un champ owner par jalon, un lien en lecture seule depuis l’enregistrement CRM vers l’outil opérationnel pour qui a besoin du détail, et trois points de vérification promus de sous-étapes cachées à étapes nommées. La synchronisation bidirectionnelle est sortie de la roadmap. Coût total : une fraction de l’intégration, et la visibilité que le fondateur demandait arrive en semaines plutôt qu’en un trimestre.
Le playbook
- Écrivez la question d’abord. Obtenez la phrase exacte que le dirigeant veut pouvoir dire, dans ses mots. Chaque décision de design ci-dessous se juge à cette aune.
- Choisissez le domicile du reporting. Un système répond à « où en est-on ». C’est en général le CRM, parce que la vue funnel et le forecast y vivent déjà. Tranchez-le à voix haute.
- Définissez six à dix jalons. Uniquement les transitions structurantes. S’il vous en faut plus de dix, vous décrivez des tâches, pas des jalons.
- Mettez un owner sur chaque jalon. Une personne nommée, et elle change de mains à mesure que le jalon avance.
- Déclarez le système de travail par étape. Une ligne par étape dans le document de journey : ici vous travaillez dans ce système, de cette façon.
- Écrivez les critères d’entrée et faites-les respecter. Pas d’avancement tant que l’étape précédente a des points ouverts. Promouvez chaque go/no-go caché en étape visible.
- Reliez, ne dupliquez pas. Un pointeur en lecture seule d’un enregistrement vers l’autre couvre le cas du détail. Ne synchronisez que la valeur du jalon, et dans un seul sens.
- Relisez chaque semaine à l’aune de l’étape un. Si le dirigeant ne peut toujours pas dire la phrase, c’est la couche qui est fausse, et c’est la couche que vous corrigez, pas l’intégration.
La plupart des équipes bouclent les huit points en deux ou trois semaines. L’intégration qu’elles s’apprêtaient à commander aurait pris un trimestre et n’aurait toujours pas répondu à la question.
Si votre comité de direction demande où en sont les choses et obtient une réponse différente selon la personne interrogée, vous avez un déficit de visibilité par construction, pas un problème d’outillage. Nous pouvons poser la couche de statut sur votre journey existant, ou, si le second système est un CRM que vous quittez de toute façon, commencer par la migration. Dans les deux cas, dites-nous ce que votre dirigeant cherche à voir et nous vous dirons si vous avez besoin d’une intégration.
Sources
- Forrester. « What Salesforce’s Acquisition Of Momentum Means. » Anthony McPartlin, février 2026. forrester.com
- SaaStr. « Lovable, Harvey and Assembly AI: How the Fastest AI Companies Rebuilt Customer Success. » Jason Lemkin, juin 2026. saastr.com