Une équipe produit qui shippe avec l’IA : ce que ça veut dire vraiment, Florian Bruniaux

Arriver chez Méthode Aristote pour sortir une V1 de plateforme EdTech from scratch

Écouter à 04:44

Florian explique comment il a rejoint Méthode Aristote, une Head EdTech très early, alors que la boîte démarrait à peine. Il revient sur le positionnement du projet, avec du soutien scolaire hybride et une approche AI first pour des élèves de la quatrième à la terminale. Le chapitre se concentre surtout sur le défi de sortir une V1 de plateforme EdTech from scratch en quelques semaines, avec une petite équipe senior et peu de contraintes.

Florian: on m'a attiré vers une boîte qui s'appelle Méthode Aristote, qui est ma boîte actuelle, qui est une Head EdTech, qui est très early. Donc, j'ai rejoint la boîte en juillet, Mais les statuts ont été déposés en septembre. 2025. 2025, oui, tout à fait. Et à la base, la méthode Aristote, C'est du soutien scolaire pour des enfants de la quatrième à la terminale, pour les accompagner dans leur progression scolaire, Que ce soit des élèves en difficulté qui ont besoin de soutien pour réussir, ou, à l'inverse, Des élèves qui visent l'excellence et qui, en gros, vont préparer des concours. Et le pitch de la boîte, c'était d'être ai first. Tant dans le produit, donc, avec une approche où on a du soutien scolaire hybride, des humains, des tuteurs humains en distanciel. Par contre, qui vont accompagner des enfants avec des cours en visio, mais également une palanquée d'exercices et d'outils ai pour les aider. Et donc le produit AI, Mais en fait, l'organisation, surtout les fondateurs, qui sont des serials entrepreneurs qui on avait déjà cofondé. Le groupe Cartésien, qui est un groupe Head EdTech, plutôt en mode PME, on va dire, qui fonctionne, qui tourne, qui est le groupe à partir duquel on a fait notre levée de fonds. Donc, méthode, Aristote, À l'heure actuelle, On est une petite dizaine, plutôt des profils seniors, plutôt tous coûteux suisses, tous convaincus par l'IA. Et on est Ai first, Orga et, à tout sa fond, Que ce soit les techs, les produits, les sales, les markets, vraiment tout le monde. Et en fait, c'était ça aussi. Leur volonté des fondateurs, C'était d'avoir une petite équipe très dynamique, qui allait aller très vite. Et ils ont dissocié du coup. Méthode aristote du groupe. Parce que le groupe fonctionne très bien, a sa stabilité, Ils ne voulaient pas déranger ça, mais en même temps, Ils avaient envie d'aller challenger et tester un nouveau marché, les enfants, et le soutien scolaire avec des nouvelles méthodes. Et donc, en juillet, Quand j'ai signé, c'était est-ce Que t'es capable de nous sortir une V1 from Scratch? Vu qu'il n'y avait pas de code base, ils avaient poqué le truc. On va dire à l'ancienne avec de la bidouille. Et pour la rentrée, donc, concrètement, je suis rentré au 15 juillet, avec pour objectif de sortir la première version au

Terry: mois de septembre pour septembre, donc en l'espace de 5 semaines. Une première version d'Apple à solo, donc de produit, même je dis d'Apple, mais de produit de plateforme EdTech. Donc, tu as réussi J'ai réussi.

Florian: J'ai réussi. Alors, c'était assez intense. Après, j'avais signé pour et de toute façon, ça m'amusait. Et je partais pas, on va dire, sans rien. Donc, en gros, J'avais un bagage EdTech parce que j'étais redevenu hands-on depuis quelques années. Donc, je savais quoi faire. Je savais comment le faire. Les délais ont fait que j'ai fait des choix pragmatiques. Le fameux Build Or Buy. Donc, je savais comment j'allais dérouler ma partition. J'avais des guidelines pour la partie produit, mais en même temps, pas trop de contraintes. Donc, en gros, Il fallait surtout qu'on ait un truc pour exister. Mais je n'avais pas trop de contraintes et de frictions. Et on m'a laissé dans mon coin. En gros, on m'a donné une vision des grandes features à implémenter et à peu près le look que ça devait avoir. Et après,

Terry: on m'a dit débrouille-toi. Le scénario un peu idéal de la page blanche, avec quand même une compréhension métier. D'un point de vue, vision de ceux qui portent le projet initialement. Et toi, te dire, il faut dérouler, applique les bonnes pratiques que tu connais et, surtout, utilise au plus possible l'IA. Ce que je trouve intéressant, c'est qu'aujourd'hui, comme je disais, là, on parle. Donc, tu rentres dans l'aventure en juillet 2025, septembre 2025, cinq semaines après, Il y a un premier produit qui est là. Et là, On enregistre fin avril 2026. Maintenant, ce n'est plus juste toi à l'équipe produit et EdTech. C'est globalement une dizaine de personnes avec un ratio qui est lequel entre les profils, les développeurs, product people, sales, CSM. C'est quoi un petit peu sur cette dizaine de personnes, le ratio

Florian: En gros, sur 10 personnes, il y a moitié Équipe EdTech produit et moitié opérationnel, ops, sales. En interne, après, on a quelques sales externes en freelance qui nous accompagnent en temps partiel, on va dire, pour du funding, Ce genre de choses. Et nos tuteurs qui sont, par contre, Je ne les ai pas comptés dans les disques, qui sont des tuteurs, qui sont la plupart des étudiants en grandes écoles, qui sont en freelance et qui nous accompagnent. Et donc, On est deux DEVS seniors à l'heure actuelle, où on a tous les deux entre 13 et plus de 15 ans d'expérience. Et après, on a trois... Product Engineer, en gros, c'est des couteaux suisses produits qui, à la base, viennent plutôt du monde de la pédagogie, dont deux anciens profs, un ancien prof de philo, qui est l'un des fondateurs, Un ancien profil qui est plutôt commerce et qui, après, a été prof, Et l'un des rares juniors qu'on a dans l'équipe, qui est un profil qui a 25 ans et qui est plutôt, lui, Construction du matériel pédagogique à destination des élèves. Très concrètement, comment on prompte correctement l'IA pour faire des bonnes apps EdTech.

Terry: Trop bien. Et par rapport aujourd'hui, à la proposition de valeur de ce produit-là sur lequel vous continuez d'évoluer, C'est un produit qui agit comme une marketplace. C'est quoi un peu les fonctionnalités principales du produit que vous avez construit ?

Comment fonctionne l’abonnement de soutien scolaire et le rôle des tuteurs

Écouter à 10:18

Florian décrit un modèle d’abonnement, et non une marketplace, pour inscrire un enfant avec une ou plusieurs séances de cours par semaine. Il explique aussi la période d’essai avec un tuteur humain, les essais possibles si cela ne fonctionne pas, puis la co-construction d’un programme d’accompagnement. Enfin, il présente le rôle des tuteurs, les exercices autonomes et le nouveau système supervisé, avant de préciser qu’ils sont encore en phase de PMF.

Florian: Alors, non, ce n'est pas marketplace comme on pourrait l'avoir sur certains de nos concurrents. Là, On est plutôt sur une logique en gros. D'abonnement, donc. Les familles vont pouvoir abonner leur enfant sur un format avec en gros une ou plusieurs séances de cours, donc avec un tuteur humain par semaine et après autant de séances dites d'entraînement ou supervisées souhaitées. Donc, concrètement, Ce qui va se passer, c'est que les parents inscrivent leur enfant, ils ont une période d'essai, etc. L'enfant va avoir une séance avec un tuteur pour voir si ça fit. Si ça ne fit pas, en gros, il a le droit à un ou deux essais pour trouver comment le fait. Dans le vrai tutorat, avec un prof à domicile ou un truc comme ça. Quand ça fit des deux côtés, parce qu'honnêtement, il faut que ça vienne de l'élève, mais aussi du tuteur. Après, on lance la machine et le tuteur va co-construire avec l'élève, un programme d'accompagnement en fonction que ça soit du soutien. En français, en anglais, en gros, On fait tout le programme scolaire français des filières générales et on commence à ouvrir au fur et à mesure et aller chercher des choses un peu différentes, comme des élèves qui vont être dys, qui vont avoir des problématiques dyscalculiques, dyspraxie, etc. Donc, on essaye d'y aller à tâton. Et le tuteur va pouvoir donner des devoirs, en quelque sorte, des séances en autonomie où l'élève va pouvoir se connecter sur la plateforme. Faire les exercices que son tuteur lui a donnés, des exercices type chatbot, des exercices type QCM, des exercices divers et variés. On essaye de sortir de plus en plus du chatbot pour arriver vers un truc, Un peu un format dynamique. Ou même pour réviser un oral d'anglais, pour réviser les verbes irréguliers en anglais. On a tous eu ça quand on était au collège, Ce genre de choses. Et on commence là à lancer un nouveau format, qui est le système supervisé. Un tuteur comme une séance d'études qui va être connectée et pouvoir répondre aux élèves en séance en autonomie qui vont pouvoir lever la main, en gros appeler le surveillant, Dire là, j'arrive pas, est-ce que tu peux m'aider ? Et voilà, Et en ordre de grandeur, on a à peu près 300-400 élèves déjà abonnés en période payant. Concrètement, et je sais pas, je suis... Plus sur la EdTech, mais quelques, en gros, peut-être 100 ou 200 qui doivent être en période d'essai. Et donc, On est encore en phase de PMF. Concrètement, on se construit.

Terry: Hyper clair. Donc, Un produit qui vient supporter toute la phase derrière d'apprentissage, à la fois d'un point de vue. Expérience des enseignants et expérience apprenant. Parce qu'il y a les deux, du coup, la construction des cours. Et le run des cours. Oui, c'est ça.

Florian: En fait, On a plusieurs personas et nos deux personas principaux sont évidemment les élèves. Parce que c'est celui qui paye. Les tuteurs, à l'inverse, sont nos salariés, on les paye. Mais par contre, Les tuteurs ont besoin d'être outillés au maximum pour être le plus pertinent possible et pour pouvoir dégager le plus de valeur pour les élèves. Donc oui, on travaille en sorte que l'élève, ça soit facile pour lui. Et que, pour le tuteur, en fait, il puisse faire vraiment du custom pour ses élèves.

Terry: Très clair. Du coup, maintenant, Ce que je te propose, c'est qu'on fasse un petit peu, au final, On revient en arrière, mais pas si longtemps que ça,

Choisir Next.js, Vercel et des briques sur étagère pour aller vite

Écouter à 13:41

Terry revient sur les cinq premières semaines du démarrage, quand Florian était seul et devait sortir une première V1 de la plateforme en moins de deux mois. Terry lui demande aussi quelle a été sa démarche sur les outils, ce qui a fonctionné rapidement et comment il a arbitré entre construire lui-même et acheter des solutions sur étagère. Florian explique alors avoir choisi une approche pragmatique avec TypeScript, Next.js, Vercel et Clerk, en privilégiant ce qu’il maîtrisait déjà pour aller vite.

