AI Coding : Réécrire des applications legacy

Bruno — Déléguer son code à un agent, c'est accepter un poste auquel on n'a jamais vraiment postulé le rôle de manager. Sauf que, on se retrouve avec un collaborateur qui ne dort jamais, qui ne se vexe jamais, qui sort 800 lignes de code en environ 20 secondes et va défendre ses erreurs avec exactement la même assurance que ses bonnes idées. Mais alors, que reste-t-il à relire quand la machine écrit plus vite qu'on est capable nous-mêmes de lire ? Est-ce que ça change vraiment l'équipe ou juste le nombre de chaises qu'on a autour de la table ? Et surtout, à partir de quel moment la revue de code devient un entretien annuel ? Pour répondre à ces questions de délégation, je ne reçois pas Hubert Bonnisseur de la BAT, mais il s'y connaît en agent un peu trop sur deux. Quentin, bonjour.

Quentin — Bonjour Bruno.

Bruno — Alors, Quentin, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Quentin — Oui, bien sûr. Je m'appelle Quentin, je suis CTO de la practice de modernisation par l'IA chez Théodot. Théodot, on est une boîte de conseil ESN à Paris. Et la modernisation par l'IA, c'est de réécrire en général des systèmes legacy, à partir de zéro dans des technologies modernes. Sauf qu'on utilise l'IA pour le faire. On construit des pipelines agentiques, des usines agentiques qui réécrivent les systèmes legacy. Et maintenant, ça fait à peu près depuis un an que 100% du code est écrit par l'IA. Et donc, c'est ça tout notre enjeu. C'est comment est-ce qu'on met en place ces usinages antiques pour migrer rapidement des applications, des code base, tout en gardant le contrôle et en s'assurant de la qualité de la code base finale.

Bruno — Donc, en fait, cette modernisation par l'IA, on parle bien exclusivement de réécriture. ce n'est pas aussi des sujets, de réorganiser les équipes tech dans l'usage de l'IA, dans notre pratique au quotidien du dev ?

Quentin — En fait, c'est souvent les deux, puisque notre approche étant tellement différente par rapport aux approches traditionnelles, de développement, qu'on travaille souvent en équipe mixte avec nos clients, parce qu'ils y voient une opportunité à la fois de moderniser leur application, mais à la fois d'apprendre une nouvelle façon de travailler.

Bruno — Des bonnes pratiques sur comment vous savez tout ça.

Quentin — Voilà, exactement.

Bruno — Alors, du coup, la première peut-être question... Je commence déjà à sortir du script. Est-ce que du coup... Parce que ce que tu décris, on pourrait presque dire que c'est un sujet de traduction, et que les traducteurs, c'est des métiers qui existent depuis très longtemps. Est-ce que au final effectivement vous êtes en train de créer un peu le google trad et que du coup on passe d'un langage à un autre ou est-ce que on est quand même sur des sujets parfois c'est pas uniquement parce que d'un langage à un autre.

Quentin — C'est hyper intéressant que tu mentionnes la traduction puisque les llm à l'origine ont été découverts chez google, sur des tâches de traduction et en 2017 je crois c'est un papier qui s'appelle attention is all you need qui a qui a ou c'est une petite équipe de chercheurs de Google qui a juste découvert, parce que c'est presque une découverte, l'algorithme qui fait ce qu'il y a à l'intérieur de LLM, et depuis, ça va faire maintenant presque 10 ans, l'architecture en interne n'a pas vraiment changé radicalement, c'est la même classe d'algorithmes, c'est tout, c'est la même architecture qu'on a scalé, dans laquelle on a donné plus de données, etc. C'est marrant qu'on fasse ce parallélisme avec la traduction. Passer d'une code base d'une technologie à une autre, Ça peut être de la traduction. Et d'ailleurs, avant l'IA, il y avait déjà des projets comme ça qui faisaient du mapping de fichiers de 1 à 1. Par exemple, on a réécrit avant l'IA des code-based COBOL en Java, mais de manière assez 1 à 1. Donc toute l'architecture du COBOL se voyait reflétée en Java qui n'était pas vraiment du Java du coup. D'ailleurs, ça s'appelle plutôt un peu du JOBOL, un peu entre le Java et COBOL. En fait, et c'est ce qu'on faisait au début aussi quand on a commencé à travailler dessus sur l'immigration assistée par l'IA il y a deux ans avant l'âge antique où en fait, on devait faire quelque chose de très mécanique et donc ça ressemblait à la traduction, on a appelé ça de la transpilation. Maintenant, ce n'est plus tout le cas, puisque comme les modèles sont plus intelligents, comme ils sont à gentils, comme ils peuvent vérifier leur travail, comme ils peuvent se raisonner sur des gros code base, on réorganise complètement, l'architecture logicielle de la cible. Donc, on lit le système legacy, on comprend son attention, on extrait le fonctionnel, on s'abstrait complètement de comment il a été implémenté, et on le réécrit tout bien comme il faut, dans des microservices s'il faut ou alors avec des design patterns. donc ça ressemble plus à toi de la traduction.

Bruno — Est-ce que ça veut dire aussi que les systèmes parce que tu évoques des systèmes qui sont de plus en plus performants, est-ce que c'est-à-dire que tu peux en fait juste balancer toute la code base existante dans ton LLM et du coup il comprend le but du logiciel et le fonctionnement du logiciel et du coup il est capable de te faire une spec, de A à Z totale ou est-ce que tu as quand même besoin de fournir des documents humains on va dire pour que le logiciel comprenne enfin pour que le LLM comprenne où est-ce qu'on doit aller.

Quentin — Alors oui on pourrait mettre toute la code base dans le logiciel sauf que c'est trop gros, ça rentre pas, mais pour des petites si on a une code base qui rentre dans la fenêtre du contexte du LLM, on peut la lui donner et il va tout comprendre et c'est parfait en fait on n'aura pas besoin de construire d'autre chose la difficulté qu'on a c'est justement parce que, les modèles n'ont qu'un contexte limité ils ne voient qu'une partie, mais une infime partie 1%, il faudrait calculer quelle est la fraction de la code base, ils voient à chaque fois donc on est obligé de construire des choses autour de ça à chaque fois Ok.

Bruno — Alors pour essayer de comprendre comment est-ce que vous fonctionnez, parce que ce qui est aussi intéressant, c'est que comme vous générez l'intégrité du code avec l'IA, c'est intéressant pour nous de comprendre comment vous organisez votre travail, vos outils, tout ça, parce que forcément, ça pose beaucoup de questions. Ce que je te propose c'est qu'on se prenne un projet type tu reçois une application, je te laisse nous choisir la techno d'origine et qu'est ce qu'on qu'est ce qu'on va en faire et du coup c'est quoi votre premier travail comment vous organisez en fait le travail avec tous et tous ces éléments qui arrivent.

Quentin — Oui alors le flux en général on reçoit une code base legacy et, Ça peut être sur des technos, des vieilles technos, du genre du COBOL ou du vieux Java 6, ça on en a beaucoup, ou du vieux PHP sans framework ou avec du Symfony 1, des choses comme ça. Ou ça peut être même sur des nouvelles technos, puisque là je parle beaucoup de legacy. Fondamentalement ce qu'on a développé comme expertise, c'est notre approche, c'est de transformer une code base en une autre. Et donc on a aussi le cas de changement de technologie alors que la technologie n'est pas obsolète. Par exemple, lorsqu'on a des applications mobiles, qu'on a deux applications natives, une pour iOS, une pour Android, qui sont parfaitement propres, qui sont modernes, qui sont bien entretenues, etc. Et qu'on veut en fait abandonner ces approches-là et avoir une application multiplateforme, en React Native par exemple ou en Flutter, on va se retrouver à traduire une code baisse qui n'est pas legacy. Mais la tâche est la même, on part d'une code base existante et on doit, enfin il y a plein d'étapes pour aller jusqu'une code base nouvelle. La première étape c'est, d'analyser le legacy. Le legacy c'est la spec, la code base initiale. Et d'ailleurs, pour faire le lien avec ta question d'avant, auxquelles je n'avais pas répondu, on ne veut aucun autre contexte. C'est-à-dire que s'il y a de la doc associée au système, on n'en veut pas. Parce qu'elle est obsolète. Parce qu'elle n'est pas alignée, puisqu'elle est fausse. On aimerait bien avoir des tests avec la code base legacy. En général, il n'y en a pas. Donc voilà. En général, c'est une code base legacy avec de la doc obsolète dont on ne veut pas.

Bruno — On est vraiment sur des projets réels. C'est-à-dire qu'il n'y a pas de doc, pas de test. Ça, c'est la vraie vie.

