Tirer le Meilleur Parti d’une Démonstration Logicielle

 

Lisez la transcription :

Nous testons la transcription de nos podcasts à l'aide d'un programme logiciel. Merci de pardonner d'éventuelles fautes, le robot n'étant pas toujours exact à 100%.

Galen Low : Eh bien, une autre démo logicielle d'un prestataire s'effondre. Votre directeur technique et votre responsable DevOps semblent jouer au bingo du jargon à chaque terme marketing mentionné par le présentateur. Les yeux de votre directeur général se voilent au fur et à mesure que les sujets deviennent un peu trop techniques. Et même si la personne qui présente semble vraiment compétente, personne ne parle de l'éléphant dans la pièce : c'est en fait le cousin de votre PDG.

N'y a-t-il pas un moyen de rendre ce moment utile à tout le monde ?

Si des démonstrations décevantes vous ont empêché de prendre une décision éclairée lors de la sélection d'un nouveau logiciel pour votre organisation, continuez à écouter.

Nous allons décortiquer les stratégies les plus efficaces pour rendre la phase de démonstration de sélection bien plus pertinente selon les besoins spécifiques de votre organisation.

Bonjour à toutes et à tous, merci de nous écouter ! Je m'appelle Galen Low, de Digital Project Manager. Nous sommes une communauté de professionnels du digital dont la mission est de s'entraider afin de gagner en compétences, en confiance et en réseau, pour élever la valeur de la gestion de projet dans un monde digital. Si vous souhaitez en savoir plus, rendez-vous sur thedigitalprojectmanager.com.

Alors, aujourd'hui, nous parlons du processus de sélection d’un nouveau logiciel pour vos équipes projet, et plus particulièrement de comment dépasser le discours commercial d'une démonstration logicielle et s'assurer que l'outil choisi est non seulement le meilleur, mais surtout qu'il correspond à la manière de travailler de vos équipes. Avec moi aujourd'hui, Olivia Montgomery, analyste principale associée chez Capterra et ancienne responsable du PMO IT qui accompagne désormais les PME dans le choix de leur logiciel.

Bonjour, Olivia !

Olivia Montgomery : Bonjour, Galen ! Merci de m’accueillir.

Galen Low : Ravi de te revoir dans l'émission. Comment se passent les choses à Austin pour toi ?

Olivia Montgomery : C’est assez animé en ce moment. Le festival South by Southwest bat son plein, de retour en présentiel pour la première fois depuis 2020. La ville est vibrante, il y a tellement d'événements, de conférences et d'activités. C'est vraiment une semaine excitante.

Galen Low : De retour à la normale. Je suis super enthousiaste à ce sujet. Tout le fil d’actualité de mes réseaux sociaux en parle. Je ne suis jamais allé à Austin, mais je sais que c’est une communauté musicale très vivante, il s'y passe tant de choses, tant de conférences, d’occasions de se rassembler et de s’amuser.

On dirait que je n’ai plus aucune excuse. Cette année sera peut-être la bonne.

Olivia Montgomery : Et c’est vraiment chouette. Il y a aussi des tracks tech. J’ai pu assister à des conférences avec des leaders de la chaîne d'approvisionnement, le PDG d’Amtrak, John Deere est ici aussi pour présenter leur virage technologique. Il y a des expériences VR axées sur de nouveaux modes de narration, allant de thèmes lourds à du divertissement plus léger, et sur la façon dont nous pouvons interagir autrement avec le contenu et entre nous.

Galen Low : Trop bien. Quel a été ton moment préféré jusqu’ici ?

Olivia Montgomery : Au-delà de toute la technologie qu’on voit, j’ai pu voir la nouvelle Batmobile en vrai. Je dois dire que c’est un des moments forts pour moi. Je suis cinéphile, mais je regarde rarement les bandes-annonces. Donc, je n’ai pas vu celle de Batman ni encore le film, mais grâce à South by, j’ai vu la Batmobile en vrai, pour la première fois. Franchement, c’est top.

Galen Low : Je pense que c’est mieux qu’une bande-annonce !

