Archives du mot-clef hackathon

Quelques conseils aux participants des concours et autres hackathons

Publié le par

Ce lundi j’interviens à Marseille lors d’un atelier ouvert aux participants du concours Open Data lancé par la région PACA. L’objectif : encourager la créativité des réutilisateurs et des développeurs. La saison des concours et des hackathons est bel et bien lancée ! Je vous propose des extraits de cette intervention, sous forme de conseils aux participants, illustrés de quelques réutilisations que j’ai repéré ces derniers mois…

1 – Parole de jury

TransitVis, l'un des lauréats du Urban Data Challenge

TransitVis, l’un des lauréats du Urban Data Challenge

Commençons par la fin de l’histoire. Vous avez fini vos développements, votre dossier de participation est complet, vous venez de soumettre votre service ou votre application. Le jury doit maintenant se réunir pour l’étudier et départager les vainqueurs parmi les participants.

En tant que candidat il ne faut jamais oublier qu’un concours (ou un hackathon) c’est une compétition, pas un examen (contrairement au bac, il ne suffit pas d’avoir la moyenne pour être reçu). Le jury est un élément essentiel de cette compétition. Sa composition est souvent rendue publique. Il rassemble généralement des représentants des organisateurs (collectivité ou entreprises), les partenaires du concours et, parfois, des personnalités qualifiées.

Le jury d’un concours devra identifier les lauréats parmi 40 à 50 participants, celui d’un hackathon aura deux heures pour départager 5 à 10 équipes… La clé de la compétition repose donc souvent sur la différenciation d’un dossier ou d’une application parmi l’ensemble des réutilisations (je parle bien de différenciation plutôt que d’originalité, je reviendrai ultérieurement sur cette distinction qui me semble essentiel). Comment proposer quelque chose de différent ? Je vous propose quelques pistes illustrées.

2 – La donnée, un ingrédient

A la base de tous les concours vous avez donc des données, que l’on peut considérer comme des ingrédients. Lisez bien le règlement du concours : il précise souvent les données que vous pouvez utiliser (uniquement celles de l’organisateur, toutes celles en rapport avec le thème ou le territoire, etc…).

Si je poursuis la métaphore culinaire, vous êtes donc, en tant que participant, le cuisinier. Votre premier travail sera d’évaluer tous les ingrédients qui rentrent dans votre cuisine. Cette donnée est-elle bien fraîche ? Comment pourrais-je l’utiliser ? Faut-il la modifier, l’arranger, la transformer ou peut-on la consommer « crue » ? Une très belle donnée, bien riche, peut parfois se consommer crue si l’on sait la présenter, par exemple à l’aide de visualisations…

L’erreur serait d’aller directement de l’ingrédient vers son utilisation la plus immédiate. La plupart des réutilisateurs qui se voient proposer un jeu de données sur les horaires de bus font des applications d’informations voyageurs, les plus malins en détournent l’usage (dit autrement : avec des pommes de terre on peut faire autre chose que des frites…). La différenciation, toujours !

Une donnée peut donc être l’ingrédient principal d’un plat, ou simplement un ingrédient parmi d’autres. Une donnée peut être proposée crue, mise en forme, transformée ou cuite avec d’autres … Autant de manières différentes d’utiliser ces ingrédients qui sont à votre disposition.

Le concours Urban Data Challenge fournit une très bonne illustration de ce principe de diversité. A partir d’un même jeu de données historiques sur les transports de San Francisco, Genève et Zurich, les participants ont mis en oeuvre des scénarios très différents. Urban Bus Race propose une course virtuelle entre les bus des 3 villes, TransitVis affiche une représentation des flux en 3 dimensions. D’autres participants ont ajouté une nouvelle donnée, par exemple en calculant un indice de frustration (qui combine la densité du nombre de passagers, le temps d’attente à un arrêt et les retards sur le réseau de bus)…

3 – Varier les supports  et les registres 

Une seconde piste de différenciation est liée aux supports que vous pouvez mettre en oeuvre (mobile, web, autres). J’ai déjà eu l’occasion sur ce blog d’expliquer le lien historique et fécond entre l’open data et les applications mobiles. Mais on peut faire beaucoup d’autres choses avec des données ouvertes : des sites web, des vidéos, des infographies, … Rien ne nous oblige par ailleurs à nous limiter à des médiations numériques, on peut très bien utiliser des données ouvertes pour concevoir des supports papiers (par exemple une lettre d’information à l’entrée d’un jardin public, avec l’aide des données ouvertes).

