Les billets d’humeur expriment une opinion d’un collaborateur Kalistick et ne reflètent pas nécessairement la position de la société.
Vous connaissez la démonite ? Mais si, l’affection rend les speakers allergiques aux slides et accrocs aux démos à tout va. J’ai bien l’impression qu’elle contamine de plus en plus de monde et que ce n’est pas prêt de s’arrêter. Dernier exemple constaté à la soirée du Lyon JUG avec une présentation des technologies Google assurée par Didier Gérard et Salvador Diaz, dans un amphi de l’Epitech plein à craquer (plus de 220 personnes !).
A l’origine, l’intention est bonne : une démo dynamise une présentation et implique plus l’auditoire dans le sujet. Et à priori, les résultats de l’enquête réalisée par le Lyon JUG montrent que les participants sont demandeurs. Maintenant, autant une démo me semble primordiale pour montrer un produit, autant elle me semble souvent futile lorsqu’il s’agit de présenter des technologies (langages, frameworks, …). Je ressors toujours frustré de ce type de présentation. Quelques raisons :
Heureusement que ça marche !
On a souvent l’impression que le speaker qui fait une démo a pour objectif de montrer que ça démo fonctionne, plus que d’éclairer l’auditoire sur comment ça fonctionne. Mais lorsqu’on m’implémente un Hello World en Groovy, GWT, Flex ou autre, on n’a pas à me convaincre que ça marche ! Heureusement que c’est le cas ! A la limite, ça peut être intéressant de faire une démo qui plante et d’expliquer pourquoi ça ne marche pas pour introduire une problématique particulière !
Le temps tourne !
Une démo, ça prend du temps. En terme de préparation, pour le speaker : une démo qui marche (ça arrive parfois), qui est simple à comprendre et qui est intéressante représente un gros travail. Mais une démo consomme aussi beaucoup de temps de présentation, surtout quand elle est réalisée en direct ; car quand le speaker code, son discours est logiquement appauvri.
Pour ma part, je décroche la plupart du temps. Une fois compris ce que le speaker cherche à faire, ce qu’il résume généralement en 2 phrases avant sa démo, je préfère passer à autre chose que de le voir rajouter ses points-virgules qu’il a oubliés ou de corriger les problèmes de configuration de son IDE.
D’autant que ces démos sont généralement laborieuses, c’est l’effet démo :
- le speaker n’a pas assez préparé sa démo
- il a effectué un petit changement de dernière minute, sans risque évidemment, sauf que ça ne marche plus
- face à un auditoire, il est difficile de garder tous ses moyens, même pour des speakers rodés à ce type d’exercice.
Et les concepts ?
Démarrer une démo sans présenter des concepts ou introduire les besoins auxquels la technologie répond, c’est un peu expéditif. Quand Didier Girard, commence sa démo de Google App Engine, il explique les concepts de IaaS, PaaS, SaaS pendant plusieurs minutes sans le moindre slide. Pour éviter de « faire peur » à l’auditoire avec des slides « théoriques ». Alors qu’un slide avec 3 puces aurait au moins permis de fixer l’attention sur chaque terme.
A mon avis, beaucoup ressortent de ce type de présentation sans avoir véritablement compris ces concepts, en ne gardant que quelques notions et quelques images superficielles.
Simple mais inutile
Quand on présente une technologie, on essaie généralement de montrer qu’elle est simple, et plus que les technologies concurrentes si possible. On ouvre son IDE, on crée un projet avec un wizard, on crée un formulaire avec un designer, on pose son bouton, on code un affichage de Hello World, on le déploie d’un clic et on teste le tout. Oui et alors ? On sait tous qu’on ne fera jamais comme ça dans un vrai projet, où il est nécessaire d’industrialiser le processus pour qu’il soit automatisé de manière homogène. Chaque technologie à ses features d’appel, mais sont-elles les plus intéressantes à montrer, ne relèvent-elles pas d’une dimension démagogique ?
Dans la même veine, quand un framework web serveur (type Wicket, Spring MVC, Grails, …) est présenté, la démo met naturellement plus en avant l’IHM web finale que la mécanique même du framework. Le ressenti de l’auditoire est donc faussé par la démo si la qualité de l’IHM n’est pas du même niveau que celle du framework. De manière plus générale, il est difficile de présenter une démo qui garde le focus sur le sujet à présenter, sans que l’attention ne soit détournée par d’autres éléments (IDE, données de démo, problèmes divers, …).
Simple mais difficile
La plupart du temps, même quand il s’agit de montrer quelque chose de simple comme un Hello World, le contenu du projet de démo peut être compliqué à appréhender pour un débutant. Par exemple pour une démo d’un framework de persistence type Hibernate, le speaker pourra montrer : la base de données, un fichier de configuration général du framerwork, un fichier de mapping d’une table, une classe POJO, une classe DAO, une classe Main, et la configuration du plugin de l’IDE. Au total beaucoup de petites choses dans lesquelles il est facile de se perdre quand on ne connaît pas le sujet. D’autant plus difficile quand le speaker jongle entre les différents fichiers, passe d’un projet à un autre, que des bouts de code apparaissent par magie suite à des copiers-collers, etc.
Pour conclure
Plus qu’une mode, cette démonite correspond probablement à un changement plus global dans la société où on privilégie plus la forme et l’immédiateté d’accès à l’information au détriment du fond et de la réflexion. C’est sûr qu’un slide avec 5 puces est moins sexy qu’une démo Flex, mais il permet aussi de focaliser l’auditoire sur des concepts importants en évitant de le distraire ou de fausser sa perception par des effets d’animation tragi-comiques.
Donc la démo c’est bien, mais encore mieux quand elle reste à sa place, à savoir un complément d’illustration !
Disclaimer : je ne suis pas sûr d’être un bon speaker mais je suis sûr d’être un bon auditeur.
No related posts.
