IA et génération de code : productivité boostée, lucidité en danger

0:05 Alors, on va continuer avec un autre talk qui arrive, c'est celui d'Arthur Magne. Alors, Arthur, c'est très intéressant parce qu'il est le CPO, vous le savez, de PackMind, et il va nous expliquer comment l'IA peut faire gagner beaucoup de temps. On l'a vu depuis quelques talks, mais il va surtout nous montrer comment on peut garder cette maîtrise avec lucidité, la bonne qualité, les bonnes pratiques surtout, et la rigueur. C'est un talk qui me paraît éviter que la génération de codes ne devienne une manipulation temporelle incontrôlable. Je vous demande d'accueillir Arthur Magne. Let's go. Salut, salut Arthur. Merci beaucoup. Ça va? Ça va très bien. Il fait chaud en loge et là, on est mieux. Là, on est bien. On est super bien. Il fait 40 degrés en loge, c'est une horreur. C'est vrai. Alors, juste, je précise parce que j'ai oublié. Pardon, Arthur, n'oubliez pas que vous avez les QR codes pour commenter les talks que vous voyez. Donc là, écoutez bien celui d'Arthur pour ensuite le commenter. À tout à l'heure. Commentez-le. Merci. Effectivement, je ne vois personne. J'ai l'impression d'être sur Teams avec tout le monde qui a sa caméra coupée.

1:08 Je suis le seul à présenter mon truc. C'est une journée comme toutes les autres pour moi. C'est très bien. Évidemment, je vais vous parler d'IA, mais je ne vais pas rentrer directement dans ce que l'IA va apporter dans notre métier de développement. Je voulais en premier prendre un petit peu de recul sur ce qu'on a appris des dernières années autour de notre métier de développeur, développeuse, etc. Et je vais le faire par le prisme de ma propre expérience. Je vais vous raconter un petit peu mon histoire, rapidement, je vous rassure. Ce qui s'est passé, c'est que j'ai fait mes études, un peu comme tout le monde, à l'université de Bordeaux pendant cinq ans. Et on est en 2014, je termine mes études. J'ai appris pendant toutes ces années des bonnes types d'architecture, la partie test, la partie pragmatique du développement. Et je me retrouve à faire mon stage de fin d'études, un stage de six mois, dans une grande ESN, dont on ne doit pas prononcer le nom, pour un grand compte bancaire dont on ne doit pas prononcer le nom non plus. Mais en fait, le nom, il importe peu. C'est le genre de contexte qu'on va retrouver un petit peu partout.

2:11 Donc moi, j'arrive dans cette entreprise, je suis super content, c'est une grande entreprise toute neuve, etc. Et j'arrive sur mon poste de développement, j'ai mon premier projet qui arrive, c'est un gros projet pour la banque. Et je me retrouve dans un état second, où je me dis« qu'est-ce que c'est que cette merde? » En fait, je me retrouve avec 1500 lignes de code JavaScript et Dotus Notes mélangées, pour ceux à qui ça parle, sans aucun test, sans aucune structure, sans aucune logique. Et je me dis« ok, ça c'est le genre d'application sur laquelle il y a 50 personnes qui sont passées pendant les 20 dernières années, tout le monde n'en avait rien à faire, ça a été des bridges sur des bridges sur des bridges. » Et j'ai eu un peu peur, je me suis dit, est-ce que c'est ça notre métier de développeur? Est-ce qu'on apprend des trucs super à l'université ou en école d'ingé? Et derrière, on se retrouve à essayer de mettre des rustines sur des rustines dans les applications. Donc évidemment, j'en ai parlé autour de moi aux autres collègues qui étaient partis en stage dans différentes entreprises. Et la première chose qui m'a marqué, c'est que c'est très hétérogène. Évidemment, tous les projets ne sont pas comme ça, heureusement.

3:11 Il y a des projets qui sont très bien, il y a des projets qui sont très moyens, puis il y a des projets qui sont très nuls. J'ai peut-être juste pas eu de chance. Donc à ce moment-là, évidemment, je me suis dit, ça va être une catastrophe. Je ne vais peut-être pas rester dans ce monde-là. Je vais peut-être faire une reconversion en boulangerie ou autre chose. Mais non, j'ai eu un peu de chance. Je suis tombé sur mon maître de stage qui travaille au laboratoire de recherche de Bordeaux et qui m'a dit, on est en train de monter une start-up justement sur la qualité logicielle, sur tout ce qui est justement gestion d'adhètes techniques, etc. Donc évidemment, je ne suis pas resté dans mon stage. dans la grosse ESN, je suis parti créer justement cette entreprise avec cette personne de l'Université de Bordeaux. Et c'était super intéressant parce qu'on a été vraiment à l'inverse de cette partie non qualité. On s'est mis à travailler sur comment est-ce que les entreprises devraient gérer leur dette technique, gérer justement la qualité. Ce qui a fait que pendant les années qui ont suivi, donc là on était encore en 2014, donc pendant les 5, 6, 7 années qui ont suivi, ça m'a permis de faire pas mal de conférences et de rencontrer pas mal de monde, des gens qui sont dans la salle ici, pas mal de gens que j'ai rencontrés grâce à TechRock d'ailleurs, pour la petite histoire c'est hyper intéressant, des gens comme Julien Topsu, qui est ici, des gens comme Cyril Martraire, Dora Bartaguis, Fabrice Bernard de Théodo, etc.