Quentin — Voilà, exactement. Donc on a ça, donc on a cette code base là, mais qui est où il y a toute l'information. On sait exactement, il y a toutes les règles métiers. En général, c'est des systèmes, c'est des gros systèmes, des systèmes qui sont utilisés en production, qui sont critiques pour nos clients parce qu'un projet de modernisation, ça coûte cher, de réécriture. Et donc, ils le font que sur des applications qui sont critiques et qui tournent et qui ne font pas ça sur une petite application qui a sans enjeu. Donc, on commence par l'analyser complètement. Et on fait ça en... La première étape, c'est d'identifier tous les points d'entrée dans l'application, puisque ça va être notre unité de migration. Ça peut être, on appelle ça des touchpoints, des points de contact. Donc, c'est des pages, c'est des écrans, c'est des endpoints, c'est des commandes. C'est tout ce qu'on va pouvoir appeler de l'extérieur du système. Ça va mouliner, ça va envoyer un résultat. Et ça, c'est un enseignement qu'on a eu sur des projets, avec nos projets de migration, puisqu'on en a fait maintenant une trentaine. Il y a eu des projets, on n'a pas suivi cette approche-là, de migrer touchpoint par touchpoint. On s'est dit, on va commencer par migrer des composants internes techniques. Voilà, de base, et après on va les construire et après on finira avec le front et machin. Et en fait, on s'est rendu compte que, ok, on l'est migré, mais c'est quand on branche tout ensemble qu'on se rend compte que ça marche pas, ou on a des problèmes d'intégration, etc. Donc maintenant, l'obsession, c'est la validation. Pouvoir valider son travail au fur et à mesure et donc du coup la validation ça doit être une tranche verticale end to end qui part de l'extérieur donc d'un appel utilisateur d'un pays ou une commande et ça doit descendre jusqu'à la base de données tous les services etc, donc on identifie tous les touch points et après on cartographie l'application, et pour ça on a des agents qui rentrent dans chacun des touch points en parallèle et qui construisent le graphe de dépendance de l'application espèce d'énorme call graph, ça on a d'autres activités mais ça c'est des activités qui sont structurantes pour comprendre la géométrie de l'application voir où est sa complexité. Et c'est ça qui va nous permettre de séquencer toutes les toutes les pages de migration.

Bruno — Donc après j'imagine une fois que tu as cette cartographie vient le travail, de spécification de la réécriture j'imagine qu'il ya parfois l'idée on garde la même structure parfois on refait tout il ya des choses, qui font pencher la balance d'un côté ou de l'autre sur ces choix-là ?

Quentin — Oui, alors, effectivement, une fois qu'on a une bonne vision du legacy, il y a l'enjeu de... Enfin, il faut faire la stratégie de migration. C'est ce que tu dis. Ça veut dire qu'est-ce qu'on va migrer, dans quel ordre ? Est-ce qu'on va faire des modifications pendant la migration ? Quelle est l'architecture cible ?

Bruno — Modification dans le sens de la fonctionnalité.

Quentin — Fonctionnel, ça veut dire que parce que souvent des systèmes négatifs il y a 20 ans on se dit bah tant qu'on y est -ce qu'on peut pas, parce qu'on a des irritants est-ce qu'on peut pas modifier, et c'est tricky c'est tricky en vrai, les projets on a fait des modifications pour la migration c'est toujours plus difficile parce qu'on a du mal à valider à la fin, encore une fois l'obsession c'est sur la validation si on fait de l'iso fonctionnel, si on fait exactement pareil, il y aura pas d'ambiguïté le dev il a une page à gauche il réécrit la page à droite, il fait les mêmes clics ça doit faire la même chose, si on fait des petites modifs du coup il faut une spec du métier il faut bien comprendre, il y a peut-être des petites zones d'ombre et puis on l'envoie validation métier qui va tester des choses qu'il avait pas pensé à des edge cases, c'est plus compliqué et ça freine le flux de migration, donc ce qu'on propose en général enfin ce qu'on a découvert qui marchait le mieux c'est de faire une migration ISO hyper rapide parce que c'est vraiment pareil et donc du coup on peut, passer toutes les pages très vite et puis on est sûr qu'on est correct et après faire les modifications. Parce qu'on a une base de code, en plus, à la fin, on a une base de code qui est propre, il y a tous les tests, qui est AI ready, c'est-à-dire qu'elle est bien structurée pour que les IA travaillent bien à l'intérieur, il y a tous les outils qualité, les tests unitaires, les linter, toutes sortes de choses autour qui fait qu'il y a écrit du code bon du premier coup à l'intérieur, toute la documentation, donc c'est plus facile de faire la modification.

Bruno — Et donc, comment est-ce que vous faites le choix de, on réimplémente, en gros, on prend la même architecture, la même structure, mais je m'imagine que tu as aussi des cas où tu as une grosse application monolithique à l'ancienne, que tu décides d'éclater en microservices. Qu'est-ce qui va faire ce type de choix ?

Quentin — En vrai, on se fiche de savoir quelle est l'architecture du legacy. La seule chose qui est importante, c'est qu'est-ce qu'on veut à la fin. donc, on peut choisir d'avoir un monolithe, d'avoir des microservices d'avoir un monolithe hyper modulaire ou alors au contraire tout mélanger enfin peut-être pas tout mélanger, c'est vraiment, on dessine la cible sans regarder le passé parce qu'après on va juste extraire les fonctionnalités mais sans regarder la technique et les projeter dans la cible qu'on a à chaque fois.

Bruno — Et donc cette décision de ce dessin d'architecture que vous faites à quel point il est humain versus AI NN ou complètement full AI ?

Quentin — Aucun des deux. Complètement full humain.

Bruno — OK.

Quentin — Ouais. En général, cette partie-là, autant pour l'analyse de legacy, on se repose vachement sur l'IA qui va tout cartographier, tout analyser, nous sortir plein d'états, etc. Autant pour l'architecture cible, là, c'est quelle est la pyramide de tests qu'on veut ? Les tests unitaires, les tests d'intégration, les tests end-to-end, est-ce qu'on en veut ? Quel design pattern on veut à l'intérieur ? Est-ce qu'on veut de la clean architecture ? Est-ce qu'on veut des barndets de contexte ? comment ça marche, comment on structure les liens qu'il y a entre les différents modules, est-ce qu'ils ont le droit de se parler, etc. Tout ça, c'est complètement humain. Soit, nos clients, ils ont déjà des avis tranchés là-dessus, parce qu'ils sont...

Bruno — Ou ils ont des contraintes, parce qu'ils sont déjà sur AWS.

Quentin — Exactement. Soit ils ne savent pas, et puis ils nous laissent faire, mais nous, on est obligé de le spécifier. Parce que, de toute façon, si tu ne spécifies pas, c'est la jungle. Et il y a fait n'importe quoi. on est obligé de le spécifier donc il faut être hyper carré sur ce genre de choses.

Bruno — Mais c'est humain et donc après vous vous lancez sur le travail de réécriture, comment est-ce que comment est-ce que vous organisez ce travail parce que donc de ce que je crois comme tu nous parlais tout à l'heure de, c'est plus facile de faire un truc iso et de tout un procès de validation parce que j'imagine que l'idée c'est de se dire, en fait une fois qu'on appuie sur le bouton idéalement faut que le faut que l'iel soit capable de tracer qu'elle soit de limite capable de coder tout de a à z toute seule de valider tout seul et tu attends deux trois jours tu as grillé je ne sais pas combien de millions de tokens, mais au moins deux, trois jours, tu as une application qui fonctionne. C'est ça un peu l'idée ?

Quentin — Alors non, ce n'est pas aussi magique que ça. On est là bien.

Bruno — Oui, mais c'est ça. J'entends que ce n'est pas aussi magique que ça, mais c'est l'objectif final de se dire qu'il faut qu'on arrive à avoir un système qui est le plus autonome possible. Et une fois qu'on a fait l'architecture, qu'on a la cartographie, tu réécris tout et on revient dans trois jours.