Olivia Montgomery : Je crois aussi. Ça donne vraiment le ton. Maintenant j’ai hâte de voir le film.

Galen Low : C’est ce genre de chose que j’attendais de retrouver avec la réouverture. Se retrouver devant l’inattendu, des choses qu’on n’avait pas prévues.

Génial. Passons au sujet du jour.

Abordons la partie la plus sous pression et source de doute du processus de sélection logicielle : la démonstration. Commençons par planter le décor.

Imaginons que l’on vous confie la mission de trouver un nouvel outil pour votre organisation. Vous êtes soit la personne décisionnaire, soit à la tête du comité de sélection. Vous avez passé des heures à recenser des cas d’usage, à récolter les besoins de l’équipe, à établir les budgets avec les responsables, et à faire tout un tas de recherches en ligne. Enfin, vous êtes arrivé·e à une shortlist d’outils qui semblent convenir, et vous voulez les voir en action.

Pourquoi cette phase est-elle source de pression et de doute ? Parce que c'est l’aboutissement de tous vos efforts jusqu’ici. Vous devez gérer tous les parties prenantes, expliquer convenablement les besoins aux éditeurs, absorber beaucoup d’informations, réagir à chaud, et tout cela en réunion, l’environnement le plus stressant qui soit.

Donc, je me disais, autant commencer par les arguments des sceptiques : faut-il vraiment faire une démo ? N’est-ce pas juste un show commercial ?

Olivia Montgomery : Faites les démonstrations, s’il vous plaît ! Je comprends, j'ai assisté à de nombreuses démos très commerciales. C’est là que j’ai commencé à réfléchir à comment améliorer ce processus. Je crois vraiment à l’importance des démonstrations, même si elles exigent beaucoup de préparation, surtout côté chef de projet. Elles peuvent devenir la clé du choix.

Faites des démos, mais ce n’est pas aussi simple que de se laisser porter par le discours du fournisseur. C’est là que beaucoup se trompent. Il faut vraiment orienter et définir ce que l’on veut voir dans la démo.

Galen Low : C’est vrai. Les outils sont souvent très complets, et on choisit un logiciel pour répondre à beaucoup de besoins différents. Est-il même possible de tout couvrir en démo autre que de survoler les fonctionnalités de base ? Quelles stratégies adopter pour obtenir les réponses dont on a besoin ?

Olivia Montgomery : Très bonnes questions.

D'abord, non, on ne peut pas tout couvrir lors d’une démonstration. C’est là qu’intervient la recherche en ligne au préalable, ou l’utilisation d’un cahier des charges (RFP) auprès des deux ou trois derniers éditeurs retenus. Demandez-leur tous les éléments techniques par écrit. La démo n’est pas le meilleur endroit pour passer en revue toute la liste fonctionnelle.

Concentrez-vous sur l’interface utilisateur et sur deux/trois scénarios clés propres à votre équipe. Quels processus métier doivent être gérés par cet outil ? Et tout simplement, est-ce que les utilisateurs aiment l’ergonomie ? Parfois c’est leur premier contact avec l’outil, et découvrir l’interface est essentiel.

L’aspect et l’ergonomie sont donc au cœur de la démo. L’inventaire fonctionnel doit être établi avant la signature du contrat.

Galen Low : C’est essentiel, merci. J’avais tendance à voir la démo comme un point culminant, mais en fait elle vient combler certains manques.

C’est plutôt un maillon de la recherche. Il y a des choses qu’on doit voir en réel : interface, cas d’utilisation précis. Ce n’est pas « j’ai tout étudié sur papier, on me montre tout en deux heures ». Ça ne fonctionnerait pas.

Il vaut mieux arriver en ayant pris connaissance de tous les documents, et demander à creuser les points importants durant la démo.

Olivia Montgomery : Exactement. Je recommande même de prévoir deux démonstrations.

L'une pour les besoins métiers, l’autre pour la technique. Les combiner rendrait la réunion trop longue et compliquée, et la moitié du public ne serait pas concernée par l’autre moitié de sujets. Je conseille donc clairement de les séparer, par respect pour le temps de chacun.

