Startups et logiciels V - Démo Niaque

Que ce soit pour les investisseurs, les gros clients ou les enthousiastes influents qui vont disséminer au grand public la bonne parole sur vous et votre produit, il vous faudra sans doute un jour passer par la case démonstration. Saurez-vous esquiver la peau de banane ?

Pourquoi faire des démonstrations ?

Prenez n'importe quel éditeur de logiciel – allez, au hasard, Compuware – et cherchez leur page produits. Vous allez voir, ça va vous paraître familier :

La dernière version d’Uniface, basée sur XML, ouvre la porte à l’automatisation des processus métier et des échanges B2B, devenant ainsi la solution globale pour les acteurs du e-commerce de 2nde génération.

Allez, soyez franc : vous n'avez rien compris à ce que fait Uniface. Il suffit d'aller un peu sur les sites des gros éditeurs de logiciels (et des moins gros) pour trouver une pléthore de descriptions comme celle-ci, avec tous les mots à la mode : XML, B2B, globale, e-commerce, 2nde génération – vous remarquez comme ça s'intensifie vers la fin ?
Le problème, c'est que ce genre de langage techno-marketing est depuis longtemps la norme dans l'industrie du logiciel. Si les gens du marketing chez Compuware avaient écrit quelque chose de compréhensible, on ne les aurait tout simplement pas pris au sérieux. C'est dommage mais c'est comme ça.
Les startups sont tentées de faire la même chose, et c'est tout à fait normal. Regardez eNetshare : "logiciels innovants pour accélérer et sécuriser la messagerie électronique et les outils de collaboration de l'entreprise". Et ce qui est génial, c'est que tout le monde joue au jeu du plus-c'est-fumeux-mieux-c'est, y compris les investisseurs et les gros clients. Si votre paragraphe de présentation n'est pas fumeux au possible, vous ne les attirerez jamais.
Je me moque un peu du marketing des T.I., mais n'oublions pas un autre problème, lié au grand public : même si vous vous adressez aux gens avec des mots simples, le risque demeure que peu d'entre eux comprennent vraiment à quoi sert votre logiciel.
Dès lors que les mots ne suffisent plus pour expliquer la fonction d'un logiciel, la démonstration s'impose comme une évidence. La seule véritable façon de s'assurer que le quidam ait bien compris ce que fait votre produit, c'est tout simplement de lui montrer.
Enfin, n'oubliez pas votre manager. Si vous faites un travail de développement, des démonstrations probantes à votre responsable augmenteront vos chances de pouvoir continuer votre travail tranquillement, ou même d'avoir plus de liberté. Ce n'est pas négligeable, surtout lorsque vous travaillez seul dans votre coin.

L'effet démo

