Le hackathon d'écosystème : un défi, plusieurs entités

Un hackathon d'écosystème est un hackathon co-porté par plusieurs organisations, parce que le problème n'appartient à aucune d'elles seule : un parcours patient qui traverse un ministère, des hôpitaux et des assureurs, ou un processus commercial qui implique la douane, les ports et les logisticiens. Il réussit lorsque les co-porteurs s'accordent sur quatre points avant que quiconque n'écrive une ligne de code : le défi commun unique, les données que chacun ouvrira, à qui appartient ce qui en sortira, et qui portera ensuite les idées gagnantes. L'essentiel du travail se fait dans les huit semaines qui précèdent l'événement, pas pendant.

Cet article ne traite que de la version à plusieurs porteurs. Pour la mécanique générale de l'événement lui-même, voir Comment organiser un hackathon qui produit quelque chose de concret. Pour la vue d'ensemble des entités qui travaillent sur des problèmes partagés, voir L'innovation d'écosystème.

Pourquoi les hackathons d'écosystème sont différents

Un hackathon à porteur unique a un sponsor, un ensemble de systèmes et un décideur. Un hackathon d'écosystème en a plusieurs de chaque, et les frictions apparaissent à des endroits prévisibles :

• Le défi dérive. Chaque partenaire pousse sa propre priorité, et le brief devient une liste de cinq problèmes.
• Les données arrivent tard, voire jamais. Les équipes juridiques de chaque organisation font leur revue séparément, à leur propre rythme.
• L'évaluation devient politique. Chaque partenaire espère discrètement que « son » équipe gagnera.
• Personne ne porte le lundi. Une solution qui exige le changement de trois organisations n'a généralement pas de port d'attache.

Le bénéfice est réel : les participants voient le parcours dans son ensemble, pas la seule tranche d'une organisation, et les partenaires rencontrent pour la première fois les collaborateurs des autres qui travaillent sur le même problème. Beaucoup de hackathons d'écosystème valent moins par leurs lauréats que par les relations de travail qu'ils créent.

Comment en organiser un, étape par étape

1. Cartographier l'écosystème avant de choisir les partenaires. Dessinez une carte d'écosystème du parcours qui vous intéresse : qui est en contact avec l'usager, qui détient les données, qui fixe les règles, qui paie. Décidez ensuite qui doit être co-porteur et qui peut être contributeur. Trois à cinq co-porteurs, c'est gérable ; au-delà, les décisions avancent au ralenti.

2. S'accorder sur un seul défi, rédigé du point de vue de l'usager. Organisez une demi-journée avec un décideur de chaque co-porteur. Utilisez un arbre à problèmes sur le parcours partagé, puis rédigez un énoncé de défi unique qui nomme l'usager et le moment où les choses se cassent entre organisations. Si la priorité d'un partenaire n'entre pas dans ce cadre, elle ira dans un événement ultérieur, pas dans ce brief. Voir Comment rédiger un énoncé de défi que les équipes veulent relever.

3. Signer un court protocole d'accord avant toute annonce. Deux pages suffisent. Il doit couvrir : le défi ; la contribution de chaque partenaire (financement, données, mentors, lieu) ; la propriété intellectuelle (en général les équipes conservent leur PI et les partenaires obtiennent un droit de négociation prioritaire, mais ce sont vos juristes qui tranchent) ; les conditions d'accès aux données ; la façon dont le jury est choisi ; et qui pilote chaque phase. S'accorder sur tout cela après l'annonce, c'est ainsi que des événements prennent des mois de retard.

4. Préparer les données tôt, et ensemble. Décidez quels jeux de données chaque partenaire ouvrira, sous quelle forme (réelles, anonymisées, synthétiques ou échantillon) et à quelles conditions. Regroupez-les en un seul endroit, avec un format de description unique. Fixez aux équipes juridiques et de protection des données une échéance au moins quatre semaines avant l'événement. Si un partenaire ne peut pas ouvrir ses données à temps, un jeu synthétique réaliste de même structure vaut mieux que rien.

5. Désigner un pilote et un tableau des rôles clair. Co-porter ne signifie pas co-diriger chaque tâche. Nommez une organisation pilote pour la logistique et la communication, et utilisez une matrice RACI pour le reste : qui valide le brief, qui recrute, qui fournit les mentors, qui entérine les lauréats, qui finance la suite.

6. Recruter des participants dans tout l'écosystème. Les équipes mixtes sont tout l'intérêt. Réservez des places aux collaborateurs de chaque partenaire, et visez des équipes qui réunissent au moins deux organisations ainsi que des développeurs, designers ou étudiants extérieurs. Demandez à chaque partenaire d'envoyer des mentors qui connaissent leur partie du parcours et savent répondre à « comment cela fonctionne-t-il vraiment de votre côté ? ».