4:18 Donc plein de gens qui poussaient différents mouvements qui étaient hyper intéressants pour notre métier, et notamment le mouvement Software Craftmanship, pour ceux à qui ça parle. Le mouvement Software Craftmanship, ça explique que notre métier de développeur, ce n'est pas un métier d'exécutant un peu classique, ça se rapproche beaucoup de l'artisanat, dans le côté compagnonnage, mentoring, recherche d'excédence technique, recherche d'application des meilleures pratiques dans le code, etc. Donc ça a été super intéressant pendant des années. On s'est mis à travailler autour de ça, à essayer de former aussi des équipes autour de ça. Donc c'était génial, mais qu'est-ce qui s'est passé justement au bout de certaines années? Rien du tout en fait. Au final, ce mouvement s'est resté un mouvement qui était assez niche, qu'on n'a pas retrouvé. dans la majorité des entreprises, ou alors quand les entreprises vous disent « bah oui, nous on est craft, on fait des trucs super », oui, en général, c'est peut-être 10% des équipes, et encore dans les équipes, c'est 20% de l'équipe elle-même, etc. Donc en fait, on sent que le mouvement craft, lean, etc., plein de choses autour de ça, ils n'ont pas vraiment percé globalement, parce que ça demandait de la conduite du changement, et vous savez que la conduite du changement, c'est compliqué.

5:20 Donc ce qui s'est passé, c'est que quelques années après, 2021, 2022, on a ChatGPT qui sort, on a GitHub Copilot qui sort, les premiers outils justement avec les LLM qui permettaient de générer du code, et on se retrouve avec une baguette magique où on a l'impression qu'on va pouvoir faire du vibe coding et avoir d'un seul coup avec un tout petit prompt un truc magique qui arrive. Ce qui s'est passé en fait, c'est que quand on commençait à ouvrir LinkedIn à ce moment-là, on était à la foire de Paris avec des vendeurs qui nous disaient« Regardez comment en 10 minutes j'ai fait une application que normalement j'aurais fait en 3 semaines, regardez ma to-do list avec 3 features PT, c'est vraiment génial, vous allez pouvoir faire pareil, virer tous vos développeurs, etc. Donc évidemment, si on est là aujourd'hui encore, c'est que ça ne marche pas comme ça. Ce n'est pas aussi magique que ça en a l'air. Et ça a été justement la première chose importante qu'on a appris quand l'IA est arrivée. C'est qu'en fait, il y avait des promesses énormes qui avaient été faites. Des promesses énormes justement sur les gains de productivité qu'on allait avoir, sur le fait qu'on n'allait plus avoir à relire du code et à travailler du code, etc. Alors si c'était le cas, les LLM, ils écriraient du code en assembleur et pas en Java pour qu'on puisse voir les boulettes qu'ils ont fait.

6:24 Donc le but aujourd'hui des LLM, c'est qu'ils écrivent du code qui est facile à comprendre et à lire par les humains pour justement s'assurer que tout fonctionne bien, ce qui n'est souvent pas le cas. Donc en fait, pourquoi est-ce que ça ne marche pas? Pourquoi est-ce que quand on prend des choses qui sont dites sur des kédines et qu'on essaye de l'appliquer chez nous à la maison, souvent c'est une catastrophe? Parce que souvent quand les systèmes sont complexes, on a besoin de beaucoup de contexte, on a besoin de guider justement l'IA, un peu ce qu'a dit Quentin aussi avec son talk juste avant. En fait, il faut découper les choses, il faut être capable de donner le bon contexte, de guider ces IA, etc. Et une IA toute seule, c'est un peu débile. Évidemment, si on la lance sur un projet complexe à faire beaucoup d'actions de manière assez généraliste, on va se retrouver avec un château de cartes qui, au bout d'un moment, va finir par se casser la gueule. Donc on va avoir des problèmes de dette technique à retardement qui vont arriver, et peut-être que dans six mois, peut-être que dans un an, qu'on va devoir vraiment reprendre le code qui a été généré par DIA, ça va être très compliqué. Donc en fait, ça c'est un constat qu'on a fait, c'est un constat que différentes personnes ont fait. On s'est dit, est-ce que c'est le cas pour tout le monde? En fait, qu'est-ce qui se passe au niveau des entreprises globalement dans le monde, que ce soit en France, aux Etats-Unis ou ailleurs?

7:29 Et il y a l'étude d'Aura évidemment qui est sortie. Et l'étude d'Aura 2025, elle rapporte des choses assez intéressantes qui sont assez proches de celles de 2024. Notamment le fait qu'individuellement, quand on utilise de l'IA, on a l'impression d'être beaucoup plus productif. Oui, c'est parce que là, on voit le code qui se génère très rapidement, on peut faire plein de choses qu'on ne faisait pas forcément avant, etc. Donc l'effet TENX qu'on peut essayer de chercher, individuellement, on peut presque réussir à l'atteindre. Par contre, individuellement, on s'en fout un petit peu, à moins qu'on soit dans une start-up et qu'on doit y faire d'époque. C'est assez intéressant. Mais si on travaille dans une vraie organisation, dans une vraie entreprise, il faut regarder la globalité. Il faut regarder est-ce que l'output de l'entreprise, le chiffre d'affaires, etc. Évolue dans la bonne direction. Et est-ce que pas juste moi individuellement, je m'en sors. Et ce qu'on voit en fait avec les études d'Aura, c'est le petit truc orange là qu'on voit au milieu, c'est que plus on utilise d'IA dans notre logiciel, plus c'est d'IA qui génère justement du code, plus on va perdre en stabilité sur notre delivery. Ça veut dire qu'on va avoir plus de bugs, ça veut dire qu'on va avoir peut-être une maintenance qui va être accrue, etc. Ça va être beaucoup plus compliqué.