Terry: parce qu'on parle d'un démarrage. En juillet 2025. Sur ces cinq premières semaines sur lesquelles, au départ, tu étais seul, tu as. Cet enjeu-là de construire une première V1 de la plateforme, telle qu'elle est maintenant aujourd'hui. Et on va venir, au fur et à mesure, après... En ces quelques mois, du coup, de comment t'as fait entre la V1? Que t'as sortie? Pour ensuite onboarder une nouvelle personne? Et permettre en fait autant du coup à d'autres profils. Donc DEV Seniors, que les profils product de contribuer à la construction de cette plateforme avec les outils modernes. Mais déjà, toi, donc t'arrives solo. Tu viens d'un passé une dizaine d'années dans le management, donc t'étais quand même sorti de la EdTech. Même si, évidemment, t'as une formation d'1G et tu travailles au quotidien avec des DEVs que tu manageais donc que... Tu as ces compréhensions de concept et de manière de fonctionner, n'empêche pas moins que tu étais sorti un peu du côté end. zone. Et donc tu arrives avec cet enjeu, qui est quand même un bel enjeu, en l'espace de moins de deux mois, de réussir à sortir une première veille d'un produit. Quels ont été, à ce moment-là, toi, quelle a été ta démarche ? Et rapidement ensuite, sur les outils que tu as utilisés, là où tu as eu des bons résultats rapidement, Versus les choses que tu as mis de côté parce que tu t'es dit, ça ne va pas le faire. Et également, ton approche entre construire les choses versus acheter des solutions sur étagère. Comment tu as arbitré, tout ça Une version un peu condensée de ton apprentissage sur ces cinq premières semaines qui t'ont permis de sortir la viande du produit.

Florian: Oui, alors déjà, Je rebondis sur un point. Je n'ai pas fait le passage directement de « je suis hands-off » à « je code en cinq semaines » parce que j'avais fait un passage entre les deux par une autre boîte où justement, je m'étais rechauffé très concrètement. J'avais largement pris confiance et c'est ça aussi qui a fait que j'avais accepté aussi ce challenge qui en était. un, qui était en mode pas de problème. En plus, étant donné que j'ai carte blanche sur la techno, typiquement, je suis parti sur du pragmatique. En fait, j'ai toujours été pragmatique sur les outils, pas d'effet Waouh et tout, c'est faut aller vite. J'ai fait du TypeScript, je maîtrise le TypeScript, J'allais évidemment repartir là-dessus. Je maîtrise Next.js parce que juste avant, j'avais des problématiques de SEO et tout. Je suis parti sur du Next.js. Alors qu'il y aurait pu avoir des débats par rapport à là pour une plateforme EdTech. Mais en gros, c'était Je prends ce que je maîtrise pour aller vite. En gros, ma zone de confort. Très clairement, c'est ça. Je reste dans ma zone de confort pour ne pas faire de folie. Et après, sur les outils, typiquement, des points de friction classiques, c'est pour l'hébergement. Je ne voulais pas me prendre la tête à monter des trucs de fou au début. C'est en gros, Solution sur étagère. Next.js, serverless, Vercel, Ceux qui ont créé le framework. Donc, en gros, on ne s'embête pas. Au début, c'est gratuit. On sait qu'à un moment, il faudra payer un peu plus. On l'accepte. Il faut créer un système de connexion, d'authentification, Surtout que là, on va avoir des mineurs et tout. Donc, il faut entre Guillemets, montrer pas de blanche, que ce soit safe. Je pouvais recoder, mais non, J'ai pris un outil sur étagère qui s'appelle Clerc, qui n'est pas très cher et qui marche bien. En gros, en plus, on n'a pas mis de contraintes de budget. On n'allait pas s'enflammer non plus, mais à un moment, s'il fallait mettre 200 balles pour une licence mensuelle. Dans un truc, on m'a direct, dit, Il n'y a pas de souci, Il y a déjà de l'argent. En fait, Un point aussi qu'il faut spécifier, c'est qu'en fait, on avait fait une levée de fonds. Auprès de notre groupe, donc, c'est mes fondateurs qui ont mis eux-mêmes dans leur nouvelle boîte. Je suis arrivé comme si on sortait post-seed donc c'est confort quand même et après, au fur et à mesure, par exemple, on veut faire de la visio, J'allais par coder une solution de visio, j'ai Bench rapidement, J'ai trouvé une solution qui convenait, On a estimé combien ça allait coûter et c'est parti et à chaque fois, les décisions, par contre, c'est J'identifie, je fais un petit bench, je donne des tarifs. Et en quelques heures, en gros, le matin, Il va falloir un truc visuel. Le soir, J'ai déjà mon go par les fondateurs. On a anticipé un peu ce que ça allait coûter, comment ça allait scale, etc. Et on y va. Donc, au fur et à mesure, c'est allé assez rapidement.

Premiers usages de l’IA pour le design et la duplication de code

Écouter à 17:23

Florian explique qu’au début, il n’utilisait pas encore vraiment l’IA, même s’il s’appuyait déjà sur des outils comme GitHub Copilot et une licence ProPlus pour l’aider à identifier des solutions. Pour les premiers usages concrets, il s’en sert surtout pour faire évoluer les specs, esquisser des idées de design à partir de screenshots et l’aider à répliquer certains services ou types d’utilisateurs. Terry relance ensuite sur cette première version du produit, où l’IA générative sert surtout à dupliquer des classes et à étendre les capacités d’un IDE avant la suite de l’accélération.

Terry: Sur cette phase de bench, est-ce que déjà, là, tu t'appuyais sur l'Ia Là, pas d'un point de vue dev, mais d'un point de vue du Perplexity, du claude. Perplexity,

Florian: gentiment, pas encore. Je vais y revenir plus tard. Maintenant, c'est vraiment, ça fait partie de mes outils phares, on va dire. Encore à ce moment-là, j'étais, donc je dev dans WebStorm, donc un IDE. Et j'utilisais Github, Copilot, mais j'avais déjà une licence ProPlus, en gros, Donc, avec accès à tous les modèles et largement de quoi, on va dire, être outillé. Donc, ouais, je... Je demandais à ce qu'ils m'aident à identifier une solution. Typiquement, pour la visio, Je n'avais encore jamais fait. Donc, là, je m'en suis servi. Après, par contre, j'ai pas mal repioché dans mes anciennes codebase. Donc, en gros, Je suis revenu, j'ai réappliqué ce que je maîtrisais. Et ça, je le précise parce que je n'ai pas Vibe codé, comme le terme a été pas mal décrié. En mode, tu laisses le truc codé tout seul, tu ne sais pas ce qu'il fait. Non, là, en gros, J'ai repris du code que je maîtrisais, qui avait été fait, On va dire, à l'ancienne par des seniors, dont moi, mais pas que. Donc, J'ai repris les choses qui avaient fait leur preuve, que j'avais en plus testé, challengé, éprouvé depuis deux ans et demi. Donc, je suis parti sur des bases saines. Et c'est seulement après, On va y venir, où j'ai... passé, j'ai enclenché la deuxième et où j'ai beaucoup accéléré sur la partie IA. Au début, c'est rien de fou, c'est juste, J'ai bossé beaucoup, j'ai refait ce que je savais faire, même si j'ai pas été Endzone tout au long de ma carrière, J'ai piloté des DEVS qui, eux, l'étaient et qui allaient vite. Donc, en gros, juste, J'ai appliqué tout ce que je savais faire en condensé pour sortir la première plateforme.

Terry: Et donc, là, sur ces cinq premières semaines, au final, T'as pas utilisé plus que ça? L'IA générative à ce moment-là ? De ce que j'entends ?

Florian: Pour changer les specs, Pas mal en gros, quand j'avais une idée en mode pour y aller un peu pour les designs aussi, parce que, concrètement, moi, j'ai plutôt un bagage. bagage, enfin plutôt un Dev back, Slash, même Devops sre, Dans les faits. Depuis, je suis full stack, je touche à tout et je suis expert en rien, mais par contre, j'ai pas trop la fibre. UI, ux. Pour moi, le joli, c'est subjectif, donc j'ai Merci. Plus utiliser par rapport à ça différents outils, même du lovable, des fois pour bidouiller, mais juste la partie graphique pour avoir une idée. En gros, je veux faire un truc qui va ressembler à ça, Je mettais des screenshots de quelques templates ou sites qui me plaisaient et je demandais à lovable de me faire un truc. Et après, j'aurais utilisé ça pour donner la screenshot en gros, du coup, à copilot pour y aller et après, pour challenger certains points, typiquement aide-moi à répliquer mon service euh... J'ai fait les utilisateurs, j'ai dit n'importe quoi, Il faut créer un nouveau type d'utilisateur, aide-moi. En gros, il répliquait. Donc, au début, c'était très orienté. chatbot, entre guillemets. Au fur et à mesure, Quand j'ai voulu accélérer, c'était en mode agent, puisqu'au pilot, c'était amélioré. Donc, en gros, me générer mes fichiers et tout. Mais c'était rien par rapport à l'usage que j'ai maintenant avec claude, que j'ai pensé après la première version.

Terry: Ok, hyper intéressant. C'est intéressant parce que ça pose bien aussi le cadre que sur cette première version, sur laquelle tu as pu à la fois, permettre aux produits d'exister et derrière de pouvoir embarquer des équipes autour, tu as quand même construit une première fondation où globalement, tu maîtrisais les briques technologiques que tu emboîtais ensemble, que ce soit des briques prises, pas mal sur étagère par rapport à ce que tu dis, Plus des bouts de code que tu avais déjà créés dans d'autres expériences passées avant et dont tu avais une connaissance et une expertise aussi assez fine. Donc ça, c'est assez clair. Donc, tu poses ce premier produit de cette manière en commençant à utiliser l'IA générative, Mais plus pour la duplication de classes, étendre les fonctionnalités classiques d'un IDE pré-Gene AI. Ensuite, si on accélère, qu'est-ce qui se passe entre cette V1 du produit qui sort. Septembre 2025 ? Et aujourd'hui, avril 2026, où vous avez un process assez intéressant, je pense, autour de l'usage, justement, de claude Code et des agents IA. Et cette approche vibe Coding, plus ou moins. Qu'est-ce que tu peux partager là ?

Passer à Claude Code et multiplier la vélocité de développement

Écouter à 21:37

Florian raconte qu’on lui demande d’accélérer sans recruter, ce qui l’amène à tester claude Code puis à s’y plonger sérieusement. Il documente ce qu’il apprend, itère sur ses erreurs et constate en quelques semaines une vélocité qui passe d’un niveau normal de dev senior à environ x2 ou x3. Terry interrompt ensuite pour revenir sur cette approche itérative et sur les premières bonnes pratiques qu’on peut en tirer.

