Schéma de pipeline de ventes pour fondateurs B2B : champs minimaux, étapes et suivi d'activité pour prévoir clairement et faire avancer les deals sans surcharge CRM.
Au début, votre pipeline paraît clair parce qu'il y a peu de deals et que la plupart du contexte vit dans votre tête. Puis la liste s'allonge, vous manquez un suivi, et le pipeline commence à raconter une histoire plus flatteuse que la réalité. C'est le « mensonge du pipeline » : pas volontaire, mais parce que rien dans le système n'oblige à dire la vérité.
Ça se manifeste par les mêmes schémas :
La réaction fréquente est de surcharger le CRM : plus de champs, plus d'étapes personnalisées, des notes plus longues. Ironiquement, cela aggrave souvent la prévision. Quand la mise à jour devient lourde, les gens mettent à jour moins, et le pipeline pourrit tranquillement.
Un schéma de pipeline commercial minimum viable fait l'inverse. C'est juste assez de structure pour prendre des décisions. Il n'essaie pas de tout capturer. Il capture les quelques faits qui vous empêchent de vous mentir à vous-même.
Si vous n'appliquez qu'une règle, retenez celle-ci : chaque deal ouvert doit avoir (1) une prochaine action explicite, (2) une date pour cette action, et (3) une date de clôture liée à un véritable calendrier acheteur (une réunion, une étape juridique, une revue budgétaire). Si l'un de ces éléments manque, le deal n'est pas actif.
Les étapes doivent aussi signifier quelque chose. Un deal n'avance que lorsqu'il s'est passé quelque chose de concret, pas parce que ça fait plaisir. L'objectif n'est pas un joli tableau de bord. L'objectif est une vue honnête sur laquelle vous pouvez piloter l'entreprise.
Un schéma de pipeline ne fonctionne que si tout le monde l'utilise de la même manière. Avant d'ajouter des champs ou de débattre des étapes, décidez ce que représente un élément de pipeline.
Un défaut propre pour le B2B : un deal = une décision d'achat. Si la même entreprise peut acheter deux fois (deux équipes, deux produits, deux budgets), ce sont deux deals, pas un enregistrement confus.
Gardez les objets simples. Trois catégories suffisent souvent : un lead (une personne joignable), un account (l'entreprise), et un deal (l'achat spécifique que vous essayez de conclure). Si vous êtes en solo, vous pouvez même zapper les enregistrements formels de lead et d'account et simplement veiller à ce que chaque deal nomme clairement l'entreprise et le contact principal.
Rédigez quelques règles opérationnelles, surtout si d'autres personnes touchent au pipeline :
Exemple : vous parlez à Alex chez Northwind d'un pilote pour l'équipe finance. C'est un deal. Si un mois plus tard le produit veut un contrat séparé, créez un deuxième deal. Ne forcez pas un seul enregistrement à couvrir deux décisions.
Un pipeline reste utile quand chaque deal a les quelques champs que vous vérifiez chaque semaine. Ajoutez des champs « au cas où » et ils deviennent décoratifs.
Commencez par un format de nom de deal qui empêche les doublons. Un modèle simple fonctionne : Entreprise - Produit/Portée - Trimestre/Mois. Exemple : “Acme - Team plan - Mar 2026.” Cela rend évident quand “Acme - Demo” et “Acme - Follow-up” sont en fait le même deal.
Chaque deal a aussi besoin d'une identité claire :
Le rôle compte car il change ce que vous faites ensuite. Un champion a besoin d'accompagnement. Un décideur a besoin d'un cas business.
Ajoutez des champs de responsabilité :
Ensuite ajoutez seulement l'argent et le timing que vous allez utiliser :
Si vous hésitez sur un champ, laissez-le de côté. Vous pouvez toujours l'ajouter plus tard. Supprimer des champs après que des habitudes se sont formées est beaucoup plus difficile.
La plupart des pipelines « importants » ne le sont pas. Ils sont pleins de deals jolis sur le papier mais sans chemin clair vers un oui.
Commencez par un champ qui force la clarté : Cas d'usage (portée). Écrivez ce que l'acheteur cherche à accomplir en termes simples, plus ce à quoi ressemble le « terminé ». Si vous ne pouvez pas décrire le résultat en deux phrases, vous ne comprenez probablement pas encore le deal.
Ensuite, capturez le processus décisionnel en un seul endroit. Ce n'est pas une addition de contacts. C'est l'histoire de comment la décision se fait : qui signe, qui peut bloquer, et quelles étapes doivent être suivies (revue sécurité, juridique, achats). Si vous ne connaissez pas le signataire, traitez le deal comme précoce.
Ajoutez un signal d'adéquation prix même approximatif. Des plages (“< $5k”, “$5-25k”, “$25k+”) fonctionnent bien, ou un simple Likely / Unclear / Unlikely basé sur ce que vous avez entendu. Le but est d'arrêter l'avancement des deals qui ne peuvent pas se permettre votre offre.
Enfin, gardez un champ red flags (drapeaux rouges) sur une ligne. Si ça prend un paragraphe, ça appartient aux notes.
Un ensemble compact qui marche pour la plupart des fondateurs B2B :
Exemple : “Veut nettoyage du CRM avant renouvellement, signataire = VP Sales, revue sécurité requise, budget probable $10-20k, concurrent = ne rien faire, red flag : le champion ne gère pas le projet.” Cet unique enregistrement est plus difficile à s'auto-illusionner.
Un pipeline se gâte quand il devient une liste de souhaits. La solution n'est pas plus de champs. C'est quelques signaux d'activité qui forcent chaque deal à répondre à une question : que se passe-t-il ensuite ?
Si vous n'ajoutez qu'une couche à votre schéma de pipeline, adoptez ces champs d'activité :
Règle pratique : si un deal n'a ni prochaine étape ni date d'échéance, ce n'est pas un vrai deal. Mettez-le en pause ou clôturez-le. Cela améliore plus la précision des prévisions que n'importe quel modèle de scoring.
Gardez “Raison de perte” courte pour que vous l'utilisiez vraiment : prix, pas de budget, pas de décision, a choisi un concurrent, timing, pas adapté.
À quoi ça ressemble : vous avez une démo avec un responsable ops mardi. Juste après l'appel vous mettez date de dernière activité = mardi, dernier canal = réunion, prochaine étape = “Envoyer 2 études de cas et confirmer qui signe,” date d'échéance = jeudi. Si jeudi passe sans réponse, le deal passe en rouge sans que personne ne discute de « progression du pipeline ».
Un bon modèle d'étapes fait un travail : il dit la vérité sur l'endroit où se trouve chaque deal, sans vous faire micro-gérer une douzaine de petits pas. Si vous ne pouvez pas dire ce qui doit être vrai pour qu'un deal soit dans une étape, l'étape devient une impression.
Ce modèle en six étapes marche pour la plupart des fondateurs B2B :
New : Vous avez un nom et une raison de contacter. Le premier contact est fait ou planifié.
Qualified : L'adéquation de base est confirmée. Le problème est réel, le client correspond à votre ICP, et il y a un chemin plausible vers l'achat.
Discovery done : Vous avez eu une vraie conversation. Vous comprenez le cas d'usage, les critères de succès et qui est impliqué.
Proposal sent : Le pricing et la portée sont entre les mains du client. Une prochaine étape est bookée ou explicitement demandée.
Negotiation/Legal : Achats, sécurité, approbation budgétaire ou modifications contractuelles sont en cours.
Closed won / Closed lost : Le résultat est marqué et une raison est enregistrée.
Faites avancer un deal uniquement quand quelque chose s'est produit dans le monde réel (réunion complétée, proposition envoyée, juridique engagé). Si rien ne s'est passé, l'étape reste la même.
Un nom d'étape n'est pas une définition d'étape. Si vous étiquetez juste une colonne « Qualified » ou « Negotiation », vous vous retrouverez avec des deals qui y restent parce que personne n'est d'accord sur ce que « fait » veut dire.
Rédigez les règles d'étape comme de simples vérifications vrai/faux. Quand chaque deal dans une étape partage les mêmes faits, votre pipeline reste fiable.
Le critère d'entrée dit ce qui doit déjà être vrai avant qu'un deal entre dans une étape. Le critère de sortie dit ce qui doit changer avant qu'il avance. Gardez les deux courts et mesurables.
Exemples :
Si vous ne pouvez pas écrire des critères sans mots comme « bon », « solide » ou « intéressé », l'étape est trop floue.
Fixez un âge maximal pour chaque étape comme alerte précoce, pas comme punition. Exemple : Discovery max 14 jours, Proposal max 21 jours. Quand un deal atteint la limite, déclenchez une réinitialisation : réservez une prochaine étape, reculez-le, ou clôturez-le.
Décidez de l'action par défaut quand les critères ne sont pas remplis :
Ça empêche les “deals zombies” de gonfler votre forecast.
Vous pouvez construire un schéma de pipeline en quelques heures si vous le traitez comme un petit produit : règles d'abord, puis seulement ce qui soutient ces règles.
Commencez sur une page blanche, pas à l'intérieur d'un outil. Rédigez vos étapes et critères d'entrée/sortie en anglais simple. Si vous ne pouvez pas expliquer une étape en une phrase, c'est probablement deux étapes (ou pas une étape du tout).
Un flux de construction simple :
Faites un test réaliste lors de la mise en place : prenez un deal actif et essayez de le faire avancer étape par étape. Si vous devinez sans cesse, vos critères sont trop vagues.
Une règle à appliquer tôt : si la date de la prochaine activité est vide, le deal ne peut pas rester dans une étape active.
La plupart de la surcharge CRM vient de bonnes intentions : vous voulez plus d'exactitude, alors vous ajoutez plus de champs, plus d'étapes, et plus de prise de notes. Le résultat est l'inverse. Les gens arrêtent de mettre à jour, et votre pipeline devient un cimetière.
Si deux étapes se ressemblent, elles seront utilisées de la même façon. « Discovery », « Deep discovery » et « Discovery follow-up » signifient souvent « on a parlé », sans événement clair suivant. Les étapes ne doivent changer que lorsqu'un fait concret change.
Test rapide : si vous ne pouvez pas dire en une phrase ce qui doit être vrai pour entrer dans une étape, l'étape est probablement superflue.
La date de clôture n'est utile que si elle est liée à une raison. Traitez-la comme la date du prochain point de décision (approbation budgétaire, réunion achats, date de signature), et déplacez-la quand cet événement bouge.
Les longues notes cachent l'essentiel : ce qui s'est passé en dernier, et ce qui se passe ensuite. Gardez les notes courtes et suivez l'activité avec la date de dernière activité plus la prochaine étape (avec un propriétaire et une date d'échéance).
Sans définition, « qualified » devient « ils avaient l'air sympa ». Choisissez 3 à 4 vérifications qui doivent être vraies (problème, acheteur, calendrier, et une forme de budget). Si l'une manque, ce n'est pas encore qualifié.
Les pipelines qui ne font que croître cessent d'être un pipeline et deviennent un cimetière. Fermez rapidement les lost quand le deal est inactif ou mal adapté, et capturez une raison claire pour pouvoir en tirer des enseignements.
Choisissez un créneau chaque semaine (30 minutes suffisent) et traitez-le comme une réunion avec votre futur vous. L'hygiène du pipeline, ce n'est pas ajouter des champs, c'est vérifier que chaque deal a encore un chemin réel devant lui.
Un flux de revue simple :
Exemple concret : si un deal est marqué « Proposal sent » mais qu'aucune réunion n'est prévue pour en discuter, ce n'est pas un deal en stade proposition. Reculez-le, fixez la prochaine étape, et cessez de le compter tant que l'acheteur n'est pas de nouveau engagé.
Vous vendez un outil d'analytics B2B à une boîte e‑commerce de 50 personnes. Après le premier appel, vous créez un deal et ne remplissez que ce que vous utiliserez la semaine suivante. Un schéma simple paie ici parce qu'il force la clarté, pas la paperasserie.
Juste après l'appel, l'enregistrement ressemble à :
Le deal commence en Discovery. Vous le faites avancer seulement quand l'invitation calendrier est acceptée (pas quand quelqu'un « a l'air intéressé »). Après la démo, le déclencheur pour passer en évaluation est une demande concrète (par exemple, “Pouvez-vous vous connecter à Shopify et à nos données d'entrepôt ?”), suivie d'une vérification technique convenue.
Puis le blocage : le CFO se tait après la tarification. Votre journal montre deux relances, aucune réponse, et la date de prochaine étape passe. La règle est simple : si la prochaine étape n'est pas convenue, le deal ne peut pas rester en Proposal.
Vous faites donc un mouvement honnête : soit reculer en évaluation (si vous avez besoin d'un nouveau sponsor ou d'infos manquantes), soit clôturer lost (si le décideur n'engage pas d'ici une date fixée). Dans cet exemple, vous reculez, mettez à jour les parties prenantes (Ops implique le manager finance), fixez une nouvelle date de prochaine étape, et ne revenez en Proposal que lorsque le CFO confirme une réunion de décision.
Un schéma de pipeline ne fonctionne que si vous lui faites confiance. Le moyen le plus rapide d'y arriver est de commencer minimal et d'en vivre pendant 30 jours. Cela vous montre ce que vous utilisez vraiment, pas ce que vous pensez pouvoir avoir besoin.
Pour le premier mois, soyez strict : si un champ ne change pas une décision, retirez-le. Si une décision revient souvent et que vous ne pouvez pas y répondre depuis le pipeline, ajoutez exactement un champ pour combler ce manque.
Un test simple avant d'ajouter un nouveau champ : « Si c'est vide, on ne peut pas décider de ___ ».
Si vous voulez construire un CRM léger et personnalisé au lieu d'imposer un générique, des outils comme Koder.ai (koder.ai) peuvent aider une fois que vous avez rédigé vos étapes, champs requis et règles de validation. Il est bien plus facile de générer et d'itérer une appli simple quand le schéma est clair.
Un pipeline « qui ment » montre des progrès qui ne sont pas soutenus par des actions réelles de l'acheteur. Les causes les plus fréquentes sont l'absence de prochaine étape, des dates de dernière activité dépassées et des dates de clôture repoussées sans un calendrier confirmé par l'acheteur.
Rendez trois champs non négociables pour chaque deal ouvert : une action concrète suivante, une date d'échéance pour cette action, et une date de clôture liée à un événement réel de l'acheteur (réunion, revue, signature). Si l'un d'eux est vide, traitez le deal comme inactif jusqu'à ce qu'il soit rempli.
Par défaut, un deal = une décision d'achat. Si la même entreprise peut acheter deux fois via des équipes, budgets ou contrats différents, créez des deals séparés pour ne pas mélanger des timelines et des parties prenantes.
Commencez par un format de nom de deal qui évite les doublons, une entreprise, un contact principal, un propriétaire, une valeur attendue, une date de clôture cible et une source claire. Ajoutez ensuite juste assez de qualification pour expliquer pourquoi il devrait se conclure : cas d'usage, processus décisionnel, et adéquation tarifaire.
Une phrase décrivant le cas d'usage et les critères de succès vous force à comprendre le résultat, pas seulement l'intérêt de l'acheteur. Si vous ne pouvez pas décrire clairement le résultat, le deal est généralement trop prématuré pour être prédit.
Rédigez-le comme une courte histoire sur la manière dont la décision est prise : qui signe, qui peut bloquer, et quelles étapes doivent avoir lieu (sécurité, juridique, achats). Si vous ne connaissez pas encore le signataire, maintenez le deal en stade précoce et faites de la prochaine étape la recherche de cette personne et de ce processus.
Utilisez une fourchette approximative ou un simple Likely/Unclear/Unlikely basé sur ce que vous avez entendu. Le but n'est pas un calcul parfait, mais d'empêcher l'avancement de deals où le budget réel ne correspond pas à votre offre.
Suivez la date de dernière activité, la prochaine étape, la date d'échéance de la prochaine étape, et une raison de clôture quand le deal se termine. Les notes peuvent exister, mais ce sont ces champs d'activité qui empêchent les deals de dériver et qui vous forcent à décider de la suite.
Faites avancer les étapes seulement lorsqu'un événement réel s'est produit : appel de découverte complété, proposition envoyée, ou service juridique introduit. Si un changement d'étape peut se faire parce que vous « vous sentez bien », les définitions d'étape sont trop floues et votre forecast dérivera.
Fixez un nombre maximal de jours pour chaque étape comme alerte précoce, puis déclenchez une remise à zéro quand la limite est atteinte. L'action par défaut : soit planifier une prochaine étape réelle, soit renvoyer le deal à l'étape précédente qui correspond aux faits, soit le clôturer comme « pas de décision » après des tentatives de suivi claires.
