Comment rédiger un énoncé de défi que les équipes veulent relever

Un bon énoncé de défi nomme un vrai problème, les personnes qui le vivent, la raison pour laquelle il compte maintenant, ce qui est exclu et ce que le porteur fera d'une bonne réponse, le tout sur une page. Il est assez précis pour que les équipes démarrent dès le premier matin, et assez ouvert pour ne pas imposer la solution. Les sept étapes ci-dessous vous y mènent en deux semaines de préparation environ.

Ce qu'un énoncé de défi doit accomplir

L'énoncé de défi est le document le plus important de tout hackathon, jam ou challenge d'innovation ouverte. Il détermine qui s'inscrit, sur quoi les équipes travaillent, comment le jury note et si quelque chose survit à l'événement. La plupart des énoncés échouent dans l'une de deux directions :

• Trop large. « Améliorer l'expérience client. » Les équipes passent la première journée à choisir un problème et aboutissent à dix idées sans lien, impossibles à comparer.
• Trop étroit. « Construire un chatbot pour le centre d'appels. » La solution est déjà choisie. Les équipes deviennent des prestataires non rémunérés et les meilleures idées n'apparaissent jamais.

La cible se situe entre les deux : un problème clair, une personne claire, de vraies contraintes et la liberté sur le comment. C'est la version « défi » du travail décrit dans comment rédiger un énoncé de problème ; la différence, c'est qu'un énoncé de défi doit fonctionner pour des inconnus qui n'ont jamais mis les pieds dans votre organisation.

Sept étapes vers un énoncé de défi

1. Partir du porteur, pas du sujet. Trouvez la personne qui vit le problème et qui a l'autorité d'agir sur une réponse. Interrogez-la pendant une heure. Demandez-lui ce qui ne cesse de dysfonctionner, ce qu'elle a déjà essayé, ce qu'elle ne peut pas changer et ce qu'elle ferait le lundi suivant d'une bonne idée. Si personne ne correspond à ce profil, arrêtez-vous : un défi sans porteur produit un travail que personne ne reçoit, ce qui est la première erreur traitée dans 9 erreurs de hackathon que les organisateurs répètent.

2. Descendre d'un niveau sous le symptôme. Ce que le porteur décrit en premier est généralement un symptôme : « les réclamations augmentent », « les dossiers prennent trop de temps ». Utilisez un arbre à problèmes ou une série de 5 pourquoi pour trouver la cause à la fois réelle et traitable dans le temps dont disposent les équipes. « Les dossiers prennent trop de temps » peut devenir « les demandeurs déposent des dossiers incomplets et le dossier reste en file d'attente faute d'une seule pièce manquante ». Voilà un objet sur lequel une équipe peut concevoir.

3. Nommer les personnes concernées, en mots simples. Un défi sans personne reste abstrait. Qui vit exactement le problème, et à quel moment ? « Des primo-demandeurs qui remplissent le formulaire sur leur téléphone, généralement le soir » est bien plus utile que « les clients ». Deux ou trois entretiens avec les parties prenantes avec ces personnes, même courts, vous donneront le vocabulaire et les détails qui rendent l'énoncé concret. Un énoncé de point de vue (utilisateur, besoin, insight) est une bonne façon de le formaliser.

4. En faire une question qui appelle de nombreuses réponses. Reformulez le problème sous forme de question « Comment pourrions-nous ». Testez-la : dix équipes différentes pourraient-elles donner dix bonnes réponses réellement différentes ? Si une seule réponse convient, la question est trop étroite. Si n'importe quelle réponse convient, elle est trop large. « Comment pourrions-nous aider les primo-demandeurs à déposer un dossier complet du premier coup ? » passe le test. « Comment pourrions-nous construire un vérificateur de pièces jointes ? » non. « Comment pourrions-nous transformer les services publics ? » non plus.

5. Écrire les contraintes avec honnêteté. Les contraintes ne sont pas l'ennemi de la créativité ; le flou, si. Listez ce qui ne peut pas changer (réglementation, systèmes cœur, plafond budgétaire, délais), ce qui est disponible (jeux de données, API, temps du personnel, vrais utilisateurs joignables) et ce qui est explicitement hors périmètre. Les équipes respecteront une limite ferme. Ce qui les frustre, c'est de la découvrir au pitch, quand un juré lâche : « nous ne pourrions jamais faire ça ».

6. Dire pourquoi c'est important et ce qui se passera ensuite. Consacrez une ou deux phrases à la raison pour laquelle ce problème compte maintenant, idéalement dans les mots des personnes concernées plutôt que dans ceux des documents stratégiques. Puis énoncez clairement l'engagement du porteur : un pilote sur un service nommé, un développement sur 90 jours avec une équipe, un test financé. C'est ce qui donne envie de relever votre défi plutôt que celui d'un autre. Si l'engagement est modeste, dites-le franchement. Les équipes préfèrent une petite étape concrète à une vague promesse de « mise en œuvre potentielle ».