Florian: Ce qui se passe, c'est qu'en fait, en septembre, Je suis fier d'avoir lancé ça. Donc, en gros, on est tous contents, On a tenu le truc. Et là, en gros, mes boss, presque un peu gênés. Donc, à la fois, Merci, Florian, c'est trop bien et tu t'es donné, tu n'as pas compté tes heures. Par contre, en fait, On a un bon problème, c'est que le business, on a une forte traction, Nos sales sont bons, ils vendent bien. Et du coup, en fait, On a plein d'idées de features encore à faire. Est-ce que tu peux encore accélérer ? Et donc ça, C'est le truc qui m'a... Donc ça, C'était même un petit peu avant, c'était presque fin août. En gros, ils me demandent, sans recruter, est-ce que tu en as encore sous le pied, sans te cramer Parce que, par contre, en plus, ils sont clairement axés humains, Donc ce n'était pas le message. Double taser. C'était en mode, est-ce que par peu importe le moyen... S'en recruter, T'as un levier pour aller plus vite. Et eux, direct, Ils m'ont dit, est-ce qu'il n'y a pas des trucs dans l'IA Débrouille-toi, en gros. Ben, si, je dis, je sais qu'il y a claude Code que j'avais un peu testé, mais j'avais survolé. Donc, je leur ai dit, si vous me laissez deux, trois jours, là, le temps que je regarde. Et là, je suis rentré dans claude, mais vraiment. Donc, j'ai pris la doc, j'ai regardé sous le capot, je m'y suis mis. Et plus, ça m'a intéressé, là, par contre, j'ai dit, ouais, là, Il y a un truc qui va être game, changer avec, justement, sortir du truc copilot qui, pour moi, est le niveau zéro, entre guillemets, le chatbot. Là, je me suis rendu compte que je ne traiterais pas bien. Le contexte, la mémoire, les outils et que j'allais accélérer. Là, Je m'y suis mis aussi sur mon temps libre. Très concrètement, j'ai commencé à documenter, à apprendre. Et dès que je faisais des erreurs à itérer, Et c'est ce qui est devenu par la suite, mon guide claude Code, dont je parlerai peut-être un peu plus tard. Et donc, à partir de là, Ma vélocité, on va dire, Si j'étais un niveau 1, c'était ma vélocité normale de DEV senior, bien, on va dire, un peu énervé. Elle a évolué en mode, en quelques semaines après claude Code, après avoir bien compris les mécanismes, etc. Je fais quasiment x2, X3 en termes de vélocité. Donc, je suis toujours dev. J'accélère toujours. Le backlog où on m'avait dit, est-ce que tu peux accélérer ? Je le tiens. Je tiens les features. J'enchaîne diverses et variées. Alors, je n'ai plus tout en tête. Mais concrètement, la première version, C'était genre 15% du Scope qu'on a actuellement. Donc, on fait... Des nouveautés, On fait déjà des refontes de certaines choses qui ont changé en cours de route parce que c'est Test and learn. Très concrètement, on est à fond dans... Il y a une idée le matin, l'après-midi elle est en prod ou le soir, elle est en prod, voire même pendant la réunion. En gros, je code un fixe ou un truc comme ça, donc je suis vraiment, je vais à fond. Et plus j'apprends à maîtriser l'outil, plus j'accélère. Vraiment, en gros, c'est Je fais une chose, j'apprends à ne plus la refaire. Je fais une connerie, j'apprends à ne plus la refaire. Et claude Code évolue aussi en même temps que moi, ou j'évolue en même temps que claude Code. Je veux dire, ça a été assez dingue. Il y a des communautés qui se mettent en place. Donc moi, à l'époque, Ça fait déjà des années que je suis dans EdTech Rocks, qui était plutôt orienté manager, senior, level, etc. Et là, il y a Greg Lottelier, qui, en gros, lance une communauté sur l'AI. En gros, dev with AI. C'est en gros, venez, en gros, les geeks, On va parler d'Ai et je me prends au jeu. Et on partage beaucoup et on se partage des bonnes pratiques et des conneries qu'on a faites. Et là, ça continue. Et là, j'outille. En gros, là, Je passe dans la phase où je ne suis plus juste. Un développeur produit, un métier. Je commence à construire des choses avec l'IA pour l'IA. Je commence à comprendre le context engineering. Je commence à comprendre qu'il faut que je versionne ma configuration. En gros, tout ce qui fait qu'on met en place des bonnes pratiques. Et ça continue. Donc, je tiens. Le rythme, voire même assez souvent, en gros, Je défense le backlog au sens où il n'y a plus rien en produit. Ils sont en retard. Donc, vers octobre, novembre, On fait rentrer. L'équipe produit dans Cursor. Pas pour coder.

Terry: Alors, on fait une pause là et après, on va venir ici. C'est très bien. Donc, déjà, la première pause là par rapport à tout ce que tu viens de partager. J'aimerais bien réussir à savoir. Tu as parlé de cette approche itérative de... En faisant, j'apprends ce qui marche, ce qui ne marche pas, en parallèle, évidemment. Et ça, Je trouve que c'est hyper intéressant aussi de le rappeler. Parce que le rapport au temps, quand on évolue dans le monde de l'IA, il est compliqué à garder. Je trouve parce que ça va tellement vite que des choses qui sont au final, qu'il y a quelques mois, On a l'impression que c'était il y a des années. Et donc, c'est bien de remettre les choses, c'est-à-dire qu'en fait 2025, c'est quand même une année. Je trouve assez charnière où les modèles ont atteint des performances vraiment intéressantes et en même temps, Il y a eu globalement une adoption assez vraiment massive des professionnels sur ces outils de Gen AI et non plus juste les premiers effets. Waouh qu'on avait sur. On va dire début 2024, donc à partir de fin 2024 et vraiment 2025. Je trouve en tout cas dans l'écosystème EdTech francophone, une véritable année assez charnière. Et donc, évidemment, en même temps que tout le monde progresse en termes de compréhension de comment ça marche, Il y a aussi la progression de ces modèles et donc leur performance. Et derrière tout ça, ça se nourrit mutuellement, et donc tu disais que tu as appris pas mal de choses sur cette première phase itérative. Quelles sont un petit peu du coup, les premières bonnes pratiques que tu peux en retirer? Avant d'aller ensuite sur la suite de faire monter une équipe produit dans le curseur, etc. Tu as parlé de context engineering, tu as parlé de à

Fact-checking avec Perplexity, contexte d’entrée et limites de tokens

Écouter à 26:47

Florian explique qu’il commence à faire réfléchir les modèles, puis à les fact-checker avec Perplexity pour éviter les hallucinations. Il décrit aussi comment il croise claude Code et Perplexity via MCP, en laissant parfois Perplexity choisir le modèle et en jugeant cette approche plus performante. Enfin, la discussion porte sur le contexte d’entrée du fichier Claude.md, la quantité d’informations à fournir et le fait de brûler trop vite ses tokens, ce qui l’amène à versionner sa configuration.

Florian: comprendre, déjà à jouer avec les modèles. Un truc tout bête, c'est que jusque là, comme certains l'ont même déjà dit dans ton podcast. J'ai connu GPT 3.5 4.1 dans Copilot et jouer, mais c'était pas fou. En gros, c'était, comme on disait au début, je disais, C'est un bon stagiaire ou un bon junior qui fait les tâches que je lui dis bien faire. Mais en gros, il n'y avait pas cette notion de plan, de réflexion où c'était juste pour m'apprendre. Un truc, genre, fais-moi un rate limiter ou un truc très complexe. Donc, après, je commence à faire réfléchir la machine. En gros, j'ai établi un plan avec un modèle opus à l'époque. J'ai dû commencer, je ne sais plus, c'était 3.7 ou 4, Dans ces eaux-là, en gros. Et ça commence à bien réfléchir, à faire des trucs cohérents, logiques. Après, j'apprends aussi à croiser, en fait, à les fact-checker pour éviter les hallucinations. Donc, typiquement, j'utilise Perplexity, On en parlait tout à l'heure. Perplexity s'interconnecte bien avec claude, notamment. Et donc, Je demande à claude d'aller fact-checker en utilisant Perplexity, qui utilise, lui-même d'autres modèles, du coup, d'aller vérifier une information. Tu me dis que Telltool est le leader du marché. Va vérifier. Donc, en gros, c'est cette notion de tu m'affirmes quelque chose, soit je sais déjà la réponse et je lui dis oui ou non, parce qu'il y a des hallucinations, soit en gros, Il va chercher l'information, il me redemande.

Terry: Donc, là, Tu connectes claude Code, via MCP à Perplexity. Tout à fait. Et tu lui... Je lui demande,

Florian: c'est moi explicitement qui dit au lieu... Alors, on m'a déjà dit, pourquoi tu n'utilises pas simplement la recherche de claude

Terry: C'est ce que j'allais te poser comme question.

Florian: Parce que claude utilise son modèle. Sauf que moi, en gros, dans Perplexity, on peut faire en sorte de choisir ses modèles, etc. Donc l'idée, c'est aussi de croiser deux outils. Et on va sans avoir benchmarké, Je n'ai pas de vrais chiffres. Je ne suis pas un doctorant ou un truc comme ça. Mon ressenti est que c'est plus performant en termes de qualité en faisant comme ça. Parce qu'en plus, Perplexity va chercher plus profond avec les Deep search. En gros, il donne pas mal de matière. Donc, on peut me sortir des articles de Reddit, de Stack Overflow, même si c'est en train de disparaître. Mais de donner plus de matière, ça marche bien. Donc, j'apprends à jongler avec les outils. Déjà, il y a ça aussi.

Terry: Et tu laisses ce perplexity choisir le meilleur modèle Ou tu le définis justement le modèle que Perplexity veut Par défaut, non,

Florian: Je le laisse choisir. Pour l'instant, qui est aussi sûrement un axe d'amélioration. Donc j'apprends moi-même aussi à jouer avec ça. Après, j'apprends évidemment à faire correctement. Le contexte d'entrée, donc le claude MD, mais qu'on retrouve aussi avec les autres LLM, Gemini, etc. Mais donc, le contexte d'entrée, C'est quoi mon projet C'est quoi? Ma Stack Qu'est-ce que je veux faire ? C'est quoi? Mes rules Et donc, après, comme beaucoup, au début, Je mets plein de choses. Après, je me rends compte que je crame mes tokens trop vite. Donc, au début, je commence avec la licence à 20 balles. Au bout de 5 heures, je l'éclate. Donc, je passe à la licence à 90 balles. Au bout d'une ou deux semaines, Je l'éclate trop vite. Je passe à la licence 20x à 200. Maintenant, j'en ai 3 des licences à 200 pour donner un peu le rythme. Donc j'apprends ça. J'apprends à versionner aussi la configuration.

