← Tout le portfolio

En cours Ovation.eco 2026 Concevoir & construire

Hub d'innovation interne

Les hackathons internes et la boîte à idées continue dans un seul outil, du dépôt de l'idée au passage devant jury.

Motif mAIllon — arcs concentriques sur fond bleu canard.
Motif mAIllon, pas une capture — cet outil n'a pas d'écran public que je puisse montrer sans exposer les données d'un client.

Le point de départ

Une organisation répartie sur plusieurs pays organise des hackathons internes et recueille des idées toute l'année. Sans outil commun, l'appel à innovation vit dans un tableur, les fiches projet dans un traitement de texte, et le jury note sur papier — rien n'est comparable d'une édition à l'autre, et la boîte à idées meurt entre deux événements.

Ce que j'ai construit

Le périmètre,
dans le détail.

  • Appels à innovation : thèmes, dépôt de candidature, tableau d'avancement, mode présentation, rejointe par code ou par QR.
  • Fiche projet complète — problème, solution, test, plan, pitch — avec hypothèses, modèle économique et enregistrement en continu.
  • Huit rôles et leurs droits : un participant, un facilitateur et un juré ne voient pas la même chose du même projet.
  • Boîte à idées permanente : votes, commentaires, score d'innovation, archives, et écran de projection en direct pendant l'événement.
  • Assistants contextuels branchés sur des fonctions serveur — la clé du modèle ne descend jamais dans le navigateur.

Les arbitrages qui comptent

Ce qui tient le projet debout,
et ce qu'il a fallu corriger.

01

Une écriture qui échoue ne doit pas afficher « Sauvegardé »

Le défaut le plus coûteux de la première version : la base renvoie ses erreurs dans la valeur de retour plutôt qu'en levant, donc un appel qui échouait passait pour un succès. Un vote perdu, un changement de rôle non appliqué, et l'interface qui confirme. La correction n'est pas de tester chaque appel : c'est un helper unique par lequel passent toutes les écritures, qui lit l'erreur, la signale et défait l'état local affiché.

02

Des types de base écrits à la main finissent en contournements

Les types de la base avaient été tapés à la main. Ils ont dérivé du schéma réel, et le code a compensé par une soixantaine de contournements de typage — chacun étant un endroit où le compilateur ne vérifie plus rien. La leçon n'est pas de les corriger un par un : c'est de versionner les migrations et de générer les types depuis la base, pour qu'une colonne inconnue cesse de compiler.

Votre projet

Un besoin proche
du vôtre ?

Trente minutes suffisent pour cadrer un chantier et dire franchement ce qui est faisable, à quel coût, et dans quel ordre.

Prendre contact