Quentin — Oui, mais on en est loin. On en est loin. Donc, on en est loin parce que les IA et nos harnais, toutes les solutions qu'on fabrique autour des IA, ne sont pas assez bonnes pour être travaillé en autonomie comme ça. Il y a besoin d'input de notre part, il y a besoin d'input métier, fonctionnel et d'input technique, donc notre flux est structuré comme ça, donc il y a des étapes où on a human need a loop, c'est à dire qu'on travaille l'IA avec l'humain et on est en synchrone et des étapes on est AFK, away from keyboard, c'est l'IA qui mouline et on ne la regarde pas faire et en général quand on Quand on a une page, le flux, c'est on commence par la partie. Il y a trois grandes, il y a trois grandes étapes. La partie qu'on appelle spec, c'est la partie fonctionnelle, juste pour s'assurer de qu'est ce qu'on veut développer. Après, il y a la migration, ça, c'est quelque chose de très technique. Une fois que le fonctionnel est fixé. Même pour les migrations iso-fonctionnelles, il y a quand même des questions fonctionnelles. Et après, il y a la partie validation. Une fois que c'est fait, comment est-ce qu'on s'assure qu'on a bien migré la page ? Et donc, dans chacune des étapes, il y a de l'humain et de l'IA qui va mouliner sur les humains. Donc, la partie spec. Ça commence avec l'IA. Donc, on est dans le flux de migration. On fait une usine et on migre les pages d'une grosse application qui a 1000 pages. On les migre une par une. Et on en est à la page 253, voilà. Qu'est-ce qu'on fait ? Il y a l'IA qui commence à aller explorer comment cette page, avec le graphe de dépendance qu'on a fait, en travail préparatoire, qui regarde comment elle est implémentée dans le legacy, qui va lire tout le code de la page, qui va descendre tout le graphe, qui va tout lire, pour savoir, tout absorber. Elle va regarder aussi les données. Donc, c'est les codes et les données. Idéalement, on a accès à la base de prod, en lecture seule, bien sûr, anonymisé. Une copie anonymisée de la base de prod. Donc, on a accès à toute la géométrie des données. On comprend quand il y a un champ catégoriel. On peut savoir exactement quelles sont les catégories, etc. Et ça aide vachement le lien à le faire. Donc, on regarde le code, on regarde les données. Et là, on est prêt. On fait un grill-me. Est-ce que tu as déjà entendu ce pattern ? Un grill-me. C'est un skill qui vient de Matt Pocock, qui est une star en air-coding. Je crois que son repo est numéro 15 ou 10 sur GitHub. Il y a le plus de stars. Il a juste, entre guillemets, il travaille beaucoup avec l'IA. Il a fait un repo avec des skills. Il y a une des skills qui est Grilme, qui est en fait assez simple. C'est trois lignes qui disent, pose-moi des questions non-stop sur ce que je suis en train de faire jusqu'à ce qu'il n'y ait plus de zone d'ombre. C'est ça. Et donc, c'est super, c'est une parenthèse. C'est super, c'est ce qu'il Grilme, parce que. C'est grill me cuisines moi sur ce que je suis en train de faire parce que ça inverse la relation entre l'IA et l'humain, en normal tu vois c'est l'humain qui doit donner tout le contexte il doit taper taper taper tout donner disant lit tel fichier voilà tu as tout ce qu'il faut maintenant fais cette tâche et avec le grill me c'est l'inverse tu dis juste une intention un peu floue où tu peux lui donner plein d'informations et tu dis pose moi toutes les questions et là il va te faire réfléchir. Il pose toutes les questions en boucle, en boucle, en boucle. Donc, dans notre flux, tu vois, sur la partie des fonctionnels, il y a une phase de grill-me fonctionnelle. C'est-à-dire qu'on dit, on veut migrer cette page, il a lu tout le code, il a lu les données, il sait ce qu'on est en train de faire, blablabla. Et là, il va poser plein de questions au PO sur la page qu'on est en train de migrer. Et même si c'est isofonctionnel, tu vois, il y a des petites questions du genre parce qu'ils ont fonctionnalité, c'est-à-dire qu'on garde les mêmes fonctionnalités, mais en cible, on a un design système, par exemple, alors que dans le legacy, on n'avait pas de design système. Donc, dans le design système pour la cible, est-ce que tu préfères cet élément ou cet élément pour ce composant ou celui-ci pour faire ça ? Voilà. Donc, le PE, il va donner ça. Donc, il répond à des questions. Ça peut durer une demi-heure, une heure. Il répond à, je ne sais pas, 30 questions, 60 questions. Enfin, 60 questions, c'est assez long. C'est qui un souci, je pense. À beaucoup de questions. Et après, il a fini. On consigne toutes les réponses dans un fichier Markdown. Dans le repo, dans Git, et après ça avance dans le flux. Et là, il y a une phase AFK. Donc là, il part de son ordi où il fait travailler dans le cloud et il y a l'IA qui compile tout, qui prend toutes les questions et qui génère pas mal de documents, mais dont une spec, la spec pour la page à développer.

Bruno — Il y a des guidelines qui sont données sur qu'est-ce qui fait qu'une spec est bonne ou aujourd'hui les outils sont suffisamment performants pour faire une bonne spec pour eux. Parce que j'imagine qu'une bonne spec pour l'IA n'est pas une bonne spec forcément pour un humain et inversement.

Quentin — Absolument et là t'as raison, c'est bien une spec pour l'IA qu'on doit faire et, il faut évidemment des guidelines parce que si tu spécifies pas ça va faire n'importe quoi et cette variabilité que tu vas avoir le fait que tu peux pas prévoir ce qu'elle va faire, c'est le poison de ces, flux, tu vois c'est hyper industriel, hyper répétitif ce flux, donc la variabilité c'est notre poison, on cherche à cadrer et à prédire tout ce qu'il y a à chaque étape donc l'aspect, il y a un cadre hyper clair, un template avec, des sections exactement ce qu'il faut dans la section, la longueur de la section quel type de choses, des exemples, des bons exemples des mauvais exemples, voilà pour l'aspect, et en particulier dans l'aspect un truc hyper important c'est les conditions de validation, c'est à dire que tu définis dans l'aspect exactement comment l'IA devra valider son travail après.

Bruno — Et donc une fois qu'on a fait la partie spec on peut passer du coup à cette deuxième étape de production du code.

Quentin — Voilà exactement donc ça c'était la grande phase spec avec un coup d'humain dans la boucle avec le grillmi et de l'IA qui mouline, en AFK et après il y a la deuxième phase de migration qui en fait a la même géométrie c'est à dire qu'on commence par un grillmi pour le tech maintenant, Donc il y a, absorbe tout le contexte dans cloud code avec des skills qu'on utilise pour lui faire lire tout ça donc on lui donne, le graphe de dépendance il y tout le code on lui donne toutes les réponses du grilmy du p.o, l'aspect évidemment qui a été fait puis d'autres documents qui ont été créés dans cette phase préparatoire qui cadre tout le fonctionnel qui cadre le fonctionnement du legacy et ça pose des questions techniques maintenant au grilmy pour le tech avec.

Bruno — Aussi toute la doc d'architecture qui a été conçue en amont c'est quoi le système cible.

Quentin — Exactement, alors effectivement ça on n'en a pas parlé ça ça a dû être défini, avant le début du projet, avant de migrer à la première page et écrit, consigné, dans des fichiers markdown dans le repo pour que l'IA ait accès et elle doit l'avoir lu avant de commencer son Grill.me tech, donc Grill.me tech elle pose plein de questions au tech en mode ben voilà, il faut implémenter telle feature il y a tel pattern qui existe dans le code est-ce que tu préfères tel pattern, tel pattern plein de questions comme ça, donc pareil 10, 20, 30 questions ça dure en moyenne, sur l'immigration ça dure en moyenne une demi-heure, une heure pour le tech qui répond à toutes ces questions là, et il valide et là c'est bon, la slice la page qu'on peut migrer est prête à être développée là il y a le gros du travail qui va générer tous les tokens, mais dans lequel on n'est plus dans la boucle. Et donc là, en général, Alors, en début de projet, on est vachement en babysitting des agents. C'est-à-dire qu'on les regarde travailler. On regarde cloud code, on regarde, ça défile, ça défile. On l'arrête, on dit, attention, c'est pas comme ça, c'est plutôt comme ça, etc.

Bruno — Il faut être vif quand même, du coup.

Quentin — Il faut pas sauter dessus. Non, mais bon, quand il commence à faire des patterns qu'on veut pas, il faut l'arrêter parce que sinon on perd trop son temps, il va complètement à côté de la plaque. En début de projet, il n'y a pas encore tout ce qu'il faut pour bien le cadrer. plus on avance, quelques semaines dans le projet ou quelques mois genre au bout de un mois ou deux mois après les agents font bien, ils avancent bien ils font quasiment tout le temps bon du premier coup en termes de code, de grande direction, et à ce moment là on n'est plus obligé de les babysitter et ils peuvent être déportés dans le cloud et donc à ce moment là à la page 253 à laquelle on était tout à l'heure. J'espère que ça fait déjà longtemps qu'on est dans la migration, on pourra faire autant de pages. L'usine, elle est assez stable. Les agents font bronte du premier coup. Dans ce cas-là, après le Grimmy Tech, on appuie sur un bouton, ça passe dans le cloud et puis, ça bosse pendant, en moyenne, entre 5 et 8 heures. Donc, c'est des tâches très longues avec beaucoup de contexte parce qu'il y a tous les fichiers Markdown initiaux plus le Grimmy du Tech qu'il faut faire. C'est découpé par ticket une dizaine de tickets pour la page et sont implémentés les uns après les autres et sont validés aussi par l'ia voilà donc on écrit tous les tests tous les tests part ça ouvre la mer la paire.

Bruno — Attendu coup tu as utilisé le temps et on écrit tous les tests c'est pas.

Quentin — Bon pardon c'est pas bon c'est lié ok c'est lié ça fait partie de la migration de la page d'écrire le code d'écrire les tests de faire tourner les tests et de boucler jusqu'à est-ce que tout soit vert ? Et quand tout est vert, l'IA ouvre une PR. Et donc, le matin, on a des PR.

Bruno — OK. Donc ça, du coup, on rentre dans la troisième étape que tu évoquais, la partie de validation.

Quentin — Oui.

Bruno — Les PR, est-ce qu'elles sont préfiltrées par des IA ? Ou vous lisez toutes les PR à la main ?