Terry: Juste sur le claudeMD, qu'est-ce que tu retiens, toi, à date, en termes de bonne pratique Le CLAUDE.MD, c'est ce fichier-là qui va être à la racine un peu de ton projet, qui va donner du contexte, comme un product guide peut te donner aussi sur le contexte global de quel est le produit que tu construis, et potentiellement, après, des contraintes techniques, des sujets de base de données, enfin, des sujets que tu veux donner. Mais si tu mets trop de choses, c'est quelque chose qui va à chaque fois être... Inclus dans la fenêtre de contexte. Quand tu vas compter, donc ça va prendre des tokens dans cette fenêtre de contexte, donc ça va te manger plus de tokens que nécessaire si jamais tu lui dis tout le temps. Trop d'informations et créer du contexte. R.O.T. Parce qu'il y a à la limite la problématique de trop de Tokens. Donc on ouvre un peu plus les vannes,

Florian: On est prêt à payer ce que j'ai fait, etc. J'ai la chance d'être dans une boîte qui est Ai First et qui, en gros, on m'a pas dit Ah non, non, tant pis t'as cramé ta licence, tu te débrouilles. En gros, pas de problème passe à la plus grosse, donc ça, c'était facile. Mais après, il y a la qualité, les hallucinations, comme on dit et donc, déjà, il faut savoir, C'est qu'entre le moment où je me suis mis à claude, donc en gros, fin août, début septembre et maintenant, Les règles ont changé. En gros, c'est différent. Parce que déjà, au début, la tendance, C'était plutôt un gros claude MD, Alors que maintenant, on est revenu à un petit claude MD qui fait moins de 150 lignes. Il y a eu la folie des MCP. Tout le monde a fait des MCP. Mais au début, les MCP étaient chargés. Tous les outils étaient chargés d'emblée, donc pourrissait le contexte. Donc, il fallait les activer et désactiver. Depuis, ils ont sorti ce qu'on appelle le Lazy loading. Les fonctions du MCP sont chargées de façon intelligente à la volée. Après, j'ai appris, Il y a les skills qui sont sortis, qui ont fait parler d'eux.

Terry: Yes, pardon. Il y a beaucoup de choses, mais ce que je voulais voir, sur la partie claudeMD, à date, les bonnes pratiques. Tu disais petit. claudeMD, 150 lignes.

Florian: Petit claudemd, qui va référencer d'autres fichiers à charger au bon moment, et des règles qui vont être des règles métiers, des règles, Merci. Technique et architectural. Et sur le claude.mD. En tant que tel, c'est à peu près. Tout après, on utilise d'autres mécaniques. Et après, je t'avais arrêté sur les skills et même avant, quand je t'ai dit Attends, on fait une pause sur CLAUDE.MD. Tu partais sur continue

Terry: sur les skills,

Florian: ça va me revenir, donc en gros, sur la Config, c'est ça. C'est anthropique qui est en tout cas avec mon sens de lecture. En gros, je parle souvent de claude, parce que c'est celui que j'ai utilisé, parce que c'est celui que je maîtrise. Dans les faits, Tout est transposable et je pense qu'on peut faire des super choses avec à peu près tous les outils. Je pense que Anthropic a pris le Lead sur la partie, plutôt des Enterprise et sur les DEVs. Et on voit que la tendance se confirme de toute façon, avec tout ce qu'ils sont en train de sortir. Et donc les skills, On apprend à l'IA à savoir faire des choses et à aller les chercher au bon moment, en fonction de ce qu'elle est en train de faire. Après, on apprend à faire des rules, donc des règles qui définissent ça, C'est un bon test. Ça, c'est une belle fonction. front-end. Ça, c'est une belle fonction. back-end. Ça, c'est comment on fait du design system chez méthode, Aristote, etc. Ce sont des petits bouts de connaissances, comme des petits cours qu'on donnerait des petites guidelines. Et en gros, on apprend à lui injecter au bon moment. Et c'est là où, dans le contexte engineering, Il y a pas mal de travail. C'est ça, c'est ce jeu de... En donner assez, ni trop, ni trop peu, et de l'injecter au bon moment, en fonction de ce sur quoi il est en train de travailler. Donc, il y a un jeu. Et aussi, Ce qui est intéressant, c'est que... Plus j'ai passé de temps avec claude, plus j'ai adapté ma config. Le paroxysme a été en gros en fin d'année 2025, où 50% de mon temps et de mes commits étaient de la Config. AI. Et ça, c'est intéressant. C'est un truc, surtout que je communique... De tes commits humains. Pardon ?

Terry: De tes commits humains.

Florian: Ouais, ouais. Même humains ou assistés. Mais en gros, c'est... Ce n'est pas quelque chose de statique. En fait, ça devient une nouvelle compétence, comme les DEVS ont appris à faire du clean code ou appris à faire des choses. Les PM ont appris à faire des PRD. Utiliser l'IA correctement devient un hard skill à part entière. Et en gros, un truc qu'on fait évoluer, ce n'est pas, on le fait une fois, après, on l'oublie. C'est en gros, C'est devenu un truc que j'ai entretenu au cours du temps.

Terry: Là-dessus, C'est quoi ton avis sur le métaprompting Moi, j'aime beaucoup faire ça. C'est-à-dire que je demande à l'IA de m'aider à construire ce type de document ou en fonction de ce que je souhaite faire. Notamment, Si je veux prompter pour un besoin en particulier, je vais d'abord prompter pour m'aider à écrire ce prompt-là. Ou après, dans des cas de Workflow agentique, que j'ai des bouts de systèmes prompt à écrire, Je vais faire en sorte de demander à l'IA de m'aider à écrire ces systèmes. prompt. Donc, là, pour la construction des claudeMD, même des skills, etc. À quel point tu utilises cette approche-là de métaprompting Utiliser l'IA, elle-même pour qu'elle te donne...

Florian: Je le fais même tous les jours, honnêtement. Je fais toujours ça, en fait. J'écris déjà quasiment plus une ligne de code. Quand je le fais, en gros, c'est sur des hooks, au dot mechanic, du shell, de l'outillage pour l'IA. Et même les fichiers. Markdown, C'est très rare. Tous les fichiers, que ce soit des agents, des skills, du MD, peu importe, c'est... Je donne mes directives à l'IA et c'est l'IA qui rédige et qui adapte. Évidemment, s'il y a une faute d'orthographe, je ne vais pas ramener, je ne sais pas combien, pour aller juste, supprimer une faute. Mais dans les faits, oui, le meta prompting et même de plus en plus, C'est quand je fais une tâche, même une tâche de mettre à jour mon claude MD pour le dégraisser, par exemple. J'ai un skill qui permet de faire ça. Donc, à chaque fois, Il y a cette logique de réutilisation, de mémorisation pour la fois d'après aller plus vite.

Terry: Yes, très clair. Donc ça, C'est les premiers apprentissages que je trouve hyper pertinents sur tes premiers mois, on va dire, d'onboarding très intense sur claudeCode. Ensuite, je t'ai arrêté tout à l'heure. Quand tu commençais à dire, On a fait venir une équipe produit et qu'on les a tous mis sur Cursor. Donc, je te laisse reprendre à ce niveau-là.

Faire entrer l’équipe produit dans Cursor avec le même contexte que les devs

Écouter à 35:44

Florian explique que, le produit devenant un bottleneck, l’équipe a cherché un moyen d’aller plus vite en donnant davantage de contexte aux profils produit, au lieu d’utiliser ChatGPT en simple chatbot. Ils mettent alors Cursor en place comme un chatbot qui a le contexte du projet, afin que ces profils puissent rédiger des specs plus pertinentes et guider plus directement le travail. Terry s’étonne de l’arrivée de profils non techniques dans un IDE, et Florian décrit une prise en main progressive, avec un premier volontaire, des specs assistées et des ajustements rapides.

Florian: Donc, là, en gros, Ce qui s'est passé, c'est que moi-même, J'ai musclé mon jeu, je vais plus vite, Je suis toujours un DEV qui va plus vite, mais je bosse encore tout seul. Pour l'instant, en gros, c'est On me donne des specs et après, tu te débrouilles, tu shippes. Et là, après, en gros, le produit devient bottleneck. Et j'ai plus assez de choses à faire. Donc, je trouve toujours du temps pour faire des tâches techniques, de la qualité, des tests. On ne s'ennuie jamais en tant que dev, mais à un moment, presque un peu. Et donc là, en gros, On se rend compte que le produit doit aussi aller plus vite. Et aller plus vite, il y a aussi. Donc, juste là, ils utilisaient Chatgpt en mode chatbot. Mais donc, il manquait le contexte. Il manquait le contexte du projet, etc. Donc, là, en gros, on décide... De trouver une façon pour qu'ils soient plus pertinents et qu'ils aillent plus vite. En gros, on met cursor parce qu'ils n'étaient pas encore assez técosses pour utiliser claude, Code ou quoi. Donc, on prend Cursor, mais ils l'utilisent comme, En fait, Chatbot, qui a le contexte du projet. Donc, en gros, ils ont une idée de feature. Ils sont en mesure de me faire une Spec qui peut dire. Et tu pourrais te brancher sur telle partie du code qui fait déjà à peu près ce que tu veux. Et donc là, on augmente la vélocité parce que déjà, ils se font plus guider, etc.

Terry: Le coup d'entrée sur cursor pour ces profils non techniques, parce qu'à la base, cursor, c'est un IDE, donc c'est les outils à la base réservés aux développeurs, c'est Integrated, development environment. Donc, là, on est en train de. C'est quelque chose qu'on voit dans toutes les fonctions, On produit justement cet outil. Et moi, ça me surprend parce que je me dis. Mais alors les profils techniques? Pas de question, mais des gens qui viennent pas du tout qui n'ont jamais vu de terminal entre Guillemets et qu'on met dans un IDE direct, je me dis toi, c'était quoi, ça s'est passé. euh...

