Le POC devait « rassurer ». Au bout de six semaines, chaque éditeur avait livré une démo personnalisée, deux ateliers, et un sentiment diffus que « ça peut marcher ». Aucune décision. Le comité a demandé… un second POC.
Un POC CRM utile n’est pas une cour prolongée. C’est un protocole de décision compressé : trois semaines, des scénarios écrits, une scorecard, un go / no-go assumé.
À quoi sert vraiment un POC (et à quoi il ne sert pas)
Il sert à tester les zones d’incertitude : reprise de données délicate, droits complexes, intégration critique, usages métier ambigus, performance perçue. Il ne sert pas à reconstruire tout le futur SI, ni à former toute l’entreprise, ni à « découvrir » un besoin encore flou.
Si le besoin n’est pas cadré, faites un atelier de cadrage. Pas un POC.
À retenirUn POC réussi produit une décision. S’il produit seulement de l’apprentissage flou, c’était une démo chère.
Semaine 0 : figer le protocole avant le kickoff
Avant le jour 1, écrivez : objectifs du POC, scénarios (5 à 8 max), données de test, critères de succès, scorecard pondérée, rôles, et la décision possible à J+21 (choisir A, choisir B, ne choisir personne, prolonger sur un point précis seulement).
Invitez les bons profils : un power user métier, un admin/IT, un sponsor. Trop de monde transforme le POC en théâtre.
Semaine 1 : socle et scénarios prioritaires
Installez un environnement propre. Importez un échantillon représentatif — pas 2 millions de lignes, mais assez sale pour être réaliste. Jouez d’abord les scénarios qui font mal si ils échouent : création d’opportunité complète, règles d’affectation, recherche d’un contact, reporting minimum, un flux d’intégration critique.
Documentez au fil de l’eau ce qui est natif, paramétré, custom, ou impossible. Cette taxonomie évite les souvenirs embellis.
ConseilInterdisez les contournements « on fera un script magique plus tard » pendant le POC, sauf s’ils sont chiffrés et assumés dans la scorecard.
Semaine 2 : frottements réels et utilisateurs terrains
Faites utiliser l’outil par ceux qui s’en serviront, sur leurs cas. Chronométrez les tâches fréquentes. Notez les points de friction UI, les champs inutiles, les droits absurdes. Testez une demande d’export ou de suppression si la data est sensible.
C’est aussi la semaine des intégrations : un flux qui « marche en théorie » doit pousser un vrai événement observable dans les deux systèmes.
Semaine 3 : scorecard, risques, décision
Chaque critère reçoit une note factuelle. Exemples de critères : couverture des scénarios critiques, qualité de la reprise, effort de paramétrage, clarté des droits, tenue de l’intégration, adoption perçue, TCO indicatif, niveau de dépendance éditeur/intégrateur.
Organisez une séance de débrief sans commerciaux éditeurs dans la pièce. Puis formalisez la décision et les conditions éventuelles (clauses, jalons, POC complémentaire ultra-ciblé).
| Critère | Poids indicatif | Preuve attendue |
|---|---|---|
| Scénarios métier | Élevé | Parcours filmé / PV |
| Data | Élevé | Import + contrôles |
| Intégration clé | Élevé | Flux bout-en-bout |
| Adoption | Moyen | Test utilisateurs |
| Effort / TCO | Moyen | Estimation écrite |
| Risques résiduels | Élevé | Liste priorisée |
Les erreurs qui tuent un POC
Scénarios trop nombreux. Données trop propres. Absence de scorecard préalable. Présence permanente de l’avant-vente qui « aide » au point de masquer la difficulté. Critères qui changent à la fin pour sauver le favori. Durée qui s’étire faute de sponsor.
AttentionSi un candidat refuse de travailler sur vos scénarios et vos données, ce n’est pas un POC : c’est une démo déguisée.
POC mono-outil ou comparatif ?
Comparer deux finalistes en parallèle est puissant… et coûteux en attention. Si vous le faites, imposez le même protocole, les mêmes données, les mêmes utilisateurs. Sinon le plus théâtral gagne.
En mono-outil, le POC valide surtout la faisabilité et l’effort. La décision peut alors être « oui avec conditions » plutôt que « A vs B ».
Budget et charge : rester lucide
Trois semaines mobilisent vos équipes. Prévoyez du temps réel : préparation data, ateliers, tests, débrief. Un POC « sans effort client » n’existe pas — ou n’apprend rien.
Côté prestataire, clarifiez ce qui est gratuit, ce qui est créditée sur le projet, ce qui reste dû si vous n’allez pas plus loin.
Faire du POC un accélérateur, pas une pause
Enchaînez immédiatement : lettre d’intention, plan V1, hypothèses reprises du POC, risques transformés en tâches. Les acquis d’un POC moisissent vite si six semaines passent sans suite.
Un expert CRM peut animer le protocole et garantir l’équité de la scorecard. Pour constituer la shortlist avant POC, le comparatif CRM évite de tester un outil déjà hors-jeu sur des critères durs.
ChecklistPOC 3 semaines : protocole signé, 5–8 scénarios, data réaliste, users métier, scorecard figée, débrief sans vendeurs, décision écrite à J+21.
FAQ rapide
Trois semaines suffisent-elles toujours ? Pour valider l’essentiel, oui. Pour une reprise data massive multi-sources, un volet data peut nécessiter une extension ciblée — pas un POC fleuve.
Faut-il payer le POC ? Souvent partiellement. Un POC 100 % gratuit peut aussi vouloir dire investissement commercial… avec biais.
Que faire si les deux finalistes sont proches ? Tranchez sur les risques résiduels et le TCO, ou sur un micro-POC du point bloquant unique.
Le POC remplace-t-il la recette ? Non. Il réduit l’incertitude amont. La recette valide la construction réelle.
Trancher, puis construire
Un POC CRM en trois semaines réussit quand personne ne dit « on verra bien ». Les scénarios ont parlé, la scorecard a tranché, les risques sont nommés.
Écrivez le protocole avant d’ouvrir l’environnement. C’est la différence entre une décision et une impression.