7. Constituer un jury conjoint avec des critères publiés. Chaque co-porteur désigne un juré ; ajoutez au moins un juré indépendant. Publiez les critères avant l'événement et pondérez-les (une matrice de décision pondérée fait l'affaire). Incluez un critère qui récompense les solutions fonctionnant entre organisations, pas au sein d'une seule. Voir Les critères d'évaluation qui désignent le bon lauréat.

8. Animer l'événement avec le parcours partagé au mur. Pendant le hackathon, gardez visible le parcours usager complet, avec la partie de chaque organisation signalée. Quand l'idée d'une équipe exige un changement chez un partenaire, elle doit pouvoir voir lequel et interroger le mentor de ce partenaire présent dans la salle.

9. Décider de la suite avant le dernier jour. Convenez dans le protocole de ce qu'obtiennent les lauréats : un pilote avec des partenaires nommés, une période d'accompagnement définie, un accès aux systèmes réels. Nommez un porteur par concept gagnant et une date pour la première réunion de suivi. Un plan de communication avec les parties prenantes tient tous les partenaires informés après l'événement, quand l'attention retombe.

Exemple illustratif

Illustratif. Dans une ville portuaire européenne, l'autorité portuaire, l'administration des douanes, une fédération de transporteurs routiers et le service des transports de la ville partageaient une même frustration : des camions qui attendaient des heures sur les routes de la ville leur dédouanement et leur créneau. Chacun avait tenté des solutions de son côté.

Ils ont consacré sept semaines à la préparation. Une séance de cartographie de l'écosystème a révélé que le retard se logeait entre trois systèmes qui n'échangeaient jamais leurs estimations d'arrivée. Le défi unique disait : « Comment pourrions-nous donner à un chauffeur routier qui arrive au port une heure de présentation fiable, avant qu'il n'atteigne la ville ? » Le protocole laissait aux équipes la propriété de leur code, accordait aux quatre partenaires un droit prioritaire de pilotage et engageait chaque partenaire à fournir un mentor pendant toute la durée de l'événement. La douane ne pouvant pas libérer de données en temps réel à temps, l'équipe data de l'autorité portuaire a construit un jeu synthétique de même structure.

Quinze équipes ont participé, chacune comptant au moins un membre d'une organisation partenaire. Le jury réunissait quatre jurés partenaires et un président indépendant. Le concept gagnant était une fenêtre d'arrivée partagée qui s'appuyait sur les trois systèmes. Comme le protocole désignait déjà l'autorité portuaire comme porteur de la suite, un pilote de douze semaines a démarré le mois suivant l'événement.

À faire et à éviter

À faire

• S'accorder sur un seul défi. Un problème clair vaut mieux que cinq problèmes partiels.
• Signer le protocole avant l'annonce, y compris les conditions de PI et de données.
• Nommer une organisation pilote pour la logistique, et donner à chacun des autres un rôle clair.
• Récompenser dans les critères les solutions inter-organisations.
• Fixer le porteur et la date de la suite avant l'annonce des lauréats.

À éviter

• Inviter tous les partenaires possibles comme co-porteurs. Les contributeurs peuvent aider sans voter sur tout.
• Laisser l'accès aux données devenir une question de dernière minute. C'est la cause de retard la plus fréquente.
• Laisser les partenaires juger les équipes de leurs propres collaborateurs sans voix indépendante dans le jury.
• Présenter l'événement sous la marque d'un seul partenaire. Un problème partagé exige une visibilité partagée.
• Terminer par une photo de groupe et un communiqué de presse. Sans perspective de pilote, l'événement confirme que la coopération n'est qu'une façade.

Questions fréquentes

À qui doit appartenir la propriété intellectuelle dans un hackathon multi-organisations ? Il n'y a pas de réponse unique, et c'est à vos équipes juridiques de décider. Un montage courant : les équipes conservent leur PI, tandis que les partenaires obtiennent un droit prioritaire de négociation pour un pilote ou une licence. L'essentiel est que ce soit écrit et publié avant les inscriptions.

Combien d'organisations peuvent co-organiser un même hackathon ? Trois à cinq co-porteurs, c'est gérable. Au-delà, associez des organisations comme contributeurs (mentors, données, lieu) sans donner à chacune une voix sur chaque décision.

Et si un partenaire ne peut pas partager ses données ? Utilisez un jeu de données synthétique ou un échantillon de même structure, décrivez-le honnêtement aux participants, et prévoyez d'utiliser les données réelles lors de la phase pilote, dans le cadre d'un accord en bonne et due forme.

Les méthodes pour préparer

Commencez par une carte d'écosystème et une cartographie des attentes des parties prenantes pour voir ce que veut chaque partenaire. Mettez-vous d'accord sur le défi avec un arbre à problèmes, puis répartissez le travail avec une matrice RACI. Pour l'ensemble des formats, voir le guide de référence sur les hackathons, jams et challenges, et pour fédérer tout un secteur au-delà d'un seul événement, Comment ministères et régulateurs fédèrent un secteur autour d'un défi.