Quentin — Elles ne sont pas préfiltrées par des IA. Et ça, c'est quelque chose qu'on voit souvent. Et c'est quelque chose avec lequel je ne suis pas tellement d'accord. Boîtes qui mettent des reviews de PR par des IA. Pour moi, ça n'a pas vraiment de sens. Si tu as une IA qui n'est pas capable de regarder d'un œil critique une PR et tu vas faire confiance à ce qu'elle dit, autant la mettre avant dans ton flux. C'est le principe du shift left. Tu essaies de mettre les trucs de validation au plus tôt pour que ça soit... Moi, si j'ai un agent qui permet de faire de la review, j'ai envie de le mettre dans mon job pendant la nuit de migration, comme ça, tu as des agents qui écrivent, d'autres qui valident, et ça boucle jusqu'à ce que ça soit terminé. Donc, normalement, quand la PR est ouverte, il y a déjà les IA qui ont vu. Donc, les PR, elles sont faites pour les humains.

Bruno — Ok. Et donc, ça veut dire que sur tes 1000 pages que tu as régénérées, tu vas avoir tout le code qui va être relu par des humains à 100%.

Quentin — Oui. Alors, à différents niveaux d'attention. En début de projet, tu vois, on travaille sur des projets qui font 10 mois ou un an. Et puis, moi, je suis dans le service. Donc, en fait, nos équipes, elles changent tout le temps de projet. C'est-à-dire qu'on fait un projet pendant six mois et après, nouveau projet, nouveau contexte, nouvelle stack, etc. Dans des environnements d'entreprise, c'est beaucoup plus propice à... Il y a beaucoup plus de stabilité. C'est-à-dire que tu mets tout ça en place et après, tu ne changes pas dans six mois avec une nouvelle stack. Donc, voilà. Nous, on repart de zéro à chaque projet. Donc, en début de projet, en tout cas en phase d'adoption de ce genre de mécanique, c'est ultra important de tout regarder et d'être hyper précis. C'est vraiment un travail de fournir, de dire, tu prends un problème, t'extrais, tu regardes la cause racine, t'essaies de comprendre pourquoi il y a ce problème-là, qu'est-ce qu'il fait dans l'usine qu'on a eu ce problème-là dans l'APR, tu corriges l'usine en plus de corriger l'APR, tu vois, tu fais en sorte que l'usine ne reproduise pas ce problème. Et ça, c'est tout l'enjeu des premiers mois de migration. Chez Théodaux, on est vachement dans la philosophie Lean, et c'est l'activité de Kaizen, d'amélioration continue. Et donc ça, dans cette phase-là de validation, en fait, c'est presque une phase de Kaizen. Donc en fait, c'est plutôt Spec, Migration, Kaizen, nos trois phases. Donc la troisième phase, c'est à la fois, oui, corriger ta PR, mais fondamentalement, et là où on passe le plus de temps, c'est de faire en sorte de corriger l'usine pour que tous les problèmes de ta PR se reproduisent pas donc en début de projet on relie beaucoup les PR, plus on avance plus, on va être en confiance sur certains aspects du code, certaines parties du code certaines templates qui c'est facile de faire, pour l'IA et donc du coup on va relire plus en diagonale parce qu'on aura plus confiance dans notre arnais de validation.

Bruno — Ok et donc ça veut dire que de la manière que tu disais qu'il y a au début les premières phases de dev tu surveilles ce que fait Claude pour l'interrompre, si jamais tu vois qu'il fait de la merde c'est le même principe sur TPR où effectivement au début tu vas vraiment les relire de manière consciencieuse prendre le temps et qu'au final en fin de projet quasiment tu cliques ok sans, je comprends bien que c'est pas sans lire mais c'est comme un petit peu sans lire.

Quentin — On a des on a des trucs qui vont nous aider à à mettre notre focus sur les points importants de la paire plein, plein plein de petites choses autour par exemple on a un système de ce qu'on appelle blueprint blueprint c'est des tu as des templates des modèles et donc on a c'est qu'on défini dans notre code. On définit dans notre code des sortes de d'exemples canoniques de tu vois si tu veux faire un repository tu vas faire un blueprint de repository qui fait ce genre de choses ou un service ou je sais pas quoi un dto et. C'est ces modèles canoniques on les a vus on les a regardés ils sont parfaits c'est nos jocondes en fait ils sont ils sont parfaits et, lia quand on a on a un système on a des skills de blueprint on a des scripts déterminés ce qu'ils vont nous aider à collecter tous les blueprint, en faire un index, à les utiliser, etc. Et donc, Lya, quand elle écrit un nouveau repository, elle peut dire qu'elle l'écrit et qu'elle utilise ce blueprint. C'est-à-dire qu'on, déjà, elle est allée le voir, elle le lit, elle regarde le fichier et elle met, c'est tout simple, c'est juste des annotations en haut de la classe du fichier en disant ce fichier suit ce blueprint. Et ça, ça augmente considérablement la confiance. Elle ne triche pas vraiment, en fait. On n'a pas vraiment vu de... Quand elle triche en mode, j'ai utilisé ce blueprint, elle fait un truc... Les plus gros risques, en fait, c'est qu'elle n'a pas vu des bons patterns dans le code, et elle a inventé un truc nouveau, ou alors elle s'est dit qu'elle allait faire quelque chose, une nouvelle abstraction, ou alors elle crée un deuxième helper qui fait la même chose que le premier parce qu'elle ne l'avait pas vu, etc. Donc, en fait, un des exemples de ce qu'on fait qui nous permet d'accélérer la relecture des PR, c'est qu'on a un système de blueprint et donc du coup quand on a une paire on a un ensemble de composants on a 15 composants et on a on a une cartographie on sait qu'il ya 12 composants qui viennent de blueprint, et qu'il y en a trois qui sont sans blueprint qui ont été construits sur mesure dans ce cas là on va les regarder très fort attention là c'est liac qui a, été créative en revanche pour tous ceux où il ya des blueprints a priori à ce stade là de du flux on n'a pas besoin de trop les regarder quoi.

Bruno — Et du coup après le une fois qu'on a fait toutes ces étapes sur toutes les tous les morceaux du projet peut-être un projet, final tu as une nouvelle étape de validation totale du du système ou du coup tu es en confiance et tu chippes l'ensemble.

Quentin — Bah ça dépend de la stratégie de, de de déploiement qui a été décidé en amont du le projet au début, le mieux, c'est de faire du progressif. Ça veut dire que tu migres une page, tu vas jusqu'au bout, jusqu'au bout et tu la mets en prod et les utilisateurs voient la nouvelle page migrer parce qu'il n'y a rien de pire qu'une grosse migration big bang à la fin où tu mets. Et puis là, tu te rends compte de plein de problèmes dans tous les sens. Donc, il faut pour réduire un maximum sur ce que là, il faut faire du progressif alors page par page, module par module ou tu vois, tu peux regrouper des domaines. Ça demande plus de... C'est un peu plus difficile de faire des migrations progressives. Donc, en fait, c'est un trade-off pour nos clients entre réduire le risque de migrer les pages, déployer les pages ou les composants les uns après les autres pour un peu plus, d'échafaudage autour de scaffolding pour faire en sorte que ça marche et faire des ponts entre l'ancien et le nouveau, etc. Mais l'objectif c'est bien de pousser en prod le plus rapidement.

Bruno — Possible t'as utilisé plusieurs fois le terme de harnais on comprend que t'as aussi des systèmes de boucles puisqu'on parle beaucoup d'harnais engineering, de loop engineering, je serais du coup très intéressé d'avoir un peu dans le détail en termes d'outillage, comment vous construisez ça et en fait t'as aussi évoqué un truc que je trouve intéressant c'est que t'as dit, comme effectivement Théodo vous êtes dans le service c'est que tu vas faire un projet, un coup qui va durer peut-être trois mois, six mois, huit mois. Et puis après, tu as un nouveau projet créé avec une nouvelle techno, un nouveau concept, un nouveau métier. Donc tu recommences à chaque fois entre guillemets de zéro. Mais du coup, ma question, c'est à quel point tu recommences à chaque fois de zéro ? Quelle est la partie de ton usine logicielle qui est générique, quel que soit le projet ? Qu'est-ce que tu dois reconstruire pour chaque projet ? Et du coup, comment est-ce que vous construisez ces différents harnais et ces différents systèmes de boucle ?