8:31 Donc on se rend bien compte aujourd'hui que l'IA va nous donner de la vitesse, mais en fait la vitesse sans le contrôle, ça peut être catastrophique. Ça peut être catastrophique à court terme comme encore plus à moyen long terme. Et il y a aussi une chose qui est assez intéressante dans le rapport d'Aura, c'est qu'ils nous disent que 30% des gens qui utilisent IA n'ont pas confiance, ou ont très peu confiance dans le code qui est généré par des agents IA. Et ça, en fait, c'est juste pas viable. Pourquoi? Parce qu'on est en train de nous dire, les équipes de GitHub Next, etc., de plein d'entreprises, nous disent, en fait, l'équipe du futur, les équipes tech, c'est un mélange d'humains et d'agents IA, d'agents spécialisés, etc. Donc vous pouvez imaginer les agents IA comme des gens qui participent justement avec vous, qui sont vos collègues. Si vous avez un collègue et que 30% des gens de votre équipe n'ont pas confiance dans le code qui est généré, ce collègue-là, soit il va falloir s'en débarrasser, soit il va falloir lui parler gentiment, mais lui expliquer qu'il y a quelque chose qui ne va pas. Donc on voit bien que ce n'est pas viable de travailler avec des... des LLM et des agents de cette manière-là, si on ne change pas radicalement quelque chose.

9:34 Ce qui se passe aussi, et ce qui a un impact assez fort, c'est qu'on nous vend des gains de productivité énormes, mais en fait, on ne parle souvent que de génération de code. Quand on parle de LLM dans le développement, on a tendance à faire ce raccourci de« si je génère 95% de mon code avec de l'IA, comme ce que fait Anthropic, je vais aller 95% plus vite». Alors non, ça c'est complètement faux en fait. Pourquoi? Parce que la partie création de code qu'on a quand on a et des devs dans une équipe, ce n'est pas 100% de notre travail. J'ai eu la chance d'aller à New York et à San Francisco il n'y a pas longtemps pour parler justement avec des entreprises sur la productivité avec l'IA. Et je parlais avec une personne qui est le deputy CTO de DX, qui fait justement de la mesure de performance des équipes avec l'IA. Et il m'a dit une phrase assez intéressante. Il m'a dit, tu sais, Arthur, La production de code, ça n'a jamais été le bottleneck, jamais, pour la grande majorité des entreprises. En fait, il n'est pas là le problème, ce n'est pas sur la production de code. Et donc souvent, on voit des entreprises qui mettent de l'IA pour produire du code plus rapidement, et ça crée des bottlenecks partout, sur la partie revue de code, sur la partie spécification, sur la partie testing, etc., sur le delivery global.

10:39 Donc ça, c'est une vraie problématique qu'on va avoir. J'ai parlé aussi avec des équipes de Google, notamment ceux qui font les études d'Aura, et ils m'ont dit qu'en interne, en 2024, ils ont fait une étude pour demander justement à leurs ingénieurs combien de temps ils passaient en moyenne à développer par semaine. Et la réponse, c'était entre 3 et 6 heures par semaine. Vous imaginez bien que si, grâce à l'IA, on va 50% plus vite pour produire du code, et qu'on est quelqu'un chez Google, on n'est pas tous chez Google, mais on va gagner entre 1h30 et 3h par semaine. On est loin des plus 50% en productivité. Donc évidemment, ça c'est une des grosses problématiques qu'on va retrouver. Et donc, ce que ça va donner, c'est que pour les entreprises, quand on regarde des gains réels globaux sur le nombre de full requests qui partent en production et donc les vrais gains de productivité qu'on va avoir, en fait, on retrouve des scores. de productivité qui sont entre moins 15% et plus 15%. Donc on est assez loin des 50% prévus de productivité, etc. Et ce qui est intéressant avec cette courbe, c'est qu'on voit surtout que ça peut être négatif.

11:42 On peut faire des investissements massifs qui sont très chers, justement, sur investissement sur les outils IA, etc. Et en fait, au début, on peut juste complètement perdre en productivité. Alors, ce qui est important avec ces études, déjà, c'est qu'il faut faire très attention aux moyennes avec ces chiffres. Et on le voit justement avec les gens de DX qui ont fait plein d'études avec plein d'entreprises. En fait, ça oscille très très fortement entre les entreprises. Donc ça dépend vraiment du contexte dans lequel vous travaillez. Vous allez peut-être faire un moins 30% ou un plus 30%. Ça va dépendre de beaucoup de facteurs. Donc ça, c'est la première chose. Et la deuxième, c'est qu'il ne faut pas vous dire non plus que vous allez plafonner à 15%. Donc on commence à se dire, est-ce que vraiment c'est utile d'investir autant là-dedans? Si vous êtes dans un état où le delivery n'est pas génial, il y a vraiment beaucoup de choses à améliorer, peut-être que d'ajouter l'IA, vous allez faire un plus 150%. Parce que vous êtes dans un contexte qui n'est déjà pas terrible, donc ça va être facile d'augmenter. Là, vu que c'est des moyennes, toujours pareil, on a le risque de se dire, oui, pour les entreprises qui plafonnent déjà au top de la productivité, ça ne va peut-être pas non plus être radicalement différent. Donc si on fait une pause ici, on se dit, est-ce que l'IA c'est bien aussi génial que ce qui paraît ?

12:49 Est-ce que ce n'est pas une bulle, comme tout le monde dit? Est-ce qu'on n'est pas en train de pousser des gains de productivité énormes et en réalité on n'y est pas du tout? C'est vrai que là on peut se poser des questions et certaines entreprises se posent un peu des questions. Elles se disent, comment est-ce qu'on fait réellement pour travailler en symbiose avec l'IA? En fait, on peut l'atteindre, on peut réussir justement à avoir notre retour du retour sur investissement, si vous n'avez pas compris. Alors ça, c'est le genre de blague que ChatGPT n'est pas capable de faire, donc j'ai dû la trouver en interne. Par contre, il génère des jolies images. Donc, on peut obtenir justement ces gains de productivité. Je vois qu'il me reste assez peu de temps, donc on va peut-être s'arrêter ici. Non, ce serait quand même dommage. L'idée qu'on a eue, c'est de se dire qu'aujourd'hui, individuellement, dans chaque entreprise, c'est quasiment impossible de faire de la veille sur tous les technos qui sortent, sur tous les outils qui sortent, et nous-mêmes, de faire des tests, des POC, etc., et de se dire que ça, ça marche bien, ça, ça ne marche pas. Individuellement, ce n'est pas possible. Il faut le faire collectivement, et collectivement, ça veut dire entre différentes entreprises. Le plus dur aujourd'hui, et c'est ce que disent aussi les gens de Google,

