De Notion à l'agent IA : comment nous avons industrialisé nos audits tech
Replay de la conférence au Dataquitaine le 19 mars 2026 - Philippe Quemener
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.
📽️ Voir le replay : https://www.dailymotion.com/video/xa5e0hg
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.
📽️ Retrouvez le replay complet de la présentation au Dataquitaine ici !