Vous avez sans doute déjà entendu parler de l'effet démo. Il y a même de fortes chances que vous l'ayez déjà vécu. Exemple classique : l'un de vos développeurs arrive tout emballé dans votre bureau en vous disant qu'il a fini de programmer la fonction "Schmilblick instantané" et que c'est absolument génial, ça marche trop bien! et il faut absolument que vous veniez voir ça tout de suite. Bon, vous finissez de peaufiner votre présentation PowerPoint, celle à laquelle personne ne va rien comprendre, si tout se passe bien, et une heure plus tard, vous allez le voir. Il clique fièrement sur le bouton "Schmilblick" et... le programme plante. Bien sûr, il ne comprend pas, normalement ça marche, il doit y avoir un problème avec le réseau, à moins que ça ne soit la boule à plasma que le collègue d'en face vient de ramener du Nature Découvertes du bout de la rue. Il devient rouge, il bafouille, puis finit par abandonner, tout penaud, en disant "Je ne comprends pas, ça marchait il y a cinq minutes!"
L'effet démo, cette anomalie des lois de la nature qui veut que tout fonctionne très bien, sauf au moment où on fait une démonstration devant quelqu'un d'autre, n'est pas inévitable. Vous aurez sans doute des surprises, mais vous pouvez au moins vous prémunir contre les plantages et autres catastrophes le jour J.
Répétez. Une démonstration, ça ne s'improvise pas. Faites-la deux, trois, quatre fois avant, devant vos collègues, amis, cousins, poisson rouge, miroir, c'est votre choix, mais répétez. Vous vous rendrez vite compte des choses à ne pas faire, mais aussi des choses qui en jettent. Soyons honnêtes, une démonstration c'est du marketing, alors il faut que ça tape! Repérez les manipulations qui en jettent et évitez celles qui ralentissent votre logiciel ou qu'il gère maladroitement.
Quoi qu'il en soit, assurez-vous que tout fonctionne pendant les répétitions. Lors du live, ne changez rien ! La tentation est grande, pour un développeur, de rajouter en dernière minute un bout de code génial, exprès pour la démo. Formellement interdit ! Votre démonstration doit se faire dans les Conditions Normales de Température et de Pression, en environnement contrôlé. Entre le moment où vous commencez les répétitions et la fin de votre grand show, rien ne doit changer, si ce n'est les corrections les plus indispensables sans lesquelles la démo serait un échec. Conservez le même code source, les mêmes binaires, les mêmes ordinateurs, le même rétroprojecteur, la même salle, la même configuration réseau (et la même prise réseau dans le mur)... vous m'avez compris, pas besoin d'en rajouter.
Pensez à faire un plan, un chemin clair à travers vos fonctionnalités, de manière à ce que les spectateurs puissent construire mentalement une image de plus en plus large de votre application. Commencez par les fonctions essentielles, puis repassez éventuellement une seconde couche pour les détails-qui-tuent.
La démonstration doit être un exercice vivant et détendu. Préparez volontiers quelques blagues aux moments opportuns – l'humour est un formidable moyen de s'incruster dans l'esprit des spectateurs. Si vous avez une petite fonctionnalité qu'il faut que le client retienne, accompagnez-la d'une petite plaisanterie. Mémorisation garantie ! Soyez souriant et confiant, votre confiance contaminera votre auditoire.

Hey, teachers, leave those kids alone!

Bien. Maintenant que je vous ai expliqué que vous ne deviez rien laisser au hasard, je vais vous expliquer tout le contraire. Phase 2 : laissez vos spectateurs prendre les commandes. Vos clients seront déjà contents de voir dans la pratique comment fonctionne votre produit, mais ils seront souvent carrément enthousiasmés à l'idée de l'essayer !
Un jour, un groupe de clients italiens étaient venus exprès pour voir une démo chez eNetshare. Ils avaient tous l'air très sérieux et posaient des questions raisonnables lorsque nous leur montrions le logiciel, mais quand nous leur avons proposé de l'essayer à leur tour, changement de ton. Notre logiciel avait un sacré potentiel fun : du chat et des fichiers partagés. L'un ouvrait un fichier, y inscrivait "toto" et le refermait, l'autre sur un autre poste l'ouvrait, voyait le "toto" et y rajoutait "est beau" etc. et le tout en se lançant des petites vannes par messagerie instantanée. Pendant quelques minutes, on aurait dit des gamins. Quand vous constatez cela, vous savez que votre démonstration aura fait son petit effet.
Mais alors attention ! C'est sûr et certain, l'un d'entre eux va tenter une manipulation imprévue. A ce moment-là, vous ne pourrez pas lui sauter sur le bras pour l'empêcher de taper sur Entrée. Ne dites jamais à quelqu'un qui essaye votre logiciel : "Stop ! Ne faites pas ça !"
Vous devez être sûr que votre logiciel est blindé. Trop souvent, les développeurs laissent des cas imprévus, des boutons qui ne font rien et des fuites mémoire en se disant que de toute façon, ce n'est qu'une démonstration, ce n'est pas le produit fini. Erreur !

Le deuxième effet démo

