Présentation complète

Volume, en une page

Volume est une plateforme de prospection et de closing B2B unifiée. Elle absorbe deux moteurs historiquement séparés — un moteur de prospection déterministe (détection de marché, scoring de comptes, campagnes validées) et un moteur de qualification/closing (webinar, formulaires notés en 6 dimensions, cockpit de vente) — sous une seule marque, un seul schéma de données, une seule expérience. Cette page documente honnêtement ce qui est construit, comment un utilisateur le vit au quotidien, en quoi c'est différent des outils existants, ce qui manque encore, et son coût réel.

Ce qui est construit

Fonctionnalités déjà en place

Prospecting Engine

  • checkAuth complète (Supabase Auth), onboarding en 6 étapes, diagnostic de maturité déterministe
  • checkMarket Engine : scoring Fit/Intent/Accessibility/Potential, entonnoir Potentiel→Volume recommandé
  • checkSignal Engine : 8 types de signaux, confiance, fraîcheur, source
  • checkProspect Engine : génération procédurale, scoring Fit/Intent/Timing/Qualité, explicabilité complète
  • checkCampaign Engine : machine à états stricte, validation de lancement bloquante, séquences multi-étapes
  • checkCompliance : liste de suppression, exclusion immédiate et permanente d'un contact en opposition
  • checkInbox & Closing Copilot : classification par règles, réponse générée sans jamais inventer de prix
  • checkOpportunités : pipeline Kanban 7 étapes, Intelligence (recommandation d'allocation par segment)

Closing Engine

  • checkProfilage : formulaires de qualification par champ, 2 modèles pré-calibrés, éditeur de champs
  • checkWebinar : inscription publique, page de profilage seul, suivi de présence/engagement réels
  • checkScoring 6D (fit/urgence/engagement/maturité/capacité/comportement), configurable par workspace
  • checkRecommandation d'offre à règles, confiance dérivée du score réel, jamais confondue avec la décision du closer
  • checkAssignation manuelle, par performance, ou round-robin réel (rotation testée unitairement)
  • checkCockpit Closer : file d'attente priorisée, dossier complet, WhatsApp, résultat d'appel → vente réelle
  • checkPipeline Kanban du funnel de closing, valeur du pipeline en temps réel
  • checkAnalytics : revenu par webinar/offre/closer, attribution par source, rentabilité réelle

Transverse

  • checkFacturation réelle : 4 plans, 3 fournisseurs de paiement (Stripe, KKiaPay, FedaPay) + mode dev honnête
  • checkCapacités par plan réellement appliquées (Closing Engine, personnalisation de formulaire, analytics)
  • checkDecision Log : chaque décision significative tracée avec raison et confiance
  • checkSuper Admin : 13 pages (utilisateurs, workspaces, compliance, facturation, logs, demandes de partenariat…)
  • checkHealthcheck public (/api/health) qui vérifie réellement la connexion à la base de données
Comment c'est vécu

Le parcours utilisateur, par rôle

Utilisateur (owner)

  1. 1S'inscrit et décrit son activité
  2. 2Reçoit un marché scoré et l'approuve
  3. 3Reçoit des prospects qualifiés et justifiés
  4. 4Lance une campagne validée par le système
  5. 5Suit ses conversations classifiées automatiquement

Prospect (public, sans compte)

  1. 1S'inscrit à un webinar via un lien public
  2. 2Répond à un formulaire de qualification en quelques minutes
  3. 3Est scoré en 6 dimensions dès sa réponse envoyée
  4. 4Reçoit une recommandation d'offre cohérente avec son profil

Closer

  1. 1Se connecte et voit sa file d'attente priorisée
  2. 2Ouvre le dossier d'un prospect : score, historique, notes
  3. 3Contacte via WhatsApp ou enregistre un appel
  4. 4Enregistre le résultat — une vente crée automatiquement client + facture

Les rôles sont isolés au niveau base de données, pas seulement dans l'interface : un closer ne peut techniquement pas lire ou modifier un prospect qui ne lui est pas assigné, même en contournant l'UI — vérifié par un test automatisé qui tente réellement de le faire.

Pourquoi Volume

Ce qui nous différencie

join_full

Un seul produit, pas deux recollés

Une seule table de prospects traverse tout le cycle, de la détection à la vente. Pas de synchronisation fragile entre deux outils, pas de double saisie.

verified

Explicabilité, pas une boîte noire

Chaque score, chaque recommandation est calculé par un moteur déterministe documenté (poids, seuils, formules commentés) — jamais un LLM qui improvise un chiffre.

lock

Sécurité vérifiée, pas supposée

L'isolation entre workspaces est appliquée par la base de données elle-même (Row Level Security), vérifiée par un test qui crée deux comptes réels et tente réellement de violer la frontière.

payments

Prix calculés, pas choisis au hasard

La grille tarifaire part d'une vraie méthode de coût (TJM, charges de développement, hébergement à l'échelle) et d'un seuil de rentabilité documenté — pas un chiffre rond arbitraire.

visibility

Le mock ne se cache jamais

Ce qui est simulé aujourd'hui (email transactionnel, assistant IA, calendrier) est étiqueté clairement dans l'interface, avec un chemin de remplacement défini — jamais un faux succès silencieux.

science

Testé, pas seulement démontré

85 tests automatisés couvrent les moteurs métier ET l'isolation multi-tenant réelle — pas seulement une démo qui a l'air de marcher une fois.

Sans langue de bois

Ce qui manque encore

Rien de ce qui suit n'est caché derrière une fausse fonctionnalité — chaque lacune est documentée dans le code et dans nos docs internes, avec le chemin de remplacement identifié.

  • removePas de calendrier / prise de rendez-vous réelle — la table existe, aucune interface n'est construite.
  • removePas d'assistant IA réel — la capacité existe au plan Ultimate, aucune intégration branchée dessus.
  • removePas d'import CSV de prospects externes.
  • removeKKiaPay et FedaPay ne sont pas vérifiés contre un vrai compte marchand — implémentés contre la documentation, pas testés en conditions réelles.
  • removePas de gestion d'équipe / invitation de membres depuis l'interface.
  • removeRéordonnancement des questions de formulaire par boutons, pas glisser-déposer (même résultat final).
  • removePas de bascule multi-workspace côté interface (le modèle de données le supporte déjà).
Modèle économique

Coût

Les prix ci-dessous sont ceux réellement appliqués dans l'application (page /facturation, même source de données que cette page) — calculés à partir d'un coût de développement réel (méthode TJM), d'un coût d'hébergement estimé à l'échelle, et d'un seuil de rentabilité visé à 1000 utilisateurs payants, pas choisis au hasard.

Détail complet de la méthode de calcul : page tarifs.

Travaillons ensemble

Nous contacter — devenir partenaire

Investisseur, partenaire commercial, intégrateur technique — ce message arrive directement dans notre file d'attente (visible depuis le Super Admin), pas dans un formulaire qui ne mène nulle part.