Huit ans à faire exister un produit numérique, de l'idée en 2018 à une application vendue à des collectivités. Et dix-huit mois à industrialiser le pilotage d'un pôle opérationnel en startup.
Six cas, racontés avec les résultats et avec les limites.
Le pôle Ateliers déployait des programmes d'inclusion numérique pour quatre grands comptes, dans des dizaines de villes. Les indicateurs vivaient dans plusieurs fichiers, les calculs n'étaient pas stabilisés, et les points d'équipe portaient sur les actions plutôt que sur les résultats. Personne ne pouvait dire quel projet était à risque avant qu'il ne le soit devenu.
Une chaîne complète en no-code et low-code, sans équipe technique dédiée.

C'était ce qui déterminait la survie de la boîte. Un client qui renouvelle vote avec son budget, alors qu'on peut faire monter le taux de participation en ouvrant des créneaux et la satisfaction en choisissant qui on interroge.
Autour : taux de participation, taux de remplissage, et un taux d'exploitabilité de la donnée, parce qu'un indicateur calculé sur des lignes incomplètes ne vaut rien. Le statut d'un projet (prospection, actif, renouvelé, en attente, non renouvelé) est devenu calculé à partir des dates au lieu d'être déclaré à la main.

288 ateliers
94 % de remplissage moyen
98,5 % de satisfaction
18 ateliers
92 % de remplissage
NPS +58
22 cycles, 453 inscrits
331 participants
no-show réduit d'environ 20 points
Chiffres attestés par une lettre de recommandation d'Aaron Teboul, CEO, disponible sur demande.
Le modèle dépend du schéma Airtable, certaines saisies restent manuelles, et le modèle analytique est volontairement simple. C'était le bon niveau pour un pôle de cette taille, pas une architecture de données d'entreprise.
Je définis les indicateurs et j'arbitre dessus. Je ne construis pas les pipelines de production : mes équipes le font, et je sais leur parler.
J'ai lancé Eiko en 2018, d'abord comme un projet appelé Mon Choix, puis en SARL, puis en association à partir de fin 2019. L'application mobile d'engagement citoyen est sortie bien plus tard. En 2026 elle était vendue à six collectivités d'Île-de-France, cinq squads bénévoles avançaient en parallèle, et l'offre commerciale promettait un tableau de bord temps réel et un rapport d'impact à trente jours.


On a été accompagnés un an par Paris&Co. C'est de là que vient la co-construction avec Meudon : sur les 15 familles du défi zéro déchet, 9 ont participé à plusieurs entretiens et ateliers de conception avec nous.
Au total, environ 400 retours quantitatifs par questionnaire, et une centaine d'heures d'entretiens qualitatifs avec une centaine d'utilisateurs. Les ateliers, que j'avais refusé d'ériger en modèle économique, servaient d'abord à ça : rester en contact direct avec les habitants et les agents.
Et quand il a fallu une base d'utilisateurs qu'on n'avait pas, on est allés chercher Zero Waste France. Ils ont relayé l'app sur leurs réseaux à l'approche des municipales 2026.
Et en creusant, j'ai trouvé pire que le retard : j'avais vendu de la mesure d'impact sur un produit qui n'instrumentait pas son propre usage. Aucune collecte en production, donc aucun moyen de dire si quelqu'un revenait. Ça a duré des années, sous ma responsabilité, et personne d'autre que moi n'aurait dû s'en apercevoir en premier.
C'est de là que vient ma règle actuelle : pas de métrique, pas de priorité.
Le réflexe aurait été de conclure que l'équipe n'avançait pas assez vite. Cinq squads, trois lignes d'arrivée floues, et moi président, product owner et recruteur à la fois. Le goulot d'étranglement, c'était l'organisation, et ma place dedans.
Ce n'était pas notre compétence, la nôtre c'était la recherche utilisateur et le produit numérique. On a quand même gardé des ateliers, mais comme canal de contact avec les habitants et les collectivités.
Engager une masse salariale sans modèle économique prouvé, c'était mettre l'association en risque. J'ai pris un product owner bénévole à la place.
Continuer la trajectoire SaaS était l'option écartée, et c'est la décision principale.