Enfin, on peut aussi rechercher de la différenciation du côté des registres d’expression. A partir d’un même jeu de données, on peut proposer quelque chose d’utile, de ludique, de décalé, … La variation entre les registres peut aussi être intéressante. Le service BrokenLifts s’appuie sur l’état de fonctionnement des ascenseurs des transports berlinois. La donnée est à la fois présentée sous une forme utile (« est-ce que cet ascenseur fonctionne ? ») mais aussi sur le registre de la  transparence et de l’accountability (« combien de jours de panne sur cet ascenseur géré par cette société ? ».

Un point de vigilance, cependant. La différenciation ne peut pas seulement passer par le choix d’un mode d’expression décalé. Le format « pitch » du hackathon encourage les discours décalés, mais la forme ne remplace pas complètement le fond.

Le site Brigand Futé (réalisé lors du HackIDF 2030) aide à planquer un cadavre en région parisienne, à partir des données du plan d’urbanisme… Le propos est donc décalé, mais la réalisation est d’un très bon niveau.

J’ai beaucoup moins accroché sur le récent lauréat d’un autre hackathon « a place to pee » qui, comme son nom l’indique, permet de localiser les toilettes dans la ville de Paris… Le sujet est pourtant bien réel (Rennes édite par exemple un guide papier très précis, réalisé avec des associations de malades), on aurait pu jouer sur plusieurs registres – et pas uniquement sur les multiples jeux de mots proposés par les concepteurs du service : « let piss a chance », « game of throne », …).

4 – Emprunter des pistes moins balisées

Il reste par ailleurs des pistes qui ont été jusqu’à présent peu explorées par les participants au concours, et notamment la conception d’outils pour les réutilisateurs et les développeurs. L’approche « business-to-developers » (B2D) plutôt que strictement « business-to-business » (B2B) ou « business-to-consumer » (B2C) est aussi une source de création de valeur. On peut citer par exemple la start-up britannique Placr qui a développé une API pour interroger les données des réseaux de transports urbains.

 

 

Un hackathon, sinon rien ?

Publié le par

Le hackathon est à la mode en ce début d’année 2013 ! Les développeurs qui s’intéressent à l’open data vont être très sollicités. C’est l’occasion de se pencher sur ce format d’animation original. A quoi sert un hackathon ? Quels en sont les valeurs mais aussi les limites ? 

(photo la Cantine Rennes)

(photo la Cantine Rennes)

Tout à la fois dispositif créatif et mode d’animation, le hackathon rassemble dans une unité de temps (généralement un week-end) et de lieu des réutilisateurs qui travaillent en mode projet. Il fait partie de la panoplie des outils d’animation que j’ai déjà eu l’occasion de détailler sur ce blog. Plus léger qu’un concours, a priori moins complexe à mettre en place que d’autres formes d’animation au long cours, le hackathon pose aussi ses propres défis.

Les 3 valeurs du hackathon

Le hackathon a d’abord une dimension de mobilisation, tant interne qu’externe. On pourra noter d’ailleurs que ce format est de plus en plus utilisé en amont de l’ouverture des données. C’est tout d’abord l’opportunité pour obtenir l’ouverture, même partielle ou limitée dans le temps, de jeux de données. Le hackathon est alors un prétexte en interne pour faire bouger les lignes, en arguant du caractère éphémère – donc perçu moins impliquant ou risqué – de l’opération.

Dans un curieux renversement de logique, on ne propose pas un hackaton parce que l’on a des données, on demande des données parce que justement un hackathon est organisé ! La dimension mobilisatrice est aussi importante en externe, c’est un excellent moyen de faire baisser la pression sur le sujet, mais aussi d’engager de premières relations avec un écosystème de réutilisateurs.