13:52 c'est d'avoir des retours d'expérience, justement. Pourquoi? Parce que c'est tellement récent, c'est tellement innovant. On va dire, est-ce que les custom agent modes de copilote, c'est intéressant? Je ne sais pas, ils sont sortis la semaine dernière. Donc évidemment, le temps qu'on teste, etc., ça va être beaucoup plus long que ça. Donc c'est très dur d'avoir ces retours d'expérience. Alors nous, sur les derniers mois ou même la dernière année, On a pu voir beaucoup d'entreprises côté Etats-Unis, on est allé dans les locaux de Meta, voir des gens de Uber, de Netflix, etc. Pour voir comment est-ce qu'ils fonctionnaient avec l'IA. On l'a fait avec beaucoup d'entreprises côté US, mais surtout beaucoup d'entreprises côté France, et des entreprises qui sont justement à la pointe aussi sur l'usage de l'IA dans les process, etc. Notamment les gens de Théodo, notamment de TOS que vous avez vu juste avant de Quentin, des gens de Doctolib, des gens de Datadome, plein d'équipes de BPI France aussi, qui ont déjà travaillé sur ces problématiques et qui ont mis des choses en place. Et ce qui est bien, c'est que malgré le fait que ce soit très émergent, on voit des patterns qui se dessinent. Et ça ne dépend pas de la techno d'ailleurs, si vous utilisez Cloud, si vous utilisez Cursor, Copilot, etc.

14:56 Il y a vraiment des patterns globaux qui sortent. Le premier, et ça va faire le lien avec le talk de Quentin, c'est qu'il faut voir la chaîne de production, ce qu'on appelle le SDLC, comme une chaîne complète. Et si on médiat juste sur une partie de la chaîne, vous imaginez une chaîne de production de voitures, par exemple, et vous accélérez juste une étape, ça va être la catastrophe, ça ne va pas du tout fonctionner. Donc, en voyant ça comme une chaîne complète, on peut se dire, où est-ce que l'IA va pouvoir m'aider dans mon delivery? Ça ne va peut-être pas être que sur la production de code, et peut-être même pas du tout. Ça va être sur la génération des specs, etc. Donc là, il y a Marek, justement, de Théodo, qui m'a partagé ce truc-là. Donc, ça vient d'un article de blog qu'ils ont fait, justement, avec des clients. Où ils montrent un petit peu comment ils ont intégré l'IA dans leur process de développement. Et ce qu'on voit ici, ce qui est intéressant, c'est qu'on voit qu'il y a l'IA un petit peu partout, donc il reste de l'humain sur la partie revue de code, sur la partie création des specs, etc. Mais en fait, l'IA, elle va nous aider à construire ces specs, elle va nous poser des questions. C'est quelque chose qu'on fait en interne aussi beaucoup, où en fait, quand on fait un example mapping dans Miro, par exemple, on l'extrait dans un fichier Markdown, on l'envoie à l'IA, elle a tout un process où elle va nous poser des questions sur le métier, etc.

16:03 Ensuite, ça va nous aider sur la partie plan technique, ça va le préparer. Ensuite, ça va nous aider sur l'implémentation des tests, etc. Et on peut le voir jusqu'à la fin de la chaîne en disant, si j'ai un retour d'un utilisateur qui me dit qu'il y a un bug ici, c'est planté, c'est l'IA qui va aller capturer le retour du client, qui va regarder quelle est la section du code à modifier, qui va me proposer une pull request. Et derrière, moi, j'aurai juste à regarder le code, à valider le code qui aura déjà été revu par l'IA aussi. Et donc là, on voit qu'en fait, il y a, on l'utilise un petit peu partout. Donc, vos... mieux gagner 10% un peu sur chaque étape plutôt que 50% sur une étape, parce que globalement, vous allez perdre. La deuxième chose qui, moi, personnellement, me fait très plaisir, Tout ce que je vous ai raconté sur le craft, le lean au début, en fait, je ne l'ai pas dit pour rien. Ce qu'on voit aujourd'hui, c'est que les entreprises qui, justement, étaient assez fortes sur la partie software craftmanship, avec plein de pratiques type DDD, architecture hexagonale, test drive and development, etc., ces entreprises, en réalité, aujourd'hui, elles sont beaucoup avantagées par rapport aux autres quand elles utilisent de l'IA. Et elles n'ont pas abandonné le craft, justement, pour produire du code avec de l'IA en mode wide coding, normalement.

