La revue trimestrielle des activités comporte une diapositive intitulée « Initiatives en matière d'IA ». Il répertorie une IA SDR que l'équipe marketing a testée au printemps, un module complémentaire de prévision acheté par le CRO après un mauvais trimestre, un score de santé client que l'équipe CS a construit dans une feuille de calcul et un chatbot sur la page de tarification. Chacun était justifié en soi. Lorsqu'on lui demande ce que les quatre ont fait pour gagner de l'argent, la pièce devient silencieuse.
Regardez de plus près et le problème ne vient pas d’un seul outil. L'AI SDR réserve des réunions dans une file d'attente où personne ne travaille pendant deux jours. Le module complémentaire de prévision lit les étapes des transactions que les commerciaux mettent à jour une fois par mois. Le score de santé ne peut pas voir l'utilisation du produit, donc les renouvellements perdus s'affichent toujours en vert. Quatre achats raisonnables, câblés à rien, totalisent un moteur pas plus rapide ni plus précis qu'il ne l'était il y a un an.
L'initiative NANDA du MIT, dans son rapport 2025 « The GenAI Divide », fondé sur des entretiens avec des représentants de 52 organisations, des enquêtes auprès de 153 dirigeants et une revue de plus de 300 initiatives d’IA rendues publiques, a révélé qu'environ 95 % des projets pilotes d'IA générative d'entreprise n'ont que peu ou pas d'impact mesurable sur les profits et les pertes. Plus de la moitié des budgets d’IA générative sont consacrés aux outils de vente et de marketing, mais les retours les plus importants proviennent de l’automatisation du back-office. L’argent circule vers les revenus ; les résultats ne le sont pas.
Enquête McKinsey sur l'état de l'IA 2025 des 1 993 personnes interrogées racontent la même histoire de l’autre côté. Quatre-vingt-huit pour cent des organisations déclarent utiliser régulièrement l'IA dans au moins une fonction commerciale, mais seulement un tiers environ ont commencé à l'étendre à l'ensemble de l'entreprise, seulement 23 % font évoluer les agents d'IA n'importe où, et seulement 39 % signalent un impact sur l'EBIT au niveau de l'entreprise. L'adoption est universelle ; les systèmes qui modifient les chiffres sont rares.
Au sein de l'équipe commerciale, le rapport 2024 State of Sales de Salesforce, une enquête menée auprès de 5 500 professionnels de la vente dans 27 pays, a révélé que les commerciaux consacrent 70 % de leur temps à des tâches non liées à la vente et que seulement 35 % font entièrement confiance aux données de leur organisation. Un autre outil autonome résout rarement ce problème. Décider de quels systèmes le moteur a besoin, comment ils dépendent les uns des autres et lesquels construire en premier.
Diagnostic : pourquoi les équipes commerciales se retrouvent avec des outils plutôt que des systèmes
La plupart des entreprises entre $3M et $30M ARR ne manquent pas de logiciels. Il leur manque une carte. Quatre modèles expliquent pourquoi.
Les outils sont achetés par symptôme et non par système
Un trimestre lent produit un achat prévisionnel. Une alerte au désabonnement produit un score de santé. Un écart dans le pipeline produit un outil sortant. Chaque achat répond à la plainte la plus forte du moment, de sorte que la pile est façonnée par le moment où les problèmes sont devenus visibles plutôt que par leur coût. La fuite la plus coûteuse est souvent la plus discrète, comme les prospects entrants qui attendent un jour pour un premier contact, et elle n'obtient jamais de ligne budgétaire.
Les systèmes sont construits avant les systèmes dont ils dépendent
Une prévision est aussi bonne que le pipeline qui la sous-tend. Un jeu de renouvellement n’est aussi bon que les signaux de désabonnement qui le déclenchent. La qualité d’un rapport de conseil d’administration dépend de celle de chaque système qui l’alimente. Un outil de prévision acheté avant que l’hygiène des transactions ne soit fixée produit un chiffre confiant à partir d’étapes obsolètes, et le conseil d’administration apprend à se méfier des deux. État de la recherche sur le Gartner sur le Sales Operations ont constaté que seuls 45 % des responsables commerciaux et des vendeurs avaient une grande confiance dans l'exactitude des prévisions de leur organisation, et seulement 47 % pensaient que les données de leur organisation étaient de haute qualité (Gartner, 2020). Ces deux chiffres sont liés.
Les domaines ne partagent pas de définition du client
Le marketing suit les prospects, les ventes suivent les opportunités, la réussite des clients suit les comptes et les finances suivent les factures. Chaque domaine achète des outils adaptés à son propre objet, de sorte que chaque outil voit une tranche différente du même client. Estimations Gartner qu'une mauvaise qualité des données coûte aux organisations au moins $12.9 millions par an en moyenne (Gartner, 2020). Dans un moteur de revenus, une grande partie se situe au niveau des coutures, où le résultat d'une équipe est l'apport d'une autre et personne n'a défini ce qui se passe entre elles.
Personne ne possède les coutures
Les revenus fuient le plus au moment des transferts : du responsable au représentant, du SDR au AE, du AE à l'intégration, de l'intégration au renouvellement. Chaque fonction possède sa part de chaque transfert et personne n'est propriétaire du transfert lui-même. Les outils achetés par une fonction héritent de cet angle mort, de sorte que chaque fonction semble bien équipée tandis que le client passe entre les mailles du filet.
Le cadre : le Nine Systems Framework
Le Nine Systems Framework décrit un moteur de revenus entièrement construit sous la forme de neuf systèmes discrets dans quatre domaines. Chaque système a une tâche, répond à une question récurrente et produit un résultat dont dépend au moins un autre système. Un système signifie un logiciel fonctionnel fonctionnant sur vos propres données dans votre propre pile, et non sur une licence ou un document de processus.
| Domaine | Système | La question à laquelle il répond | Cela dépend |
|---|---|---|---|
| GTM Operations | Speed-to-Lead | Chaque prospect entrant qualifié a-t-il reçu une réponse alors qu'il était encore chaud ? | Des règles claires de capture et de routage des leads |
| Handoff Orchestrator | Chaque lead et chaque transaction ont-ils été transférés entre les équipes en fonction de leur contexte et à temps ? | Speed-to-Lead ; définitions d'étape convenues | |
| Signal-Based Outbound Engine | Quels comptes affichent actuellement une intention d’achat et qui devrait agir ? | Un dossier de compte fiable et un profil client idéal | |
| Sales Operations | Pipeline Hygiene Sentinel | Quelles transactions sont périmées, mal organisées ou manquent de ce dont elles ont besoin pour être conclues ? | Handoff Orchestrator ; étapes de transaction cohérentes |
| Forecast Assistant | Que allons-nous réellement clôturer ce trimestre, et pourquoi cela diffère-t-il de l'appel ? | Pipeline Hygiene Sentinel | |
| CS Operations | Churn Signal Watchtower | Quels clients montrent des signes précoces de départ ? | Données d'utilisation, de support et de relation jointes au compte |
| Renewal Radar | Quels renouvellements et extensions nécessitent une action, par qui et quand ? | Churn Signal Watchtower | |
| Revenue Intelligence | Board Report Engine | De quoi le conseil d’administration a-t-il besoin pour ce trimestre, construit à partir de données en direct ? | Chaque système ci-dessus |
| Revenue Answers | Quelle est la réponse à la question qu’un dirigeant vient de poser, sans attendre un analyste ? | Chaque système ci-dessus |
Les dépendances forment trois chaînes et un toit. La chaîne d'acquisition s'étend du Speed-to-Lead au pipeline en passant par le Handoff Orchestrator, le Signal-Based Outbound Engine alimentant le même pipeline du côté sortant. La chaîne de vente s'étend du Pipeline Hygiene Sentinel au Forecast Assistant, car une prévision basée sur un pipeline insalubre est une estimation avec un point décimal. La chaîne de rétention s'étend du Churn Signal Watchtower au Renewal Radar, car un jeu de renouvellement qui démarre sans avertissement précoce commence trop tard. L'intelligence des revenus est le toit : les Board Report Engine et Revenue Answers lisent à partir de tous les autres systèmes et sont aussi précis que le plus faible en dessous d'eux.
Trois règles découlent de la carte. D'abord, construire un système uniquement lorsque ce dont il dépend est suffisamment bon, ou créez d'abord la dépendance. Deuxième, construire là où il y a le plus d'argent qui coule, pas là où il y a le plus de bruit, c'est pourquoi chaque engagement commence par un diagnostic plutôt que par un catalogue. Troisième, construire un système à la fois, testez-le sur votre propre historique et mesurez à nouveau avant de choisir le suivant.
La carte ne prescrit pas un ordre fixe ; une entreprise qui perd la plupart de ses revenus à cause du désabonnement ne devrait pas commencer par le temps de réponse entrant. Mais cela suggère un point de départ typique. Les fuites en amont s'aggravent : un plomb perdu dans la première heure ne devient jamais un pipeline ou un renouvellement. Ainsi, lorsque le diagnostic révèle des fuites d’ampleur similaire dans plusieurs domaines, la chaîne d’acquisition vient généralement en premier, la chaîne de vente en deuxième, la chaîne de rétention à côté ou juste après, et le toit de l’intelligence en dernier. Il s’agit d’un point de départ suggéré, et non d’un point de référence, et le diagnostic l’emporte chaque fois que les chiffres indiquent le contraire.
Un exemple concret
Exemple illustratif, avec des chiffres ronds inventés : une entreprise $12M ARR demande un système de prévision car elle a raté ses deux derniers appels trimestriels. Le diagnostic révèle qu'environ un tiers des opportunités ouvertes n'ont pas changé de stade en 60 jours et que les demandes de démonstration entrantes attendent en moyenne 20 heures pour une première réponse. Un Forecast Assistant construit sur ce pipeline permettrait de prévoir avec précision les accords périmés. La carte indique l'autre direction : le Pipeline Hygiene Sentinel en premier, donc les prévisions indiquent des transactions réelles, et le Speed-to-Lead à côté, car une réponse lente draine le haut du même pipeline. La prévision arrive en troisième position, sur la base de données fiables. Vos chiffres seront différents ; la logique ne le fera pas.
Implémentation : six étapes de la carte au premier système
Les quatre premières étapes sont en lecture seule.
Placez votre pile actuelle sur la carte
Pour chacun des neuf systèmes, notez ce qui existe aujourd'hui : un système fonctionnel, un outil qui fait en partie le travail, un processus manuel ou rien. Soyez strict : un tableau de bord que quelqu'un vérifie lorsqu'il s'en souvient est un processus manuel. Vérifiez : chacune des neuf lignes a un statut et un propriétaire nommé, même si le propriétaire n'est "personne".
Évaluez la fuite derrière chaque espace
Pour chaque ligne qui n'est pas un système fonctionnel, estimez le coût de l'écart chaque année : les prospects qui ne fonctionnent plus, les transactions qui échouent, les renouvellements qui expirent, les heures passées sur des rapports manuels. Une fourchette approximative avec un niveau de confiance déclaré suffit. Vérifiez : chaque écart comporte une estimation en dollars et les preuves qui la sous-tendent.
Vérifiez les dépendances
Pour les écarts les plus coûteux, consultez la colonne « dépend de ». Si la dépendance est faible, la première construction honnête est la dépendance. La plupart des équipes sautent cette étape. Vérifiez : les noms de la liste restreinte, pour chaque système candidat, si ses entrées sont prêtes.
Choisissez un système
Choisissez le système qui colmate la plus grande fuite dont les dépendances sont prêtes. Notez ce qu'il doit faire, quelles données il touche et à quoi ressemble la tâche correcte. Le diagnostiquer avant de créer un playbook parcourt ce diagnostic en lecture seule plus en détail. Vérifiez : un système est choisi, avec une définition écrite du succès.
Construisez-le et testez-le sur votre propre historique
Construisez-le dans votre pile existante et exécutez-le sur des cas antérieurs avant qu'il ne touche les données en direct. Nous soumettons chaque système à la même barre : testé sur une vingtaine de cas antérieurs du client, avec 85 % d'accord et aucune action dangereuse non détectée, sinon il n'est pas expédié. Vérifiez : les résultats des tests sont notés au cas par cas et le système a franchi la barre avant la mise en ligne.
Re-mesurer, puis revenir à la carte
Après un cycle complet, réévaluez la fuite que le système a été conçu pour fermer. Revenez ensuite à la deuxième étape, car la fermeture d’une fuite modifie la taille ou l’état de préparation de la suivante. Vérifiez : le chiffre avant et après est indiqué et le système suivant est choisi à partir de nouveaux chiffres plutôt que de la liste d'origine.
Workflow : comment un système passe du diagnostic à la production
Chaque système suit le même chemin dans le moteur. Un flux de travail suggéré :
Ce qui se produit: un examen en lecture seule des données du CRM, de l'automatisation du marketing, des produits et du support place l'entreprise sur la carte des neuf systèmes et évalue chaque écart en dollars.
Rôle système : remplacez les avis par une liste classée des fuites et des systèmes qui les ferment.
Propriétaire: le CRO ou le fondateur le parraine ; RevOps fournit un accès et un contexte.
Ce qui se produit: la liste classée est vérifiée par rapport à la carte des dépendances et un système est choisi car il colmate la plus grande fuite dont les entrées sont prêtes.
Rôle système : empêcher de construire un système sur des données auxquelles il ne peut pas faire confiance.
Propriétaire: l'équipe de direction des revenus accepte la commande ; La finance est d’accord sur les estimations des fuites.
Ce qui se produit: le système est construit à l'intérieur de la pile existante et testé par rapport aux cas passés de l'entreprise avant sa mise en service.
Rôle système : montrent, sur la base de l’histoire réelle, que le système prend la bonne décision assez souvent pour faire confiance à la production.
Propriétaire: les ingénieurs qui le construisent, avec un propriétaire exploitant nommé côté client qui signe le test.
Ce qui se produit: le système fonctionne en production, ses résultats sont rapportés chaque trimestre par rapport à la fuite pour laquelle il a été construit et la carte est mise à jour.
Rôle système : gardez la carte comme un plan vivant, et non comme une recommandation ponctuelle.
Propriétaire: le propriétaire exploitant rend compte des résultats ; RevOps maintient la carte à jour.
Le récit du conseil d'administration
Les conseils d’administration ont besoin de trois déclarations, pas de neuf systèmes.
Nous avons arrêté d’acheter des outils d’IA problème après problème. Nous planifions désormais notre moteur de revenus en neuf systèmes dans quatre domaines, savons lesquels d'entre eux nous possédons et lesquels nous manquent, et avons chiffré chaque écart en dollars.
Les systèmes dépendent les uns des autres. Construire dans le bon ordre signifie que chaque nouveau système fonctionne sur des données auxquelles il peut faire confiance, de sorte que nos dépenses sont consacrées aux résultats plutôt qu'à un autre projet pilote que personne n'utilise après l'essai.
Chaque système a été testé sur notre propre historique avant sa mise en service, et chaque trimestre, nous signalons la fuite pour laquelle il a été conçu, avant et après. La carte montre quel système vient ensuite et pourquoi.
Inter-domaine : comment les neuf systèmes se connectent
Les domaines sont un moyen d'organiser la propriété, pas des murs. Dans GTM Operations, Speed-to-Lead, Handoff Orchestrator et Signal-Based Outbound Engine décident de la part de la demande que vous payez qui devient pipeline. Dans Sales Operations, le Pipeline Hygiene Sentinel et le Forecast Assistant décident si ce pipeline est réel et quelle partie sera fermée. Dans CS Operations, les Churn Signal Watchtower et Renewal Radar décident quelle part des revenus que vous avez gagnés vous conservez et augmentez. Dans Revenue Intelligence, les Board Report Engine et Revenue Answers transforment tout ce qui précède en décisions.
Ce sont les coutures qui comptent le plus. Le Handoff Orchestrator relie le marketing aux ventes et les ventes à l'intégration. Le Churn Signal Watchtower devrait renvoyer le contexte au Signal-Based Outbound Engine, afin que l'équipe arrête de prospecter des sosies de clients qui partent. Un système qui améliore un domaine améliore généralement les entrées d'un autre, c'est pourquoi un bon séquençage des composés.
Si vous décidez qui doit construire ces systèmes, le Arbre de décision ingénieur GTM vs manager RevOps vs ingénieur de croissance couvre le côté embauche. Si vous décidez comment, c'est le cœur de ingénierie déployée vers l'avant pour les équipes commerciales : des ingénieurs travaillant au sein de votre pile, un système à la fois, chacun éprouvé sur vos propres données. Les recherches du MIT vont dans la même direction : les partenariats externes ont eu un taux de réussite environ deux fois supérieur aux constructions internes (MIT NANDA, 2025). Voir les neuf systèmes en un seul endroit.
Sources : MIT NANDA, La fracture GenAI : état de l’IA dans les entreprises 2025 (2025 ; copie du rapport hébergée par Valtao). McKinsey & Company, L’état de l’IA en 2025 : agents, innovation et transformation (2025 ; 1 993 répondants). Salesforce, État des ventes, 6e édition (juillet 2024 ; 5 500 commerciaux dans 27 pays). Gartner, Enquête sur l’état de Sales Operations (février 2020), et recherche sur la qualité des données (2020). Le Nine Systems Framework, sa carte de dépendances, le séquençage suggéré et l'exemple travaillé constituent le cadre du VANDFORT, les points de départ suggérés et les figures illustratives, et non des références.