La seconde valeur du hackathon est liée à l‘expérience-même du hackaton par ses participants. Ceux qui ont eu l’occasion d’en vivre un vous le diront : ils ont vécu une expérience. Tout d’ailleurs dans l’organisation vise à renforcer cette dimension : l’unité de lieu (on vit en vase clos pendant 48 heures), le travail en petit groupe d’individus qui ne se connaissaient pas nécessairement auparavant (la colonie de vacances est l’archétype du team building, c’est bien connu), la contrainte de temps (à la fin chaque groupe présente son projet), voire la compétition (quand le hackathon donne lieu à un vote).

Le problème avec cette dimension expérientielle est qu’elle ne produit guère d’externalités pour ceux qui ne l’ont pas vécu. Je vais le dire autrement : soit vous avez vécu le hackathon – et vous en comprenez la valeur -, soit vous ne l’avez pas vécu. La transmission d’une expérience vécue est toujours délicate, hackathon ou pas – d’où l’importance de la documentation projet sur laquelle je reviendrai ultérieurement dans ce billet.

La troisième valeur du hackathon est liée à la communication. C’est un dispositif qui permet de donner corps à une démarche d’ouverture des données et constitue en tant que tel un objet de communication. Comment dès lors rendre compte des travaux et de l’ambiance générale ? Le hackathon permet certes d’avoir quelque chose à montrer de l’open data, mais cela ne peut pas se réduire à une photographie de quatre gars et une fille devant un ordinateur 😉

L’opération MuseoMix, largement disséquée dans cet article d’Hubert Guillaud d’Internet Actu ou, dans une moindre mesure, les hackathons organisés par Transilien SNCF, font l’objet d’un retour en ligne assez poussé : vidéos, témoignages de participants, présentation détaillée des projets réalisés (ou en cours de réalisation). Mais le budget nécessaire à cette couverture ne correspond pas tout à fait l’idée du hackathon comme formule d’animation un peu cheap et accessibles à toutes les bourses.

Et pourtant cette fonction de communication est essentielle pour essayer de transmettre aux non-participants un peu de l’essence de l' »expérience hackathon« . Il faut donc l’inclure dans son organisation et sans aucun doute la considérer comme une fonction à part entière. On retrouve ici l’idée de la documentation de projet au fil de l’eau mise en place notamment à la 27ème Région.

Les défis du hackathon

La question principale qui se pose aux organisateurs du hackathon est celle de la finalité : à quoi sert-il ? S’agit-il essentiellement de mettre en oeuvre des démarches agiles et des pratiques d’innovation plus légères, ce qui en soit présente déjà un intérêt comme le souligne Fréderic Charles dans son article « Un hackathon pour innover à la DSI en mode start-up » ? Ou le hackaton a-t-il un objectif de réalisation (de prototypes, de services) ?

Faute d’avoir défini, clarifié et partagé en amont les objectifs, on risque d’être un peu déçu par la réalité des réalisations. De la même manière qu’un Start-Up Week-End (marque déposée, sic) fait émerger des idées d’entreprises (et non des entreprises elles-même), le hackathon fait émerger des idées de service, éventuellement des prototypes. Mais le passage à la phase opérationnelle demande bien souvent un effort supplémentaire.

C’est aussi sur ce point que l’organisateur devra se positionner : comment souhaite-t-il accompagner la concrétisation ? Est-il prêt à financer les projets les plus intéressants ou considère-t-il que son action s’arrête le dimanche soir ? Le hackathon est peut-être finalement une formule un peu plus engageante et impliquante que nous pourrions initialement le penser. L’après-hackathon est un sujet à part entière.

L’autre question qui se pose – au hackathon mais aussi plus globalement aux autres formes d’animation ponctuelles comme les concours – est celle de la répétabilité. Peut-on répéter indéfiniment la formule sur un public cible de développeurs intéressés par l’open data, cible qui n’est pas -par définition – extensible à l’infini ? Dit autrement, un hackathon ca va, trois hackathons bonjour les dégâts ? Les équipes des premières éditions se concentrent sur la concrétisation de leurs idées, il faut donc être capables de mobiliser de nouveaux participants – et ce n’est pas toujours simple. Le premier semestre 2013 va être un bon test grandeur nature, vu le nombre important d’hackathons annoncés…

Ps : j’en profite pour vous conseiller la lecture du guide pratique d’organisation d’un hackathon, proposé par Open Data BC (British Columbia) en anglais, donc.