Florian: Ça s'est passé, on va dire, étape par étape. On est encore dans la transformation. Il y a eu un volontaire dans l'équipe qui a un profil faux, aussi. Donc, smart de base, Pas un junior. C'est quelqu'un qui a plus de 15 ans d'expérience sur différents métiers, etc. Mais quand même, qui sait s'adapter et apprendre, un fast learner, quoi. Qui avait des bases techniques, le vocabulaire, on va dire. Il sait ce que c'est du Python, du SQL, ce genre de choses. Le terminal, non, Il ne savait pas maîtriser et naviguer dans le terminal. Mais là, en gros, On parle d'un outil comme ça pourrait être un photoshop ou autre chose. En gros, on apprend un peu comment ça marche, et puis on bidouille. En gros, c'est ça. C'est aussi ce mindset qu'on retrouve dans le Early stage. C'est en gros, tu ne sais pas faire, tu testes, si tu casses, tu répares et ainsi de suite. Donc, en gros, non, Ça n'a pas fait trop peur. Et lui est rentré très vite. C'était le premier sur cette phase de Spec assisté. On a fait rentrer les 3 profits, donc comme ça et ça, a redébloqué le backlog. Et en gros, on a pu accélérer. Donc, sous-entendu, Ils m'ont recréé d'autres fichiers de SPEC plus vite, plus quali. Ce qui fait qu'en fait, étonnamment, moi-même, J'allais plus vite vu que je récupérais un truc déjà à mi-chemin entre la spec, le PRD pur fonctionnel et la SPEC technique, Vu qu'en fait, l'IA avait déjà donné des éléments. Mais en même temps, des fois, ils se laissaient en gros, Comment dire, avoir par l'IA qui sortait des solutions à bazooka. Pour faire un truc. Et donc, au final, Ils avaient presque perdu du temps sur la partie. Anticipation technique. Parce que j'arrivais, je disais, oui, mais non. En fait, on ne va pas faire comme ça. Donc, on a eu pas mal d'ajustements, mais les itérations sont très courtes. On ne parle pas, on ne fait pas de sprint, etc. Les itérations, Si on se plante, le lendemain, on fait mieux. Et ainsi, de suite. Et là où ça a un deuxième gros game, changer, on va dire, dans l'organisation, c'est justement, donc, Augustin, pour le citer, il se dit, OK, moi, Je veux aller encore plus loin. Il y a plein de petites tâches, en gros, sur lesquelles, Si je t'explique, tu vas me faire perdre du temps. En gros, sous-entendu, Si je pouvais les corriger, moi-même, Ça irait vachement plus vite parce que je n'aurais pas à écrire de ticket. On n'aura pas à les mettre dans Notion, etc. Je n'aurais pas à t'expliquer. En gros, je vais m'amuser aussi. Il avait aussi envie d'apprendre. Et donc là, il me dit, comment je fais pour envoyer du code en prod Concrètement, Il me demande si je suis OK. Moi, je dis évidemment. En plus, on parlait d'aller faire les petits fixes, des correctifs, pas les trucs, fun en gros, le support pour ainsi dire Donc je dis évidemment, tu es le bienvenu, donc là, moi, j'ai outillé pour éviter des bêtises, pour éviter qu'il supprime des fichiers qu'il ne faut pas,

Mettre des garde-fous, des hooks et une code review automatisée pour les contributions IA

Écouter à 40:00

Florian explique d’abord comment il a outillé l’usage de Cursor et claude Code en rapatriant sa configuration et en posant des règles pour éviter les actions risquées, comme pousser en prod ou merger sans validation. Il détaille ensuite ce qu’il considère comme un « game changer » avec les hooks, qui permettent de déclencher des garde-fous avant l’utilisation d’un outil, et les barrières mises en place pour interdire certaines opérations. Enfin, Florian raconte l’automatisation de la code review dans la CI, avec un rapport lisible en rouge, orange et vert, puis l’évolution du travail de l’équipe autour de ces PR.

Florian: Du coup, en termes d'outils, vas-y si tu donnes les grandes lignes de comment t'as outillé ça? Donc les grandes lignes, c'est déjà de rapatrier littéralement tout ce que j'avais moi en config sur ma machine, je le rapatrie pour que lui l'utilise. Il y a un défi, c'est que moi, je suis sous Mac, Merci. claude et claude Code. Lui est sous Windows et Cursor. Donc, on a déjà des trucs tout bêtes de configuration. Moi, j'ai une machine avec 48 go de RAM. Lui, une machine avec 16 go de RAM. Donc, on se prend quelques petits murs de config et tout. Passer ça, une fois que ça marche, c'est typiquement faire en sorte que, lui, Il ne fait pas attention. Je ne sais pas qu'on ne veut pas écrire dans un fichier de configuration sur la machine. On ne veut pas qu'il vienne pousser en prod sans mon accord. On ne veut pas qu'il merge. Une pull request sans que je sois passé dessus. Donc, en gros, c'est soit des règles, donc l'ODMD ou, on va dire, toute l'arborescence équivalente. Et moi, Ce que je découvre, qui est vraiment Game Changer, c'est les hooks. Les hooks, en gros, C'est quelque chose qui va détecter un événement et qui va pouvoir déclencher une action qu'on va pouvoir faire comme on veut. Concrètement, c'est juste, On écoute un événement avant d'utiliser un outil, on déclenche un pré-to-use, et là, On peut mettre un garde-fou, concrètement. Et mes gardes-fous, c'est non. En gros, Augustin, non, Tu n'as pas le droit de toucher à ça, c'est trop risqué. Donc, en gros, à son claude ou à son cursor, ça dit pas le droit. Et donc, là, c'est tu ne peux pas supprimer tel fichier, tu ne peux pas supprimer. Sur la base de données de prod, ce genre de choses. Donc, là, j'ai mis pas mal de barrières. Je vais me donner l'image du bullying où, en gros, on met les barrières, le petit toboggan pour faire descendre la boule aux enfants et tout. En gros, le truc, c'est, entre guillemets, Il ne peut pas faire d'erreur. Dans les faits, ce n'est pas vrai. Il y a toujours eu des erreurs, mais jamais rien de grave. Honnêtement, jamais quoi que ce soit, qui nous ait porté, préjudice. Et après aussi plein d'aller-retour vraiment, ça a été une période où on a enchaîné du ping-pong quotidien pour ajuster, C'était vraiment, on tourne là, on tourne là, Ah mince, ça fait tourner là et on est passé du. Il n'est pas sachant en EdTech, il n'a jamais codé de sa vie, etc. À Il envoie sa première pull Request. En une semaine, la première Pull Request était trop grosse, on voit, il m'a fait comme un DEV junior classique, il envoie plein de trucs, c'est pas bien découpé, Merci. En réitère, je le forme en express. Et en gros, après trois semaines, Il me faisait des vrais pull requests quali qui répondaient aux critères de qualité de code qu'on avait, donc la couverture de test, le découpage. Et un truc qui a été aussi très utile, c'est tout le système de code review. On l'a automatisé. Donc, J'ai un agent qui tourne dans ma ci qui vient analyser plein de critères qui sont mes critères de qualité. Et qui donne un rapport à la fin que, par contre, j'ai mis en mode human readable. Donc, concrètement, rouge, pas bien, Tu n'as pas le droit d'avancer, il faut corriger. Orange, C'est pas ouf, mais si on n'a pas le choix, tu peux y aller. Vert, c'est du bonus, On ira plus tard. Et donc, là, c'est fin d'année. On met à peu près 15 jours où on va moins vite parce qu'on prend le temps d'affiner ça. On part en vacances de fêtes de fin d'année. Et on commence la nouvelle année, en gros, avec un dev. En plus, dans l'équipe, qui n'est pas un bon DEV au sens technique du terme, mais qui, par contre, est excellent en termes de business, parce qu'en gros, c'est lui-même qui avait fait toute la conception. Il est arrivé six mois avant moi, etc. Donc, il sait ce qu'il veut, il sait, le produit, il maîtrise tous les enjeux. Et là, du coup, par contre, en fait, lui, Il envoie de la feature. Et moi, je me mets à changer de rôle. Je me mets à envoyer plutôt de l'outillage et de la tâche EdTech.

Terry: Hyper intéressant. Parce qu'on vient du coup comme ça. Vers aussi l'évolution des métiers côté DEV et du rôle derrière, en tout cas, dans ton cas, de la technique. Donc, premier point que tu dis que je trouve hyper intéressant, C'est ce sujet de cursor au final que tu as mis en place. Pour pouvoir permettre à l'équipe produit d'avoir le même contexte que l'équipe de DEV et donc d'éviter en fait... La raison numéro 1 pour laquelle tu as introduit cursor, c'est pour être connecté à la base de code et, du coup, permettre d'interagir avec cette base de code. Mais d'un point de vue fonctionnel, d'un point de vue produit donc permettre aux product people d'interagir avec donc, là, j'imagine que tu leur... Juste petite question technique sur les modèles que tu sélectionnais dans cursor pour interagir avec cette base de code. Tu les laissais par défaut ou tu les forçais à utiliser les mêmes modèles que toi tu utilisais

Florian: Non, justement, comme moi, j'étais très axé sur les modèles anthropiques, au contraire. Il y a eu cette recherche, alors au début, en mode bidouillage, pour tester. C'était plutôt team. OpenAI, donc plutôt les modèles GPT, donc du codex, etc. Et puis, après, jouer avec les modes pour qu'ils réfléchissent beaucoup, pour qu'ils réfléchissent un peu moins, etc. Globalement, au début, C'était en mode, on met tout à faux. On met vraiment open bar.

Terry: Yes, yes. Du coup, ensuite, l'étape d'après, C'est notamment pour le profil le plus technique. Et qui voulait vraiment apprendre d'être capable, à partir de Cursor, d'aller émettre, d'aller pusher du code en prod, En tout cas, de soumettre des pull requests pour aller faire des petites améliorations de fixe. Et là, Ce que je trouve intéressant de ce que tu dis, c'est que toi, en tant que CTO, Ton rôle technique a évolué vers un rôle de facilitateur pour permettre à des gens moins techniques de venir contribuer à cette base technique, mais en gardant évidemment... Toute cette expertise que toi t'as accumulée au fur et à mesure des années. Et aussi cette compréhension de qu'est-ce qui fait qu'il y a un système derrière. On le pense d'un point de vue systémique, justement, et qu'on fait une architecture. Et on met des garde-fous qui permettent derrière de gérer la croissance. Donc, par rapport à ça, quels sont si on accélère? Là? Tu dis rentrée de vacances de Noël, donc à la rentrée 2026, tu commences à voir que ton rôle se déporte vers là, c'est-à-dire un rôle de jouty je mets en place les outils nécessaires pour permettre à ces profils moins EdTech de pouvoir contribuer au produit. Du coup, toi, dans cette évolution-là de ton rôle, Quelles sont les choses que tu as apprises ? Peut-être les erreurs que tu as faites, que tu ferais différemment aujourd'hui, avec le recul, même si c'est quelques mois, c'est toujours intéressant d'avoir ce recul-là. Et ensuite, si on accélère jusqu'à arriver à aujourd'hui, donc fin avril 2026, où vous en êtes là en termes d'organisation, de contribution à la base de code, à l'évolution du produit, de cette interaction entre profil DEV Senior, versus... Ce profil product au sein de ton équipe.

Rôle de tech. lead, code review et bottleneck QA

Écouter à 46:24

Florian explique qu’avec l’arrivée retardée d’un deuxième DEV senior, il se retrouve à gérer un gros volume de pull requests, à poser des garde-fous et à automatiser ce qu’il peut pour suivre le rythme. Il décrit ensuite son évolution vers un rôle de tech lead, en continuant la review humaine pour améliorer ce que la machine ne voit pas et en travaillant sur la configuration et l’optimisation du contexte. Quand un autre goulot d’étranglement apparaît côté QA, avec des régressions visuelles et l’absence de tests end-to-end, l’équipe fait intervenir un nouveau profil en stage pour tester et corriger.