Celui qui vient voir votre démonstration vient pour se faire une idée de ce que sera le produit fini. Il peut parfaitement comprendre que tout ne soit pas fait (en tout cas au niveau des détails – il s'attendra probablement à ce que toutes les grosses fonctionnalités soient présentes), mais comme me disait souvent Denis : les gens ne savent pas ce que c'est qu'un bug. Ils ne comprennent pas comment l'application peut disparaître soudainement alors qu'ils viennent de cliquer sur un bouton, surtout si on leur explique derrière que "c'est normal, ce n'est pas fini".
Tous vos efforts pour créer une bonne image de votre produit peuvent tomber en ruine en une demi-seconde si le logiciel plante. Vous aurez beau dire que vous n'avez pas encore eu le temps de tout régler, etc., si votre programme plante, c'est mal. S'il ne produit pas l'effet attendu, c'est mal. S'il est lent ou moche, c'est mal, mal, mal. Vos spectateurs retiendront mille fois mieux les erreurs et les dysfonctionnements que les points positifs et les belles images. C'est dommage, certes, mais c'est comme ça. Vous devez tout faire pour ne pas laisser une mauvaise impression.
Rêgle d'or : pas de plantage. Plantage interdit. Un point c'est tout.
Evitez également les boutons-qui-ne-font-rien-quand-on-appuie-dessus. Ce n'est pas très grave en soi, la personne qui aura cliqué pourra comprendre que vous n'avez pas encore travaillé à cette partie là. Mais il lui restera quand même le souvenir du moment de surprise et de doute quand, juste après le clic de souris, il ne s'est strictement rien passé. Votre IHM peut montrer des fonctionnalités qui ne sont pas encore implémentées, mais assurez-vous alors que les boutons, les éléments de menus ou les cases à cocher correspondantes soient désactivées (grisées). Et quand l'utilisateur vous pose la question, soyez positif et dites "oui, c'est prévu", ne dites pas "on n'a pas encore eu le temps de le faire". Il faut convaincre votre auditoire que vous maîtrisez votre développement.
La vie est injuste : les gens vous reprocheront vos défauts, et oublieront vite vos qualités. Si vous laissez vos clients ou vos investisseurs potentiels voir un produit bancal, le dommage est considérable. Ils auront définitivement l'impression que vous n'avez pas fait votre boulot correctement. Il n'y a que les informaticiens qui savent que le développement d'un logiciel fait partie des plus complexes de toutes les activités humaines. Les autres, ils se disent juste que ça doit fonctionner, point barre. Ils ne veulent pas de jérémiade ni d'excuse, ils veulent voir un bon produit. Rattraper une mauvaise impression est dès lors très difficile. Si votre démonstration exhibe des anomalies et des maladresses, ceux qui l'auront vue raconteront aux autres que ça ne marchait pas bien, et ni les uns ni les autres n'auront très envie de voir comment se porte votre logiciel trois mois plus tard. C'est presque à coup sûr une clientèle perdue, et une mauvaise image pour vous. Et perdre des clients peut se révéler fatal pour une startup.

L'essayer, c'est l'adopter

A la conférence "The Future of Web Apps", Joshua Schachter, le créateur de del.icio.us, parle de ces sites qui imposent à l'utilisateur de s'inscrire avant de pouvoir faire quoi ce que soit.

Les utilisateurs veulent se faire une bonne idée de ce qu'ils vont avoir s'ils s'inscrivent. Ce n'est pas quelque chose que vous pouvez leur dire, ils ne le liront pas. Alors vous devez leur montrer, vous devez les laisser se balader, pour qu'ils aient un aperçu de ce qui se passe sur votre site, de ce qu'il fait et de ce que ça veut dire.

Proposer une version d'essai de son produit est monnaie courante dans le monde du logiciel, mais chacun le fait à sa manière. Les meilleures formules, à mon avis, sont du type "gratuit pendant trois semaines". Les versions bridées qui ne vous permettent pas d'enregistrer votre travail, ou qui vous affichent de la publicité ou (encore pire) des popups toutes les heures pour vous rappeler qu'il faut payer laissent immanquablement dans l'esprit de l'utilisateur une connotation négative.
L'approche de sites comme del.icio.us ou flickr.com est plus saine : l'utilisateur peut déjà faire pas mal de choses, et notamment consulter (à défaut de pouvoir contribuer). S'il a envie de franchir le pas, il s'inscrira d'autant plus volontiers qu'il n'aura pas été harcelé par des popups et des messages subliminaux à la discrétion pachydermique.
La démonstration, plus efficace que les descriptions marketing, permet à un client, à un investisseur ou à votre manager de se faire une bonne idée de ce que fait votre logiciel. Enthousiasmer le spectateur est un puissant moyen de gagner sa confiance, mais attention - le moindre accroc peut ruiner tous vos efforts.