Quentin — Super question. Effectivement, on a une usine générique standard qui, lorsqu'on commence un nouveau projet, on la pose dans le projet. En fait, très concrètement, un projet de migration, c'est on ouvre un nouveau, on travaille en mono repo. On ouvre un repo, un dossier dans lequel on met le système legacy on va développer le nouveau système à l'intérieur du même dossier, on va mettre notre usine, on va mettre tout dans le même dossier pour que l'IA ait accès à tout elle ait tout le contexte, elle puisse faire tourner de stack etc donc mettre déployer l'usine c'est, copier-coller à l'intérieur du dossier de travail. Tout le tooling ça dépend de l'outil qu'on utilise mais la plupart des projets utilisent Cloud Code actuellement, donc on importe toutes les skills Cloud à l'intérieur tous les outils, les scripts déterminés ce qu'on a qui viennent, avec, on met tout ça dans le projet sauf que l'usine générique elle marche très mal sur un nouveau projet il y a une variabilité énorme de projets, d'ailleurs moi c'est ça qui m'amuse aussi d'être dans le service, c'est qu'on voit des trucs complètement différents, surtout à ce moment-là parenthèse, mais, à ce moment-là qu'il y a cette révolution autour du métier de dev, je trouve ça trop cool d'être là de pouvoir voir, j'ai l'impression d'être dans une tour de contrôle où on voit. Toute l'industrie en même temps donc on développe notre usine on dépose notre usine générique, elle marche très mal, et donc tout le début du projet, les premières semaines les premiers mois, on rame c'est pour ça qu'on baby-sique les agents, parce qu'ils marchent pas parce que l'usine elle marche pas il faut tout brancher il ya plein de plein de festivités plus elle avance plus elle va marcher mais elle aura vachement dérivé par rapport à l'original et après, Il y a un enjeu aussi de, quand on a des bonnes idées sur certains projets, de les faire remonter dans le standard et dans le générique. Ça, on n'a rien. Il n'y a pas de... Genre, tu ne peux pas renvoyer... C'est tellement du spécifique à chaque fois que tu ne peux pas vraiment faire, une espèce de guide push vers le générique. Non, non, c'est trop difficile de voir. Donc, c'est vraiment... C'est très humain comme process.

Bruno — Mais ce travail de customisation de votre usine logicielle, est-ce que vous avez un process qui vous permet de dire, en fait, quand on commence le projet, on sait tout ce qu'on a à customiser ou est-ce que c'est à mesure que le projet avance, que tu adaptes et du coup, au final, la première page que tu migres, tu passes beaucoup de temps à refaire ta tuyauterie pour t'adapter à ta première page et puis petit à petit, tu t'en fais de moins en moins.

Quentin — C'est exactement ça. C'est exactement ça. L'enjeu, c'est bon, évidemment, on sait, on a une liste de choses qu'il faut mettre en place sur le projet, mais fondamentalement, on est dans du delivery, c'est-à-dire que la première semaine, il faut migrer la première page. Et donc, on met en place tout ce qu'il faut pour migrer la première page. On avance, les trucs marchent mal, on babysit on corrige les gens etc on la migre d'ailleurs, elle va en prod si on la pousse en prod et c'est bon et après une fois que cette page est en prod, on n'a pas fini le travail sur cette page puisqu'il y a cette partie de Kaizen, où on regarde tout ce qui s'est mal passé et alors là il y a des tonnes de trucs qui vont pas donc on revient en arrière, on corrige les trucs etc. On ne régénère pas la première page elle est faite, elle est poussée en prod elle est validée et tout, en revanche quand on fait la deuxième page on bénéficiera de tout ça donc c'est vraiment page par page, situation après situation que petit à petit le périmètre de l'usine va couvrir tous les use case ok.

Bruno — Avant de repasser à la suite, j'aimerais revenir après sur le harness engineering, le loop engineering, mais en fait, ton analogie, puisqu'on parle d'usine logicielle, et cette spécificité sur chaque projet, tu dois adapter ton usine, ça me fait penser à Airbus, en fait, parce que je ne sais pas si tu le sais, mais quand Airbus construit un avion, en fait, ils construisent aussi l'usine qui va construire l'avion, parce qu'en fait, en général, un avion, c'est tellement spécifique comme construction, que tu n'as pas des chaînes de montage d'avions, en fait, pour faire un A380, un Beluga et autres, c'est chaque avion et donc, en fait, quand ils conservent un avion ils doivent concevoir aussi l'usine qui va construire et assembler l'avion et donc, à mesure qu'ils construisent, en fait, ils doivent aussi, adapter l'usine, en fait, que c'est un nouveau modèle.

Quentin — Hyper intéressant.

Bruno — Donc, en fait, ils retrouvent la même mécanique.

Quentin — C'est exactement ça. Hyper intéressant, oui. C'est exactement ça.

Bruno — Donc, ouais, j'aimerais revenir, du coup, sur cette notion d'Armess Engineering et de Loop Engineering. Déjà, je serais curieux d'avoir ta définition de ces deux systèmes-là, parce que c'est des termes qui sont assez récents. Pour rappel, en général, j'essaie de le faire au début, mais là, j'ai oublié. On enregistre cet épisode, on est le 15 septembre, je crois que c'est ça, on est le 15 septembre. Donc au moment où ça sortira, les choses vont peut-être bouger, au moment où vous l'écouterez peut-être encore plus. Mais oui, le R&S Engineering, le Loop Engineering, ça fait quoi ? Ça fait 4 mois, 6 mois qu'on en parle, c'est assez récent. C'est peut-être une autre vision. Mais donc, je serais curieux d'avoir, déjà, ta définition de ces termes-là, et qu'est-ce que, et d'outillage, et de formation et méthodologie, parce que c'est quand même des humains qui l'utilisent. Il faut aussi les éduquer à ces nouveaux systèmes, à ces nouveaux outils.

Quentin — Oh là, plein de choses emballées. Le Harness Engineering... Pour moi, c'est tout ce qu'on va mettre autour du modèle pour qu'il se comporte bien. Le harnais, il y a plusieurs définitions. Les gens utilisent harnais pour parler de l'outil qu'on utilise, Cloud Code ou Copilot ou Codex, c'est le harnais. Et donc du coup, harness engineering, c'est aussi tout ce que tu vas mettre à l'intérieur de l'outil, donc les skills, les scripts, tous les tools que tu exposes à ton modèle ça fait partie du harnais et donc c'est tout ce que tu fais autour du modèle, et sans utile sans tu vois quand je parle de ce qu'on fait j'emploie pas le terme de harness engineering mais finalement c'est uniquement ça c'est uniquement, donner tous les outils qu'il faut au modèle lui donner les bonnes instructions via des skills et des choses et les bonnes vérifications pour qu'il soit bien dans les rails et qu'il écrive exactement le code qu'on veut qu'il écrive sans variabilité puisque encore une fois c'est notre poison, voilà donc c'est vraiment que du harness engineering, loop engineering bon pour moi ce terme là est un peu moins clair ce que je retiens de loop engineering c'est de faire des boucles, et c'est cette notion de. Il y a d'ailleurs j'entends plusieurs choses sur les boucles, Je ne sais pas exactement quelle est la définition, mais moi, je te dis ce que Boucle m'inspire. Une première chose que Boucle m'inspire, c'est cette notion de vérifiabilité. C'est-à-dire, tu donnes au modèle la capacité de vérifier son travail. Et donc, du coup, il peut travailler, il peut faire vérifier, faire vérifier, faire vérifier jusqu'à ce que ça fonctionne et que ça fasse bien ce que tu veux. D'ailleurs il y a une grosse migration qui a fait un peu parler d'elle, qui est la migration de Bun, le runtime TypeScript qui a été réécrit en Rust à partir de Zig, par quelqu'un chez OpenAI chez Anthropic pardon où il a fait une énorme paire un million de lignes et en fait ça a pu marcher, entre guillemets, enfin, d'aller jusqu'à 7PR et que tous les tests soient ouverts, parce que, justement, la code base initiale était vachement encadrée avec tous les tests. Et donc, du coup, on a donné à l'IA la capacité de vérification de travail. Et donc, du coup, il y avait ces boucles permanentes jusqu'à ce que ça vous donne. Je dis marcher entre guillemets parce que ce n'est toujours pas sorti. Et donc, il y a un paquet de rework et d'optimisation et de branchement. Je ne sais pas ce qu'ils font exactement. Enfin, peut-être qu'à l'heure où on enregistre le podcast, c'est sorti. Mais quand j'avais regardé il y a quelques jours ou quelques semaines, ce n'était toujours pas sorti. Alors que ça fait des mois qu'ils ont fait la migration, qu'ils ont fait un gros coup de pub en disant c'est bon, on a fait une migration. Donc ça, c'est la première chose sur Boucle, sur cette notion de. Je donne la capacité à l'IA de vérifier son travail. Autre chose qu'on entend avec les boucles, c'est des tâches périodiques. Et donc, c'est avoir une boucle sur une tâche périodique qui va tourner tous les jours ou toutes les heures, qui va monitorer quelque chose, genre sur Twitter, les plaintes clients sur ton produit, ou dans Gira, les nouveaux bugs, ou je ne sais pas quoi, et puis qui monitorent et dès qu'il y a un événement, font quelque chose, implémentent, une feature, font une PR, ou alors à chaque fois que, enfin, bref, voilà. Donc, il y a cette notion de périodicité. Et après, il y a des trucs un peu plus abstraits, qui est juste, je pense que c'est Boris qui est le concepteur de cloud code, qui dit juste, il faut que tout soit des boucles, et on a des agents qui administrent les boucles, et ça je ne comprends plus à partir de là. Ça devient beaucoup trop flou, beaucoup trop abstrait. Pour moi, les boucles, c'est cette boucle entre code et vérification, et puis les tâches périodiques. Les tâches périodiques, on ne fait pas tellement, on l'utilise un petit peu, mais en vrai, pas trop. En revanche les bouclages antiques ça c'est notre obsession dès qu'il y a besoin de développer quelque chose il faut avoir la boucle de validation que l'IA peut faire.

