Tiremesù
FR
Hackathons, jams et défisComparatif9 min de lecture

Hackathon interne ou ouvert au public ?

Hackathon interne ou public ? L'interne pour l'adoption et la culture, le public pour les talents et les idées neuves. Comparatif et formats mixtes.

La rédaction de Tiremesù

Hackathon interne ou ouvert au public ?

Choisissez un hackathon interne quand votre besoin premier est l'adoption : des solutions compatibles avec vos systèmes et des personnes qui les porteront ensuite. Choisissez un hackathon public quand votre besoin premier est un regard extérieur, de nouveaux talents ou de la visibilité, et que vous acceptez que la plupart des idées aient un long chemin à parcourir pour entrer dans votre organisation. Si vous avez besoin des deux, optez pour un format mixte : un événement ouvert avec des collaborateurs internes répartis dans chaque équipe, ou un événement interne avec un petit nombre d'invités extérieurs.

Le choix porte rarement sur l'événement lui-même. Il porte sur ce qui se passe ensuite, sur qui porte les résultats, et sur le niveau de risque que vous pouvez prendre en matière de données et de réputation. Pour l'ensemble des formats, voir Hackathons, jams et challenges : tous les types expliqués.

Le comparatif en un coup d'œil

Hackathon interne Hackathon public
Idéal pour L'adoption, le travail transverse, la montée en compétences Les idées neuves, le repérage de talents, la réputation, toucher une communauté
Participants Salariés (parfois prestataires) Étudiants, développeurs, startups, citoyens, professionnels
Compatibilité avec vos systèmes Élevée : les participants connaissent les contraintes Faible à moyenne : les externes ne connaissent pas votre réalité
Nouveauté des idées Moindre : hypothèses partagées Plus forte : points de départ différents
Données partageables Données internes réelles, selon la politique interne En général uniquement des données publiques, anonymisées ou synthétiques
Propriété intellectuelle Appartient normalement à l'organisation Doit être convenue et publiée dans le règlement
Chemin vers la mise en œuvre Plus court : ceux qui construisent sont déjà en interne Plus long : exige contrats, achats ou recrutements
Risque de réputation Faible, essentiellement interne Plus élevé : résultats et comportements sont visibles
Effort de préparation Modéré Élevé : règlement, communication, prix, protection des participants
Prix habituels Du temps, un sponsor, un pilote Argent, incubation, contrats, entretiens d'embauche

Quand un hackathon interne convient

  • Vous voulez que le résultat serve. Les équipes internes connaissent les systèmes, les circuits de validation et les personnes. Leurs idées sont plus modestes, mais davantage survivent.
  • Votre véritable objectif est la culture ou les compétences. Un hackathon interne est souvent la première occasion pour des personnes de services différents de construire quelque chose ensemble. Cela suffit parfois à le justifier.
  • Les données sont sensibles. Si les équipes ont besoin de vraies données clients, patients ou financières, il est bien plus simple de les garder dans vos dispositifs de contrôle existants.
  • Vous débutez dans votre démarche d'innovation. Commencer par un événement interne vous apprend à briefer, mentorer et assurer le suivi avant d'avoir un public qui regarde.

La faiblesse, c'est l'uniformité. Les équipes internes partagent les angles morts de l'organisation. Compensez en mélangeant services et niveaux hiérarchiques, et en invitant quelques utilisateurs ou agents de terrain à tester les idées pendant l'événement.

Quand un hackathon public convient

  • Vous êtes enfermé dans vos propres hypothèses. Les externes posent les questions que vos équipes ont cessé de poser.
  • Vous cherchez des personnes. Beaucoup d'organisations utilisent les hackathons publics en partie pour rencontrer des développeurs, designers et startups qu'elles pourraient recruter ou avec lesquels elles pourraient travailler.
  • Le problème appartient à une communauté. Les problèmes d'une ville, citoyens ou sectoriels gagnent souvent à la participation de ceux qui les vivent.
  • Vous avez quelque chose à ouvrir. Des données publiques, une API, une sandbox ou un vrai porteur de défi font qu'un événement public mérite le week-end des participants.

La faiblesse, c'est le fossé qui suit. Des équipes externes ne peuvent pas facilement franchir la porte de votre organisation le lundi. Sans voie claire (un pilote rémunéré, un programme startups, une procédure d'achat), les lauréats rentrent chez eux et les idées s'estompent. Voir Pourquoi la plupart des lauréats de hackathon ne lancent jamais rien.

Les questions pour décider

Avant de choisir, répondez à ces questions avec votre sponsor :

  1. Que doit-il exister trois mois après l'événement ? Une solution en pilote oriente vers l'interne ; un vivier de partenaires ou de recrues oriente vers le public.
  2. Qui portera les idées gagnantes ? Si aucun porteur interne n'est prêt à reprendre le travail d'une équipe externe, un événement public décevra.
  3. Quelles données pouvez-vous partager, et avec qui ? Si la réponse est « uniquement en interne », construisez la version publique autour de données synthétiques ou ouvertes, ou choisissez l'interne.
  4. Que pouvez-vous promettre aux lauréats ? Les participants d'un événement public attendent plus qu'un trophée. Soyez clair sur ce que vous pouvez tenir.
  5. Quel niveau d'exposition pouvez-vous assumer ? Un événement public est une prise de parole publique. Menez un court premortem : imaginez que la presse en a donné une mauvaise image et listez pourquoi.
