Tout ce que je construis commence par une recherche d'une réponse existante. Parfois, il n'y en a simplement pas.
Comment j'en suis arrivé là
La version courte : je finissais toujours par construire l'outil dont j'avais réellement besoin plutôt que celui qui existait déjà. La version longue commence par un jeu.
Knightmare est toujours actif, juste en pause : un Maître du Jeu IA conçu pour mener une véritable campagne de jeu de rôle sur table en 1:1 — pas un chatbot qui joue un rôle de MJ, un agent réellement capable de mener la table comme le ferait un MJ humain. Tout le monde dans l'équipe joue au JDR ; l'AD et moi sommes tous les deux MJ. Construire son orchestration d'agents sur LangGraph m'a appris exactement où ça casse — la frustration qui a planté « il va falloir que je réécrive ça » bien avant que je le fasse vraiment. Nous avons mis un prototype fonctionnel entre les mains de vrais joueurs, et le retour a été constant : il fallait de vrais financements pour que ça devienne ce que ça devait être. Alors l'équipe a tranché : construire d'abord quelque chose qui rapporte, puis revenir sur Knightmare avec les moyens nécessaires. Le nom de KGM Technologies en est la preuve : prenez les majuscules de KniGhtMare et vous obtenez KGM.
Comment je pense le logiciel
Les systèmes survivent aux vrais utilisateurs
J'ai livré des logiciels qui survivent à la démo. Plus de 90k lignes en production chez KGM, un client payant qui dépend de Notalyse — les deux devaient survivre à de vrais utilisateurs et de vrais cas limites, pas à un chemin heureux soigneusement choisi. C'est la barre que je fixe à chaque système avant de le considérer terminé.
Une infrastructure ennuyeuse est un atout
Les parties d'un système que personne ne voit — déploiement, pipelines de données, la tuyauterie entre les services — reçoivent le schéma le moins glamour et le plus éprouvé disponible, volontairement. Le risque créatif appartient aux parties que les gens ressentent réellement ; tout ce qui les soutient doit être assez ennuyeux pour ne jamais faire la une.
Honnêteté sur les limites
Je préfère dire à un client que quelque chose ne fonctionnera pas avant de le construire plutôt que de laisser le périmètre déraper silencieusement après. Le moyen le plus rapide de perdre la confiance d'une équipe, c'est une confiance qu'on n'a pas méritée — donc je dis ce que je sais vraiment, et je signale ce que je ne sais pas.
Résoudre des problèmes que personne n'a n'est pas de la vantardise, c'est un sous-produit de la façon dont je traite les nouveaux problèmes. Chaque projet est traité comme son propre cas particulier — ses propres contraintes, ses propres risques, sa propre forme. Je cherche d'abord ce qui existe déjà : la plupart de ce que je construis part d'une idée existante que je plie autour des contraintes réelles du problème. Construire à partir de zéro est rare, réservé aux cas où rien d'autre ne convient vraiment. Cet instinct — retrouver le même schéma sous-jacent dans une plateforme de conformité juridique, un projet de jeu à cinq personnes et un framework d'agents — est la même connexion transversale qui se manifeste par l'hyperfocus une fois que je suis plongé dans l'un d'eux, et par la franchise quand je dis la vérité à un client plutôt qu'un argument de vente.
Comment j'utilise l'IA
Je traite l'IA comme n'importe quel outil : un levier, pas un remplacement du jugement. Ce portfolio en est la preuve, pas juste une affirmation — chaque décision d'architecture, chaque brouillon rejeté, chaque mot de la voix sur cette page m'appartenait ; l'exécution a été une collaboration avec un agent IA que j'ai dirigé et relu comme je relirais un ingénieur très rapide et très littéral. Je ne le romantise pas et je ne le méprise pas non plus — j'ai construit des frameworks d'orchestration d'agents à titre professionnel, donc j'ai vu précisément où ça va vite et où ça a encore besoin d'un humain qui tient la vraie compréhension du problème.
Sur quoi je travaille en ce moment
- KGM Technologies
- Notalyse
- Projets R&D personnels
Ce que je ne suis pas
Je ne suis pas designer visuel — je m'améliore, mais le soin de l'interface ne me viendra probablement jamais aussi naturellement que l'architecture backend. Je n'ai aussi jamais géré une grande équipe d'ingénieurs ; la plupart de ce que j'ai construit, je l'ai construit seul ou avec une poignée de personnes. Je pense que je serais bon à ça — je n'ai simplement pas encore eu l'occasion de le prouver. Et je ne suis pas vendeur : conclure en gérant les émotions de quelqu'un n'est pas une compétence que j'ai développée. Ce que j'ai, c'est un vrai talent pour expliquer les enjeux — découper un problème en options réelles (économique, intermédiaire, haut de gamme, chacune avec les compromis qui vont avec) pour que quelqu'un puisse vraiment décider par lui-même plutôt que se faire vendre quelque chose.
En dehors du code
En dehors du code, j'entretiens des aquariums — de vrais biotopes, pas de la décoration : équilibrer la chimie de l'eau, les plantes et la faune pour obtenir quelque chose qui tient vraiment la route dans le temps. Le même instinct que le travail, appliqué aux aquariums plutôt qu'aux serveurs.