Bruno — Sur le concept de harnais je te rejoins, moi sur la partie loop, pour moi c'est sur ces, si je pense de moi ma compréhension c'est vraiment très exclusivement cette notion de comment je peux avoir un système où j'ai toutes les validations et du coup il est capable de produire quelque chose de s'assurer que c'est bon et tant que c'est pas bon il continue, à boucler et comment s'assurer en fait que j'ai le moins de validation à faire derrière en tant qu'être humain, c'est à dire que comment je peux faire pour que vraiment, le bouton magique je dis fais moi ça et il me fait ça et faire en sorte que le fais moi ça soit de plus en plus de plus en plus flou de plus en plus vague, que tu puisses vraiment avoir un système qui soit de plus en plus autonome moi en tout cas c'est aussi comme ça que je le vois, du coup en termes d'outillage j'imagine que ça passe beaucoup par des skills et des points MD. À quel point est-ce que c'est des skills maison Théodaux versus des choses que vous chopez sur Internet versus des capacités entre guillemets natives de CloudCode ?

Quentin — Le gros de ce qu'on a, c'est Maison. C'est Maison parce qu'en fait, on y terre vachement dessus. Et on a des apprentissages et puis on change. On est quand même sur une tâche hyper précise. Il y a des frameworks de skills qui existent. Il y a les frameworks B-MAD ou Superpowers ou même Matt Pocock dont je parlais tout à l'heure, il a aussi son framework de skills. Mais en fait, on peut, même si on les utilisait, on les copierait dans notre repo et on les ferait évoluer. On est sur cette tâche hyper précise de migration, donc on n'a pas besoin d'avoir des trucs très génériques. Elle peut être plus précise, voilà. Mais ça ressemble beaucoup au framework existant de skill, quoi. Donc on a des skills. On fait très attention aux skills. C'est la solution de facilité lorsqu'il y a un problème de dire je vais rajouter une règle dans le skill. Tu dis la skill ou le skill ? Moi je disais la skill, j'entends plein de monde qui disent le skill, donc je ne sais plus, je fais un coup sur deux.

Bruno — Pour moi c'est une compétence.

Quentin — Oui c'est ça, pour moi ça paraît normal. Mais en fait, ce qu'on a vu sur des projets, c'est que du coup les skills, les skills au pluriel comme ça, elles deviennent de plus en plus grandes et on a plein de règles dans tous les sens hyper précises etc et en fait je me souviens que c'était. Le fondateur de CloudCode, Laboris, qui disait qu'un modèle il faut penser qu'il peut suivre 200 instructions, 200 règles donc si on lui donne un millier ça fait trop de choses, surtout les modèles plus intelligents maintenant, ils sont perturbés avec ça, et donc en fait il faut faire très attention et rajouter des règles dans les skills, c'est la solution de dernier recours. Il faut épuiser toutes les autres solutions en avant. Donc, par exemple, c'est, si l'IA a mal fait quelque chose, c'est peut-être parce que dans la code base existante, enfin dans la code base dans laquelle on travaille, il y a ce pattern-là, ce mauvais pattern que l'IA refait. Donc, au lieu de dire ne fais pas ce pattern, il suffit de temps en temps de juste aller faire un scan de la code base existante, retirer ce pattern partout et comme ça, l'IA arrêtera de le faire. parce qu'elles reproduisent ce qu'elles voient. Ou par exemple, faire un outil déterministe qui permet, de faire la tâche qu'on va faire parce que l'IA n'arrive pas à bien faire un truc. De temps en temps, ça peut être fait de manière indéterminée. Donc, il y a tout un ensemble de choses avant de faire la skill. Mais bon, bref, on a notre collection de skills, on a nos outils, nos scripts déterministes qu'ils sont faits à côté, qu'ils peuvent utiliser. Et c'est ça essentiellement. C'est-à-dire qu'on est dans Cloud Code avec les skills, les outils, Et c'est notre harnais.

Bruno — OK. Et du coup, en termes de formation, d'accompagnement, parce que c'est un métier très différent, enfin, quand même assez différent de ce qu'on avait avant, est-ce qu'il y a aussi... Tu parles de cette compétence de grill-me. Est-ce qu'au final, les gens peuvent répondre n'importe comment, comme ils veulent, à un grill-me ? Est-ce que vous devez accompagner les gens chez Théodaux pour interagir correctement avec ces outils-là ?

Quentin — Alors oui, carrément. Carrément, et pas seulement qu'avec l'IA. Avec les fondamentaux du software engineering aussi. Qui, maintenant que l'IA fait tout, en fait, ça ne s'apprend pas de manière naturelle. Il ne suffit plus de mettre un junior à côté d'un expérimenté pour qu'il apprenne les fondamentaux. Du coup, nous, ce qu'on remarque, c'est qu'il faut être beaucoup plus intentionnel en termes de formation. Là où avant, À l'époque, il y a deux ans, il suffisait, voilà, tu vois, tu mets des juniors et des seniors, et puis il y a un transfert naturel de compétences. Là, le junior, en fait, il ne voit pas. Et donc, nous, ce qu'on change en interne, c'est qu'on fait, des parcours de formation, tu vois, avec des exercices et des formations qui sont certifiantes en interne, tu vois, en disant, bon, un tel, il sait faire du back-end en speedboot. Un tel, il sait faire du front en react.

Bruno — C'est des formations où vous apprenez aux gens à coder à la main, à l'ancienne, où on reste sur réussir à le faire correctement avec l'IA ?

Quentin — C'est « il faut savoir faire à la main avant de le faire faire avec l'IA ». Mais, Mais il y a aussi d'autres façons de découvrir, pour découvrir par exemple React. La façon traditionnelle, c'est tu codes en React, tu suis des tutoriels et tout. Et il y a une façon qu'on aime bien faire pour apprendre une technologie, c'est de demander à la personne de la réimplémenter, lorsqu'elle a déjà joué avec à la main, de la réimplémenter avec l'IA. Donc tu dois réimplémenter, reconstruire React. Mais avec l'IA et avec les phases de Grimmy, c'est toi qui dois réfléchir et tu dois comprendre comment fonctionne React à l'intérieur tu dois guider l'IA pour qu'elle les réimplémente tu vas écrire du code React et puis avec ton propre moteur parce que tu n'as pas la librairie tu vas le faire tourner et en fait ça donne une très bonne compréhension de comment ça marche, et pareil pour Cloud Code ça fait partie de la formation de tous les théoders qui rejoignent la boîte ils passent par un module où ils doivent recoder CloudCode, Évidemment, ça ne fait pas tout que l'autre code. Ils vont en fait recoder un espèce de mini-harnais agentique qui implémente la boucle de je prends le point d'utilisateur, j'appelle l'API, j'appelle les tools, etc. Et c'est ça qui donne une compréhension un peu plus fine de ce qui se passe à l'intérieur des outils qu'on utilise.

Bruno — Ce qui est marrant parce que il y a longtemps, on expliquait à des gens plus jeunes, il y a vraiment longtemps, que pour apprendre à maîtriser un langage fallait commencer sans framework pour faire le langage brut surtout à s'obliger à se confronter à tous les problématiques que ça pouvait avoir pour qu'après, quand on te donne un framework du coup tu on te simplifie la vie sur plein de choses et du coup tu fais les choses de manière là en fait le fait de vouloir recoder cloud code c'est une manière de ça t'oblige à comprendre, le bas niveau la tuyauterie du système que tu utilises pour en faire plus avec le système.

Quentin — Bah oui mais en fait c'est la même chose tu vois de dire t'es en PHP tu peux faire sans framework parce que tu peux en PHP c'est un peu triste.

Bruno — Parce que du.

Quentin — Coup des gens font sans framework tu fais sans framework après tu vois comment on utilise un framework c'est super, moi j'avais suivi, je me souviens à l'époque la série de post de blog de Fabien Potentier qui expliquait comment recoder un mini-framework en PHP à partir de zéro. Et donc, il avait fait une série, je ne sais plus, il y a 6 ou 10 posts à la suite qui expliquent les différentes composantes d'un framework. Et c'est super. C'est comme ça qu'on comprend vraiment comment c'est fait à l'intérieur. Donc, c'est une autre façon de la prendre. En vrai, je n'ai pas vraiment la réponse sur comment les... Les juniors doivent apprendre à la fois les bases du code et du software engineering. Et puis avec l'IA, il n'y a pas assez de recul. Donc on teste des trucs, mais il y a un monde dans lequel les jeunes, en utilisant l'IA, ils ne comprennent pas vraiment ce qu'ils font. Même avec tout ça, même s'ils font un petit peu la main et qu'après ils utilisent l'IA, même s'ils recodent React ou CloudCode et qu'après ils l'utilisent. Voilà, on verra. peut-être qu'il y a une génération nous on fait partie des vieux qui avons appris, à coder à la main en se prenant des erreurs des pages blanches dans le navigateur et on a développé une espèce de gymnastique mandale que les jeunes auront plus mais peut-être qu'elle ne sera plus non plus nécessaire.