7. Le tester auprès de quelqu'un d'extérieur. Soumettez le brouillon à deux ou trois personnes qui ne connaissent rien au problème, idéalement le type de personnes que vous espérez voir participer. Demandez-leur de vous réexpliquer le défi avec leurs propres mots et de citer la première idée qu'elles essaieraient. S'il y a malentendu, ou si toutes les idées se ressemblent, réécrivez. Une cartographie des hypothèses de ce que l'énoncé tient pour acquis constitue une dernière vérification utile.

Un modèle sur une page

Utilisez ces rubriques, dans cet ordre, et tenez l'ensemble sur une page :

1. Le défi — la question « Comment pourrions-nous », en une phrase.
2. Qui est concerné — les personnes, le moment, une citation si vous en avez une.
3. Ce que nous savons — trois à cinq faits ou observations, avec leur source.
4. Pourquoi maintenant — une ou deux phrases.
5. Ce que vous pouvez utiliser — données, systèmes, personnes joignables.
6. Ce qui est exclu — les contraintes, honnêtement.
7. À quoi ressemble une bonne réponse — les critères d'évaluation, publiés dès maintenant (voir les critères d'évaluation qui désignent le bon lauréat).
8. Ce qui se passe ensuite — l'engagement du porteur, nommé.

À faire et à éviter

À faire

• Écrire dans la langue des personnes concernées, pas dans celle de votre stratégie.
• Inclure au moins un fait que les équipes n'auraient pas pu deviner.
• Publier les critères et l'engagement post-événement dans le même document.
• Faire présenter le défi en personne par le porteur dès le premier matin.

À éviter

• Nommer la technologie. « Grâce à l'IA » ou « avec la blockchain » dans la question restreint les réponses avant que quiconque ait réfléchi.
• Masquer des contraintes pour rendre le défi plus attrayant.
• Fusionner deux problèmes en un seul énoncé pour contenter deux sponsors ; rédigez deux défis ou choisissez-en un.
• Employer des sigles internes ou des noms de services que des externes ne connaîtront pas.

Exemple illustratif

Illustratif. Le réseau de bibliothèques d'une ville d'un pays d'Europe du Nord souhaitait lancer un challenge ouvert sur « la bibliothèque du futur ». Le premier jet disait : « Comment pourrions-nous réinventer la bibliothèque à l'ère numérique ? » Testé auprès de trois étudiants, il a produit trois versions de la même application.

L'équipe est retournée voir la responsable des services en agence, qui détenait le budget des transformations d'agences. En une heure, elle a découvert le vrai sujet : les visites des adolescents en soirée avaient chuté, alors que les agences restaient ouvertes jusqu'à vingt heures avec un personnel peu occupé. Une séance de 5 pourquoi avec le personnel des agences a fait ressortir une cause : les adolescents voyaient la bibliothèque comme un lieu de révision silencieuse en période d'examens, et rien d'autre.

L'énoncé révisé disait : « Comment pourrions-nous donner aux 14-18 ans une raison de venir dans leur bibliothèque de quartier un soir de semaine ordinaire ? » Contraintes : pas de travaux, personnel existant uniquement, un petit budget de matériel. Disponible : deux agences prêtes à tester, cinq adolescents joignables pendant l'événement, les données de fréquentation par heure sur les deux dernières années. Engagement : la responsable des services en agence mettrait en œuvre l'idée gagnante dans deux agences pendant un trimestre scolaire. Vingt-deux équipes ont participé ; les idées allaient d'un échange d'aide aux devoirs à un repair café en soirée. Chaque idée pouvait être comparée à l'aune de la même question.

Questions fréquentes

Quelle différence entre un énoncé de problème et un énoncé de défi ? Un énoncé de problème décrit ce qui ne va pas, surtout pour l'équipe qui en a la charge. Un énoncé de défi transforme ce problème en invitation adressée à des personnes extérieures à l'équipe : il y ajoute la question, les contraintes, les ressources et ce qu'il adviendra d'une bonne réponse.

Quelle longueur pour un énoncé de défi de hackathon ? Une page. La question elle-même doit tenir en une phrase. S'il vous faut plus d'une page, vous avez sans doute deux défis, ou vous expliquez votre organisation plutôt que le problème.

Faut-il donner des exemples de solutions possibles dans le défi ? En général, non. Les exemples ancrent les équipes, et beaucoup se contenteront de construire l'exemple. Si vous devez le faire, donnez-en deux très différents et précisez clairement qu'il s'agit d'illustrations, pas d'attentes.

Pour aller plus loin

Le défi s'inscrit dans un dispositif plus large ; voir comment organiser un hackathon qui produit quelque chose de concret et la cartographie des formats dans hackathons, jams et challenges : tous les types expliqués. Pour bien préparer, appuyez-vous sur les guides arbre à problèmes, 5 pourquoi, énoncé de point de vue et questions « Comment pourrions-nous ».