Hackathon, design jam ou défi d'innovation : lequel sert votre objectif

Optez pour un hackathon quand le problème est clair et qu'il vous faut un prototype fonctionnel construit par des personnes qui savent coder ou fabriquer. Optez pour une design jam quand vous ne savez pas encore quel est le bon service ou la bonne expérience et qu'il faut le découvrir vite, avec de vrais usagers. Optez pour un défi d'innovation quand la solution existe probablement déjà quelque part, dans une startup, un laboratoire ou chez un fournisseur, et qu'il faut la trouver, la tester et la contractualiser.

Autrement dit : un hackathon répond à « pouvons-nous le construire ? », une design jam à « que devons-nous construire ? », et un défi à « qui l'a déjà ? ». La suite de cet article montre comment savoir quelle question vous posez réellement. Pour toute la famille des formats, voir tous les types de hackathons et de jams expliqués.

La comparaison en un coup d'œil

Quand un hackathon est pertinent

Un hackathon est pertinent quand trois conditions sont réunies. Le problème est assez précis pour tenir en une phrase. Les systèmes, données ou matériaux sont disponibles et autorisés. Et quelqu'un reprendra le résultat et financera l'étape suivante.

Les bons usages typiques : automatiser une étape manuelle que tout le monde juge pénible, construire un outil interne sur un jeu de données existant, connecter deux systèmes qui devraient communiquer, ou tester si une nouvelle technologie tient une charge réelle. Dans chaque cas, l'incertitude est technique, pas humaine.

Un hackathon est mal adapté quand personne n'a vérifié si les usagers veulent la chose. Les équipes construiront des réponses impressionnantes à la mauvaise question, et le jury récompensera la plus impressionnante. Si vous choisissez cette voie, suivez comment organiser un hackathon qui produit quelque chose de réel.

Quand une design jam est pertinente

Une design jam est pertinente quand le problème touche à la façon dont les gens vivent un service et que vous ne savez pas où il se casse. Sa force : les équipes sortent de la salle. Elles pratiquent l'observation en contexte, parlent aux gens, jouent le service en jeu de rôle et testent des prototypes papier l'après-midi même.

Le modèle le plus connu est la Global Service Jam, lancée en 2011 par Adam Lawrence et Markus Hormess, et sa cousine du secteur public, la GovJam : 48 heures, un thème révélé au départ, des prototypes partagés ouvertement à la fin. Pour une design jam interne, on abandonne généralement le thème secret au profit d'un vrai problème de service.

Les bons usages typiques : repenser un parcours d'accueil, réduire les visites ou appels répétés, repenser un service pour un public qu'il dessert mal aujourd'hui, ou apprendre à une équipe ce qu'est le service design en le pratiquant. Une jam est en outre peu coûteuse à organiser, puisque personne n'a besoin d'environnement de développement.

Une design jam est mal adaptée quand l'organisation attend un logiciel à la fin. Assurez-vous que le sponsor sait que le livrable est un concept testé, souvent formalisé sous la forme d'un service blueprint sommaire, et que le construire est une étape distincte. Organiser une jam détaille le format.

Quand un défi d'innovation est pertinent

Un défi d'innovation est pertinent quand vous soupçonnez que la capacité existe hors de vos murs et que la construire vous-même serait plus lent ou plus risqué. Vous publiez un défi, recevez des candidatures, établissez une présélection, accompagnez les finalistes pour adapter leur solution à votre contexte, et en pilotez une ou plusieurs.

Les bons usages typiques : trouver un partenaire technologique pour un problème partagé par votre secteur, repérer des startups pour un programme de pilotes, ou inviter des universités à appliquer des recherches existantes à un problème opérationnel. C'est le bon format quand il vous faut des porteurs de solutions qui ont passé des années sur le problème, pas un week-end.

Il est mal adapté quand vos processus d'achats, juridiques ou de sécurité informatique ne savent pas gérer un pilote avec une petite entreprise. Le défi attirera de bons candidats, puis les perdra au moment du référencement. Réglez les conditions du pilote, l'accès aux données et la propriété intellectuelle avant le lancement. Comment rédiger un énoncé de défi que les gens ont envie de résoudre couvre le brief ; travailler avec des startups couvre la relation.

Les combiner : l'enchaînement qui fonctionne

Les trois formats sont plus forts enchaînés, car chacun produit un type de preuve différent.