17:10 Elles ont enseigné le craft à l'IA. En fait, les agents IA qui travaillent avec nous, ce qui est bien, c'est que c'est un peu comme les White Walkers de Game of Thrones ou les zombies de The Walking Dead, qui ne sont jamais fatigués. Et quand on leur donne des instructions, normalement, ils exécutent ces instructions. Normalement, pas tout le temps. Mais ce qui est intéressant, c'est que notre agent IA qui travaille avec nous, ce n'est pas un développeur classique qui va se comporter différemment le vendredi à 17h, du lundi à 10h. Donc si je lui dis, je veux que tu fasses des tests en premier, que tu fasses du test drive en développement, etc., normalement, si je le lance n'importe quand, 24h sur 24, il va bien appliquer ça. Donc là, c'est intéressant parce que ce n'est pas évident de transmettre justement à ces agents IA notre manière de faire du code. Et d'ailleurs, il y a un an, c'était quasiment impossible de faire du TDD avec Copilot ou les autres outils. Aujourd'hui, en fait, avec les nouveaux mécanismes qu'ont sorti des solutions, Comment ça y est arrivé ? Et c'est justement une chose assez importante. En fait, ça dépend des process qu'on va avoir, de tout ce qu'on va avoir autour du craft, etc., de l'architecture, mais ça dépend aussi un petit peu des outils.

18:12 Comme je l'ai dit, c'est tellement émergent qu'il y a un an, deux ans, en fait, on n'avait pas la possibilité sur Copilot, Cursor, Cloud, etc., de customiser vraiment ce qu'on appelle les skills, les instructions, etc. Toutes ces choses sont arrivées un peu plus tard. Il y a eu des cursors rules, il y a eu des team rules, il y a eu des skills, des plugins de cloud, des commandes, etc. On voit que ces solutions sont sorties, elles ont voulu juste travailler sur la génération de code, donc elles montraient à quel point le code d'entreprise était généré par DIA, et c'était ça leur métrique clé. Loi de Goodhart, attention, ça ne sert à rien d'avoir beaucoup de code qui est généré si c'est du code de mauvaise qualité. Et c'est maintenant qu'en fait, elle commence à laisser la place justement à des instructions custom, etc. Et justement, à San Francisco, la conférence GitHub Universe, GitHub présentait comment on peut faire du TDD avec le nouveau système de custom agent mode de Copilot. Et donc, dans leur exemple, ils avaient fait trois agents. Un agent test rouge qui générait le test qui faille, un agent test vert qui faisait passer le test, et un agent refactoring qui était spécialisé sur toutes les bonnes pratiques de l'entreprise et qui était capable justement d'aller...

19:18 d'aller faire juste le refactoring sans toucher au test, etc. Et donc, ils avaient un agent orchestrateur qui organisait ça. C'est un peu overkill, ce n'est pas forcément la bonne manière de faire. Mais pour la démo, ça marchait bien. Et on se rend bien compte que là, on a entendu... d'enseigner justement à Adia et aux agents avec lesquels on travaille notre manière de bosser. En fait, c'est ça qui est intéressant. Tout ce qu'on a appris pendant des années, sur le Lean, sur le DDD, etc., toutes les pratiques qui viennent du Lean aussi, comme le Danto-Su, pour ceux à qui ça parle, c'est vraiment une pratique qui indique que quand on a un bug sur notre application, on doit être capable de capturer pourquoi est-ce que ce bug est arrivé, donc de trouver la root cause de bug, On doit documenter tout ça, on doit expliquer pourquoi ça arrivait et comment faire pour que ça n'arrive pas. Là, vous y... Imaginez, ça c'est une mine d'or pour vos agents IA. Si ça vous documentez dans Notion et que ça reste dans Notion, c'est nul. Par contre, si vous documentez et que vous donnez en entrée à vos agents IA, là ça devient vraiment intéressant. Donc en fait, cette manière de discuter avec les agents IA et de leur donner justement de l'information, C'est peut-être là la clé, justement, pour avoir des résultats bien meilleurs.

20:20 Et ça tombe bien, on arrive sur un nouveau buzzword, on l'a déjà entendu depuis hier, context engineering. Context engineering, on va dire que c'est l'évolution naturelle et heureusement du vibe coding. En fait, context engineering, c'est... Comment je peux transmettre à mes agents IA tout le contexte, donc le savoir dont ils ont besoin, pour effectuer une tâche en autonomie sans que j'ai à repasser dix fois dessus, parce que le résultat est catastrophique. En résumé, ça veut dire qu'on va être amené à itérer sur l'input, donc sur ce qu'on va donner en contexte aux IA, plus que sur l'output. Donc si on a ça en tête, en fait, ça drive tout. Si on commence à utiliser des LLM, à générer des choses, et puis ensuite en revue de code à modifier beaucoup de choses, avoir des bugs en prod, etc., là on itère sur l'output. Ce n'est pas super intéressant. Donc il vaut mieux itérer sur l'input, Et on aura des meilleurs résultats. Ça vient aussi du Lean, c'est une méthodologie qui s'appelle Jidoka, qui a dit que quand une pièce est mauvaise, on va plutôt travailler sur la création de la pièce, sur la fabrique de création, plutôt que juste retravailler la pièce, faire des petits bridges, etc.

21:22 Donc le fait de travailler sur cette chaîne de production, en fait ça, ça devient intéressant. Parce que là, on va commencer à se poser des bonnes questions de comment je transmets justement à mon monde. la manière de travailler, le bon contexte, etc. Que ce soit du contexte technique ou du contexte métier, évidemment. Et justement, on a d'autres choses dans le rapport de RAC qui pointent dans cette direction, notamment cette phrase qui indique que quand les développeurs apprennent à communiquer avec les agents IA, en leur donnant des instructions spécifiques, etc., ces mêmes développeurs gagnent 30% en productivité sur la création de pull requests, ce qui est assez énorme. Donc on voit bien qu'en fait, ce skill de communiquer avec les agents IA, ça va être à l'avenir quelque chose d'essentiel pour notre métier. Et justement, on en parlait avec une personne de Microsoft la semaine dernière, une des responsables qui accompagne les entreprises sur l'utilisation d'IA, etc. Et elle me disait que ce qu'elle racontait souvent aux entreprises avec lesquelles elle travaillait, c'était« si vous aviez peur que votre documentation ne soit pas à jour avant, attendez de voir que vos instructions pour les agents IA ne soient pas à jour.