Présentée à l'équipe le 24 juin 2026. Un livrable central unique, un pilote mesuré livré à Val d'Yerres Val de Seine. Trois P0 de survie seulement, l'app rejoignable en moins de 3 min, la création d'activité en autonomie, un rapport d'impact exportable. Une ligne d'arrivée par squad avec un responsable nommé. Et le rôle de PO délégué à deux personnes, mobile et data, pour me sortir du chemin critique.
La règle de tri, écrite dans le document d'équipe : une idée intéressante n'est pas une priorité.
🔗 Les arbitrages sont documentés, datés et signés de mon nom : EPIC #655, Roadmap 2026 sur Framagit.
La délégation n'a pas tenu partout. Le départ du lead data m'a obligé à reprendre la squad, et je me suis retrouvé exactement là d'où je voulais sortir. Le socle avance, il y a un premier tableau Looker et des marts sur BigQuery, mais le rapport d'impact n'est toujours pas livré.
Ce que j'en retire : dans une organisation bénévole, une délégation sans doublure ne tient pas. Je referais la même décision, mais je nommerais un suppléant sur chaque rôle critique avant de me retirer.
La validation automatique des éco-gestes par IA était sur la roadmap. Elle était séduisante et elle aurait bien sonné en démo. Je l'ai mise au parking avec la même règle que le reste : personne ne savait dire à quoi on verrait qu'elle marchait.
Elle reste dans notre vision à douze ou dix-huit mois, et je la referais, mais après le socle de mesure, pas avant. Une fonctionnalité d'IA sans critère de succès reste une fonctionnalité sans critère de succès.
Pour le reste, j'utilise les modèles de langage au quotidien en analyse de tickets, en rédaction de premières specs et en exploration de données. Ça me fait gagner du temps sur le texte, ça ne décide rien à ma place. Et je tiens la distinction entre automatisation déterministe et modèle probabiliste, parce que sur un produit destiné à des collectivités, la traçabilité de la mesure comptait plus que la sophistication du calcul.
On avait une web app. C'était plus rapide à faire évoluer, et pour une équipe bénévole c'était le bon niveau d'effort. Deux côtés ont poussé pour passer en natif, sur le Play Store et l'App Store.
Leurs habitants ne comprenaient pas qu'une application ne soit pas sur les stores. Et on ne pouvait pas l'appeler autrement qu'une app, puisqu'il n'y avait pas de version ordinateur. C'était un problème de crédibilité côté client, pas un caprice.
De bonnes raisons techniques : les notifications et la géolocalisation étaient nettement plus simples en natif.
J'ai cédé. Et le coût a été supérieur à ce qu'on avait anticipé : ça a considérablement allongé le temps de développement, avec une équipe bénévole qui n'avait pas cette marge.
Aujourd'hui encore je ne sais pas si c'était la bonne décision. L'argument des collectivités était réel, celui des développeurs aussi, et le coût l'était tout autant.
Le cadrage : chiffrer le coût du passage avant de dire oui, et poser une date à laquelle on aurait regardé si la présence sur les stores changeait quelque chose à l'acquisition. On ne l'a jamais mesuré.
Il y a eu d'autres arbitrages où je n'avais pas le dernier mot : les décisions d'architecture, tranchées par les leads techniques, et les ateliers qu'il a fallu repersonnaliser entièrement pour chaque collectivité parce que notre format standard ne convenait pas.
Pendant des années, l'app n'instrumentait pas son propre usage. Il fallait un socle data pour répondre à une question simple : combien de personnes commencent un parcours, et combien le terminent ?
raw_strapi_* · 14 tablesstg_strapi__* · 13 vuesdim_ et fct_ · 7 tablesLe socle permet maintenant de voir l'entrée du parcours. La prochaine mesure à instrumenter est l'activation à J1, qui demande de relier comptes et parcours : elle n'est pas dans les marts actuelles.
Les chiffres de cette section sont extraits par requêtes SQL en lecture seule sur les marts de production, via Claude connecté à BigQuery.
L'EPIC globale #655 est le point d'entrée : un objectif, trois P0 de survie, les grandes epics par squad et le parking. Plus de sprints datés, on raisonne en saisons.
Les labels ready-for-dev, good-first-issue et help-wanted servent à l'onboarding des bénévoles : un ticket cadré, avec des critères clairs, qu'un nouveau dev peut prendre tout de suite.
🔗 EPIC #655, Roadmap 2026 sur Framagit · accès aux tickets sur demande
Kikouchou aide à organiser des séjours de groupe, et en particulier la répartition des chambres. Avant de dépenser en acquisition, je voulais vérifier que le besoin existe, et chez qui.
D'abord les hébergeurs, puis les organisateurs de groupes. Seuil de décision fixé à l'avance : 3 réponses sur 10.
Parcours réel des visiteurs, hors comptes internes, de la landing jusqu'à l'invitation.
Volume de recherche de la catégorie avant de dépenser un euro de publicité.
2 réponses sur 10, et deux chiffres leur suffisent : pas de douleur de ce côté. L'utilisateur de Kikouchou est l'organisateur du groupe, pas l'hébergeur. La seconde vague a donc visé les organisateurs.
La catégorie ne se cherche pas : « organiser un week end entre amis » pèse 10 à 100 recherches par mois. Seul le nom d'un concurrent connu, Tricount, se cherche vraiment. Publicité sur la catégorie sans objet, donc aucune dépense avant d'avoir tranché la cible et le message.
Le projet est informel et en cours. L'échantillon est petit (8 séjours créés), et aucun chiffre d'affaires n'existe à ce stade. Ce cas montre la méthode, pas un résultat commercial.
Chaque information vit à un endroit. L'état d'un suivi dans sa base, l'historique dans un journal, les règles dans une page de référence. Une copie ailleurs finit par diverger.
Quand quelque chose change, on remplace la ligne concernée. L'historique va dans un journal où l'on ajoute sans réécrire, et une décision annulée reste écrite.
On ne duplique pas une page pour la mettre à jour. Une seule page canonique, modifiée là où elle est.
Jamais à la racine. Un compte rendu va dans la base des comptes rendus, pas en page libre.
On ne le supprime pas et on ne le laisse pas traîner.
Pas de mot de passe dans une page. Les identifiants partagés passent par un coffre.
Ce portfolio est produit avec Claude à partir de BigQuery, Framagit et Notion. Je relis chaque chiffre avant publication.
Parlons de votre produit.