Le POC (Proof of Concept) est l'étape la plus dangereuse du cycle de vente deeptech B2B. La majorité des startups deeptech qui perdent un deal ne le perdent pas au premier rendez-vous. Elles le perdent après le POC. Le scénario est toujours le même : 3 mois de travail technique gratuit, un résultat que tout le monde trouve "très intéressant", et puis... rien. Le prospect passe à autre chose. Le "POC éternel" est la première cause de mortalité commerciale en deeptech.
Ce guide vous donne un framework concret pour structurer un POC qui convertit en contrat. Il s'appuie sur des résultats terrain : avec Parcoor (cybersécurité médicale), 2 POCs ont été convertis en 100 licences pilote en appliquant cette méthode. Avec Dynalight (API Management), le taux de réponse a été multiplié par 10 en amont, ce qui a permis de ne lancer des POCs qu'avec des prospects réellement engagés.
Pourquoi les POCs deeptech échouent
Après avoir accompagné des dizaines de cycles de vente deeptech, le constat est clair : les POCs qui échouent partagent toujours les mêmes 3 défauts. Ce ne sont pas des problèmes techniques. Ce sont des problèmes commerciaux.
Défaut 1 : Pas de critères de succès définis
Le POC démarre avec un objectif vague : "tester la solution" ou "voir si ça marche dans notre environnement." Sans critères de succès mesurables et validés par les deux parties avant le lancement, personne ne sait ce qui constitue une réussite. Le POC se termine avec un "c'est prometteur, on va réfléchir" qui ne débouche sur rien.
Exemple concret : un POC en cybersécurité médicale peut avoir comme critère vague "évaluer la détection des vulnérabilités" ou comme critère précis "détecter au moins 80% des vulnérabilités connues sur un panel de 50 dispositifs médicaux en 4 semaines, avec un temps de scan inférieur à 10 minutes par appareil." La deuxième formulation permet un verdict binaire : réussi ou non.
Défaut 2 : Pas de budget prévu pour la suite
Le POC est gratuit. Tout le monde est content. Mais personne n'a prévu de ligne budgétaire pour le contrat. Quand le POC est concluant, le champion interne se retrouve à devoir demander un budget qui n'existe pas. Résultat : 6 mois d'attente pour le prochain exercice budgétaire, et entre-temps le projet perd sa priorité.
La question du budget doit être posée avant le POC, pas après. Pas sous forme de "combien êtes-vous prêt à payer" (trop agressif à ce stade), mais sous forme de "pour que ce POC ait du sens, il faut qu'il existe un chemin vers un déploiement. Quel serait le processus budgétaire si les résultats sont positifs ?"
Défaut 3 : Pas de sponsor interne identifié
Vous avez un contact technique enthousiaste qui adore votre solution. Mais il n'a pas le pouvoir de décision budgétaire. Quand le POC se termine, il ne peut pas porter le projet en interne. Il envoie un email à son N+1, qui le transmet au CFO, qui le met dans une pile de demandes. Sans un sponsor interne avec le pouvoir (ou au moins l'accès) de débloquer un budget, le POC meurt dans l'indifférence organisationnelle.
Un POC sans critères de succès, sans budget identifié et sans sponsor interne n'est pas un POC. C'est une démo gratuite déguisée.
Les 3 types de POC en deeptech B2B
Tous les POCs ne se valent pas. Le format que vous choisissez dépend de votre stade, de votre position de force, et de l'engagement que vous pouvez demander au prospect.
| Type | Quand l'utiliser | Durée | Risque |
|---|---|---|---|
| POC gratuit | Zéro référence, besoin d'une première preuve | 4-6 semaines max | Élevé (pas d'engagement client) |
| POC payant | 1-2 références existantes, filtrer les sérieux | 4-8 semaines | Modéré (engagement financier = sérieux) |
| POC equity | Partenariat stratégique, cible premium unique | 2-3 mois | Variable (alignement long terme) |
Le POC gratuit : votre arme de première référence
Quand vous n'avez aucune référence, un POC gratuit est souvent le seul moyen de mettre un pied chez un client. Le piège : le faire durer trop longtemps et sans cadre. Un POC gratuit doit être limité à 4-6 semaines, avec des critères de succès stricts et un engagement du client sur le temps de ses équipes.
La règle : un POC gratuit n'est acceptable que si le client s'engage aussi. Engagement de temps (une personne dédiée côté client, un créneau hebdomadaire de suivi), engagement d'accès (données, environnement de test), engagement de décision (un rendez-vous de bilan avec le décideur budgétaire à la fin).
Le POC payant : le filtre de sérieux
Un POC payant entre 1 000 et 5 000 euros ne couvre pas vos coûts. Ce n'est pas son objectif. Son objectif est de filtrer les prospects sérieux des curieux. Un prospect qui accepte de payer, même un montant symbolique, a validé en interne que le sujet est une priorité. Il a déjà franchi une barrière psychologique et administrative.
Dès que vous avez 1-2 références, passez au POC payant. Votre discours : "On a déjà prouvé que ça marche chez X et Y. Le POC est à 3 000 euros, déductible du contrat annuel si vous signez dans les 3 mois suivant la fin du POC."
Le POC equity : le cas rare
Le POC en échange d'equity (ou de conditions commerciales très avantageuses sur 3-5 ans) se justifie dans un seul cas : un partenariat stratégique avec une entreprise qui va devenir votre référence phare et votre canal de distribution. C'est un pari calculé. Vous donnez beaucoup en échange d'une position de marché. A ne pas utiliser avec un prospect classique.
Framework pour structurer un POC qui convertit
Un POC qui convertit n'est pas un POC techniquement réussi. C'est un POC dont la conversion a été préparée avant même le premier jour de test. Voici les 4 éléments à cadrer avant le lancement.
1. Critères de succès mesurables
Avant le jour 1, vous devez avoir un document signé (ou au minimum validé par email) qui liste les critères de succès du POC. Chaque critère doit être :
- Mesurable : un chiffre, un pourcentage, un temps
- Validé par le client : pas juste par votre interlocuteur technique, mais par le décideur
- Binaire : atteint ou non, pas "plutôt satisfaisant"
- Limité : 3 à 5 critères maximum, pas 15
Exemple Parcoor : pour le POC en cybersécurité médicale, les critères étaient : (1) détecter 80%+ des vulnérabilités connues sur le panel de test, (2) temps de scan inférieur à 10 minutes par dispositif, (3) zéro interruption de service sur les appareils scannés, (4) rapport exploitable par l'équipe biomédicale sans formation supplémentaire.
2. Timeline avec checkpoints
Un POC sans checkpoint intermédiaire est un POC qui dérive. La timeline idéale pour un POC deeptech de 6 semaines :
- Semaine 1 : installation, configuration, accès aux données de test
- Semaine 2-3 : premiers résultats, checkpoint technique avec l'équipe client
- Semaine 4 : résultats intermédiaires, ajustements, checkpoint avec le sponsor
- Semaine 5 : résultats finaux, préparation du bilan
- Semaine 6 : bilan formel avec le comité de décision, discussion de la suite
Chaque checkpoint est un rendez-vous planifié à l'avance (pas "on se recontacte quand c'est prêt"). Le checkpoint de la semaine 4 avec le sponsor est le plus important : c'est là que vous préparez le terrain pour le bilan final.
3. Engagement client formalisé
Le client doit s'engager sur des ressources avant le lancement. Pas un engagement vague ("on vous donnera accès"). Un engagement précis :
- Une personne référente côté client, disponible 2h par semaine pendant le POC
- Un accès technique à l'environnement de test, livré avant le jour 1
- Un créneau hebdomadaire de 30 minutes pour les checkpoints
- Un rendez-vous de bilan planifié dès le départ avec le décideur budgétaire
Si le client refuse de s'engager sur ces éléments, c'est un signal fort : le projet n'est pas une priorité. Mieux vaut ne pas lancer un POC voué à l'échec que d'investir 6 semaines pour rien.
4. Plan de conversion documenté
Avant le POC, vous devez connaître les réponses à 4 questions :
- Qui décide ? Nom et fonction du décideur final (pas juste "le comité")
- Quel budget ? Existe-t-il une ligne budgétaire ? Quel est le processus d'approbation ?
- Quel calendrier ? Quand le budget est-il disponible ? Y a-t-il une date limite ?
- Quels concurrents ? Etes-vous en compétition ? Avec qui ? Sur quels critères ?
Ces questions ne se posent pas au premier rendez-vous. Elles se posent entre le moment ou le prospect accepte le principe du POC et le moment ou le POC démarre. C'est la fenêtre parfaite : le prospect a dit oui au POC, il est dans une dynamique positive, il accepte de partager ces informations.
Comment impliquer le bon comité de décision dès le POC
En deeptech B2B, un achat implique typiquement 3 à 7 décideurs. Si vous ne parlez qu'au champion technique pendant tout le POC, vous allez produire un résultat technique excellent que personne d'autre dans l'organisation ne comprend. Voici comment impliquer les bonnes personnes aux bons moments.
Cartographier le comité avant le POC
Demandez à votre champion technique : "Si les résultats du POC sont positifs, qui sera impliqué dans la décision d'achat ?" Vous devez identifier au minimum :
- Le champion technique (votre contact principal, celui qui valide la solution)
- Le sponsor business (VP Ops, COO, celui qui porte le projet auprès de la direction)
- Le décideur budget (CFO, CEO, celui qui signe le bon de commande)
- Le bloqueur potentiel (procurement, juridique, sécurité, celui qui peut dire non)
Adapter le message à chaque profil
Le champion technique veut une preuve que ça marche. Le sponsor business veut un impact opérationnel chiffré. Le décideur budget veut un ROI. Le bloqueur potentiel veut la certitude que ça ne va pas créer de problème.
Votre bilan de POC doit avoir 4 sections, une pour chaque profil. Pas un rapport technique de 30 pages que seul le CTO va lire. Un document de 5 pages avec :
- Résumé exécutif (1 page) : résultats vs critères, recommandation, prochaines étapes
- Résultats techniques (1 page) : pour le champion technique
- Impact business (1 page) : métriques opérationnelles, projection de ROI, pour le sponsor
- Conditions de déploiement (1 page) : sécurité, conformité, intégration SI, pour le bloqueur
Inclure le sponsor au checkpoint de mi-parcours
Le sponsor business ne doit pas découvrir les résultats au bilan final. Il doit être impliqué au checkpoint de mi-parcours (semaine 3-4). A ce stade, vous avez des résultats intermédiaires encourageants. C'est le moment de dire : "Voici ce qu'on observe. Si ça se confirme, voici ce que ça signifie en termes d'impact opérationnel. Comment est-ce qu'on prépare la suite ?"
Ce rendez-vous de mi-parcours transforme le sponsor d'observateur passif en co-constructeur du projet. Quand il arrive au bilan final, il a déjà commencé à préparer le terrain en interne.
De la référence au contrat : industrialiser le closing
Un POC réussi n'est pas un contrat signé. C'est le début de la phase de closing. Voici comment accélérer la conversion et éviter que le deal ne stagne après un POC positif.
Transformer le bilan en proposition commerciale
Le bilan de POC et la proposition commerciale doivent être présentés dans le même rendez-vous. Pas "on vous envoie le bilan, puis on planifie un autre call pour la proposition." Le bilan crée le momentum. La proposition capitalise sur ce momentum. Si vous laissez passer 2 semaines entre les deux, le momentum disparait.
Concrètement : votre présentation de bilan dure 30 minutes. Les 15 dernières minutes sont consacrées aux "prochaines étapes." Vous sortez une proposition commerciale déjà prête, avec 2-3 options de déploiement. Le client n'a pas à "réfléchir et revenir vers vous." Il a tous les éléments pour décider.
Proposer 3 options, pas 1
Ne proposez jamais une seule option de contrat. Proposez 3 :
- Option A (starter) : déploiement limité, 20-50 licences, engagement 6 mois. C'est l'option "zéro risque" pour le client qui veut avancer prudemment.
- Option B (standard) : déploiement complet sur un site ou un service, 100-200 licences, engagement 12 mois. C'est l'option que vous visez.
- Option C (enterprise) : déploiement multi-sites, 500+ licences, engagement 24 mois avec support dédié. C'est l'option "aspirationnelle" qui rend l'option B raisonnable par comparaison.
Cette technique (appelée "anchoring" en négociation) fonctionne parce que le client compare les options entre elles, pas votre prix vs zéro. 80% du temps, le client choisit l'option B.
Créer un calendrier de déploiement
Le dernier obstacle au closing est souvent "on va lancer ça au prochain trimestre." Pour éviter ce report, incluez dans votre proposition un calendrier de déploiement précis qui commence 2 semaines après la signature. Montrez que chaque semaine de retard a un coût : vulnérabilités non détectées, données non protégées, inefficacités qui persistent. L'urgence ne se crée pas artificiellement. Elle se rend visible.
Résultats terrain : des POCs qui convertissent
Ce framework n'est pas théorique. Voici les résultats concrets sur les startups deeptech accompagnées :
| Startup | Type de POC | Durée | Résultat |
|---|---|---|---|
| Parcoor | POC gratuit cadré (cybersécurité médicale) | 6 semaines | 2 POCs convertis en 100 licences pilote |
| Dynalight | Prospection ciblée en amont du POC | 3 mois de prospection | Taux de réponse x10 (2% vers 15-30%) |
| Watcha | Déploiement pilote Land & Expand | 12 mois (cycle complet) | +10 000 licences, Lyon Métropole signée |
Le cas Parcoor en détail
Parcoor (cybersécurité des dispositifs médicaux) est l'illustration directe de ce framework. En partant de zéro client, la méthode a produit les résultats suivants :
- Phase terrain : 47 entreprises qualifiées et 197 décideurs identifiés grâce aux conversations discovery et à la traduction des différenciants techniques en arguments business
- POC structuré : critères de succès définis avec l'équipe biomédicale du client (taux de détection, temps de scan, zéro interruption), sponsor identifié (directeur du système d'information), budget pré-validé
- Conversion : 2 POCs lancés avec ce cadre, les 2 convertis en contrats pilote. Résultat : 100 licences déployées
La différence entre un POC qui convertit et un POC qui meurt, ce n'est pas la qualité de la technologie. C'est la qualité du cadre commercial qui entoure le POC.
Les études de cas complètes sont disponibles sur la page réalisations. Pour comprendre la méthode complète en amont du POC (ciblage, prospection, qualification), consultez l'article comment trouver ses premiers clients deeptech.
Questions fréquentes
Pourquoi les POCs deeptech échouent-ils souvent ?
Les POCs deeptech échouent pour 3 raisons : pas de critères de succès définis avant le lancement (le client ne sait pas ce qui constitue une réussite), pas de budget prévu pour la suite (le POC est gratuit mais personne n'a prévu de ligne budgétaire), et pas de sponsor interne identifié (personne ne porte le projet après le POC). Sans ces 3 éléments, le POC devient un "POC éternel" qui ne convertit jamais.
Faut-il faire un POC gratuit ou payant en deeptech B2B ?
Ca dépend de votre stade. Un POC gratuit se justifie quand vous n'avez aucune référence et que vous avez besoin de votre première preuve terrain (4-6 semaines max). Un POC payant (1 000-5 000 euros) filtre les prospects sérieux et fonctionne quand vous avez déjà 1-2 références. Le POC en échange d'equity est à réserver aux partenariats stratégiques rares avec une cible premium.
Combien de temps doit durer un POC deeptech B2B ?
Entre 4 et 8 semaines maximum. Au-delà, le risque de "POC éternel" augmente : le sponsor interne perd de l'élan, d'autres priorités prennent le dessus, et le budget risque d'être réalloué. Les POCs les plus efficaces durent 4-6 semaines avec des checkpoints hebdomadaires et des critères de succès validés dès le départ.
Comment convertir un POC deeptech en contrat commercial ?
Quatre éléments doivent être en place avant le lancement du POC : des critères de succès mesurables validés par le client, une timeline avec des checkpoints hebdomadaires, un engagement client formalisé (personne référente, accès technique, créneau de suivi), et un plan de conversion documenté (décideur, budget, calendrier, concurrence). Parcoor a converti 2 POCs en 100 licences pilote en appliquant ce framework.