22:26 Ça va être cataclysmique. » Parce qu'en fait, une ligne d'instruction qui n'est pas bonne, et vous allez avoir peut-être des dizaines de milliers de lignes de code qui vont être produites de la mauvaise manière. Donc il faut bien voir ces fichiers markdown, ces fichiers d'instruction, comme les briques de votre chaîne de production qui vont produire du software à l'avenir. Et ça, ça va évoluer forcément dans ce sens, parce que plus ça va aller, et plus c'est les IA qui vont produire ce code. Et donc nous, on aura vraiment à travailler avec ces instructions de la bonne manière. Ce qui est intéressant, c'est de regarder un petit peu ce côté, ça va être quoi l'évolution de notre métier de développeur? On se rend compte que le markdown, malheureusement, ça va devenir peut-être aussi la norme. Moi, j'aime bien dire aux gens, peut-être qu'en 2026, le langage le plus utilisé par les êtres humains, ce sera du markdown. Et les IA vont utiliser ce markdown pour produire du code en Java, en Python, etc. Mais ça devient super important. Et en fait, ce markdown-là, ça va devenir un peu justement la clé pour des entreprises qui vont vouloir avoir des bons niveaux de qualité. Ce qui est important de retenir, c'est que si on veut faire du space-driven development, si on veut atteindre tout de suite le niveau qui est présenté par Quentin avant de Théodo, on se rend compte qu'il ne faut pas foncer là-dessus.

23:38 Faire du space-driven development sans context engineering et sans gérer son contexte, c'est faire du vibe coding. Donc vraiment, ça n'a pas d'intérêt en production. Pour faire des POC, ça va être intéressant, mais sinon, non. Les différentes étapes qu'on a vues avec les entreprises comme Doctolib, etc., souvent c'est d'avoir des équipes dédiées, donc c'est des équipes Developer Experience ou des équipes plateforme, qui dans le temps étaient des équipes qui faisaient chier tout le monde parce qu'elles mettaient du SonarCube et des trucs de calimétrie qui allaient tout bloquer. Aujourd'hui, elles ont plus d'importance que jamais. Et d'ailleurs, on se retrouve avec des entreprises comme Betclic ou autres qui ont des équipes Developer Experience et maintenant qui deviennent Developer Experience IA et donc qui s'occupent juste de mettre à disposition des différents outils IA, etc. Pour les différentes équipes. Donc ça, c'est vraiment la première étape. Si on veut progresser, il faut en général ces équipes-là ou ces personnes qui travaillent sur ces sujets-là. Chez Doctolib, ils sont 4 pour 600 développeurs et pourtant ils ont des super résultats et ils partagent dans des conférences ce qu'ils ont mis en place. Et sur le papier, effectivement, c'est super. Dans les premières étapes, ça va être vraiment context engineering, comment est-ce qu'on travaille sur ça, et petit à petit, on va pouvoir passer sur du spec-driven et faire ce que Quentin montrait juste avant.

24:41 Si on garde juste trois choses importantes de ce talk à retenir, la première, c'est que le contexte, c'est la clé. C'est garbage in, garbage out. Si vous avez du mauvais contexte, évidemment, vos agents vont faire n'importe quoi. Et l'IA, c'est un amplificateur. Si vous êtes dans un contexte assez pourri, avec une chaîne de production assez naze et pas de test, etc. Si vous mettez juste de l'IA, ça va s'amplifier, vous allez avoir juste de bugs, etc. Si vous êtes dans un contexte très clean, c'est très bien. Donc il faut commencer justement par travailler sur ça. La deuxième, comme je le disais, qui me fait très plaisir personnellement, c'est que toutes les entreprises qui délaissaient un petit peu le craft et le lean et ces pratiques assez avancées de développement, aujourd'hui, elles y reviennent. Et on le voit parce que quand on discute avec elles, c'est les premières à nous dire comment est-ce qu'on fait pour gagner en productivité, en efficience avec l'IA. C'est en passant en premier par ces pratiques de qualité et à l'enseigner justement à l'IA. Et les trois petits points, c'est parce que j'ai envoyé les slides il y a un mois, et en un mois, il se passe beaucoup de choses, donc je voulais me laisser un petit peu de flou pour pouvoir parler d'autres choses. Ce que j'ai appris cette dernière semaine, vraiment, le plus important, c'est que ces fichiers Markdown, ces fichiers d'instruction, ça va devenir vraiment la clé de la chaîne de production.

25:46 Ça veut dire qu'il va falloir les traiter comme du code. Il va falloir les tester, sachant que ce n'est pas déterministe. Il va falloir être capable, justement, de voir leur performance. Il va falloir de gérer toute cette histoire de contexte Windows, etc. Donc, dans les années à venir, il y aura sûrement beaucoup de travail autour, justement, de cette partie, gestion de ces artefacts qui vont être notre chaîne de production. Merci, j'arrive pile sur le dongle. Bravo Arthur, bravo bravo. Merci, vous n'allez pas faire plus. Je ne sais pas si tu savais, Arthur, mais tous tes propos étaient évidemment sous-titrés. C'est le cas depuis hier déjà et c'est une innovation de cette année. Et je suis assez fascinée de voir la vitesse à laquelle on arrive à revenir sur les phrases. On entend la dernière partie de la phrase pour redonner du sens à celle-ci. Donc voilà, je voulais juste souligner ça parce que j'étais assez bluffée. Et ça permet d'améliorer son anglais en même temps. Donc c'est plutôt une bonne nouvelle pour tout le monde. J'ai une petite question pour toi avant qu'on ouvre ta session avec le public. Les slides sont concoctés avec de l'IA aussi ou pas?

