Flexiwork : discovery produit, un arbitrage build-vs-buy, et 45 minutes ramenées à 30 secondes

Contexte

Flexiwork est une plateforme B2B de location et d’acquisition d’espaces de bureaux. J’y suis intervenu deux fois, à quatre ans d’écart. En 2022 et 2023 comme front-end engineer sur la refonte de la plateforme, dans une équipe de deux personnes. En avril 2026, ils m’ont rappelé, cette fois comme consultant produit et technique.

Être repris par un ancien client est la partie de cette histoire dont je suis le plus fier, et c’est la raison pour laquelle les deux missions appartiennent à la même étude de cas.

Première mission : la décision de ne pas écrire le code

Problème

La plateforme avait besoin d’une refonte. J’étais responsable des spécifications produit et du choix de la stack technique, j’ai retenu Next.js et Tailwind, et j’ai mené toute la refonte UI/UX sous Figma.

Puis je suis arrivé à une conclusion contraire à mon propre intérêt : l’équipe ne serait pas capable de maintenir une base de code sur mesure après mon départ. Personne ne pouvait en être propriétaire. Une plateforme sur mesure bien construite que personne ne peut faire évoluer vaut moins qu’une plateforme modeste que l’équipe sait réellement opérer.

Ce que j’en ai fait

J’ai décidé de reconstruire la plateforme en no-code. Cela impliquait de noter chaque fonctionnalité selon sa faisabilité sur la nouvelle stack, de reporter en V2 celles qui pouvaient attendre, et d’être explicite sur ce qui serait perdu. Puis j’ai livré la refonte seul avant de passer la main.

La leçon que j’en ai tirée est celle que j’applique encore : la bonne architecture est celle avec laquelle l’équipe peut vivre une fois que vous êtes parti.

Seconde mission : conseil produit, de bout en bout

Problème

Quatre ans plus tard, l’entreprise avait grandi et la contrainte avait changé de place. L’acquisition, les opérations, la donnée et la conversion demandaient toutes du travail, et rien ne disait par quoi commencer ni ce qui méritait d’être construit.

Discovery et PRD

J’ai mené la discovery d’une roadmap produit en quatre chantiers : acquisition organique, outillage interne, infrastructure de données et conversion commerciale. Le tout formalisé dans un PRD complet et présenté aux fondateurs, pour que le plan soit quelque chose qu’ils puissent challenger et s’approprier, plutôt qu’une liste de tickets.

Le séquencement était la substance de la recommandation : acquisition, puis opérations, puis données, puis conversion. Chaque étape alimente la suivante, et les faire dans un autre ordre gâche le travail.

Build ou buy, avec des chiffres

Pour chaque chantier, j’ai tranché entre construire et acheter, avec un ROI benchmarké. C’est là qu’un consultant justifie ses honoraires, et la réponse honnête est souvent « achetez-le, ou ne le faites pas encore ». Décider ce qu’on ne construit pas vaut plus que construire vite.

Ce que je livre

J’exécute sur les quatre chantiers :

• Un générateur de présentations commerciales propulsé par l’IA. Des APIs Claude orchestrées via n8n, qui produisent les supports commerciaux que l’équipe assemblait à la main.
• Une refonte SEO technique pour faire fonctionner l’acquisition organique.
• L’agrégation automatisée d’offres multi-sources, pour ne plus collecter les annonces manuellement.
• Une deal room côté prospect avec suivi d’engagement et synchronisation HubSpot, pour que l’équipe commerciale voie ce qu’un prospect a réellement regardé.

Approche technique

Le générateur de présentations est la pièce qui montre le mieux comment j’utilise l’IA en production. Le problème intéressant n’est pas d’appeler un modèle, c’est de l’ancrer : le support doit contenir les vraies offres, les vrais chiffres et la vraie mise en forme de l’entreprise, ce qui veut dire que le LLM est une étape à l’intérieur d’un pipeline qui collecte et met en forme les données d’abord. n8n orchestre ce pipeline ; le modèle fait la partie où il est réellement bon.

La même discipline traverse la deal room, où HubSpot reste le système de référence et où le produit s’y synchronise plutôt que de le dupliquer. S’intégrer aux outils dans lesquels une équipe vit déjà, plutôt que lui demander de déménager.

Difficultés

Le plus dur dans la seconde mission n’est pas technique. C’est de tenir une roadmap en quatre chantiers dans l’ordre, quand chaque chantier a quelqu’un qui le veut en premier. Le PRD existe exactement pour ça : rendre les arbitrages visibles pour que la décision appartienne aux fondateurs, et qu’elle tienne.

Résultat

Le générateur de présentations propulsé par l’IA a fait passer un workflow commercial de 45 minutes à 30 secondes. La roadmap est séquencée, formalisée et exécutée chantier par chantier.

[ADD RESULT : résultats sur les chantiers acquisition et conversion, une fois qu’ils pourront être mesurés et partagés.]