Florian: Mon rôle, concrètement, à ce moment-là, donc, John Borde aussi, un deuxième DEV senior, Mais le temps qu'il arrive. Donc, pour l'instant, en gros, On considère, On est deux vrais DEVs de métier et un product builder qui envoie, par contre, lui, c'est Jules Auvert, la boîte de Pandore, par contre, lui, Il se met à envoyer comme un fou. Il envoie vraiment un rythme assez dingue, mais par contre, Il ne fait pas attention à tout. Donc, ma première erreur, c'est, en gros, Il faut vraiment y aller sur les garde-fous, faire attention. Et encore qu'il avait quand même un un certain sens critique, parce que pas un junior non plus, Un profil quand même qui dit, oh, Là, j'ai peut-être fait une connerie, donc en gros, je vais valider. Mais par contre, Il envoie un volume au début où j'ai presque du mal à suivre la Code review. Au début, je fais de la code review humaine. Donc, après, pareil, je ne m'étais peut-être pas assez préparé. J'avais peut-être pas assez anticipé qu'il allait m'envoyer. 7, 10 pull requests par jour, parfois. Et qu'en gros, après, c'était, Pourquoi ce n'est pas encore merde tout ce que j'ai fait Parce que je n'arrive pas à suivre, en fait, au outillé. Donc je pense que ça, il faut l'anticiper. Ça peut aller. En fait, quelqu'un qui connaît bien ce qu'il doit faire, Il peut aller très, très vite. En fait, donc, on prend un volume de code review de fou, beaucoup de code, Il faut automatiser tout ce qu'on peut éviter. En gros les allers-retours où le niveau de qualité de code n'est pas bon. Donc, au final, je repasse, On va dire peut-être plus de temps que lui à remettre des cares, donc en gros, encore une fois, Investir sur tout ce qui est lié à la Config pour garantir qu'on ait un niveau de qualité satisfaisante. Et donc ça, Il a fallu des semaines d'aller-retour, mon système de code review. Je pense que oh, ça doit être le truc où j'ai le plus de commits, etc. J'ai fait, je ne sais pas combien de versions pour arriver à un truc où il n'est plus passé. grand-chose. Et donc, j'évolue sur un rôle de tech. lead, un peu, On va dire, pendant un temps où je fais encore de la review humaine. Je relis le code littéralement et j'améliore en gros ce que je vois, que la machine ne voit pas, pas bien. Parce qu'en plus, je ne suis pas non plus un expert technique, donc c'est vraiment pas bien. Après, une fois que je commence, moi-même à avoir confiance en l'outil, là, je peux réévoluer pour refaire des nouveautés. Des nouveautés pour... Optimiser le contexte, pour sortir des nouvelles features, pour faire en sorte qu'on peut y se lancer une release en lançant une commande. En gros, tout ce qui améliore aussi mon quotidien. Du coup, pas que celui des autres, mais le mien. Et après, on arrive sur un autre Bottleneck qui est la QA, qui est on Shit vite. On n'a pas de problème de qualité logicielle, au sens où on a des tests et tout. Je veux dire, ce n'est pas le plus beau code du monde, mais on n'a pas du tout à avoir honte vu le rythme. Par contre, on a des petites régressions visuelles. On n'a pas encore de test. end-to-end. Donc, plutôt à des trucs en bout de chaîne, qui ne sont pas forcément graves, mais le bouton qui pète dans une certaine configuration d'écran. Ou alors on n'a pas bien testé. Donc, là, on se rend compte qu'il nous faut de la QA. Donc, bottleneck, QA, On fait intervenir un nouveau profil en stage qui nous fait en petites mains pour tester, Qui, lui-même se met à l'IA et Shipper les correctifs. Donc, mon rythme, en gros, à moi, de review s'intensifie encore. Et après...

Quand la vélocité devient un nouveau bottleneck produit et organisationnel

Écouter à 49:20

Florian décrit comment l’arrivée de nouveaux profils et l’accélération générale font émerger des coûts, des contraintes de CI, et des problématiques de scalabilité et d’organisation. Il explique aussi que les processus se réinventent, avec moins de réunions, des épics qui passent de plusieurs mois à quelques jours, et une vigilance accrue face au risque d’aller trop vite. Florian poursuit en montrant que cette vélocité change aussi la taille ressentie de l’équipe, les attentes produit et la nature des sujets à traiter, tandis que Terry rebondit sur l’idée de product waste. Terry insiste ensuite sur l’importance de bien comprendre le problème avant de choisir la solution technique, dans un contexte où l’IA accélère les essais et le techno push.

Florian: Deuxième, des PM rentrent dans le jeu. Donc, en gros, tout va beaucoup plus vite. On est confronté à des problématiques que moi, j'ai connues par le passé, mais avec des tranches de 6 mois, 1 an, J'en sais rien, Au début, on paye quasiment rien en CI, comme on va plus vite, On commence à avoir des coûts qui explosent. Comme on fait plus de déploiements, on éclate les fritières des différents outils. Et c'est plein de choses auxquelles en fait ça accélère. Comme on fait plein de tests unitaires, comme c'est l'IA qui fait, en gros, on en a plein, ça prend beaucoup de temps. Et donc, là, je me mets à gérer en ce moment des problématiques que j'ai connues. Avec des équipes de 10 ou 15 DeVs où il faut commencer à optimiser, à découper la ci, où on fait limite rentrer un profil Devops SRE dans l'équation. Et donc, en fait, ça qui est marrant, c'est que là, à l'heure actuelle, on va toujours aussi vite, même on a continué d'accélérer. On fait rentrer un non-tech dans la code base en une semaine, en gros, C'est à peu près le temps qu'il faut pour qu'il soit pertinent, etc. Tout à l'heure, On parlait de notre futur stagiaire. Je ne dis plus que je veux un stagiaire ingénieur, ce n'est plus le problème. Je préfère avoir un profil produit parce qu'on a craqué un peu le truc EdTech. Et je pense qu'à deux DEVS seniors, Comme on fournit à peu près autant que 8 à 10 devs, on est déjà à la bonne taille. Mais sauf qu'on a des problématiques d'une équipe de plus d'une quinzaine de personnes en EdTech produit. Alors qu'en fait, on est 3 à 5 fois moins. Donc, mes nouveaux sujets, c'est d'arriver à utiliser l'expérience CERN, se dire, mince, C'est des patterns que j'ai connus à telle époque, dans telle boîte, qui sont des problèmes de scalabilité, etc. Et honnêtement, C'est super intéressant. Et nos process se réinventent. Avant, j'ai toujours entendu que... Tous les six mois, on fait évoluer la méthodologie de l'entreprise, des techs produits. Et tous les 18 mois, On change fondamentalement. Je ne sais pas, Scrum, ShapeUp, Ce genre de choses. Nous, là, on est en mode Kanban. On essaye de minimiser les réunions. On n'a pas beaucoup de friction. Mais en fait, des fois, ça va vite, très vite. Et pourtant, Je suis plutôt en mode, je ne sais pas comment dire. J'aime bien quand c'est intense. Je réfléchis vite. Je suis assez à l'aise avec les plans qui changent, etc. Mais c'est vraiment... particuliers. Je veux dire, il faut aimer ça aussi. C'est du Early Stage et l'IA a fait qu'accentuer ça. C'est que il faut suivre aussi quand une épique, Avant, c'était plusieurs mois et on avait le temps d'anticiper, de réfléchir. Maintenant, une épique, c'est quelques jours, une semaine. Et donc, On donne aussi des mauvaises habitudes. Des fois, avec mon DEV senior, on dit On en a fait des enfants gâtés, pourris. En parlant de l'équipe produit, parce qu'en gros, ceux qui n'ont pas connu le monde d'avant... En mode, comment? Ça se fait que la grosse épique de tout le système de paiement qu'on a commencé lundi, Elle n'est pas encore en prod, On est quand même jeudi. Alors comment t'expliquer ? Donc, en fait, on arrive sur des nouvelles problématiques où on se dit, mais attends, On est allé trop vite. Et du coup, on commence à faire aussi des erreurs, à trop paralyser. Pas des erreurs, forcément techniques, mais des erreurs du, On n'a pas assez bien réfléchi sur un truc. Côté produit. On n'a pas eu le temps de voir le design comme on voulait. Ou même, comme on se prend en jeu de vouloir aller vite, on est moins vigilant. Donc, il y a des nouvelles choses auxquelles moi-même, je suis confronté et où je me dis qu'à un moment, à force d'accélérer, Je pense que c'est même moi qui vais dire. « Attends » . Là, en fait, non. On va arrêter d'accélérer parce qu'en fait, on va atteindre un point de rupture où on va faire un jour. peut-être une vraie bêtise.

Terry: Ça me permet de rebondir. J'aime bien ce point-là parce que, même avant que l'IA soit là, alors après, en fonction des stats, Ça dépend des endroits où ce qu'on va voir. Mais il y a cette logique qu'une grosse partie de ce qui est produit en termes de code, c'est du product waste. C'est des choses, des features qui sont produites, mais qui sont très peu, voire jamais utilisées, qui n'apportent pas de valeur à l'utilisateur. Alors, du coup... D'où l'importance des fonctions de produit pour comprendre très, très finement. Quel est le problème auquel je veux apporter une solution. Et ensuite, y mettre en face la solution appropriée technique pour vraiment répondre à un problème et pas faire du coup du techno push. Ce qui est quand même en partie ce qu'on est en train de faire plus ou moins tous et toutes là, avec l'IA, c'est qu'en fait, On balance des choses au mur et on voit ce qui colle. Parce qu'on est quand même dans une phase aussi de transition, d'un point de vue des usages, de l'approche conversationnelle. Et donc pas mal de choses qui sont en train d'évoluer. Et malgré... Même avec la meilleure intention product qu'on peut avoir, on a quand même cette, en tout cas à date, la fin avril 2026, cette logique qu'on fait un peu malgré tout, du techno push. Mais si on met ça de côté, par rapport à ce que tu dis là, le fait que tout accélère. Et donc, parfois, il y a des choses que tu vas faire, qui ne vont pas être assez bien réfléchies, Quelle est un petit peu toi ta vision, justement, sur ce que ça vous a permis de faire au-delà de compresser le temps Parce qu'on l'a vu, on parle... De quelques mois pour onboarder, une équipe produit complète, capable de shipper quelque chose à 5 personnes. Là où, en fait, hier, il en fallait 15, puisque tu l'as très, très bien décrit. Mais derrière, au-delà de compresser, le temps est-ce Que tu vois une amélioration en termes de qualité est-ce que tu vois. Quelles sont en fait les choses que ça apporte pour Toi

Ce que l’IA apporte au-delà du gain de temps dans la construction produit

Écouter à 54:32

Florian explique que l’IA ne lui fait pas seulement gagner du temps : elle lui redonne de l’épanouissement, lui permet de maximiser la valeur et de tester, valider puis jeter plus vite, sans repasser par des réunions. Il décrit aussi une façon de construire plus directe, où l’on peut shipper un petit MVP, itérer rapidement et faire sauter des tâches répétitives et de friction. Terry rebondit en parlant d’un champ des possibles qui paraît infini, tout en rappelant que cette facilité n’est pas forcément triviale pour les profils non techniques.

