Il y a quelques semaines, Philippe, CTO part-time de l’équipe, montait sur scène au Dataquitaine pour raconter comment Hones a construit Miska, un outil interne qui automatise une bonne partie de notre méthode d’audit.

Un vrai retour terrain, sans filtre, avec les bugs inclus.

Le problème de départ n’est pas technique

Chez Hones, on fait du conseil tech et produit. Notre valeur, c’est une expertise terrain accumulée sur des missions d’accompagnement de dirigeants. Mais cette expertise vivait dans des templates Notion, des trames de slides, des checklists éparpillées. Un travail manuel conséquent, difficile à répéter et encore plus à faire monter en charge.

L’idée de Miska est née de là. Pas d’un désir de faire de la tech pour la tech, mais d’une question concrète : est-ce qu’on peut automatiser ce qu’on fait à la main sans perdre ce qui fait la qualité de notre méthode ?

Un outil développé en 15 jours.

La plateforme couvre l’intégralité du workflow d’audit : tableau de bord, gestion du périmètre, base documentaire, planification des entretiens, prise de notes structurée, construction des constats et génération du rapport final. Du début à la fin.

15 jours de développement effectif. Front, back, agents IA spécialisés inclus.

Ce chiffre a fait lever des mains dans la salle lors de la conférence, et c’est normal.

On le reconnaît volontiers : c’est ridiculement peu comparé à ce que ça aurait représenté il y a quelques années avec un UX designer, un PM, plusieurs développeurs sur plusieurs mois. Sur les phases de production documentaire, notre vélocité a été multipliée par deux, avec 100% de la méthode Hones embarquée dans l’outil.

Ce qui a rendu ça possible : BMAD

Le cœur de notre approche, c’est le framework open source BMAD (Breakthrough Method for Agile AI-Driven Development). L’idée centrale : plutôt que de balancer des prompts en vrac à un LLM généraliste, on orchestre des agents spécialisés qui ont chacun un rôle précis, un contexte limité, des artefacts à produire.

Un agent analyste. Un agent PM. Un agent architecte. Un agent développeur. Chacun reçoit uniquement ce dont il a besoin. Un choix délibéré, car avec un contexte trop large, l’agent commence à compenser ce qu’il ne comprend pas.

Mais BMAD n’a de valeur que si la spécification en entrée est solide. Ce qu’on a appris rapidement : si on n’est pas capable d’expliquer fonctionnellement son métier à un humain, on ne sera pas capable de l’expliquer à un agent. L’outil amplifie la clarté, il n’en génère pas.

La phase de conception dans BMAD inclut ce qu’on appelle la “revue adversariale” : l’agent PM soulève les incohérences, force à trancher avant même qu’une ligne de code soit écrite. Un dernier filet avant le développement.

La où on s’est plantés

Premier écueil : partir trop grand. Avoir des ambitions larges ne pose pas de problème en soi, mais vouloir tout automatiser d’un coup génère exactement le problème qu’on cherche à éviter. Des contextes trop vastes, des agents qui mélangent les sujets, des résultats qui dérivent.

Deuxième point : la démo ne suffit pas. Un cas test qui fonctionne bien une fois ne dit rien sur ce qui se passe en conditions réelles sur quinze missions différentes. Chaque prompt doit être réévalué sur des cas terrain variés.

Et l’UX, qu’on a sous-estimée. On a envisagé un formulaire, même un chatbot à un moment. Notre vélocité nous a permis de corriger le tir rapidement, de construire un vrai design system et de repartir sur des bases plus solides.

Une direction claire pour les années avenir

Il y a dix ou quinze ans, on faisait du sur-mesure. Puis l’industrie a basculé vers le SaaS, la modularité, essayer de faire tenir ses besoins dans des outils standardisés. Avec des méthodes de développement comme celle-là, le sur-mesure redevient viable économiquement. On en a eu la confirmation concrète : un outil de back-office complet spécifié et livré pendant un trajet Paris-Brest, utilisable le lendemain midi.

L’étape d’après pour nous, c’est de passer de l’outil structuré à un vrai sparring partner : un agent à gauche, le livrable à droite, et une itération continue sur tout processus intellectuel, que ce soit pour préparer une proposition commerciale, rédiger un rapport ou structurer une décision.

Une startup qui levait 5M€ pour construire son produit peut aujourd'hui le faire avec deux fois moins, en deux fois moins de temps.

Ce n'est pas une hypothèse, c'est ce que vivent déjà les équipes tech les plus avancées.

Cycles raccourcis, coûts compressés, PMF atteint plus vite : l'IA est en train de réécrire les fondamentaux du build, et avec eux, toute la logique du financement de l'innovation tech.

Ce glissement soulève une question que personne dans l'écosystème n'a vraiment envie de poser à voix haute : si les startups ont objectivement besoin de moins de capital, comment le rôle des fonds d’investissement va-t-il évoluer ?

Le système de financement de la tech tel qu’on le connaît s’apprête à vivre un vrai basculement.

Lever des fonds est-il en train de passer de rite de passage à aveu de faiblesse ?

Les business angels et accélérateurs captent-ils mieux la réalité des startups tech d'aujourd'hui ?

Et si le réseau et l'expérience opérationnelle étaient devenus la vraie denrée rare

🎤 Replay d’un échange animée par Joachim CEO de Hones, avec :

• Olivier Tilloy, Managing Director chez Techmind

• Matthieu Sénéchal, CTO de Hones

• ce qu’il se passe réellement lors d’une levée quand l’entreprise change d’échelle,

• ce que demandent vraiment les acquisitions une fois qu’il faut les intégrer,

• comment arbitrer quand le business, le produit et la tech doivent fonctionner ensemble,

• et ce que ce type de trajectoire transforme durablement dans la posture d’un CEO.

Un condensé de ce qu’un dirigeant voit vraiment quand il enchaîne les acquisitions.

—

🎤 Replay d’un échange animée par Joachim Fourquet (CEO de Hones), pour tous ceux qui doivent piloter une trajectoire post-levée où la stratégie prend enfin la forme de décisions concrètes.

IA générative, frameworks ultra-matures, démocratisation des outils no-code/low-code...

Le build s’accélère. La barrière technologique s’effondre.

Et si demain, refaire Doctolib ne demandait que quelques jours ?

Et si des systèmes bancaires pouvaient être reconstruits en un sprint ?

Une question se pose alors :

👉 La tech peut-elle encore faire la différence ?

Quand tout le monde peut construire des logiciels :

• L’avantage concurrentiel ne se trouve plus dans le code,

• Et la tech devient une simple commodité.

Le vrai différenciateur, dans les prochaines années, ne serait-il pas votre capacité à faire connaître, vendre, et faire adopter rapidement votre solution ?

Une question qui soulève des enjeux clés pour les fondateurs, VCs et CTOs :

• Où placer ses priorités ?

• Comment réallouer ses budgets entre R&D et GTM ?

• Faut-il revoir les grilles de valorisation ?

• Le rôle du CTO doit-il se transformer en profondeur ?

🎤 Replay d’un échange en live animé par Joachim Fourquet, co-fondateur de Hones

avec :

• James Rebours, CEO – Klark AI

• Olivier Gerardin, Operating Advisor – Serena

• Matthieu Sénéchal, CTO & co-fondateur – Hones