En plus, vous n’avez pas les mêmes intervenants pour chaque démo. C’est vraiment une étape de sélection et de collecte complémentaire de besoins auprès du prestataire. Peu importe qu’il s’agisse d’un outil de gestion de projet, de comptabilité, d’un ERP, je préconise toujours la même logique.

La première démo est donc métier. Invitez le sponsor métier, mais aussi le super-utilisateur, souvent un responsable d’équipe, le référent qui utilisera l’outil au quotidien. Cela garantit une analyse tant stratégique (capacité de l’outil à supporter la croissance) qu’opérationnelle (le super-utilisateur valide les fonctions clés dont il a besoin, comment ça marche et ce que ça lui apporte).

Parfois, il est difficile d’impliquer le super-utilisateur dès le début, mais c’est lui qui vous suivra jusqu’au bout du projet, assurera la recette, et fera remonter les besoins réels. Il est donc fondamental qu’il soit partie prenante de la démonstration.

Pour bien préparer cela, récoltez les scénarios utilisateurs (user stories) auprès de l’équipe, et transmettez-en au moins un ou deux au fournisseur plusieurs jours avant. Qu’il puisse configurer la démo autour de ces besoins précis. Exemple : en tant que comptable, je dois pouvoir générer un rapport de clôture mensuelle en moins de 24h – il faut le voir fonctionner en réel.

Le scénario utilisateur n’est pas censé imposer chaque détail du process : on reste ouvert à des innovations de la part du fournisseur – il pourrait proposer une méthode nouvelle à laquelle vous n’aviez pas pensé. Mais le super-utilisateur doit voir ses fonctions clés, et le sponsor vérifier que le tableau de bord répond à ses attentes.

Pensez à demander au fournisseur d’importer des données factices pour la démo, souvent il prépare un environnement sandbox à cet effet. Cela permet de visualiser la structure des rapports.

Galen Low : J’adore ce concept de séparer les groupes. C’est parfois contre-intuitif dans un processus de décision, mais il y a bien deux types de discussions à mener.

C’est finalement une question d’optimisation du temps collectif. Comme tu le disais, parfois on essaye d’exclure le super-utilisateur trop tôt, mais il joue un vrai rôle d’ambassadeur dans la sélection – alors que s’il n’était pas inclus, il pourrait critiquer vivement le choix.

J’aime beaucoup l’idée du bac à sable. Et parfois, plutôt que de simplement assister à la démo, certains voudraient pouvoir tester l’outil en direct. Est-ce envisageable ?

Olivia Montgomery : Je suis certaine que les super-utilisateurs aimeraient ça, car parfois une démo ne reflète que l’état futur idéal, or il faut aussi s’assurer que l’outil convienne aux processus actuels. On imagine parfois que le nouvel outil va révolutionner l’organisation du jour au lendemain, mais ce n’est pas la réalité. Le super-utilisateur, lui, sait si dès le jour 1 il pourra exécuter son travail avec.

Donc, si possible, laisser un accès en amont au sandbox peut lui permettre de valider la compatibilité avec le présent, tout en anticipant l’avenir.

Pour les équipes techniques, cela dépendra de leur intérêt, du temps disponible, mais dans tous les cas il faut discuter avec l’ensemble des parties prenantes, puis avec le fournisseur pour adapter la démonstration. Il y a un équilibre à trouver entre ne pas laisser la main au vendeur, et rester ouvert à des approches innovantes proposées.

Galen Low : J’aime beaucoup. Parlant de préparation, as-tu des exemples de scénarios à soumettre en amont ? Ou des conseils sur la manière de recueillir ces besoins sans brider la créativité du fournisseur ?

Olivia Montgomery : Oui, bien sûr. Si vous avez la chance d’avoir un business analyst IT, c’est idéal, mais ce n’est malheureusement pas courant. Même avec, le super-utilisateur n’a peut-être jamais rédigé de scénario. Il lui faut une aide.