Florian: Alors, déjà, moi, de l'épanouissement, parce que, en gros, concrètement, je suis un passionné. C'est vrai que je n'ai pas peut-être pas dit au début, mais moi, je m'éclate dans ce que je fais. Et limite, Je me suis jamais senti aussi légitime qu'en ce moment, de par mon bagage précédent, etc. Donc moi, je prends mon pied, littéralement. Mais ce qui n'est pas le cas de tout le monde. J'ai des anciens collègues qui sont des DEVS aguerris, qui, du coup, perdent leur valeur ajoutée, qui, eux, étaient dans le DEV parce qu'ils maîtrisaient extrêmement bien. Un langage. Et ça, ça change. Mais moi, j'aime si je me concentre. Moi, j'ai toujours été Business first. En gros, je me suis jamais défini. Mon ego n'a jamais été dans le... Code et la qualité du code. Je ne me suis jamais vendu comme un expert. Moi, j'étais un EM. Delivery, avec la qualité, évidemment. Engineering manager. Et du business. En gros, on est là pour envoyer quelque chose qui se vend, qui sert à quelque chose et qui va permettre de générer de l'argent. Très concrètement, moi, ça a été mon bagage. Et donc, ça, j'aime bien. Parce que maintenant, là où des fois, j'étais frustré... De ne pas pouvoir faire comme je voulais, Parce que quand il y a de l'humain, il y a de la friction, il y a différentes choses. Là, maintenant, en gros, J'ai été dans ma boîte précédente dev, je pense, et là, je suis redevenu. Engineering, manager, Mais pas d'humain, en quelque sorte, d'IA. Et du coup, je peux maximiser la valeur, et on parlait de trucs, on fait du test and learn. Moi, je suis très à l'aise avec le, On prend un truc, on valide, on met à la poubelle, On n'a plus besoin de ne pas repasser par des réunions. Et moi, Ce que j'aime bien, c'est que j'ai connu... Une époque, d'autres organisations, où on met plusieurs jours à parler d'un début de fonctionnalité. En gros, il faut deux semaines pour arriver à une spec. Là, maintenant, en deux semaines, on l'a envoyé en Prod et on a réitéré deux fois. Parce qu'évidemment, la première version, Si on va trop vite, elle n'est pas forcément terrible. Mais après, on n'envoie pas des fusées sur la Lune. On ne fait pas du médical. Je veux dire, Il y a aussi un contexte où moi, tout est au vert pour que, justement, J'y aille comme une brute. Côté produit... Ils peuvent aussi valider leurs idées plus vite. On dit très rarement non, même aux sales. Est-ce qu'on pourrait faire, ça On peut très vite Shipper, un petit MVP qui va suffire. On enlève, en fait, on fait sauter toutes les tâches répétitives et de friction de tout le monde. Comme à une époque, certains l'ont fait avec le no code, le low code, etc. Mais là, on le fait encore plus vite et directement dans notre asset technologique, à nous. Donc, on n'est pas branché et dépendant d'un make ou d'un n8n, C'est directement dans nous ce qu'on va pouvoir réutiliser dans les grandes lignes. Après, on apprend, Je peux résoudre des problématiques qui sont diverses et variées. Je n'ai pas parlé de l'Open source, mais en gros, c'est maintenant. Il y a une idée, On peut envoyer un truc et on recode ce qu'on veut. On peut

Terry: tester des technos qu'on ne maîtrisait pas. C'est illimité en fait, et donc je vais remonter là dessus. Ensuite, on va aller vers la fin de l'échange. Mais sur cet aspect, en gros, le short des possibles est juste infini. Moi, je ressens, ça. Je ressens ça aussi parce que j'ai commencé ma carrière en tant que dev. Donc, j'ai, comme tu l'as, La lecture technique aussi, de comment ça marche sous le capot. Je sais naviguer dans un terminal. J'ai la compréhension de comment tout ça, ça tourne. Et donc, J'ai une capacité à un peu diriger la machine pour qu'elle fasse ce que j'ai envie, qu'elle fasse. Et du coup, Je vois aussi ce truc de « les champs des possibles » , il est juste infini maintenant. Parce qu'avant, ça prenait... Des heures à scroller sur Stack Overflow. Pour trouver la réponse à sa problématique, pour installer ce SDK ou trouver la fonction qui fait ça. Là, tu demandes, boum, C'est quasi instantané. Mais par contre, Je pense qu'on a quand même, Quand on a ce background technique historique, un biais de croire que c'est aussi trivial que ça pour tous les profils. Et du coup, un peu la hype du vibe coding, où on pense que du jour au lendemain, maintenant, on peut devenir builder. Sans avoir une compréhension, un minimum technique. Et je pense que, enfin, Je suis curieux d'avoir ton regard là-dessus, parce que, et juste pour illustrer le propos, je prends un produit comme lovable.dev. Donc là, on enregistre fin avril 2026. Lovable.dev va être très, très, très fortement challengé par Anthropic, qui a sorti le pendant qui est claude Design. Et étant donné que Lovable s'appuie sur Anthropic derrière, la question va être, est-ce que c'est la fin ou pas, ou de Figma Make et équivalent. Mais aujourd'hui, en tout cas, à date, lovable.net. C'est un produit qui a ciblé la population des profils produits non techniques pour leur permettre justement de construire des apps. Sans avoir à se soucier de la technique et l'expérience, utilisateur, la couche expérientielle. Elle est juste, vraiment bien faite, ce qui permet vraiment à des gens. En l'espace de quelques minutes, de publier une app en prod sur le Web, avec même du Backend. Si on veut aller loin, alors après, je pose plein d'autres questions. Mais tout ça pour dire que la couche expérientielle, donc pour des profils non techniques, a été vachement travaillée. Parce que, justement, quand on ne vient pas de la technique, ce n'est pas si trivial que ça. En fait, quand tu n'as jamais vu un terminal, quand tu ne sais pas ce que c'est, qu'une ligne de commande, etc., Le gap d'entrée peut être important. Donc, quel est toi? Ton regard par rapport à ça, sur cette logique de vibe coding à des profils non techniques, de l'évolution, justement, de faire en sorte que tout le monde demain va pouvoir construire des produits Et donc, ce que moi, je dis, dans d'autres épisodes aussi, que le... Le coût de la barrière à l'entrée de faire du logiciel a vraiment diminué. C'est vrai dans certaines mesures, mais dans d'autres, en fonction des... Je pense qu'on a aussi ce biais-là, Quand on vient du monde de la technique, on voit tout de suite à quel point c'est beaucoup plus simple, Mais on reste une part marginale de la population globale. Donc, je suis curieux aussi d'avoir ton regard par rapport à ça, d'autant plus que là, tu as abordé des builders, justement, qui n'étaient pas techniques sur du code.

Ce qu’un profil non technique peut vraiment construire avec le vibe coding

Écouter à 1:00:19

Florian explique que le vibe coding permet à presque n’importe qui de lancer un site web ou un prototype trivial, même sans être très proche de la EdTech. Mais il nuance vite en disant que, dès qu’il faut faire croître le produit, il faut encore des ingénieurs et un rôle de supervision comme celui de « harness engineer ».

Florian: Oui, c'est assez large comme question, mais en gros... Je pense qu'il y a différentes étapes. Je pense que maintenant, à peu près n'importe qui, avec l'avant volonté, Et je ne parle pas de la personne qui est totalement loin de la EdTech, Je ne sais pas comment dire, le premier métier qui me vient en tête, un artisan, Je ne sais pas, un maçon, un électricien, un truc comme ça, là, C'est très loin. Et encore que, avec la volonté, on pourrait déjà faire son site Internet. On ne parle pas de Shipper, une grosse app ou un truc comme ça. Là où, avant, il fallait payer plusieurs milliers ou dizaines de milliers des fois pour un site Internet, là, quelqu'un peut se débrouiller. Sur la partie, lancer quelque chose de trivial. Un site web, pour moi, c'est trivial. Lancer un prototype ou un truc comme ça, c'est facile. Mais après, il y a la réalité, le scale. En gros, ce n'est pas juste le truc qu'on va montrer aux investisseurs. Ou qui va faire son petit projet perso dès qu'on veut commencer à avoir un truc qui va croître correctement. C'est là où beaucoup de DEVs me disent Tu verras quand ça va péter. Et ça, je rejoins. La différence aussi avec mon équipe qui, au début, a utilisé Loveable, C'est que là, en gros, Ce n'est pas tout à fait pareil. Ils ont utilisé les outils faits par un DEV Senior qui l'a fait avec eux et conjointement. Et c'est là où je diffère. C'est qu'en gros, il y a quand même, Comment dire, le mentor derrière ou en gros, qui va les assurer. En gros, il y a même un terme qui est apparu, c'est « harness engineer » . Donc, c'est celui qui assure, c'est en gros, ne t'inquiète pas, je t'assure, tu ne vas pas tomber. Et si tu tombes, en gros, Je vais mettre un matelas sous toi et je vais nettoyer s'il y a un truc qui se casse. Donc, c'est quand même, effectivement, Je pense qu'on s'apprête à vivre une grosse transfo dans le monde de la EdTech et du produit, Mais qu'il va falloir encore des ingénieurs, etc. Et que non, quelqu'un qui ne connaît rien à la EdTech, comme on a vu certains profils type CEO. En gros, je vais dégager tous mes devs, Ils ne servent plus à rien, je n'ai plus besoin d'eux. Non, peut-être pour sortir un petit Side project. Mais pas pour un système d'une boîte qui va les faire, qui va scaler et faire gagner des millions. Ça, je n'y crois pas.

Terry: Yes. Donc, avant d'aller vers mes questions de fin d'échange, est-ce Qu'il y a un sujet en particulier, dont on n'a pas parlé, Un message à faire passer

Open source, guide sur claude et projet RTK

Écouter à 1:02:32

Florian revient sur son envie de faire enfin de l’open source, après avoir longtemps gardé ses idées de projets de côté faute de temps. Il explique que son premier projet est devenu un guide documentant ce qu’il a appris sur le claude, puis qu’il s’est lancé dans RTK, un outil en Rust pour économiser des tokens. Florian insiste enfin sur le fait qu’avec de la motivation, du temps et un peu de budget, il faut oser se lancer dans ce genre de projets.