Le canevas du premortem
Le canevas du premortem

Si les réponses sont partagées, notez les deux options au regard de vos critères avec une matrice de décision pondérée plutôt que de trancher par préférence.

Le canevas de la matrice de décision pondérée
Le canevas de la matrice de décision pondérée

Combiner les deux

Les événements les plus solides mêlent souvent les formats :

  • Événement ouvert, équipes ensemencées. Rendez le hackathon public, mais placez un ou deux collaborateurs dans chaque équipe. Ils apportent les contraintes et le réseau interne ; les externes apportent l'angle neuf. Les collaborateurs portent ensuite l'idée gagnante en interne.
  • Événement interne, externes invités. Gardez-le interne, mais invitez un petit nombre d'utilisateurs, d'étudiants ou de fondateurs de startups comme membres d'équipe ou testeurs.
  • Deux étapes. Organisez une étape interne pour choisir et affûter les défis, puis une étape ouverte pour les résoudre. Ou une étape ouverte pour les idées, puis faites entrer les meilleures dans une semaine de développement interne.
  • L'interne d'abord, le public ensuite. Utilisez les hackathons internes pendant un an pour vous muscler sur le brief, le mentorat et le suivi. Puis ouvrez, avec un historique à faire valoir.

Quel que soit votre choix, préparez tôt le passage de relais. Une check-list de déploiement pour les idées gagnantes, convenue avant l'événement, compte davantage que le format.

Le canevas de la check-list de déploiement
Le canevas de la check-list de déploiement

Exemple illustratif

Illustratif. Une banque régionale d'Europe du Sud voulait simplifier les demandes de prêt des petites entreprises. Son équipe innovation a proposé un hackathon public ; les équipes risques et conformité se sont opposées au partage de toute donnée de demande.

Elles se sont accordées sur un dispositif en deux étapes. D'abord, un événement interne de deux jours a réuni chargés de crédit, personnel d'agence et informatique pour cartographier le parcours de demande et s'accorder sur trois défis précis. Ensuite, un hackathon ouvert le temps d'un week-end a invité des étudiants et des développeurs de fintechs locales, avec un jeu de données synthétique reprenant les mêmes champs que les demandes réelles. Chaque équipe comptait un salarié de la banque comme membre, pas comme mentor.

L'équipe gagnante, composée de deux étudiants, d'un développeur d'une startup locale et d'une chargée de crédit, a proposé une pré-vérification guidée indiquant aux demandeurs les pièces qui leur manquaient encore avant le dépôt. Comme la chargée de crédit faisait partie de l'équipe, l'idée a eu un sponsor interne dès le départ, et la banque a proposé à la startup un pilote rémunéré via sa procédure fournisseurs existante.

À faire et à éviter

À faire

  • Décider en fonction de ce qui doit se passer après l'événement, pas de l'image qu'il donnera.
  • Publier un règlement clair pour les événements publics : PI, données, conditions de participation, prix et code de conduite.
  • Intégrer des collaborateurs internes dans les équipes lors des événements publics, pas seulement comme mentors.
  • Préparer une vraie voie pour les lauréats : pilote, partenariat, recrutement ou incubation.
  • Commencer en interne si vous n'avez jamais organisé de hackathon.

À éviter

  • Organiser un hackathon public pour paraître innovant. Les participants remarquent quand aucun porteur ne se tient derrière le défi.
  • Partager des données sensibles avec le public, même « juste le temps d'un week-end ».
  • Promettre une mise en œuvre à des équipes externes sans le budget et le processus pour la tenir.
  • Fermer les événements internes à tout regard extérieur. Quelques utilisateurs ou testeurs affûteront chaque idée.
  • Évaluer équipes internes et externes avec la même exigence de faisabilité. Les externes n'ont pas votre contexte ; récompensez la compréhension.

Questions fréquentes

Les hackathons publics produisent-ils de meilleures idées ? Ils produisent généralement des idées plus variées, parce que les participants partent d'endroits différents. Les hackathons internes produisent plutôt des idées plus faciles à mettre en œuvre. Aucun n'est meilleur en soi ; tout dépend de votre besoin de nouveauté ou d'adoption.

À qui appartiennent les idées issues d'un hackathon public ? À qui le prévoit votre règlement publié, d'où l'obligation de le rédiger avant l'ouverture des inscriptions. Beaucoup d'organisateurs laissent les équipes conserver leur PI et demandent un droit de négociation prioritaire. Faites-vous conseiller juridiquement selon votre situation.

Des salariés peuvent-ils participer à un hackathon public organisé par leur propre employeur ? Oui, si le règlement le permet, et c'est souvent une bonne idée. Précisez s'ils peuvent remporter des prix, et à qui appartient ce qu'ils construisent pendant l'événement.

Les méthodes pour préparer

Utilisez une cartographie des parties prenantes pour voir qui doit soutenir l'événement et qui recevra les résultats, et la cartographie des hypothèses pour éprouver ce que vous supposez des participants et des résultats. Pour co-organiser avec d'autres organisations, voir Le hackathon d'écosystème ; pour l'organisation de l'événement lui-même, voir Comment organiser un hackathon qui produit quelque chose de concret.