La démo ERP est le moment où l’acheteur est le plus vulnérable. L’éditeur est sur son terrain, la démonstration est préparée pour impressionner, et le commercial a répété chaque transition. La plupart des équipes acheteuses abordent ce moment sans préparation structurée. Résultat : on retient l’éditeur qui a le meilleur commercial, pas celui dont le produit correspond le mieux au besoin réel. Ce guide vous donne les outils pour inverser ce rapport de force.
Cet article fait suite à notre guide sur le RFP ERP et les 50 questions à poser aux prestataires. Si vous êtes encore en phase de présélection, commencez par là.
Avant la démo : préparer le scénario acheteur
Exiger un scénario métier, pas un tour du produit
La démo par défaut d’un éditeur ERP est une visite guidée de ses fonctionnalités les plus abouties. Le produit est présenté dans les meilleures conditions, avec des données fictives choisies par le commercial. Vous ne verrez jamais les zones d’ombre.
La seule façon d’évaluer un ERP objectivement, c’est de lui soumettre votre réalité.
Envoyez à chaque éditeur, au minimum deux semaines avant la démo :
- Un jeu de données représentatif de votre activité (une commande client fictive avec rupture partielle, un bon de commande fournisseur multi-référence, une clôture mensuelle avec écritures d’abonnement)
- Les 3 à 5 processus absolument critiques que vous souhaitez voir jouer en live, pas commentés en slide
- Le format attendu : “Nous voulons voir l’opérateur effectuer l’action devant nous, dans votre interface de production”
Ce scénario doit être identique pour tous les éditeurs en lice. C’est la condition sine qua non d’une comparaison équitable. Un éditeur qui refuse de jouer sur votre scénario ou demande à modifier les données vous envoie déjà un signal.
Exemples de scénarios à fournir :
| Processus | Cas de test concret |
|---|---|
| Commande client | Article en rupture partielle : 80 unités disponibles sur 120 commandées |
| Facturation fournisseur | BL en 3 lignes, facture avec écart de prix sur ligne 2, workflow d’approbation à 2 niveaux |
| Clôture mensuelle | Réintégration d’une écriture d’abonnement sur 3 sociétés |
| Reporting DAF | Tableau de bord consolidé J+1 avec drill-down par centre de profit |
Composer l’équipe d’évaluation
Le comité de démo idéal réunit :
- Le DSI ou responsable SI, qui pilote la session
- Un utilisateur clé par processus évalué (responsable comptable, responsable achats, etc.)
- Le DAF si le module finance est dans le périmètre
- Un représentant technique (architecte SI ou chef de projet MOE)
Règle stricte : pas plus de 8 personnes. Au-delà, la session devient difficile à animer, les apartés se multiplient et les questions se perdent. Les autres parties prenantes reçoivent le compte rendu.
Chaque participant note de façon indépendante pendant la démo. Interdiction de se concerter avant la consolidation des notes, sous peine de biais de conformité.
Le déroulé standard d’une démo ERP bien conduite
Une démo productive tient en 3 heures. Au-delà, la fatigue décisionnelle s’installe et le dernier éditeur présenté bénéficie d’un effet de contraste qui fausse le jugement.
Structure recommandée :
| Bloc | Durée | Contenu |
|---|---|---|
| Présentation company | 15 min | L’éditeur se présente. Vous écoutez, pas de questions. |
| Scénario métier | 2h | Votre scénario, joué en live. Vous posez les questions. |
| Architecture et intégrations | 30 min | Questions techniques : API, sécurité, hébergement |
| Commercial et prochaines étapes | 15 min | Planning, tarification indicative, prochaine étape |
Le bloc “scénario métier” est sacré. Si l’éditeur essaie de le court-circuiter, recentrez fermement.
Ce qu’il ne faut jamais accepter pendant une démo
Des slides à la place d’une démo live. La phrase “dans la prochaine version, vous aurez…” est un signal d’alarme. Si la fonctionnalité n’est pas disponible aujourd’hui dans la version que vous achèterez, elle n’existe pas pour votre projet.
Un changement de scénario à la dernière minute. “On préférerait vous montrer notre interface standard avant” signifie généralement que votre scénario a mis en évidence une limitation. Tenez bon.
L’absence du consultant qui implémentera le produit. Si seul le commercial est présent, vous ne verrez jamais les nuances techniques. Exigez qu’un consultant certifié senior soit présent, pas juste en observateur.
La démo en mode “sandbox” trop parfait. Demandez à voir le produit dans la version exacte que vous recevrez, pas une démo cloud hébergée chez l’éditeur avec une configuration sur mesure.
La grille de scoring : 5 dimensions pour évaluer objectivement
Après chaque démo, chaque membre du comité note l’éditeur sur 5 dimensions. La note est individuelle, sur 5, puis multipliée par le coefficient de pondération.
| Dimension | Coefficient | Ce qu’on évalue |
|---|---|---|
| Couverture fonctionnelle du scénario | 35% | Le produit a-t-il exécuté votre scénario sans contournement ? |
| Ergonomie et facilité d’utilisation | 20% | Les utilisateurs clés ont-ils navigué sans aide ? |
| Capacités d’intégration et API | 20% | Comment se connecte-t-il à vos systèmes existants ? |
| Performance et scalabilité | 15% | Temps de réponse, volumes, multi-sites |
| Roadmap et vision éditeur | 10% | Plan de développement sur 18-24 mois |
Score composite = somme des (note × coefficient) × 20 (pour ramener sur 100)
Exemple : couverture 4/5 × 35% + ergonomie 3/5 × 20% + API 4/5 × 20% + perf 4/5 × 15% + roadmap 3/5 × 10% = (1,40 + 0,60 + 0,80 + 0,60 + 0,30) × 20 = 74/100
Piège classique à éviter : ne pas créer de critère informel “enthousiasme du commercial”. C’est le biais le plus fréquent dans les comités qui n’utilisent pas de grille formelle. Si le DSI ou le DAF prend position publiquement avant la consolidation des notes, les scores des autres membres convergent vers le sien.
Les 15 questions à poser pendant la démo
Ces questions sont à distribuer entre les membres du comité avant la session. Chacun prend en charge son domaine et note les réponses.
Questions fonctionnelles
- “Montrez-moi comment gérer une commande avec des articles en rupture partielle. Qu’est-ce qui se passe automatiquement ?”
- “Comment paramètre-t-on un workflow d’approbation à 2 niveaux avec délégation automatique si l’approbateur est absent ?”
- “Quelle est la procédure pour corriger une facture déjà comptabilisée ? Qui peut le faire, et quelle trace ça laisse ?”
- “Comment gère-t-on une entité multi-devise avec clôture mensuelle, avec le cours de clôture vs le cours historique ?”
- “Montrez-moi le tableau de bord du DAF en fin de mois. Quel est le délai de disponibilité des données ?”
Questions techniques
- “Quelle est l’API disponible pour connecter notre CRM ? REST ou SOAP ? Avez-vous un connecteur natif Salesforce ou HubSpot ?”
- “Comment gère-t-on les rôles et droits d’accès par société, avec des matrices de séparation des tâches ?”
- “Quel est le RPO/RTO de la solution en cas de panne ? Avez-vous un PCA documenté ?”
- “Quelle est la fréquence des mises à jour ? Peut-on décaler une mise à jour si elle tombe pendant notre clôture annuelle ?”
- “Où sont hébergées nos données ? Quelles certifications de sécurité détenez-vous (ISO 27001, SOC 2, HDS si applicable) ?”
Questions “pièges” à poser systématiquement
Ces questions ne sont pas des pièges au sens négatif : elles révèlent la maturité réelle d’un éditeur sur les sujets qui font déraper les projets.
- “Montrez-moi un client de notre taille et secteur qui utilise cette fonctionnalité en production depuis plus de 12 mois.”
- “Dans vos projets récents, quelle est la part de paramétrage standard vs développements spécifiques ?”
- “Si nous souhaitons changer d’ERP dans 3 ans, comment récupère-t-on nos données, dans quel format, et quel est le délai ?”
- “Quel est votre délai de traitement moyen pour un ticket bloquant (P1) ? Avez-vous des SLA contractualisables ?”
- “Pouvez-vous me donner 3 références clients dans notre secteur que je peux appeler cette semaine, pas via votre commercial ?”
La réponse à ces cinq questions en dit souvent plus que 2 heures de démo.
Après la démo : formaliser la comparaison avant que les souvenirs s’effacent
Les 24 heures qui font la différence
La mémoire est sélective et émotionnelle. Un commercial brillant en clôture de démo peut effacer 90 minutes de limitations fonctionnelles dans le souvenir collectif. C’est pourquoi chaque membre du comité doit soumettre ses notes individuelles dans les 24 heures qui suivent chaque démo, via un outil partagé (tableur, formulaire Notion ou Confluence).
La règle : pas de discussion collective entre deux démos. Si vous avez 4 éditeurs à évaluer, vous consolidez seulement après avoir vu le dernier. Les synthèses prématurées créent des biais de cadrage qui contaminent les évaluations suivantes.
La réunion de synthèse
La réunion de synthèse se tient après la dernière démo. Elle suit ce cadre :
- Chaque membre présente ses scores individuels sans justification initiale
- Calcul des scores composites par éditeur
- Discussion sur les écarts significatifs (note individuelle > 1,5 point au-dessus ou en dessous de la médiane)
- Vérification des red flags (voir ci-dessous)
- Recommandation au comité de pilotage
Comment gérer les désaccords
Dans un comité de 6 personnes, les désaccords sont normaux et sains. Si le responsable comptable note 2/5 la couverture fonctionnelle alors que le DSI note 4/5, il faut comprendre l’écart avant de moyenner aveuglément.
Système de vote pondéré par expertise : sur les critères fonctionnels, la note de l’utilisateur clé compte double. Sur les critères techniques, la note du responsable technique compte double.
Les 3 red flags éliminatoires
Indépendamment du score global, ces trois situations doivent conduire à l’élimination immédiate d’un éditeur :
Red flag 1 : Incapacité à démontrer live une fonctionnalité présentée comme standard. Si l’éditeur annonce une fonctionnalité dans sa réponse RFP mais ne peut pas la montrer en live pendant la démo, elle n’est pas disponible dans la version de production. “C’est en cours de développement”, “c’est un paramétrage spécifique”, “notre consultant peut configurer ça” : ces réponses disqualifient la fonctionnalité.
Red flag 2 : Absence de références vérifiables dans votre secteur. Un éditeur qui ne peut pas vous donner le nom et le téléphone de 2 ou 3 clients comparables, que vous pouvez appeler directement, n’a pas l’expérience sectorielle qu’il revendique. Les témoignages écrits sur le site éditeur ne valent pas un appel de 20 minutes avec un DSI qui a vécu le projet.
Red flag 3 : Pression commerciale excessive ou délai artificiellement court. “Cette offre est valable seulement jusqu’à la fin du mois”, “nous avons un autre prospect sur votre créneau de démarrage” : ce type de pression est une technique de vente qui révèle soit un manque de pipeline commercial, soit une volonté délibérée de court-circuiter votre processus de décision. Dans les deux cas, ce n’est pas un partenaire pour un projet de 12 à 18 mois.
Conclusion
La démo ERP n’est pas un spectacle, c’est un outil d’évaluation. Si vous avez préparé le scénario métier, constitué le bon comité, utilisé la grille de scoring et posé les 15 questions structurées, vous sortez de ce processus avec une décision documentée et défendable. La sélection finale doit reposer sur des preuves concrètes, pas sur un sentiment de confiance généré par un commercial talentueux.
La prochaine étape est la négociation contractuelle : 15 clauses à vérifier avant de signer votre contrat ERP. Pour approfondir la sélection de l’intégrateur qui implémentera le produit retenu : Comment choisir un intégrateur ERP : grille de scoring sur 10 critères.