Bruno — Les jeunes vont aussi apprendre en faisant des erreurs c'est juste qu'ils n'auront pas une erreur d'un point virgule qui manque ou d'une accolade qui est mal fermée, mais ils vont faire des erreurs aussi ils vont aussi apprendre leur métier comme nous au travers des erreurs.

Quentin — C'est vrai, avec un autre niveau d'attraction t'as vibe codé un truc pendant 3 jours dans le code base, puis ça a planté ça marche plus, et tu dois naviguer dedans, c'est peut-être plus des choses d'architecture c'est peut-être d'autres compétences effectivement il n'y aura plus de questions pour un virgule bon.

Bruno — Parce que forcément, j'étais obligé de te poser des questions d'oracle pour nous donner ta vision sur l'avenir de notre métier. Mais avant d'aller là-dessus, je serais curieux d'avoir ton point de vue. Parce que du coup, toi, tu as des équipes qui donc n'écrivent pas de code. Ils ne font que générer du code. 100% du code est généré. On parle beaucoup d'une forme de fatigue parce qu'en fait, du coup, le métier est très différent. Et notamment, j'ai vu des... Et que parfois, je partage. C'est vrai que quand tu passais trois heures à chercher ton point virgule et que tu arrivais enfin à le trouver, à le corriger et que ça marchait, tu avais un vrai sentiment de satisfaction, tu avais une vraie fatigue liée à cet effort que tu avais fourni pendant trois heures à tout décortiquer. Et on a le sentiment qu'avec l'IA, on a moins ce sentiment d'accomplissement, qu'on a moins le sentiment de fatigue et de se dire, là, du coup, c'est bon, j'ai mérité de finir ma journée à cet endroit-là parce que j'ai réussi à faire tout ça.

Quentin — Moins le sentiment de fatigue ?

Bruno — Moi j'ai le sentiment qu'effectivement quand je passe ma journée à coder avec Claude j'ai moins le sentiment de me dire là j'ai bien travaillé j'ai mérité ma fin de journée parce que j'ai l'impression que c'est Iliac qui a plus travaillé que moi.

Quentin — Ah c'est intéressant oui, C'est intéressant moi ce que j'entends souvent c'est que au contraire il y a des gens qui sont, enfin on entend plein de choses il y a des gens qui sont rincés en fin de journée parce qu'ils disent que c'est intellectuellement hyper... C'est vrai aussi. Tu vois, ils te piquent dans tous les sens, tu switches en plein donglet, etc. D'autres qui s'ennuient. Et ça, tu vois, on a des projets sur lesquels on arrive à un stade où, tu vois, où l'usine est mature, justement, où tout va bien, le code fait le monde du premier coup, et puis on relie DPR, et puis on améliore un petit peu. Pour moi, c'est quand on arrive à un stade comme ça, où... Où l'humain ou le dev se dit qu'il n'apporte pas de valeur ajoutée dans ce qu'il fait et puis ce n'est pas très amusant. Pour moi, c'est un bon signe qu'il y a peut-être quelque chose à automatiser. Tu vois que c'est que le dev apporte plus de valeur à ce niveau-là et que du coup, peut-être que, c'est un agent qui devrait le faire ou qu'il faut changer notre façon de faire ou qu'il faut arrêter de faire cette activité et qu'il faut réfléchir différemment. Moi, ce que j'entends aussi, c'est que les gens sont capables de créer des trucs de ouf comparé à avant l'IA.

Bruno — C'est vrai.

Quentin — C'est-à-dire que...

Bruno — Oui, moi, ce que j'ai beaucoup partagé à ce micro, c'est que j'ai repris du plaisir à coder.

Quentin — Parce qu'en fait, avant.

Bruno — C'était fastidieux de coder. Parce que moi, ça fait près de 35 ans que je code. Donc, en fait, quand on me demande de créer une application, l'application, elle est très rapidement prête dans ma tête. Mais le temps de le taper, c'était très, très long. Ça devenait fastidieux. alors qu'aujourd'hui effectivement en quelques jours, l'application elle est up and ready et on avance beaucoup plus vite donc j'ai retrouvé un plaisir de ce côté là mais c'est vrai que quand j'étais jeune je faisais aussi des sessions de code, où tu codes jusqu'à 3h du matin sans réaliser qu'il est déjà 3h du matin, mais oui je vois beaucoup parler de cette fatigue parce qu'il y a un métier qui est du coup très différent et du coup pour beaucoup de développeurs et développeuses, l'impression que le métier est moins challengeant qu'avant.

Quentin — Ok intéressant moi j'ai vu une différence quand on a introduit le grill-me, dans notre méthode la méthode dont je t'ai parlé tout à l'heure il y avait deux phases de grill-me, une fonctionnelle une technique mais ça n'a pas toujours été le cas, au début on devait vachement tu vois, prompter expliquer etc, il fallait penser à tout et quand on l'a mis en place en fait on l'a mis sur un projet, ça s'est propagé comme une traînée de poudre et puis même les PM Les PM qui n'étaient pas dans Cloud Code avant, tu vois, on les a mis dans Cloud Code, les PO, PM, et, ils lancent les grignes, ils répondent dedans. Et en fait, ça change, je ne sais pas comment trop l'exprimer, mais ça change la dynamique qu'il y a entre le dev et l'IA, et on maîtrise beaucoup plus ce qu'on fait, on sent beaucoup plus son contrôle. Et moi, c'est une activité que j'adore, tu vois, je pense à quelque chose un peu flou, une direction, une feature ou un refactoring dans la code base ou, un nouvel outil pour faire quelque chose en interne, je ne sais pas quoi. Et puis, je commence une séance de Grimmy, puis il me pose plein de questions et je trouve ça trop drôle. Tu vois, il me propose plusieurs choix et tout. Et puis, j'ai vraiment l'impression d'être aux manettes. Alors que si je dis juste, je vais faire ça, en fait, en normal, sans Grimmy, en fait, il part tout juste, il va te développer un truc, tu vas dans le navigateur, tu vois plein de trucs, tu dis non, mais attends, non, ce n'est pas ça. tu reviens en arrière et tu fais du ping-pong.

Bruno — Je trouve que ça change un peu là-dessus alors du coup on en vient au moment, boule de cristal, moment un peu oracle comment est-ce que toi tu vois l'avenir du métier de développeur et de développeuse ?

Quentin — C'est une vaste question en vrai j'en sais rien j'en sais rien je vois que les modèles deviennent, toujours meilleurs que autour du modèle toute l'ingénierie fait que ça marche de mieux en mieux, mais quand même qu'on a toujours autant besoin de devs et de gens techniques. Tu vois, à aucun moment, je me dis que je peux remplacer mes devs par des IA. Au contraire, je cherche encore plus des techs forts aujourd'hui avec l'IA qu'avant. Parce qu'avant, en fait, on avait besoin un peu de tous les niveaux. On avait besoin des techs un peu moins forts parce que de toute façon, il y avait des tickets qui étaient préparés par le tech lead où il y avait tout spécifié, il fallait l'implémenter. Donc voilà, ça s'est peut-être au niveau. Là, au contraire, tu vois, il y a encore plus besoin de profils tech. Et des techs forts. Donc, je pense que... En vrai, je n'ai aucune idée à une échéance de même cinq ans. Mais je pense qu'au moins dans la prochaine année ou les deux prochaines années, on aura toujours besoin de dev et toujours besoin de techs forts.

Bruno — Je partage ton avis. J'ai réalisé qu'il y a des questions que je ne t'ai pas posées, des questions qui sont peut-être très chiffrées, mais de part, ce que vous faites aujourd'hui, je pense que tu as peut-être un moyen de nous donner une vision, alors on sait que ça va être très spécifique à ton domaine et qu'il ne faut pas prendre ces chiffres comme étant de généralité mais j'aurais, deux questions chiffrées la première c'est, c'est quoi le ratio que tu vois sur ces projets de migration que vous avez s'il était fait par des humains versus, ce que vous faites aujourd'hui c'est quoi, le ratio le gain qui est fait, et le deuxième au delà du temps que vous gagnez c'est sur le coût en token, que ça représente OK.

Quentin — Aujourd'hui, on va en moyenne quatre fois plus vite que si on le faisait à la main.

Bruno — À taille d'équipe ISO ?

Quentin — À taille d'équipe en nombre de jour-hommes en fait donc en fait tu peux avoir une demi-équipe en nombre de jour-hommes c'est 4 fois moins de jour-hommes pour faire le travail, et pour nous effectivement c'est très c'est très biaisé ce que je dis, ça ne s'applique pas du tout à d'autres domaines, nous on est sur de la réécriture de la réécriture le plus souvent isofonctionnel, donc il n'y a pas la boucle avec les métiers où il y a des specs, on a tout le code, on est autonome on nous confie l'application et on peut aller le plus vite possible enfin on a un week-end il y a très peu, bon c'est pas aussi simple que ça mais il y a beaucoup moins d'éléments qui freinent, que dans d'autres cas et ce qu'on entend d'ailleurs dans d'autres cas c'est qu'ils disent que pour des gens qui font du beat classique c'est qu'ils disent que c'est plus tellement, le code qui les freine les projets accélèrent pas vraiment parce qu'en fait il y a plein de dépendances externes qui freinent le projet et donc du coup, le code c'est pas le code on a des gains.

