5 jours, du 18 au 22 mai 2026. Une équipe de 7 personnes répartie sur plusieurs campus de Rocket School. Profils mixtes : 2 Growth Marketers, 2 Business Developers, 2 Customer Success Managers. Deux d'entre nous (dont moi) avions une expérience Lean Startup. Les autres pas. Voici comment on a livré Revelo, et les 3 leçons que j'en retire pour quiconque pilote une équipe pluridisciplinaire sur un sprint court.
01. Le contexte : Rocket School #17 et le projet Revelo
Le hackathon Rocket School #17 dure 5 jours du lundi au vendredi, en méthodologie Lean Startup pure : 1 jour = 1 étape. La promesse pour les équipes : produire un MVP testé, un dossier de synthèse de 20 slides, un pitch vidéo, un Business Model Canvas et une stratégie d'acquisition avec preuves de traction. Pas une simulation : des vraies interviews terrain, du vrai outreach, des vrais retours utilisateurs.
Le sujet qu'on a tiré : comment permettre aux équipes Customer Success et Key Account Management d'anticiper les churns et les baisses de contrat avant qu'il ne soit trop tard pour réagir. Un sujet sec, technique, B2B SaaS. Pas un sujet "fun" qui aurait excité tout le monde le premier matin. Un sujet adulte.
On l'a nommé Revelo : une IA prédictive qui croise les données d'usage réelles d'une plateforme avec les engagements contractuels, pour alerter les équipes Revenue et CSM sur les contrats en train de glisser vers le rouge. Ciblage Grands Comptes SaaS, modèle freemium (Discovery 4 mois gratuit puis Elite Annual payant).
02. Le défi : équipe pluridisciplinaire, asymétrie d'expérience
Le vrai défi n'était pas le sujet. C'était la composition de l'équipe. Sept personnes réparties sur plusieurs campus de Rocket School : deux Growth Marketers (dont moi-même), deux Business Developers, deux Customer Success Managers. Tous compétents dans leur domaine. Tous motivés. Mais avec une asymétrie marquée sur l'expérience hackathon et Lean Startup : seuls les deux Growth en avaient pratiqué avant.
Moi j'ai 6 ans en conseil chez Accenture et chez Pyxo en Customer Success, et j'ai pratiqué le Lean Startup sur des vrais projets clients. Je connais le cycle Build-Measure-Learn par cœur. Je sais que la plupart des équipes en hackathon perdent au moment où elles se mettent à construire avant d'avoir interviewé.
L'asymétrie d'expérience aurait pu créer deux pièges symétriques : soit on impose en chefs et l'équipe perd son engagement, soit on travaille en démocratie pure et on perd 2 jours à débattre du nom du produit. Pour les éviter, j'ai dérivé 3 leçons que je peux maintenant formuler clairement, et qui valent bien au-delà du hackathon.
03. Leçon 1 : embarquer plutôt que diriger
La tentation, quand tu as l'expérience et que les autres ne l'ont pas, c'est de basculer en mode "je sais, vous ne savez pas". Tu décides vite, tu expliques après. Tu gagnes du temps sur les premières heures, et tu détruis 4 jours d'engagement de l'équipe.
L'inverse aussi est dangereux : faire semblant d'être en démocratie pure quand on sait que certaines décisions sont structurellement meilleures que d'autres. C'est de la lâcheté méthodologique qui finit en débats interminables.
Le bon équilibre que j'ai cherché : formuler les questions, apporter les éléments factuels, laisser l'équipe trancher.
Exemple concret
Sur le choix de la cible (Head of CS ou KAM ?), j'ai apporté les éléments : ticket moyen B2B, accès à la donnée, taille du marché, niveau de douleur ressenti. L'équipe a débattu 30 minutes. Elle a tranché.
C'était la décision que j'aurais prise. Mais ils l'avaient prise avec moi, pas contre moi. À partir de mardi soir, l'équipe a internalisé ce mode de raisonnement. Le mercredi, ils proposaient eux-mêmes les bonnes questions à se poser avant de coder. Je n'avais plus à animer, je facilitais.
Le coût et le bénéfice
Cette méthode a un coût en temps : une décision prend 30 min au lieu de 5. Mais le retour sur investissement est énorme. Une équipe embarquée le mardi soir est une équipe qui peut tenir 3 jours sans pilotage centralisé. Une équipe dirigée le lundi est une équipe qui dépend du pilote en permanence et finit le vendredi sans avoir grandi.
Pour reformuler la leçon : l'expérience est une responsabilité, pas un droit. Plus on connaît la méthode, plus on doit la transmettre, pas juste la déployer seul.
04. Leçon 2 : l'équipe novice est un atout, pas un handicap
L'autre leçon contre-intuitive du hackathon : les coéquipiers sans expérience Lean ont posé les meilleures questions de la semaine. Pas malgré leur naïveté méthodologique, à cause d'elle.
Un Lean expérimenté a des angles morts. Il a tellement intériorisé certaines règles qu'il ne se pose plus les questions de base. Il assume des choses qui ne devraient pas être assumées. Quelqu'un qui découvre la méthode, lui, voit des choses qui devraient nous interpeller mais qu'on ne voit plus.
Trois questions naïves qui ont changé notre projet
- "Pourquoi on cible des Head of CS et pas directement les CEO ?" Posée par une CSM. Réponse facile en théorie, plus compliquée à formuler clairement : ça nous a forcés à expliciter notre proposition de valeur pour chaque persona, ce qui a renforcé le ciblage.
- "Est-ce qu'on doit vraiment refuser de coder pendant 2 jours ? Ça ne devient pas une posture ?" Posée par un BizDev. Question légitime. On a passé 20 min à formaliser pourquoi (80% des hackathons perdants codent trop tôt, le jury sanctionne précisément ce raccourci). Cette discussion a soudé l'équipe sur le pourquoi de la méthode, pas juste sur le quoi.
- "Pourquoi notre 'Top 5 comptes à risque' n'est pas juste un score ? Les utilisateurs vont vouloir comprendre." Posée par une CSM. C'est devenu un élément différenciant majeur du MVP : chaque score est expliqué par 3 facteurs visibles, pas une boîte noire.
Ce que ça implique pour le pilote
Si tu pilotes une équipe novice, ta première discipline est de traiter chaque question naïve comme un signal, pas comme une perte de temps. Quand quelqu'un demande "mais pourquoi on fait ça ?", la pire réponse est "parce que c'est la méthode". La meilleure est de prendre la question au sérieux et de chercher si l'équipe expérimentée n'a pas un angle mort.
Cette discipline est exactement l'opposé du "j'ai déjà fait ça, je sais". Le novice voit des choses que l'expérimenté ne voit plus.
Que ce soit en hackathon, en sprint d'innovation, ou pour le lancement d'une offre : embarquer une équipe novice tout en gardant la rigueur méthodologique est exactement ce que je fais en freelance.
Voir mes offres05. Leçon 3 : l'IA agentique est un démultiplicateur, pas un substitut
C'est sans doute la leçon la plus actuelle, et la plus mal comprise. Tout le monde sait aujourd'hui que des outils comme Claude, ChatGPT ou des agents IA personnalisés peuvent accélérer un projet. Beaucoup en concluent qu'ils peuvent remplacer une partie du travail. C'est une erreur.
Ce que l'IA a fait pour nous pendant le hackathon
Concrètement, en 5 jours, nos agents IA ont produit en parallèle pendant qu'on faisait autre chose :
- Des brouillons de Lean Canvas itérés après chaque interview, ce qui nous a permis d'aller vite sur la formalisation
- Des structures de personas pré-remplies à partir des verbatims, qu'on n'avait plus qu'à valider et corriger
- Des trames de copywriting pour la landing page, en parallèle du wireframing
- Une première version du Business Model Canvas en 30 minutes au lieu de 3 heures
- Des scripts d'outreach LinkedIn personnalisés par persona en quelques minutes
Le gain de temps cumulé sur les 5 jours est estimé à 15-20 heures par membre d'équipe. Sans l'IA, on n'aurait jamais produit autant de livrables de qualité dans le temps imparti.
Aucune IA, aussi puissante soit-elle, ne pourra remplacer les 7 entretiens qu'on a menés en condition réelle. Aucune simulation, aucun "Et si je te jouais le rôle d'un Head of CS ?", aucun prompt sophistiqué n'égalent une vraie conversation avec une vraie personne qui a une vraie problématique. L'IA accélère ce qu'on a déjà validé. Elle ne valide pas à votre place.
Où l'IA marche, où elle ne marche pas
Pour piloter intelligemment l'IA dans un sprint Lean, voici la règle que j'ai tenue :
| L'IA est puissante pour | L'IA n'a pas sa place pour |
|---|---|
| Itérer rapidement sur des livrables structurés (canvas, slides, scripts) | Inventer des verbatims que personne n'a prononcés |
| Synthétiser 7 interviews en patterns et insights | Simuler des interviews à votre place |
| Reformuler le copywriting dans la voix du client | Décider à votre place quelle hypothèse a été validée ou invalidée |
| Préparer 80% d'un livrable que vous corrigez en 20% | Pivot d'hypothèse stratégique (humain only) |
| Générer des variantes pour A/B test | Valider un product-market fit à votre place |
La règle d'or qu'on a tenue : l'IA produit, l'humain valide en confrontant au terrain. Jamais l'inverse.
Le piège à éviter
Le piège dans lequel sont tombées plusieurs autres équipes du hackathon : utiliser l'IA pour générer des verbatims "plausibles" parce que personne n'avait le courage de prendre 30 minutes pour booker des vrais RDV. Résultat : leur Lean Canvas était joli, mais ne reposait sur rien. Le jury le sanctionne immédiatement : "5 à 8 interviews en direct, pas un Google Form. Le jury demande des verbatims réels."
L'IA peut t'aider à formuler tes hypothèses. Elle ne peut pas les valider. C'est cette distinction fondamentale qui sépare un usage adulte de l'IA d'une utilisation paresseuse.
06. Ce qu'on a livré au final
Au vendredi 16h30, on a déposé :
- Revelo : MVP cliquable d'une plateforme IA prédictive pour Customer Success, avec dashboard mocké, landing page fonctionnelle, et démo des alertes de risque sur compte réel.
- Dossier de synthèse 20 slides : ICP, 2 personas, Lean Canvas, BMC, étude de marché, stratégie d'acquisition, plan d'onboarding détaillé sur 4 mois (gratuit) puis 12 mois (payant), analyse concurrentielle, KPIs, Gantt.
- Pitch vidéo 4 min 30 avec story-arc complet (problème, solution, business model, projections, équipe).
- Preuves de traction : 7 interviews qualitatives réelles, campagne LinkedIn outbound mesurée, retours analytics de la landing page.
Note : le résultat final du jury est attendu courant juin 2026. Cet article sera mis à jour avec le classement et les retours jury dès qu'ils tomberont.
07. Les 3 leçons en synthèse
Si vous êtes freelance, consultant ou manager qui se retrouve à piloter une équipe pluridisciplinaire sur un sprint court (hackathon, sprint d'innovation, lancement d'offre) :
- Embarquer plutôt que diriger. Formuler les questions, apporter les éléments, laisser l'équipe trancher. Coût en temps au démarrage, ROI massif sur la durée.
- L'équipe novice est un atout. Les questions naïves cassent les hypothèses cachées des expérimentés. Traiter chaque question comme un signal, pas comme une perte de temps.
- L'IA est un démultiplicateur, pas un substitut. Elle accélère les livrables, elle ne remplace jamais les retours terrains. L'IA produit, l'humain valide en confrontant au réel.
08. Ce que j'en garde personnellement
L'expérience la plus précieuse de cette semaine, ce n'est pas le projet Revelo (même si je suis fier de ce qu'on a livré). C'est d'avoir réussi à transmettre la méthode Lean sans la transformer en cours magistral, et de voir mes coéquipiers la rejouer seuls le jeudi sur des micro-décisions tactiques. Ce moment où tu sens que la méthode est devenue la leur, c'est exactement ce qu'on cherche quand on accompagne des équipes en transformation.
Pour aller plus loin sur la dimension philosophique du pilotage Lean, j'ai écrit un article sur les 4 Accords Toltèques appliqués au Lean Startup. Le pont entre méthodologie rigoureuse et hygiène mentale, c'est ce qui m'a permis de tenir ces 5 jours sans m'épuiser.
Si vous avez une équipe à structurer sur un sujet d'acquisition, d'automatisation ou de lancement d'offre, et que vous voulez quelqu'un qui apporte la méthode tout en faisant grandir vos collaborateurs : c'est exactement ce que je fais en freelance aujourd'hui. Cabinets de conseil, formateurs, libéraux, indépendants. Pas du conseil en chambre, du pilotage en condition réelle.