1. Une jam pour trouver le problème. Une design jam d'un ou deux jours avec des usagers identifie où le service échoue réellement et à quel concept les usagers réagissent.
2. Un hackathon pour prouver que c'est constructible. Un hackathon ciblé, avec un brief resserré tiré du meilleur concept de la jam, teste la faisabilité technique sur vos propres systèmes.
3. Un défi pour passer à l'échelle avec une aide extérieure. Si construire en interne n'est pas la bonne voie, un défi permet de trouver des partenaires capables de livrer à grande échelle, avec les preuves de la jam dans l'énoncé du défi.

Vous n'aurez pas toujours besoin des trois. Mais les mener dans le mauvais ordre, un hackathon avant que quiconque ait rencontré un usager ou un défi avant de connaître le problème, est la raison la plus courante pour laquelle ces événements déçoivent.

Exemple illustratif

Illustratif. Un réseau national de bibliothèques au Canada voulait que davantage de jeunes adultes fréquentent ses établissements. Un membre du conseil d'administration a proposé un défi d'open innovation sur « la bibliothèque du futur ». L'équipe innovation a résisté : elle ne savait pas encore pourquoi les jeunes adultes restaient à l'écart.

Elle a d'abord organisé une design jam de deux jours. Les équipes ont passé la première matinée dans trois bibliothèques et deux cafés voisins, à observer des étudiants et à leur parler. Le constat ne portait ni sur les livres ni sur la technologie : les jeunes adultes voulaient un endroit pour étudier tard, et les bibliothèques fermaient à 18 h. Les équipes ont prototypé une soirée d'étude tardive avec personnel et l'ont testée par un test concierge dans une bibliothèque la semaine suivante.

Les soirées ont marché, mais les encadrer coûtait trop cher. L'équipe a donc organisé un court hackathon interne sur une seule question : l'entrée et la réservation en libre-service pouvaient-elles fonctionner sur le système d'adhésion existant ? Oui, avec des limites. C'est seulement alors que le réseau a lancé un défi, à la recherche d'un fournisseur capable d'assurer un accès en libre-service sécurisé dans de nombreuses bibliothèques. Chaque format a répondu à une question soulevée par le précédent.

À faire, à éviter

À faire

• Nommer d'abord la question : pouvons-nous le construire, que devons-nous construire, ou qui l'a déjà.
• Structurer le problème avec un arbre à problèmes et des questions « Comment pourrions-nous », quel que soit le format choisi.
• Adapter le responsable au format : un responsable produit pour un hackathon, un responsable service pour une jam, un responsable métier associé aux achats pour un défi.
• Appliquer la même logique de matrice de décision pondérée aux trois, avec des critères pondérés selon la preuve que produit chaque format.

À éviter

• Organiser un hackathon pour répondre à une question sur les besoins des usagers.
• Organiser une design jam et promettre un logiciel qui fonctionne.
• Lancer un défi avant que votre organisation soit réellement capable de contractualiser et de piloter avec le lauréat.
• Choisir le format pour la photo. Le hackathon ouvert doté d'un gros prix est le plus visible et, pour beaucoup de problèmes, le moins utile.

Les questions qu'on nous pose

Une design jam, est-ce la même chose qu'un hackathon ? Non. Les deux partagent un format court et intense, mais un hackathon est jugé sur ce qui fonctionne techniquement, et une design jam sur la capacité d'un concept de service à tenir face à de vrais usagers. Les jams ne demandent pas de coder et se passent bien davantage hors de la salle.

Un défi d'innovation convient-il mieux qu'un hackathon aux startups ? En général, oui. Les startups établies sacrifient rarement un week-end pour construire de zéro, mais elles candidateront à un défi qui offre un vrai pilote. Les hackathons conviennent à ceux qui construisent quelque chose de nouveau ; les défis, à ceux qui ont déjà quelque chose.

Peut-on mener un hackathon et un défi en même temps ? Oui, mais gardez-les séparés. Mélanger des collaborateurs qui partent de zéro et des startups qui ont déjà un produit crée une compétition déséquilibrée et brouille le travail du jury. Menez-les en deux parcours avec des critères différents, ou l'un après l'autre.

Pour aller plus loin

Pour la voie de la jam, commencez par l'observation en contexte et le service blueprint. Pour tester ce que produit n'importe quel format, utilisez le prototype papier et le test concierge. Tous les guides sont réunis dans l'index des guides.