Florian: Moi, j'aimais bien le truc, c'est infini, le champ des possibles. C'est un truc où, alors, Je suis enthousiaste. J'ai toujours été un Early adopteur sur les outils, etc. Et un sujet dont on a parlé avant l'échange, c'était l'open source. Typiquement, moi, je n'ai jamais eu le temps avant d'en faire. J'avais toujours plein d'idées de projets. Mais pas le temps, parce que, comme je disais, déjà, je n'étais pas un super dev. J'étais un ingé de formation et tout, mais pas un très bon DEV ou pas assez rapide. Donc, j'avais des idées. Qui restait écrit à un endroit et oublié. Et depuis le mois de janvier, Je me suis chauffé, ma bonne résolution. Ce n'était pas le sport ou arrêter la bière, c'était faire de l'open source. Et en gros, mon premier projet était tout ce que j'ai appris sur claude, je l'ai documenté. Un moment, On m'a dit, mets-le dans l'Open, source. Enfin, en gros, partage quoi. C'est devenu, ça a grossi, c'est devenu un guide. Et il y a un petit projet sur lequel je suis arrivé il y a quelques mois. Qui s'appelle RTK, qui commence à faire parler de lui. Donc, c'est un truc qui permet d'économiser des tokens, Rust token Killer. Qui est un projet en Rust, donc un langage qui n'est pas du tout accessible. Même un dev, un profil senior comme moi, C'était un truc musclé, on va dire. Il fallait déjà être très, très, très costaud. Et je n'avais jamais osé l'aborder parce que je savais que ça allait être trop compliqué. Là, avec l'IA, Je l'ai fait. J'ai réussi à travailler avec deux autres personnes sur un projet qui est mondialement connu, qui est utilisé partout, sur lesquels il y a des potentielles problématiques de boîtes qui vont se créer, etc. Voilà, donc c'est un truc assez gros. Et tout ça, on... Quelques mois sans avoir à la base, en fait, forcément toute l'étoffe technique qu'il aurait fallu. Donc, mon point, c'est en gros oser. Il faut oser. Alors, clairement, Je n'ai pas compté mes heures. Au bout d'un moment, on n'a rien sans rien. Mais en fait, c'est en mode votre seule limite, c'est votre motivation, le temps, parce que limite, Je suis frustré de devoir dormir maintenant. Et éventuellement le coût, parce qu'il faut quand même pouvoir se payer une licence. Mais en gros, dire là, très concrètement, avec une licence à 200 balles, Euh... Par mois sur deux mois, donc pour 400 euros et pas mal d'heures, On a sorti un outil qui fait à date plus de 30 000 stars sur GitHub, qui est en train de décoller. Donc, c'est que dalle. En gros, c'est moins que le TJM d'un devmeet. Donc, en gros, c'est ça où tout est en train de changer.

Terry: Oui, le coût. Parce que les stars, c'est énorme. Pour le coup, la croissance...

Florian: C'est une très, très forte. croissance. Mais on le voit aussi en ce moment, c'est en train d'évoluer, tout va très vite. En gros, on voit que beaucoup de gens prennent ce truc du... Je n'ai plus aucune limite, à part celle que je m'impose moi-même. Et c'est vraiment un message que j'essaye de donner, que ce soit à des techs, à des non-techs. C'est en mode, c'est le moment. Là, en gros, Le champ des possibles est là. Je veux dire, il y a des boîtes à créer, il y a des projets à faire. Les cartes sont en train d'être abattues, qu'on soit senior, junior, etc. Là, j'ai envie de dire, Ce qui compte le plus, c'est la motivation et les idées.

Terry: Yes, assez aligné avec ça. Pour aller vers mes questions, du coup, de fin d'échange.

Pourquoi les profils dev doivent se réinventer vers le produit et le business

Écouter à 1:05:16

Florian explique que la valeur du développeur centré uniquement sur le code diminue avec l’IA, au point que beaucoup devront se réinventer vers le produit et le business. Il évoque aussi un nouvel équilibre où il faudra davantage de profils produit que de développeurs, et où de nouveaux rôles comme R&C Engineer, Ai Funding Engineer ou machine learning Engineer peuvent apparaître. Terry confirme que les anciens ratios s’inversent et insiste sur la montée des profils capables de contribuer à la construction tout en comprenant les problèmes métiers et la valeur créée.

Terry: Est-ce que tu as une conviction forte avec laquelle tu es en général en désaccord avec Tes Pairs

Florian: En ce moment, il sait que ça va s'inverser fortement dans la EdTech. Donc, je pense qu'il va y avoir un sujet pas forcément cool, beaucoup de licenciements. En fait, Il y a beaucoup de gens qui vont devoir sortir du dev. Alors, pas forcément au sens licencier, partir, mais qui vont devoir se réinventer fortement. Donc, très concrètement, le DEV, qui n'était intéressé que par le code en tant que tel, pas par le produit, Pas par le business. Et qui était juste en gros dans son coin, étant donné que sa valeur est amoindrie par l'IA, Parce qu'en gros, être un super dev, peu importe le langage, Ruby, Python, PHP, Peu importe, ça a beaucoup moins de valeur. Donc, en fait, là, il y a des gens qui vont soit devoir se réinventer, faire du produit, se mettre à s'intéresser au business, et tout, soit devoir partir, Mais dans tous les cas... Là où, avant, moi, j'ai connu, il fallait quoi ? 8 ingés pour un product. Là, l'équilibre va plutôt être, Il va falloir 3 ou 4 profils product pour un dev. Par contre, est-ce Que c'est des nouveaux PM qui vont arriver ou est-ce que c'est juste des DEVS qui vont bifurquer les moins techs ? Comme moi, j'en étais un qui va en gros bifurquer. Mais dans tous les cas, il faut s'attendre à ce qu'on n'aura plus besoin de 30 personnes. Pour sortir une fonctionnalité, un CRM ou un truc comme ça. Tout va beaucoup plus vite. Donc, L'âge d'or des DEVS est révolu ou en train d'être révolu. Par âge d'or, j'entends où n'importe qui qui venait pouvait faire une reconversion, arriver et sans forcément, on va dire, être très, très impliqué, pouvait très bien réussir. Pour moi, c'est fini parce qu'en gros, là, les barrières, t'en as parlé, Les barrières rentrées ont sauté. Et en fait, Il y a beaucoup de gens qui vont pouvoir se passer. De développeurs à minima pour débuter.

Terry: Yes, assez aligné aussi avec ça, évidemment, On est sur un podcast product et EdTech, Je pense que de toute façon, c'est la convergence des deux. Après, on l'a aussi vu avec la nuance. Quand on commence à travailler sur des produits complexes, quand on commence à faire. Ce qui est la majorité des DEVS, ensuite, de la maintenance évolutive et corrective, c'est-à-dire ne pas partir d'une page blanche mais sur des bases de code existantes, il va falloir quand même avoir des compréhensions mais... Clairement, les ratios que l'on avait hier de 1 pm pour 5 devs, ça, C'est complètement en train de s'inverser. Donc, ça veut dire besoin de moins de personnes pour faire le travail équivalent. Donc, il faut un réajustement aussi. Et après, il y a de nouvelles valeurs à aller créer, à aller chercher. Et ça, C'est tout aussi le rôle du produit au sens large. Et donc, C'est aussi pour ça que ces profils-là, et la notion aussi de Product. builder, donc de pouvoir contribuer à la construction en même temps que la compréhension des... Des problèmes métiers et de la valeur qu'on va apporter ensemble. C'est des profils qui, je pense, ont aussi un bel avenir devant eux. À partir du moment où on a cette curiosité, cette volonté de faire et d'apprendre, qui globalement, je pense, permet de traverser les révolutions technologiques de la meilleure manière possible.

Florian: Et de nouveaux rôles qui vont apparaître aussi. C'est là où je tempère mon propos. C'est que ce n'est pas non plus, ça y est, tout est fini et il faut avoir peur. C'est en mode, il faut savoir se réinventer. Il y a des nouveaux rôles, y compris très EdTech. Je parlais de R&C Engineer, de Ai Funding Engineer, de machine learning Engineer. Donc, en fait, c'est ça. C'est juste que la zone de confort qu'on a connue, où il n'y avait pas besoin de se bousculer trop fort pour avoir une bonne carrière, Disons que pour moi, ça, c'est fini. Maintenant, il va falloir se re-challenger d'une façon ou d'une autre.

Terry: Yes, très clair. Pour aller, du coup, vers ma dernière question,

Ce qui nourrit Florian aujourd’hui et comment le contacter

Écouter à 1:08:49

Florian explique que ce qui le nourrit aujourd’hui, c’est surtout la communauté, le fait de donner à l’open source et d’échanger avec des gens qui le challengent. Il dit aussi qu’il apprend en faisant, en testant rapidement ses idées et en les soumettant à la commu. Terry lui demande ensuite les meilleures façons de le contacter, et Florian cite LinkedIn, son site, son blog, GitHub, ou une recherche de « Florian Bruniaux » sur Google.

Terry: c'est quelles sont les choses qui te nourrissent intellectuellement ? Comment est-ce que tu progresses ?

Florian: À ce moment, je dirais la communauté. En gros, vraiment, un truc, c'est... J'ai toujours fait de la veille, j'ai toujours écouté des podcasts, lu des articles de blog, etc. Mais là, ce qui me nourrit le plus rapidement, en fait, c'est vraiment donner. Je donne à l'Open Source et en gros, je récupère en retour. Parce qu'il y a des gens critiques, parce que des gens aiment, des gens n'aiment pas, etc. Et ça me nourrit tant mon égo. Quand on me dit, tu as fait un super projet, je suis content. Quand on me dit, tu as fait un projet de merde, mais qu'après la personne, argumente. C'est super intéressant parce qu'il y a évidemment des gens bien plus compétents que moi, qui me disent Tu t'es planté. Mais du coup, tant mieux si après, j'ai un cours derrière. Donc, c'est échanger avec des gens et être, dans les faits. En fait, c'est justement un truc que j'aime bien. C'est maintenant, je crée, je fais, je fais challenger et j'apprends en faisant. Et je suis beaucoup moins sur une approche théorique. On rentre très vite dans la pratique. Et ce qui me nourrit, c'est vraiment ça. C'est que maintenant, j'ai une idée. Franchement... Je prends une soirée, je la teste, je la balance dans la commu, Je vois ce qu'on me dit, si c'est nul ou que c'est vraiment, ça existe déjà, poubelle Si c'est cool,

Terry: on creuse et on creuse à plusieurs et on avise le biais de l'action. Moi, j'aime bien dire et je suis complètement aligné, c'est une des meilleures manières de progresser, de faire et en faisant, tu apprends comme ça. Moi, j'aime bien cette notion du biais de l'action, de se dire top. Les meilleures manières de se connecter avec toi, d'échanger si les personnes qui écoutent veulent follow-up ?

Florian: Sur LinkedIn, par exemple, Je suis assez actif. Après, au travers, sur mon site, sur mon blog ou via GitHub, globalement, de toute façon, en tapant Florian Bruniaux dans Google, vous trouverez des infos. Un grand cheval lunette qui sourit, C'est assez facile à trouver. Après, j'essaye d'être réactif, de donner du temps, que ce soit à des profils plus juniors qui, par la fois, ont des questions. Et à l'inverse, moi, j'aime aussi être, on va dire, mentoré par des gens qui sont en accord ou en désaccord avec moi. Donc, je veux dire, dans les deux axes, Je prends bien volontiers.

Terry: Ça marche. Super. Merci, en tout cas encore pour ton partage, Florian. Et puis, On suivra de près aussi ce projet RTK, qui est sur une bonne ligne, en tout cas, de croissance.

Florian: Merci, beaucoup. À bientôt.