26:48 C'est moi qui ai tout dessiné avec de l'aquarelle sur mon temps libre. Marie-Laurence est en toi, c'est ça? Exactement. C'est beau, c'est magnifique. Par contre, c'est Romain qui était chez Open Classroom avant qui avait fait ça justement à un talk et qui m'avait montré ça. Je lui ai parlé hier et je lui ai dit je te mentionnerai parce qu'effectivement c'est quelque chose qui venait de lui. La forme est importante aussi, on le voit au fur et à mesure des présentations, que certains ont un soin particulier pour illustrer le propos et ça fait aussi partie du talk. Donc merci pour ça, merci pour le public parce que ça peut changer aussi de certaines autres présentations. Bref, j'arrête là. Qui a des questions pour Arthur? Je suis sûre qu'il y en a quelques-unes qui vont se lancer. Alors, la colonne de gauche? Ah, merci, merveilleux. Oui, Florent. C'est une question que je te pose, mais on aurait pu la poser à beaucoup de présentations. Ce que je ressens, c'est que tout le monde est convaincu que ça va marcher comme ça, qu'on est qu'au début et que le métier va se transformer, il y a, va coder à notre place.

27:56 Est-ce que c'est possible, ou il y a une éventualité, qu'il y a un monde où les modèles sont tellement chers, les boîtes veulent faire tellement de profits, on dépense tellement de tokens, etc., que finalement, on en revienne, et finalement, tout cet effort et cet argent, il est un peu gaspillé en mode FOMO et compagnie? C'est intéressant parce que j'en parlais avec certaines personnes qui me disaient que ça devient tellement cher, effectivement, des fois les tokens, etc., que les êtres humains, ça va devenir la matière low cost pour produire du code presque. On va externaliser à des humains parce qu'on n'a pas de budget pour prendre des IA. Alors je ne suis pas convaincu qu'on en arrive là. Parce qu'effectivement, dans la consommation de tokens, si on fait du spec-driven, etc., ça peut aller très très vite. Si on le gère bien, qu'on gère bien ce context engineering, la context window, etc., c'est notre travail chez PacMind, on développe une solution open source qui travaille sur ce sujet du context engineering, de comment est-ce qu'on gère la fenêtre de context, etc. On peut faire des choses qui ne consomment pas trop en tant que token.

29:00 Il y a des choses qui viennent aussi de Stanford, notamment le framework ACE pour Agentic Context Engineering. qui explique comment le modèle devrait générer du code en gardant une petite fenêtre de contexte avec les bonnes instructions au démarrage, et qui va évoluer à chaque instruction. Donc à chaque fois que je vais communiquer avec cet outil, ça ne va pas consommer trop de tokens, parce que je vais avoir juste un petit résumé des éléments importants. Donc je pense qu'on n'arrivera pas forcément à un état où ça va coûter très très très très cher. Après, normalement, si ça coûte quand même cher, c'est qu'on l'utilise assez bien et ça devrait nous produire de la valeur. Le but, évidemment, ce n'est pas de produire du code, mais c'est de produire de la valeur. Donc tout dépend de la valeur qu'on produit avec ça, mais il peut y avoir beaucoup de gâchis. Et je pense qu'il y aura sûrement beaucoup de gâchis avec beaucoup de tests, etc., qui seront faits, qui ne vont pas forcément produire autant de valeur que prévu. Donc ça va être une source de coût qui va être aussi assez importante pour les entreprises, mais on voit que c'est là où on peut avoir le plus de gains. Est-ce que nous avons une autre question pour Arthur? Oui, à le milieu. Et représenter.

30:03 Marek, je t'ai reconnu. Oui, c'est moi. Tu as parlé de cursor rules, de copilot instructions. Et au final, on voit que c'est un écosystème qui est extrêmement éclaté, diversifié. Il n'y a pas de standard. Il y a le agents.md qui n'est pas vraiment intéressant parce que c'est vraiment hyper basique. Est-ce que tu vois aujourd'hui un peu d'interopérabilité qui arrive entre ces différentes solutions, des frameworks qui émergent, des choses à conseiller, à explorer, à appliquer, qui peuvent être peut-être un peu stables dans les années à venir? C'est un point important parce que souvent les entreprises ne vont pas vers ces fichiers, cursors, rules, etc. Tout de suite. Parce qu'en fait, on ne sait pas quoi mettre dedans en premier. Et effectivement, si les équipes utilisent à moitié Cursors, Cloud, Copilot, etc., c'est dur de rationaliser tout ça. C'est typiquement sur le sujet sur lequel on a développé un truc open source, c'est d'essayer de se concentrer sur le contenu plutôt que sur la forme. En fait, pour moi, il faut vraiment dissocier le contenu et les process qu'on va avoir, comme ce que j'ai présenté avec ton slide, où justement on voit le process avec l'utilisation de l'IA, on voit le contenu de nos standards, donc en termes de Lean, justement, on a des standards sur notre développement, on a des recettes d'utilisation.

31:17 Et ça, c'est notre contenu. Et ça ne va pas changer qu'on utilise Clod, Copilot, Cursor ou autre. Par contre, derrière, il va y avoir une phase de traduction pour les différents modèles et pour les différents agents IA. Et ça, ça peut évoluer très vite. On peut avoir du jour au lendemain... Claude qui va dire, en fait, nous, il faut que vous répétiez les instructions en haut et en bas des fichiers. On sait que ce qu'il y a au milieu des instructions, c'est assez peu lu. Et on sait que si on dépasse un tout petit peu la fenêtre d'instructions que le LLM est capable d'emmagasiner, ça va être catastrophique en termes de résultats, ça va être pire que si on avait moins d'instructions. Donc en fait, tout ça, c'est une discipline qui est un peu particulière parce que, en gros, c'est comment est-ce qu'on communique avec les IA et comment est-ce qu'on les utilise au mieux. Et c'est ce qu'on appelle aussi le context engineering. C'est très mouvant. Et aujourd'hui, effectivement, avec le move d'Anthropic et Claude, en se disant, on fait des skis, des pteguines, mais on est compatible avec rien d'autre. Donc, on ne gère pas AgentMD, on ne gère que ClaudeMD, etc. On sent qu'il y a quand même une petite guéguerre entre les différents outils. Donc, on a AgentMD, mais je suis d'accord avec toi, ce n'est clairement pas la solution. Ça ne passe pas à l'échelle. Et puis, si on met tout dedans en vrac, comme ça peut être souvent le cas, on a des très mauvais résultats.