Bruno — Qui sont de l'ordre de 1.

Quentin — 1,5 mais pour l'immigration on va à 4 fois plus vite et pour nous on le mesure on le suit de manière très précise parce que comme on est dans le service on facture au temps passé donc on sait on faisait des migrations avant l'IA donc on sait combien, de jours hommes il faudrait pour migrer tel système et maintenant avec l'IA et en fait en moyenne on est à 4 fois plus vite Et on a des projets sur lesquels on va dix fois plus vite. C'est-à-dire qu'une migration de deux ans, on l'a fait en, je ne sais pas, dix fois plus, deux mois et demi, tu vois. Mais ça, ça dépend vraiment, de toutes les conditions de travail qu'on peut avoir. Si toutes les étoiles sont alignées, ça va hyper vite. Ça veut dire que si... C'est des petits détails, mais par exemple, si on a un langage typé en cible, ça marche mieux. Si on est autonome pour pousser en prod ça marche mieux, de temps en temps on doit mettre ça et c'est notre client qui doit pousser en prod, si c'est du pur raison fonctionnel bien sûr si on peut bien faire cette boucle de validation si on peut faire tourner le legacy en local on nous envoie le legacy alors qu'il y a des migrations par exemple le windev tu vois ce que windev, vieux langage vieux langage qui est utilisé dans plein de boîtes pour construire des ERP qui font tout le business de la boîte, qui ne marchent que sur... C'est des clients lourds en Windows où il faut une clé USB avec la licence qui est branchée à la... Voilà. Et donc ça, en termes de boucle de feedback de l'IA, c'est nul. Parce que nous, on veut avoir Cloud Code qui peut faire tourner le legacy pour voir son fonctionnement, voir ce que c'est... Voilà. Donc ça, c'est des genres de situations où c'est plus difficile. On le fait, on a plein de projets Windev, Je ne sais pas si tu connais l'histoire de Windev, mais il y a un éditeur, l'éditeur qui s'appelle PCsoft s'est fait racheter par un fonds il n'y a pas longtemps. Ils ont décidé de mettre des licences, de changer le mode de facturation en licence. Donc, tu as des boîtes qui ont basé leur business sur des ERP ou sur des logiciels internes Windev ou même externes pour des éditeurs. Ou une dev, et donc ils ont acheté une licence une fois que les naissances à vie, tout à coup, PCsoft dit, ben non, à partir de maintenant, vous devez payer tous les mois, pour tous vos devs.

Bruno — Ça change le...

Quentin — Et oui, et c'est insupportable. Et ils ont même passé un deuxième truc maintenant, non seulement les devs, il y a des licences par dev, mais pour tous les utilisateurs de la solution.

Bruno — Une folie.

Quentin — Oui. Et donc, tu as même des collectivités locales, des villes, des départements, des mairies qui ont fait des outils pour leurs... Voilà, avec, je ne sais pas, 20 000 utilisateurs, 200 000 utilisateurs, et où ils se retrouvent à devoir verser à l'éditeur PCsoft des abonnements pour ça. Donc, c'est impossible. Donc, on a une avalanche de gens qui nous appellent en disant bonjour, et on voudrait sortir de WinDev et réécrire dans un autre langage, parce que, voilà.

Bruno — Et du coup, l'autre question, je vais chiffrer, c'était sur le coût en token. Est-ce que, du coup, c'est juste un abonnement de 200 CloudMax qui suffit pour chaque dev, ou est-ce que vous devez, vous êtes plutôt à, je ne sais pas, 2, 3, 4 000 euros en plus par développeur et par mois ?

Quentin — Alors le coût en token dans nos migrations, ça dépend évidemment du rythme auquel on va. Plus on peut aller rapidement parce que les conditions de travail, plus on va consommer de token. Mais l'ordre de grandeur, c'est les tokens qu'on consomme, si c'est du cloud, c'est entre 2 000 et 4 000 euros par mois et par personne. Donc, c'est un sacré budget quand même.

Bruno — C'est presque une personne de plus, au final.

Quentin — C'est presque une personne de plus, ouais. Mais 2 à 4 000 euros, tu vois, si on est dans un fauchette haut de 4 000 euros, c'est dans les cas où on va 10 fois plus vite. Donc, en fait, l'équation économique, elle est quand même favorable parce qu'on va 10 fois plus vite et on paye, tu vois, une fraction du salaire en plus de la personne. Donc, ça marche. Ça c'est sur les modèles cloud, Open Air c'est pareil, depuis cet été les modèles open source et les open wait les modèles chinois, ils deviennent assez bons pour faire ce qu'on fait et ça potentiellement c'est quelque chose que on va peut-être assister dans les prochains mois, tu vois d'ici la fin de l'année, d'ici décembre un espèce de shift de toute l'industrie là-dessus parce qu'on a fait une expérience de migration, sur un bench qu'on a en interne de pages. En moyenne, les pages qu'on migrait, ça coûtait 200 dollars par page avec load et avec OpenAI. On a fait le test avec le modèle chinois GLM 5.3 et la version flash. Donc moins intelligente et plus... Elle a presque réussi à faire bien. Il y avait quelques défauts. À la place de 200 dollars, tu sais combien c'était ? C'était 1 dollar.

Bruno — Ah oui, le ratio est...

Quentin — 1 dollar. Donc on passe de 200 dollars à 1 dollar. Donc en fait, au bout d'un moment, ok, on veut les meilleurs modèles pour aller le plus efficace et tout, mais si on baisse un petit peu la qualité... Et que ça baisse autant les coûts. Au bout d'un moment, tu vas avoir l'équation économique qui va tirer trop fort de l'autre côté. Donc, c'est possible qu'on utilise les modèles OpenWise d'ici décembre ou quoi.

Bruno — Ce qui serait pas mal, parce qu'on annonçait une explosion du coût du token avec ces quelques acteurs qui maîtrisaient le marché. Avec effectivement, de plus en plus, il y a un Kimi aussi qui a des performances folles. Effectivement, héberger un modèle, ça te coûte un peu d'argent. Mais si tu le pousses dans ses retranchements ça ne te coûte rien par rapport à ce que ça te coûtera en token chez un acteur.

Quentin — Je ne sais pas pour héberger je pense que l'équation économique de l'hébergement toi même dans ton infra des modèles elle est assez tricky le mieux je pense que c'est t'as des providers, et même européens donc du coup t'es l'RGPD ok tu passes pas par les API chinoises mais dont c'est leur métier d'héberger des modèles et du coup, ils ont des économies d'échelle et ça coûte moins cher au token et donc tu t'en sers comme une API, donc dans ton cloud code t'as juste une ligne à mettre pour qu'il utilise GLM 5.3 Flash ou alors tu utilises un autre harnais qui est mieux adapté à ça, mais l'hébergement ça coûte tout de suite vachement cher parce qu'il faut optimiser vachement l'utilisation des GPU.

Bruno — Top, merci beaucoup Quentin pour cette discussion J'aurais une dernière question pour toi Qui sont les questions rituelles du podcast La première c'est est-ce qu'il y a un contenu que tu serais partagé Avec l'ensemble des auditeuristes Ouais.

Quentin — Alors moi le contenu Que je préfère c'est la newsletter AI News Que je lis religieusement tous les jours, C'est une newsletter Qui est écrite par l'IA Et donc, qui le dit comme tel Donc c'est affiché Et c'est plutôt rafraîchissant et je trouve qu'on lit pas la même chose un contenu où on sait que c'est l'IA qui l'a écrit plutôt que c'est un humain qui l'a écrit mais on sait qu'il l'a écrit avec l'IA et du coup ça fait bizarre, là c'est écrit par l'IA et ça scanne, plein de comptes Twitter et Reddit et ça fait un espèce de digest quotidien, et je trouve ça cool parce que avec ça on est au courant d'absolument tout ce qui passe par contre c'est très très long mais on scrolle vite fait et on voit s'il y a des informations utiles.

Bruno — Canon et dernière question la plus importante de ce podcast Quentin, tu es plutôt espace ou tabulation ?

Quentin — Alors moi c'est espace sans aucun doute j'ai aucune raison pour ça c'est juste c'est dans mes tripes émotionnel moi ça me gêne de voir des tabulations.

Bruno — Dans les espaces Merci beaucoup Quentin merci Bruno et merci à tous d'avoir suivi cette conversation, donc voilà on a un exemple donc dans un côté encore une fois c'est un contexte très particulier, je sais bien qu'on peut pas appliquer cette stratégie exactement à tous les contextes mais en tout cas ça donne des bonnes idées pour essayer de faire la même chose on est encore très loin, du bouton automatique qu'on peut dire à Claude fais-moi un ERP et il fait tout tout seul on est bien d'accord, on a encore pas mal de boulot à faire mais donc on est de plus en plus sur la conception d'usines et je trouve que le projet est plutôt pas mal hyper intéressant. Donc voilà je vous remercie comme toujours de partager ce podcast autour de vous, je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, codez bien.