Ce que j’ai déjà fait, c’est envoyer un questionnaire style « Mad Libs » à l’équipe, au super-utilisateur, et aux chefs de service concernés. La trame : « En tant que [poste], je dois pouvoir [fonction] afin de [raison]. » Cela les aide à structurer simplement leurs besoins, et vous pouvez transmettre ces scénarios tels quels au fournisseur.

Donc, oui, j’aime bien cette méthode questionnaire guidé.

Galen Low : Super idée, j’adore le concept de Mad Libs appliqué à la rédaction des user stories ! Ça permet au fournisseur de façonner la démo librement tout en s’assurant que le besoin est bien pris en compte. Très malin.

Olivia Montgomery : Voir si l’ergonomie et l'expérience conviennent, c’est l’enjeu principal côté métier. Pour la démo technique, vos scénarios peuvent inclure la fréquence des traitements, les horaires d’exécution, la capacité à programmer des jobs à 1h du matin… Et vérifier l’acceptabilité métier, le besoin d’une fréquence supérieure/inférieure, les capacités techniques.

Il faut également impliquer les responsables techniques, le lead tech du fournisseur, le sysadmin… Pour comprendre où sont hébergées les données, qui les gère, l’intégration, le besoin éventuel de code personnalisé versus standard, etc. Toutes ces questions doivent être traitées avant la contractualisation, sinon les mauvaises surprises surgiront plus tard.

N’ayez pas peur de demander s’il existe déjà des intégrations avec vos outils, si un développement est à prévoir, si le fournisseur le réalisera, etc. Cela peut sembler complexe, mais si on s’est bien préparé, cela évite bien des déconvenues.

Galen Low : Bien vu. Il y a tant de points à aborder – cela pourrait facilement s’étendre en discussion sans fin. Comment prioriser les cas d’usage et les questions à adresser au fournisseur ?

Olivia Montgomery : Question clé ! Il faut s’appuyer sur les leaders d’équipe, les responsables métier et le super-utilisateur. Avant la démo, leur demander leurs principales attentes à ne surtout pas manquer. Qu’ils vous donnent leurs trois points prioritaires – vous vous assurerez qu’ils sont traités pendant la session.

Votre rôle est aussi de recadrer la discussion lorsque certains s’attardent trop sur un sujet. Les fournisseurs maîtrisent souvent bien le timing, n’hésitez pas à intervenir pour garder le cap sur les points cruciaux. Avec une bonne préparation, tout le monde sait à quoi s’attendre et ne se sent pas brusqué ou coupé.

Galen Low : C’est important, le chef de projet n’a pas toutes les clés, mais doit orchestrer tout cela, en sollicitant les décideurs pour prioriser les attentes. Chacun doit pouvoir soumettre son cas et se sentir entendu.

Olivia Montgomery : Exactement. On peut rappeler que l’objectif de la démo est de couvrir 3 ou 4 scénarios utilisateurs majeurs, et le reste pourra être demandé dans la documentation contractuelle (RFP, etc.) ou faire l’objet d’un devis par le fournisseur pour les adaptations requises.

La démo doit surtout permettre de voir l’outil fonctionner, sans trop s’égarer dans les détails techniques…

Galen Low : Très bien. Je retiens l’idée de scinder le processus (métier vs technique), puis de rassembler les décisions. Faut-il mettre en place une grille de notation pour comparer objectivement les outils sélectionnés, et ainsi garder un fil conducteur lors de la phase d’évaluation ? N’est-ce pas trop archaïque avec la complexité actuelle des logiciels ?

Olivia Montgomery : J’adore les grilles de notation des fournisseurs ! C’est loin d’être dépassé. Tout ce qui permet d’évacuer l’aspect émotionnel des démonstrations est crucial. Cela permet de centrer l’évaluation sur le problème à résoudre, quelles fonctions couvrent chaque outil… Le scorecard ramène l’analyse à des critères métiers et techniques. Même si le responsable métier a un coup de cœur, il existe une trace concrète du choix. Et c’est indispensable lors de discussions, d’audits, ou pour comprendre dans le futur pourquoi une solution n’a pas été retenue.

