Pilocom — probabilité de closing et pilotage commercial

Problème

Le CRM répond à « qu'avons-nous fait ? », mais pas à « qu'allons-nous signer, et que faut-il faire pour atteindre l'objectif ? ». Un pipeline bien tenu ne suffit pas à savoir si l'objectif de chiffre d'affaires sera atteint : il manquait une estimation crédible de la probabilité de gagner chaque affaire et une traduction de l'objectif annuel en volumes d'activité à produire chaque mois (pistes, rendez-vous, offres).

Mon rôle

Développement front-end, back-end (Laravel) et base de données (MySQL), comme sur la majorité de mes projets. Module construit comme une extension isolée du CRM (découpage Core / Suivi / Pilotage communiquant par événements), reprenant et fiabilisant les mécanismes d'un prototype Excel existant ("PILOCOM").

Architecture

Back-end Laravel partagé avec le CRM, découpé en modules isolés qui ne communiquent que par événements explicites (ex. passage d'une piste au statut "En cours" → déclenche le calcul de la probabilité de base). Base de données MySQL unique ; le module Pilotage ne crée que ses propres tables (barèmes, scores, hypothèses, objectifs) et référence les clés du CRM sans dupliquer de données.

Résultats

• Modèle de probabilité à deux barèmes (grille d'entrée à 9 étapes selon le niveau d'engagement du prospect, grille de scoring sur 100 points) combinés pour calculer une probabilité de gain ajustée en continu.
• Cascade qui traduit un objectif de chiffre d'affaires en volumes requis : affaires à signer, offres à émettre, pipeline à constituer, rendez-vous à tenir, pistes à ouvrir — avec suivi mensuel des écarts entre réalisé et requis.
• [À COMPLÉTER — impact mesuré une fois le module utilisé en production. N'inventer aucun chiffre.]

Difficultés et leçons

Le prototype Excel calculait le nombre de rendez-vous requis en divisant les offres par le taux de closing au lieu d'appliquer un taux de conversion rendez-vous → offre, ce qui multipliait l'effort requis par quatre au lieu de le doubler (jusqu'à 336 rendez-vous estimés pour une seule ligne d'offre, au lieu d'environ 84). Reprendre la cascade en raisonnant sur un nombre moyen de rendez-vous observable par offre a corrigé le calcul et rendu l'indicateur exploitable par les commerciaux.

Liens

• [À COMPLÉTER — captures anonymisées, sans nom de client ni donnée réelle]