32:21 Donc, il faut jouer avec les custom prompts qu'on partage, à quel moment on intègre le contexte, etc. C'est complexe. Et pourtant, c'est avec ça qu'on a des gains. Donc c'est pour ça que c'est en train d'émerger. Et je pense que ça va être l'avenir sur l'année 2026. Il y aura beaucoup de sujets autour de ça. C'est OK pour vous ? J'ai une question. Super. Nassira, j'ai quelque chose qui me vient là tout de suite. Moi, je viens du Lean Six Sigma et de tout ce qui est excellence opérationnelle. Et du coup, il y a quelque chose qui m'interroge quand tu parles de regarder ta chaîne de bout en bout. Je pense que c'est quelque chose qui est nouveau dans le développement. Et comment, en tant que développeur, en termes d'orga, parce que normalement, vous êtes sur la partie dev, et là, tu dis, il faut que je regarde de bout en bout. Ça, c'est des concepts qu'on a quand on est dans l'industrie et qu'on fait de l'excellence opérationnelle et qu'on décline tout ça. Comment, en termes d'orga, tu le mets en place pour challenger ceux qui sont autour de toi? Parce que du coup, tu n'es pas tout seul, et tu es dans une équipe. Quelle légitimité tu as en tant que développeur pour pousser ça?

33:24 C'est une super question. On pourrait faire toute une conf, je pense, pour la réponse. Pour les 10 ans. Pour les 10 ans, exactement. C'est vraiment la clé, en fait. C'est ce que dit aussi l'étude d'Aura. Globalement, individuellement, on va avoir une impression de vitesse, mais au niveau de l'organisation et de la chaîne de production, on ne va pas avoir tant de gains que ça. Et des fois, ça va être une perte, d'ailleurs. Sur l'étude 2024, on voit qu'on perd en efficience, en fait, globalement. Et c'est pour ça que je mettais en avant le fait que les équipes, développeurs, expériences, plateformes, etc., commencent à avoir du pouvoir, parce que c'est elles qui doivent justement regarder la chaîne complète et se dire qu'est-ce qu'on doit changer à quel endroit, comment on doit faire communiquer les personnes. Et c'est plutôt les tech leaders, on va dire, ou les personnes qui ont une visibilité sur tout le process, qui doivent mettre... ça en place. Donc, fondamentalement, en fait, ce n'est pas forcément les développeurs qui vont pouvoir dire, effectivement, il faut changer, il faudrait que j'ai accès à plus de métiers, etc. C'est plutôt les personnes qui vont gérer toute la chaîne. Et ce que je trouve intéressant aussi, on en a parlé avec pas mal de gens ici depuis hier, c'est que ça va peut-être faire sauter des couches aussi. Je ne parle pas de MOA, MOE, mais en tout cas, entre le métier et la partie tech, on va peut-être avoir un changement au niveau des product managers, des product owners, etc.

34:34 Il va y avoir une vraie migration des rôles. Ils vont toujours exister, mais ils vont changer un petit peu. Ils vont être faits avec l'IA. Effectivement, il faut avoir une vision un peu d'ensemble pour voir comment on met ça en place. En fait, ça me fait rebondir à quelque chose. Je repense, pas du tout dans le dev, mais dans une industrie pharma, sur des flux logistiques. Nous, on avait créé des rôles complets avec une vue en chaîne de valeur, avec cette vision bout en bout. Sur des produits pharma en spécifique, du coup, est-ce que tu vois émerger quelque chose comme ça ? Un nouveau rôle qui vient se positionner avec cette vision pour pouvoir pousser et changer, en tout cas faire prendre conscience de ce changement pour la mise en place de l'IA? Alors oui, ce qui se passe en général, c'est ce qu'ils ont fait chez Doctolib ou ailleurs, ils mettent en place des rôles de AI champion. Donc c'est des personnes dans les équipes qui vont vraiment faire de la veille sur l'IA et vont utiliser. Souvent, il y a ce rôle-là au niveau des équipes de dev. Donc c'est des gens qui vont regarder au niveau développement, qu'est-ce qu'on peut utiliser, qu'est-ce qui peut être utile.

35:35 Et en fait, ce rôle de AI champion, il doit exister au niveau d'entreprise. Et effectivement, ça va être des experts ou des gens qui vont se nourrir de retours d'expérience, qui vont regarder, tiens, dans ces 30 entreprises, ça se passe super bien, voilà ce qu'ils ont mis en place, on va regarder dans notre contexte est-ce que ça peut fonctionner. Mais effectivement, c'est des rôles qui n'existaient pas avant, qui souvent viennent un petit peu de la partie plateforme un peu transverse. Mais on commence à le voir. Je commence à avoir des rôles justement dans les entreprises qui n'existaient pas encore et qui sont plutôt des leaders sur la partie IA qui vont mettre ça en place. Super Arthur, je pense qu'on va se retrouver dans la speaker zone pour prolonger les échanges. Merci beaucoup de me rendre la tapette. Merci beaucoup. A bientôt. Salut tout le monde.