On peut ainsi justifier ses décisions et disposer d’un historique utile, par exemple lors du changement d’un CTO ou d’une vérification externe. La grille de notation fédère les avis, favorise la transparence et facilite la collaboration. Selon la taille de l’organisation, on centralise ou on collecte plusieurs fiches à fusionner ensuite, l’important est de garder tout cela archivé.

Galen Low : J’entends aussi qu’il ne faut pas que la grille soit trop générique. Il faudrait personnaliser les critères selon les besoins réels, et éventuellement restreindre l’échelle à 1-5 plutôt qu’1-10 pour obliger à faire un vrai choix.

Olivia Montgomery : Absolument. Je trouve 1 à 5 plus parlant. Par exemple : ne répond pas aux attentes / répond / dépasse.

Galen Low : Comme les surveys NPS où on coche toujours 3 ou 7 ! Redescendre à une échelle resserrée force à prendre position.

Olivia Montgomery : Oui, et il faut expliquer aux notants ce que signifient les valeurs, pour une homogénéité de traitement.

Galen Low : Est-ce que tout le monde doit utiliser la même grille ou bien varie-t-elle d’un groupe à l’autre (métier vs technique) ?

Olivia Montgomery : Je recommande un modèle de grille unique intégrant à la fois critères métiers et techniques, tout en précisant qui doit remplir chaque colonne ou ligne (par exemple, technique pour les intégrations, métier pour le reporting/dashboards). Mais tout le monde voit l’intégralité des critères, cela permet de découvrir où des divergences existent et d’ouvrir le débat, par exemple sur une intégration qui serait en fait du spécifique, ce qui n’est pas forcément acceptable.

Ainsi, tout le monde perçoit la diversité des avis, et quand il faut arbitrer entre les promesses commerciales (« ils m’ont dit que ») et la réalité technique (« ce n’est pas natif »), on peut faire émerger les risques et regarder si l’organisation est prête à les assumer. La grille favorise ce dialogue essentiel et la transparence.

Galen Low : C’est vrai, la grille est un outil de discussion. Ce n’est pas la machine qui calcule le meilleur score, mais une base pour défricher les désaccords. Comme au poker planning : quand deux personnes notent très différemment, c’est là qu’il faut en parler.

Olivia Montgomery : C’est exactement cela. Cela évite la tension ou les débats stériles pour rester factuel et avancer.

Galen Low : Petite parenthèse sur la compilation : que recommandes-tu pour recueillir, centraliser puis discuter ensemble les notations et observations issues des démos ?

Olivia Montgomery : Grande question ! Les réponses dépendent de la structure de ton organisation, de la maturité des process, des moyens, de l’urgence… Comme chef de projet, il faut être capable de s’adapter et d’outiller selon le contexte. Préparer en amont le pilotage, identifier les vrais décideurs (comité, directeurs…), planifier la restitution et la centralisation, choisir l’outil (tableur, formulaire, outil dédié…). L’important est d’avoir un plan de recueil et de restitution, en anticipant selon les modalités internes.

Galen Low : J’en retiens la nécessité de préparation et d’anticipation. Penser au stockage, à la remontée des points majeurs, impliquer les bonnes personnes, préparer les scénarios : ça demande un vrai pilotage !

Olivia Montgomery : Oui. Et si jamais la grille collaborative ne passe pas ou que le niveau de maturité ne s’y prête pas, ou si certains leaders préfèrent travailler en groupe, il est possible de faire l’exercice ensemble lors d'une réunion après les démos. On bloque 45 min, on remplit la grille tous ensemble, et à la fin, on a un consensus. C’est parfois une bonne solution, car cela accentue l’aspect collaboratif.

Galen Low : Très bon point. Ce n’est pas un examen, ni une compétition d’arbitrage, mais une discussion au service de la décision collective.

En fin de compte, tout le monde ne sera peut-être pas satisfait du choix. Comment gères-tu les attentes et la communication pour éviter que certains ne deviennent démotivés ?

Olivia Montgomery : Encore une bonne raison d’utiliser une grille pondérée ! Gardez toujours en tête le « pourquoi » du projet. N’appelez pas votre projet « déploiement de X », restez sur l’axe « sélection d’une solution pour résoudre… ». La grille et la pondération permettent de rester factuel : il nous faut cela, même si une fonctionnalité super séduisante existe ailleurs, l’intégration à notre messagerie reste un must have… La transparence et la rigueur évitent les choix biaisés ou dictés par l’émotion.

Galen Low : Absolument, la transparence créée par une grille partagée permet de comprendre et respecter la décision, même si tout le monde n’est pas ravi. Ça donne de la clarté, une vision, et un processus qui peut être expliqué à tous, y compris à de nouveaux dirigeants.

Olivia Montgomery : Oui, il faut le respect de la décision. Pas forcément l’adhésion parfaite, mais chacun doit comprendre le processus honnête et partagé qui a mené à ce choix. Ce n’est pas rare que des histoires de favoritisme, familial ou autre, polluent la sélection logicielle… C’est pourquoi la traçabilité du scorecard est vitale.

Galen Low : Excellente synthèse. Olivia, comme toujours, c’est un plaisir de t’avoir. L’idée des deux démos m’a vraiment marqué, c’est contre-intuitif mais très efficace. On couvre tout, sans épuiser inutilement l’audience, puis on rattache tout avec la grille. Un vrai conseil à appliquer !

Olivia Montgomery : Effectivement, votre super-utilisateur n’a pas besoin d’être là pour la discussion sur les Cron jobs et les API, et inversement. Respecter le temps de chacun, entrer dans le détail à bon escient, et surtout ne pas attendre la mise en œuvre pour réconcilier métier et IT. Cela doit arriver plus tôt...

Galen Low : Dernière question, question piège !

Olivia Montgomery : Encore une ?

Galen Low : Oui, juste pour finir.

Vous êtes chef de projet dans une organisation où la sélection logicielle manque de rigueur (par exemple, on privilégie la société du frère du boss). Comment faites-vous pour renforcer la rigueur et réduire les biais ?

Olivia Montgomery : Il faut d’abord une relation respectueuse avec la personne qui défend ce point de vue. Vérifiez s’il s’agit du vrai décideur, sinon il faudra impliquer le bon interlocuteur. Demandez s'il ou elle veut remplir la grille avec vous, dans l’optique de couvrir tous les besoins. Utilisez la méthode socratique : posez les questions, laissez-les découvrir eux-mêmes les points cruciaux oubliés… Ainsi, vous guidez la réflexion tout en restant bienveillant, ce qui peut faire évoluer la position. Et s’il faut, comparez simplement avec une alternative. Toujours rester transparent et axé sur la collaboration entre IT, métier, présent et futur.

Galen Low : Super. Merci beaucoup.

Olivia, quel plaisir. Je pense qu’on a vraiment creusé le processus de sélection et de démo logicielle. J’espère que nos auditeurs en tireront le maximum, et on aura l’occasion de refaire un épisode avec plaisir !

Olivia Montgomery : Merci à toi, Galen. J’espère que ça a été utile et que cela aidera à aborder les démos avec moins d’appréhension. C’est toujours un bonheur d’échanger avec toi, merci infiniment !

Merci !

Galen Low : Pensez-vous qu’une démonstration logicielle vaille vraiment le temps de votre équipe, ou s’agit-il simplement d’un show marketing qui zappe une vraie évaluation approfondie ? Partagez vos avis et retours d’expérience en commentaires.

Si vous souhaitez progresser en tant que chef de projet stratégique, rejoignez notre collectif : thedigitalprojectmanager.com/membership pour accéder à une communauté solidaire, partager des connaissances, résoudre des problèmes complexes et façonner ensemble l’avenir de notre métier.

Entre des modèles robustes, des sessions de formation mensuelles, le soutien des pairs via le forum de discussion, les événements de la communauté ou les groupes mastermind, être membre c’est avoir plus de mille personnes de confiance avec vous pour faire avancer votre carrière dans la gestion de projet digital.

Si cet épisode vous a plu, abonnez-vous et restez en contact via thedigitalprojectmanager.com.

À très bientôt, et merci de votre écoute.