Rapprocher la CI : L'IA a 20x la cadence, nos CI doivent suivre

Bruno — Dans les temps modernes, Charlot serre les boulons sur une chaîne de montage. Le patron, lui, accélère la cadence encore et encore jusqu'à ce que Charlie Chaplin finisse avalé par les engrenages de la machine. Aujourd'hui, ce sont nos agents IA qui poussent du code à une cadence que personne n'avait prévue, 20-30 fois plus de runs qu'avant. Et au bout de la chaîne, nos CI finissent, elles aussi, dans les engrenages. Mais alors, faut-il encore rajouter des machines ? Une IA peut-elle savoir si un test échoue pour des vraies raisons ou juste parce qu'il est un peu flaquis ? Et surtout, quand les agents écrivent du code, les tests et le déploiement, à quoi sert encore l'humain ? Pour répondre à ces questions de cadence, je ne reçois pas Charlie Chaplin, mais il s'y connaît en temps moderne. Yves, bonjour.

Yves — Bonjour.

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

Yves — Oui, bien sûr. moi c'est Yves Brissot ça fait quoi ? Ça fait à peu près 20 ans que je bosse dans le développement j'ai pu voir pas mal de choses surtout CI et absence de CI, je suis passé par Docker pendant 5 ans, je suis capitaine maintenant et aujourd'hui je travaille chez Dagger je sais pas si tu veux que je présente, déjà il y a une petite proximité de noms, Docker, Dagger, je ne sais pas exactement d'où vient cette proximité, mais il y a un petit truc en commun puisque Dagger a été fondé par des anciens de Docker et entre autres Solomon Hikes qui a créé Docker. Alors Dagger fait plein de choses mais ce qu'on essaye de résoudre aujourd'hui, c'est la CIA. La CIA qui au final a très peu évolué. Depuis le début, depuis des années et des années. Même s'il y a eu des avancées, il y a eu des trucs cool, il y a eu GitHub Action, etc. Mais en vrai, la CI n'a pas changé. Donc nous, on essaye de fixer ça depuis déjà un petit moment. On essayait déjà et on croyait déjà que la CI devait être améliorée en profondeur, avant même qu'il y ait tout ce monde agentique qui arrive. Et comme tu le disais en intro l'arrivée des agents, fait que c'est devenu finalement ce qu'on percevait avant est devenu un problème pour beaucoup, beaucoup de monde aujourd'hui, et oui aujourd'hui quand on a des problèmes de CI avant on mettait une machine plus grosse ou plus de machines mais c'est pas toujours simple et aujourd'hui ça passe pas.

Bruno — Quand tu parles de l'évolution de la CI et surtout quand tu me disais tout à l'heure t'as connu beaucoup de CI mais t'as connu aussi le monde sans CI c'est vrai que moi aussi quand j'ai commencé dans ce métier là je me souviens d'avoir vu des bureaux, de dev où tu avais des panneaux, tester ses doutés ou ce genre de choses on faisait encore des déploiements avec juste un copier-coller, enfin des transferts via FTP sur des serveurs enfin bref c'était tout un, c'était vraiment très archaïque quand tu dis que la CI a pas évolué, est-ce qu'on peut quand même au moins se dire que aujourd'hui des contextes sans CI sont quand même extrêmement rare par rapport à ce qu'on pouvait avoir, il y a 10 ans, 15 ans 20 ans.

Yves — Oui avant moi quand j'ai commencé on n'avait pas de CI je me souviens c'était pas on poussait sur FTP, on avait des éditeurs sur FTP, donc on éditait directement le code en prod, hotfix ouais alors c'était pas toujours en prod mais c'était sur on avait un serveur central pour toute l'équipe et tout le monde éditait dessus avec des éditeurs qui lançaient des warnings quand quelqu'un d'autre avait modifié le fichier. Et il n'y avait pas de diff, c'était à chacun de se débrouiller. Oui, donc ça c'était sans CI. Donc à l'époque ça se faisait. Ensuite, globalement, on a eu, le début c'était des hooks sur SVN. Les gens qui ne savent pas SVN, c'est pas grave, ils sont sûrement trop jeunes, mais c'était avant le guide quoi. Et ça c'était le début et ce hook faisait un truc, il prenait un code et il allait exécuter des tâches aujourd'hui il y a encore des entreprises à l'époque pardon, c'était courant, c'était la base il y a encore aujourd'hui des entreprises, des softs qui sont faits sans CI, je pense qu'il y en a plus qu'on ne croit ça ne veut pas dire qu'il y en a non plus c'est pas du tout la majorité mais j'en entends encore parler ou des fois dans des conférences et choses comme ça, qu'on peut présenter ce qu'on fait. Il y a encore des gens qui nous disent, moi, je n'ai pas de CI. Donc les gens, je ne sais pas comment ils travaillent. Ça fait un moment que je ne travaille plus en CI. C'est un moment que même mes projets persos ont des fois des CI très minimalistes, mais ils ont quelque chose. Mais ça existe encore. Et puis parce que la CI, elle a l'air compliquée. Elle a l'air compliquée pour une raison assez centrale, c'est qu'une CI, c'est bête et méchant aujourd'hui c'est un outil qui va lancer des tâches, Et encore faut-il savoir quelle tâche écrire. Et ça, ce n'est pas toujours simple.

Bruno — Tu évoquais du coup aussi que ça a fait un moment chez Dagger que vous savez que la CI est un contexte qui doit évoluer, qui doit changer. Effectivement, cet arrivé de Cloud Code et autres a un peu bouleversé ces CI, en les faisant tourner 20 fois plus que ce que c'était prévu jusque-là avec tous les problèmes qu'on peut imaginer. Est-ce que vous, parmi les problèmes que vous aviez identifiés, c'était aussi ces sujets de volumétrie ? Ou est-ce que ça s'est rajouté à ce que vous avez déjà identifié ? Ou est-ce que c'est devenu le seul problème aujourd'hui qu'on voit sur nos CIRI ?

Yves — En fait, c'est un tout petit peu plus complexe. C'était moins un problème de volumétrie, pas aux échelles qu'on a aujourd'hui. J'avais regardé quelques stats. Je crois que Centropique a fait un article il n'y a pas longtemps. Où ils disaient qu'ils prévoient pour 25 fois la charge sur leur CI. Je crois que chez Github, les derniers temps c'est 9 fois plus de pull requests, et j'avais la même chose sur OpenAI, c'était à peu près x10. Donc la volumétrie, on ne pouvait pas s'attendre avant ce genre de choses.

Bruno — Et ça en plus en quelques mois.

Yves — Ah oui, non mais voilà, c'est une courbe qui est complètement folle aujourd'hui. Mais... Les problèmes qu'il y avait avant, ils sont juste exacerbés par ces problèmes. Les problèmes que tout le monde avait déjà avant, même si on n'allait pas parler de problèmes de scale, c'est la lenteur des CI. Ça, c'est un problème. Nos CI sont lentes. Je suis sûr qu'il y a encore beaucoup d'entreprises où, entre le moment où on pousse et le moment où on a la réponse, ça peut prendre une demi-heure, une heure de temps. Je ne pense pas que ce soit complètement fou. J'imagine qu'il y en a, c'est encore plus long. Donc évidemment si on a déjà ce problème on rajoute le scale dessus bon ben là ça tombe mais ce problème existait déjà comment on fait mieux comment on va plus vite, comment on arrête de gâcher des ressources parce que derrière il y a ça aussi, toutes les CI vont toutes faire à chaque run, on ne change pas tout le logiciel donc il y a plein de choses qui sont identiques enfin espérons, généralement ça va être le cas et puis toute une partie du job de CI va être absolument identique. On va tester les mêmes fichiers, on va s'assurer de la même chose, on va lancer les mêmes tests, on va construire les mêmes assets. On a des bonnes raisons de le faire. Entre autres, on veut s'assurer de non-régression. Pour ça, il faut bien être sûr qu'il n'y ait pas eu un effet de bord ou autre. Mais ça veut dire qu'on refait tout. Et généralement, on refait d'ailleurs tout depuis zéro. Et c'est une perte énorme de temps, de ressources, et donc d'argent. Et ça, c'est des choses auxquelles on s'attaquait déjà avant même qu'il y ait justement ces problèmes de scale. Ces problèmes de scale ne font que rendre le problème beaucoup plus visible à beaucoup de monde. c'est-à-dire que beaucoup de personnes dans les équipes de dev voudraient des CI rapides. Et souvent on dit bah oui mais ça coûte trop cher c'est pas prioritaire, on a du mal en fait et puis en vrai ça demande de changer de paradigme comme beaucoup de choses, dès qu'on veut changer d'échelle on peut pas réappliquer exactement la même recette, il faut aller plus en profondeur et c'est ça qu'on essaye de.

Bruno — Faire Il y a aussi le sujet de la fléquiness c'est toujours un truc qui m'a énormément perturbé, parce que notamment, enfin, ce que je trouve en plus d'autant plus amusant c'est que on a quand même beaucoup de développeurs et de développeuses qui sont réticents vis-à-vis de l'IA en disant le problème de l'IA c'est qu'elle est non déterministe, et je trouve que c'est fou de se dire qu'en 2026 on a encore, des CI et des tests qui sont flaquis alors que justement nous on veut quelque chose d'hyper déterministe et de se dire, en fait, celui-là je sais qu'il est vert mais je sais que si je le rerun il sera encore vert alors qu'il y a des contextes où on sait pas et, on tolère ça, on râle mais on tolère ça.

Yves — La flaquiness d'ailleurs c'est un des trucs aussi qui coûte extrêmement cher parce qu'on se met à rerunner à relancer par défaut même un truc qui n'est pas flakky on va le relancer en se disant non mais il est rouge donc, c'est que c'est flakky puis finalement au troisième run rouge on se dit bon bah peut-être qu'il l'était pas Ah Ah. En fait, le truc, c'est qu'on a dans beaucoup de cas des logiciels qui ne sont plus simples, qui ont besoin de beaucoup de composants externes. Et je ne parle même pas des archimicroservices, mais juste un service qui a, je ne sais pas, accès à une base de données. Il arrive que la base de données réponde, ne serait-ce que plus lentement. Et puis, on a un test qui va s'assurer qu'on a bien eu la réponse. Rien que ça, rien que le plus lentement suffit à ce que ça déconne. Et plus lentement, alors on peut penser des fois les clouds qui ont leur lot de problèmes parce qu'on a tellement de stack qu'il y a forcément des problèmes. Mais même sur, je ne sais pas, une machine partagée, il y a eu un lot de plus. Ou même un lot de plus sur le serveur de CI. Et les choses vont être un peu plus lentes. Il faut aussi s'assurer pour réduire la flykness, par exemple, d'être toujours dans le même état. Comment on garantit qu'on est toujours exactement dans le même état et qu'il n'y ait pas eu un fichier d'un précédent run qui soit toujours là ? Ça, ça arrive. Sinon, on va tout supprimer, tout wipe à chaque fois, mais on est lent. Donc, on va laisser des choses, mais on a des effets de bord. Donc, en fait, on ne s'en sort jamais. Après, il y a déjà des solutions qui sont rarement mises en œuvre, mais sur de la flaquinesse, on peut déjà faire des choses. Par exemple vérifier que si un test passe sur main, une fois qu'il est passé, il est censé passer tant qu'il n'a pas été modifié, donc s'il est rouge ailleurs, peut-être c'est censé être lié à ce qu'on fait, s'il est vert qu'on ne change pas qu'il est rouge, Qu'est-ce que ça veut dire ? Mais, aujourd'hui, on rajoute juste plus de complexité. Ce n'est pas simple.

Bruno — Avant de creuser un peu sur les impacts de l'IA et ce qu'on peut faire pour améliorer nos CI, toi qui as vu tout type de CI, parce que là, on a fait un petit focus, j'ai envie de dire, sur la partie test, mais dans nos CI, on n'a pas que les tests. Tu as peut-être vu, toi, la Rolls-Rolls des CI, c'est-à-dire que les CI les plus complètes, les plus folles. Qu'est-ce qu'on peut avoir en fait comme ensemble d'actions et de validations, qu'on peut mener sur une CI, autre que simplement faire des runs de tests unitaires, tests d'intégration et tests Ntwin ?

Yves — Les tests restent quand même un élément primordial, mais après il y a aussi tout ce qui est déjà l'inter, qu'on utilise quand même de plus en plus. Linter, formateur s'assurer que c'est toujours bon tous les analyseurs statiques ou dynamiques de code etc, ça c'est une grosse partie on a pas mal d'endroits aussi où on fait de la génération de code, plus que des fonds de pens mais ça peut être je sais pas on a une API et on veut des clients, on va avoir du je sais pas en Go, on va utiliser la commande generate pour générer des outils générer des assets tout ça et donc la CI elle va aussi être là pour s'assurer qu'ils sont tous correctement à jour euh... Après, le truc, c'est que derrière, je veux faire des tests, il y a beaucoup de choses. Parce qu'avant de tester un élément, tout dépend en fait le niveau de test où on est, mais il y a aussi, je dois builder des artefacts. Par exemple, je veux builder mon logiciel. Avant de pouvoir, alors déjà pour être sûr que j'arrive à le builder, ça c'est une chose, mais avant de pouvoir ensuite le tester comme une black box et plus avoir des tests d'intégration, des tests unitaires, plus fins et tout direct sur le code, ah non je veux quand même faire ça, et ce build lui parfois il est très très complexe et il peut faire intervenir plein de choses, différents langages qui vont être packagés au même endroit, des outils où justement c'est là où on va avoir de la génération de code qui va ensuite être mixé avec autre chose, qui va être packagée sous différentes formes, différentes architectures. Et puis, si on rajoute du mobile, des choses comme ça. Ça peut être énorme, en fait, cette partie-là de build. Mais c'est une chose. Et puis là, on va dire, on arrive sur... Voilà, c'est de la CI. Et puis après, il y a encore la partie suivante qui est. Tout ce qui va avoir effet de bord, pour le coup. C'est ce qu'on va dire des fois sur la CD, plutôt, sur le déployement mais en fait il y a d'autres choses, mon image, ok mais je vais la déployer quelque part ou je vais la publier c'est pas forcément d'ailleurs la déployer dans mon infra mais déjà la publier ça ça va être tout ce qui sort aller pousser des assets sur un CDN, toutes ces étapes aussi finalement ça va être dans les mêmes ensembles pour ça on dit CI c'est une part l'intégration mais après il y a CI, CD en général ça ça peut aussi — Voilà. Et parfois, c'est des steps vraiment différents. Parfois, c'est beaucoup plus flou. Parfois, c'est juste une guette. Mais en fait, c'est le même truc qui va dire « OK, c'est bon, on a validé, donc on fait la suite. » Mais en fait, ça devrait être écrit de la même manière. Et tous ces effets de bord sont pas simples non plus.

Bruno — — OK. Qu'est-ce qu'on peut faire du coup pour... Avant de voir ce qu'on peut faire pour améliorer, qu'est-ce que cette génération de code massive... Parce que moi, dans ce que je vois avec l'IA, on a deux problèmes. C'est qu'effectivement, on fait beaucoup plus de PR, mais les PR sont aussi beaucoup plus grosses. En général, elles vont contenir beaucoup plus de codes modifiés, beaucoup plus de fichiers modifiés, donc aussi beaucoup plus de risques d'effet de bord. C'est quoi les... Est-ce qu'il y a d'autres impacts que vous voyez ? C'est quoi le stress test que tout ça, ça apporte sur nos CI ?

Yves — Alors c'est sûr qu'on a beaucoup plus de PR elles peuvent être plus grosses, beaucoup plus fréquentes parce qu'un truc qu'on va demander c'est aussi aux CI aux agents de baby-sitter les CI, on pousse la CI, il y a un check qui est rouge, la CI l'agent va déjà s'en occuper, aller fixer, repousser donc là hop, on remet une couche et encore et encore, donc ça stresse beaucoup les systèmes, Après, sur la CI en elle-même, c'est surtout ça. C'est vraiment le volume, le nombre de tests qu'on demande, le nombre de checks qu'on va demander. Ouais, c'est surtout ça. C'est le nombre, en fait. C'est le scale, en fait.

Bruno — Parce qu'en fait, la taille de la paire en tant que telle n'est pas un sujet. C'est-à-dire que tu fasses une CI où tu as changé 400 lignes, où tu as changé 4000. Aujourd'hui, on run la même CI. Donc, en fait, c'est le même problème.

Yves — Oui, sachant qu'on peut faire les choses de manière plus intelligente. C'est-à-dire que sur un même système, une paire qui change 400 lignes et une paire qui change 4000 lignes ne devraient peut-être pas exécuter la même chose dans la CI. Parce que si on est capable de dire bah oui mais ces tests sont liés à telle portion de code qui n'a jamais changé bah en fait pourquoi les renaît il n'y a pas de raison en fait aujourd'hui c'est généralement pas le cas, l'analyse d'impact pour aller savoir quel test toucher elle est extrêmement complexe si ça me fait penser à une chose il y a une chose que les agents font aussi, c'est presque vomir des tests unitaires. Les agents sont très très bons pour en écrire mais plein. Alors on est content, on n'écrit plus de tests unitaires. Les tests unitaires, c'est à la fois très bien et à la fois extrêmement chiant. C'est le nombre.

Bruno — Aujourd'hui, on est hyper content parce que non seulement on n'écrit plus de tests unitaires, mais en plus, on a une code coverage qui a des pourcentages stratosphériques. On n'a jamais vu ça. On est hyper content.

Yves — Oui, encore faut-il qu'il soit écrit de la bonne manière et au bon moment. Et qu'il soit utile. Récemment j'ai vu pas mal, de personnes dire non mais en fait il faut plus faire de tests unitaires. C'est-à-dire que la valeur aujourd'hui des tests unitaires est en train de baisser. Elle est en train de baisser parce qu'en fait, si on faisait des tests unitaires avant, c'était pour faire du TDD. Ce qui ne veut pas forcément dire d'écrire avant le test, mais c'est plus la manière d'écrire le code et les tests, mais surtout on n'écrit pas les tests après juste pour valider le code. Donc les agents on leur a appris à faire la même chose, on fait ça donc faites la même chose, donc ils écrivent leurs tests et ça marche pas trop mal, on peut arriver moi je vois mes agents qui font des tests ils sont rouges, ils vont corriger c'est vert, bon ok, est-ce que c'est vraiment le meilleur usage probablement pas mais on va avoir des tests unitaires pour tout, quand on écrit des tests à la main il y a un certain nombre de tests qu'on écrit pas, il y a des choses, on se dit non mais c'est bon là j'ai une fonction qui m'additionne deux trucs oui en théorie il faudrait que je la teste, en pratique ça sert à rien et tous ces tests ont plusieurs coûts ils ont un coût sur les CI, ils ont un coût sur chaque changement de code qu'on va faire parce qu'il va falloir les enlever en réécrire des nouveaux etc et donc on voit de plus en plus des gens qui disent mais en fait il faut se concentrer sur les tests plus haut niveau. Parce que c'est eux qui ont de la valeur et je pense qu'on va avoir la même question avec les mocs à quel point on veut ou pas supprimer les mocs, j'ai déjà vu des gens aussi qui disent non mais en fait pareil on n'en veut plus, on veut vraiment que du test réel Blackbox sur NodeSoft. NodeSoft devient une entité où on dit bah en fait j'ai des entrées, j'ai mon scénario, je dois avoir tel résultat. Et c'est ceux là qui ont d'ailleurs la plus forte valeur, c'est ceux qui vont représenter notre logiciel. Mais donc tous ces tests qui sont ajoutés, ajoutés, ajoutés par les agents, ils rajoutent encore plus de pression sur les CI. C'est-à-dire que ce n'est pas juste qu'on augmente les tests, on augmente beaucoup les tests. Et ça, c'est problématique.

Bruno — En effet. Alors du coup, est-ce que, avant de creuser peut-être les sujets de... Parce que vous, c'est des questions que vous vous posez sur comment améliorer la CI avant l'émergence de tous ces systèmes-là agentiques. Donc ma première question, ce serait déjà, avant que tout ça arrive, c'était quoi vos pistes pour améliorer la CI et du coup, pour avoir après, tout ce que ces agents-là vous ont permis de faire ou de rajouter dans ces améliorations ?

Yves — Mais en fait, je pense surtout que les pistes n'ont pas changé. C'est-à-dire que ce qu'on faisait avant l'avènement de tous ces agents, les idées qu'on avait pour améliorer la CI n'ont pas changé avec l'avènement des agents. Ça a, au contraire, validé tout ce qu'on faisait déjà avant. Parce que c'était déjà la même chose. C'est, par exemple, être capable de rener des suites de tests en parallèle. Mais comment les faire ? Comment splitter une suite de tests ? Quel test grouper sur quel type de machine et quel autre. Ça, c'est déjà ce qu'on avait. Ça fait déjà partie des solutions qu'on imagine pour fixer les CI. De la même manière, il y a la question de, non pas lesquels en parallèle, mais lesquels jouer tout court. Parce qu'une analyse d'impact, on n'a peut-être pas besoin de ci ou ça. Jusqu'à présent, c'était fait de manière, si j'ai tel et tel fichier, je ne runne pas ça. C'est par exemple ce qu'on fait sur un monorepo en disant « tu ne run que le projet que je t'ai changé ». Ce n'est pas toujours si simple. Un gros truc, un des énormes focus qu'il y avait avant, c'était le cache. C'est-à-dire être capable de cacher de manière très fine chaque action de notre CI. Ça, aujourd'hui, on ne peut pas le faire. Les CI utilisent des caches, mais par exemple, on va avoir un cache NPM, on va avoir un cache Go, on va avoir des caches comme ça. Mais des caches au niveau des actions, généralement, ce n'est pas fait. On ne peut pas. C'est-à-dire, si ma CI, elle lance un mec, un task, quel que soit le truc qui fait, je ne sais pas, un build ou même un test, ce n'est pas caché. Ce qu'on fait dans Dagger, c'est que ça, c'est caché. Ou une portion, tout dépend de ce qui a changé, en fait. Donc, si je lance deux fois le même test, la deuxième fois, il est média. Il a été caché. si je génère deux fois le même asset la deuxième fois je ne la régénère pas donc toutes ces solutions elles étaient déjà là avant pour dire, on veut des CI rapides efficaces, fiables et répétables parce que le but à la fin c'est quand même d'être sûr, qu'on peut pousser le logiciel la CI en tant que telle elle n'est là que pour ça.

Bruno — Mais là tu parles effectivement de si on reprend ces exemples de pardon, On a parlé du caching sur les systèmes de test en général, ou la génération des assets, ce genre de choses. En général, dans ma CI, justement, je ne veux aussi pas avoir de système de cache parce que je veux m'assurer que mon asset, il est généré proprement et que ce ne sont pas des problèmes que je vais avoir en prod derrière. Je veux m'assurer que le test, il est toujours valide. Donc, si je prends un résultat en cache de mon test, en fait, potentiellement, je n'ai pas testé ce que j'ai changé. Donc, comment est-ce que tu peux avoir une granularité de ton cache en disant, là je peux reprendre une ancienne version parce que je sais que ma nouvelle version ne sera pas différente.

Yves — C'est parce qu'en fait c'est beaucoup beaucoup plus fin que ça, c'est à dire qu'en fait on va pas prendre le résultat du test qui est en cache, en fait on va avoir la chaîne entière, de construction de ce résultat c'est pour ça que le DAG de Dagger c'est vraiment ça c'est à dire qu'on décrit nos étapes, nos tâches de CI sous forme de diagramme, de DAG, de diagramme acyclique on va lui définir tout ce qu'on veut et à la fin on va avoir des choses un certain nombre de choses et chaque toute petite étape de ce truc peut être cachée et donc si on part de la même base on a déjà des... Ça on le sait par exemple, c'est l'état du repo l'état du repo, des fichiers on est capable de hacher les inputs, on sait. Et puis, chaque toute petite étape qui existe va être cachable. Mais dès qu'il y aura la moindre variation, on n'est plus... On ne va pas récupérer un cache et donc on va continuer de construire. Et donc, quand je dis chaque étape, c'est que une des particularités quand même de Dagger, contrairement à beaucoup de systèmes de CI, c'est que c'est un container runtime. Ça va beaucoup plus loin, en fait, que juste lancer des tâches. Donc, on va prendre... Imaginons des tests unitaires je vais commencer par dire mes tests vont se lancer dans tel conteneur depuis telle image, je vais mettre mes fichiers dedans je vais peut-être faire des modifications dessus je vais rajouter tel autre fichier parce que c'est une assets qui a été buildée par quelque chose d'autre, et puis je vais lancer ma commande de test et en fait chacune de ces étapes est cachée indépendamment c'est à dire que si j'ai un conteneur et que je rajoute un fichier en vrai j'ai un deuxième conteneur Ils sont tous immutables. Et je rajoute un deuxième, c'est encore un autre. J'ai un répertoire auquel je rajoute un fichier, il aura son propre ID aussi. Et donc, dès qu'on va varier, on en sort. c'est ce qui va garantir que j'ai fait une modification je ne vais pas aller chercher le résultat c'est jusqu'à un moment donné dans l'embranchement je vais dériver, et donc je vais avoir peut-être 20% de, la tâche qui arrive à mon test unitaire qui a été cachée et les 80 autres qui vont changer.

Bruno — Et qui vont être refaits du coup.

Yves — Et qui vont être refaits mais comme tout est haché je garantis que c'est la bonne base ou l'inverse d'ailleurs ça peut être 80% qui étaient identiques et les 20% derniers qui changent mais donc c'est toute cette finesse, et d'ailleurs qu'on peut voir parce qu'en fait on a absolument tout ce qu'on fait est tracé on a de l'open télémétrie absolument partout donc on ne lit plus de log ce qui est absolument génial une fois qu'on a pris le pli, plus jamais on va lire de log on va voir chaque étape on a en face les timings de chaque étape on sait ce qui est caché, pas caché, on sait d'où ça vient, comment ça a été construit, on peut remonter en fait le graphe. Et donc, en fait, on sait exactement, j'ai un résultat, on a un doute, par exemple, mais ce test, est-ce qu'on est bien sûr qu'il a été exécuté correctement ? Et bien, en fait, on va pouvoir remonter l'ensemble des actions qui ont amené au résultat et donc avoir la garantie que, oui, c'est bien le résultat qu'on voulait, on peut avoir confiance dedans, mais plus vite.

Bruno — Donc, bon, la télémétrie, on n'est plus, du coup, sur de l'analyse de ta CI, à postérieure, une fois qu'elle est tournée. Sur l'amélioration de la CI qui nous a évoqué le split des tests qui est effectivement un sujet parce qu'on a tendance parfois juste à, avoir une machine qu'on met de plus en plus puissante on met de plus en plus d'argent mais en fait il y a un moment ça coûterait moins cher d'en avoir plusieurs à côté mais c'est complexe ah oui, donc ça c'est intéressant, tu nous as parlé du caching est-ce qu'il y a d'autres éléments sur lesquels on peut travailler pour accélérer ou fiabiliser les CI aujourd'hui.

Yves — Je ne sais pas trop, parce que c'est vrai que c'est un peu les éléments centraux en fait. C'est-à-dire qu'une fois qu'on est capable d'avoir du cache très fin, donc ce cache qui nous garantit aussi que la base est la même. Après, sur la fiabilité, la télémétrie va quand même être utilisable, on va savoir où on en est, on peut vérifier. Le cache, les tests, oui, non, mais c'est...

Bruno — C'est déjà, oui, finalement.

Yves — C'est la base. Finalement, c'est aussi la manière dont c'est construit, avec de l'immutabilité absolument partout. L'absence d'effet de bord qui fait que, en fait, par exemple, on ne peut pas avoir comme ça, je ne sais pas, on lance une action, on lance un test, un test qui va produire des fichiers. C'est très courant. On sait que ces fichiers ne vont pas se retrouver ailleurs. On le sait par design, en fait. Si je prends l'objet, le conteneur dans lequel j'ai exécuté mes tests et que je rajoute des fonctions, évidemment, j'ai mes fichiers. Mais si c'est pas le cas l'avantage de ZAC c'est qu'on peut rebrancher absolument partout donc si je reprends quelque chose d'antérieur j'ai beau avoir exécuté mes tests peut-être temporellement avant, je sais qu'ils ne seront pas là donc en fait la construction même, la base même de ce graph qui au final est très éleigné de toutes les cirées qui sont des taskrunners garantit ça de manière absolument parfaite.

Bruno — Canon Est-ce que le fait d'avoir du code qui est généré par IA nécessite du coup d'avoir des CI qui contiennent de l'IA, ou est-ce que les nouvelles CI doivent nécessairement contient de l'IA ou est-ce qu'à l'inverse c'est un endroit où il faut être le plus déterministe possible et donc avoir le moins d'IA possible ? Ah, T'évoquais, je fais du coup aussi une parenthèse parce que t'évoquais le split des tests Oui Est-ce que ce split des tests, on peut le faire de manière déterministe, ou est-ce qu'il faut en fait passer par une IAC qui sera capable de dire ça je le mets là et ça je le mets là ?

Yves — On peut. Mais de plus en plus, on va utiliser des IA, y compris tout ce qui arrive maintenant avec les tout petits modèles comme GEV qui permettent de répondre à d'autres types de questions. On peut splitter, on peut faire de l'analyse d'impact, on peut splitter les choses. En fait, pour splitter, on va justement avoir un retour sur la télémétrie. La télémétrie, par exemple, va permettre de nous donner les profils des tests. Et donc, on va savoir quels tests on peut grouper. Par exemple un test qui utilise beaucoup la mémoire mais peu le CPU et un test qui ferait l'inverse peut-être qu'on peut les mettre ensemble sur la même machine au même moment, ils vont être très bien ceux-là mais deux tests très gourmands, on ne va pas le faire ça, on a accès, puisqu'on a toute la télémétrie on a accès à ça c'est déjà ce qu'on fait, même pas au niveau des tests mais vraiment un niveau au-dessus où en fait on va analyser les télémétries pour savoir les profils de ressources demandées par l'ensemble des checks ou certains checks donc le check c'est finalement l'unité principale que nous on lance, et on va pouvoir les mapper sur plusieurs machines et plusieurs sur une machine, maintenant ça serait dommage de ne pas utiliser. Ce qu'on peut faire aujourd'hui avec des IA pour améliorer ça parce que derrière ça la question c'est on a une masse de données de télémétrie on peut en déduire des cours des choses comme ça. Mais pourquoi pas fider ça dans des LLM qui, justement, sont très bons pour analyser des stocks de données et nous sortir des corrélations. Les LLM sont super bons pour des corrélations. Le code est très bon pour avoir de la causalité. Donc, les deux sont bien. Et je pense qu'en fait, c'est un mix de tout ça. On ne va pas arriver sur... Peut-être qu'on y arrivera. Mais là, tout de suite, je ne pense pas à un système où, en gros, on a un LLM qui dit qu'on lui donne tout et il se débrouille. Mais on va aller juste cherry piquer dedans pour telle et telle chose, pour un peu une question d'affinité par exemple, d'ailleurs c'était le terme qu'on utilise des fois pour quand on veut déplacer des choses, sur des machines, on va parler d'affinité bah là c'est ça, on va demander à un LLM bah tiens donne moi un score où est-ce qu'il faudrait que je place ces tests ou comment je dois les splitter, donc je pense qu'on est sur un entre deux je pense que cet entre deux va durer un moment, je me verrais pas tout donner à un LLM mais je trouverais dommage de pas du tout m'en servir, surtout pour l'analyse d'impact.

Bruno — Sur les linter, les formateurs, tous ces outils là, est-ce que tu penses que ces outils doivent rester déterministes comme ils le sont aujourd'hui ou est-ce qu'au contraire il faut encore plus profiter de la capacité de ces LLM à nous faire du coup des linter encore plus évolués que ce qu'on avait vu jusque là.

Yves — Je pense que ces linters, aujourd'hui, ils ne sont pas si mal comme ils sont. Après, il y a différents types de linters. C'est vrai que je fais pas mal de go, donc on va mettre dans les linters, les formateurs, etc., où on a finalement dans la description du langage déjà défini comment on devait écrire les choses. Ce n'est pas le cas dans tous les langages, donc ça peut varier. Mais là-dessus, c'est très bien, en fait. On s'assure que les codes sont toujours identiques, formatés de la même manière, etc. Très bien. Pourquoi aller se complexifier la vie là-dessus ? Il n'y a pas de problème. En fait, je pense que ce qui devient intéressant là-dessus, l'un des problèmes qu'il y a, c'est vrai qu'on n'en a pas encore parlé de ça, c'est la partie locale. C'est-à-dire que ces linter, on veut les exécuter sur nos CI parce qu'on veut s'assurer d'un certain nombre de choses. Mais c'est presque tard dans le développement. C'est-à-dire que plus on est loin dans le process, plus ça coûte. Une boucle de dire je pousse je trigger toute ma CI le temps que je me rende compte que j'avais mis un espace et pas une table, et que ça revienne parce que de toute façon c'est rouge donc ça ne mergera jamais donc je reviens et je recommence et je repousse et pendant ce temps là l'argent continue de descendre parce que j'ai des runs qui tournent qui tournent qui tournent donc il faut que ça tourne en local aussi, on n'est pas toujours très bon aujourd'hui pour faire ça parce qu'en fait on n'a pas les mêmes outils quelqu'un qui run du GitHub Action, n'a pas un outil simple pour dire je veux runer exactement la même chose en local c'est rarement le cas il y a des systèmes pour faire tourner un peu du GitHub Action en local mais c'est assez lourd, on va des fois s'assurer, c'est un peu la promesse de Docker de dire bah oui mais on va versionner les trucs, on est dans des conteneurs mais c'est pas non plus souvent d'ailleurs l'outil ne fait pas partie. Du repository, l'outil est ailleurs mais je n'ai pas mis à jour ma machine ou je l'ai mise à jour et donc je suis en avance. Et une des choses que Dagger amène là-dessus, c'est la capacité de lancer la même chose en local et à distance. Et c'est exactement le même outil. C'est le même DAG qui va être exécuté. Donc on a la même assurance. Si sur ma CI, ça passe, ça doit passer en local et inversement. Et donc là, il y a des choses qui, moi, je trouve vraiment intéressantes. C'est d'avoir, y compris de réfléchir sur des systèmes de CI hybrides. C'est à dire que si je peux m'assurer l'assurance veut dire beaucoup de choses mais que par exemple mon linter est passé sur évidemment mon code il n'y avait aucune modification c'est ce commit exactement j'avais pas d'autres fichiers etc, d'ailleurs nous permet de s'assurer d'énormément de choses comme ça mais s'il est passé sur ma machine que ce soit moi manuellement ou mon agent ça change rien, au moment où je pousse dans ma CI je devrais être capable de lui dire voilà je te pousse par contre ce check, t'en occupes pas je l'ai déjà validé typiquement mon linter, mon formateur c'est bon je l'ai lancé en local, je coche directement et hop tu me le skippes, et là on évite de dupliquer parce que finalement ce que je vais faire sur ma machine ça a un coût aussi, ça a un coût parce que plus j'en fais plus je vais avoir besoin d'une grosse machine ça a un coût sur ma CI c'est de la perte d'infos alors. Juste un bémol sur ce que je viens de dire ça c'était ma version jusqu'à il n'y a pas très longtemps qui est déjà pas mal je sais qu'il y avait déjà des choses faites comme ça chez Basecamp après je ne sais plus dans quel nom ils sont, Basecamp, etc je crois qu'ils ont rechangé mais bon bref ils faisaient déjà des choses comme ça et là où on va c'est par contre sur du cache distribué, C'est-à-dire être capable d'avoir le même cash. C'est-à-dire que je suis à distance, ma siaille a du cash, je lance quelque chose, je bénéficie de ce cash, mais inversement. Et comme ce cash est fin et a des haches de partout, je m'assure que je n'ai pas d'effet de bord. C'est pas comme l'histoire déteste, en fait. C'est pas je vais récupérer un truc qui ressemble à ce que je veux. C'est j'ai la même chose. Et à ce moment-là, je n'ai même plus besoin de cette logique de dire je coche déjà mon truc c'est la CI va se lancer, elle va vouloir lancer un formateur par exemple le formateur va dire ouais c'est bon c'est déjà caché, voilà le résultat, et là on a un truc hybride qui devient hyper.

Bruno — Intéressant et du coup on rapproche une partie de la CI en fait enfin tout ou partie, mais quand même plutôt une partie directement du dev ou de l'agent de, l'entité qui produit le code pour qu'ils puissent avoir une boucle de rétroaction qui soit un peu plus rapide et un peu moins coûteuse, c'est surtout ça souvent.

Yves — On va jamais ramener tout parce qu'il y a toujours des choses qui sont trop lourdes moi je vois rien que sur la CI2 Dagger le repos de Dagger est pas petit, je lance jamais tout en local c'est pas possible, mais les petites choses qui concernent mon code les petites choses basiques lancer quelques linters lancer un formateur, lancer les tests unitaires du code qui vient d'être créé tout ça, c'est ce qu'on faisait avant mais on le faisait avec nos outils, typiquement je fais du Go, je vais lancer mon GoTest sur ma machine parce que bah oui mais le faire dans un conteneur c'est un peu moins rapide, c'est pas toujours pratique, j'ai pas la même fluidité etc, donc je lance mes outils natifs, je pousse et puis une fois que je pousse allez hop on recommence tout mais pas dans le même contexte je vais être dans un conteneur qui va être basé sur l'image Go qui va avoir telle version pinée etc, C'est un peu une perte, c'est du gâchis en fait. Et c'est ça qu'on veut éviter.

Bruno — Quand tu as évoqué le test splitting tout à l'heure, tu as aussi évoqué le fait qu'il y a beaucoup de tests qui sont écrits de nos jours, mais qui ne sont pas toujours utiles. On commence à avoir aussi des systèmes qui veulent sélectionner les tests qui sont renés et se dire en fait, je n'ai pas besoin de renner tous les tests parce que je n'ai pas un impact partout. Donc c'est vrai que l'IA fait très bien les diagrammes de dépendance est-ce que ça veut dire que on a aussi des systèmes aujourd'hui et du coup des systèmes qui permettent de, choisir les tests que je run et ce qui du coup rejoint le point sur le test splitting est-ce que ça veut dire que ton test splitting c'est quelque chose de statique, c'est à dire que du coup tu répartis tes tests entre ta CIA, entre tes différentes machines ou est-ce que c'est en fonction des tests que j'ai décidé de runner, je vais pouvoir les séparer sur peut-être parfois deux peut-être parfois six machines en fonction de ce que je fais une meilleure dynamique comme ça je les répartis.

Yves — Oui, la relation entre les deux, je ne sais pas exactement. C'est vrai que c'est deux layers différents qui s'ajoutent. Ne pas runner tout. Et c'est pareil, ce n'est pas que les tests, en fait. Par exemple, ne pas runner tout simplement un linter parce qu'on n'a pas touché cette portion de code. Ça devrait être du bon sens, en fait. D'ailleurs, c'est ce qu'on fait humainement. Si je suis sur ma machine, j'ai une appli, je ne sais pas, il y a un backend, il y a un frontend, j'ai touché qu'au backend, je ne vais pas lancer le linter du frontend. Bah si elle va le faire, quand bien même ce serait caché, c'est quand même quelque chose qui m'a coûté, même si c'est moins, mais il a fallu que je construise mon truc, que j'aille chercher et tout. Donc ça n'a pas de sens de le faire. Ça n'a pas de sens, je pense qu'il y a quand même une certaine fébrilité. Et donc on pourrait imaginer des systèmes encore une fois un peu plus hybrides où ma PR en fait elle le fait par exemple qu'une fois dans tout son cycle de vie, ou par exemple quand je merge, tout est renaît à ce moment-là voilà, on peut avoir des choses comme ça. Maintenant, oui, de toute façon, une fois qu'on a décidé quels tests on veut runner, finalement, comment on les split va varier. On n'a plus le même ensemble. Donc, on ne va pas faire la même chose. Après, les règles exactes, ça devient complexe. Mais ça aura un impact, forcément. Mais voilà, il faut trouver la bonne balance et ce n'est pas si simple.

Bruno — — Question forcément un peu, alors peut-être polémique, mais qui pourra peut-être générer un extrait qui fera du clic. Est-ce que tu penses qu'avec justement toute l'émergence de ces LLM et quand, même le gain en qualité qu'ils ont au fil du temps, est-ce que tu penses qu'on peut commencer à supprimer la code review humaine, et mettre une code review full AI dans ta CI et rester confiant, de ce qui est amené après en CD.

Yves — Très bonne question. Si je me base sur ce que j'ai vu, c'était sur l'article d'Entropic, où ils racontent, je crois que c'est celui d'Entropic ou d'OpenAI, mais je crois qu'ils sont un peu au même stade. Ils racontent que leur bottleneck aujourd'hui, c'est la CI. Parce que la review a été résolue. Aujourd'hui, c'est illusoire de se dire qu'on va relire le code. J'écris plus de code, pourquoi j'irais le relire ? Donc ça, c'est la partie peut-être un peu plus polémique. Avec les volumes qu'on a, ça devient extrêmement compliqué. Ça devient un boulot assez ingrat en même temps. Et puis, c'est compliqué de savoir ce qui se passe vraiment. Les reviews vont devenir gérées par des agents au moins en partie alors c'est là où faire une review par un agent ça veut pas dire qu'il n'y a pas un go humain à la fin, mais aujourd'hui nous c'est déjà ce qu'on fait chez Dagger aujourd'hui quand on demande une review donc c'est assez récent, mais quand on demande à quelqu'un d'autre une review on s'attend à ce qu'il ait déjà lui-même fait des reviews, fait faire des reviews et des reviews je crois que le terme c'est adversaire en général donc c'est par quelqu'un d'opposé finalement moi je sais que j'ai un process où, je bosse aussi bien avec du cloud que du codex si j'ai cloud qui me crée du code je vais avoir des reviews par codex, Je vais avoir plusieurs reviews par Codex, chacune avec des focus différents. Alors, qu'est-ce que j'avais ? Je vais essayer de voir si je... Non, je ne l'ai pas noté, mais... J'ai, par exemple... En fait, j'ai même plusieurs niveaux de reviews. J'ai des reviews dans mes plans, donc avant même d'implémenter. Et par exemple, j'ai une review sceptique. Le but de cette review, elle est instruite de cette manière. Pense que ce que je fais, c'est de la merde. Démontre-moi que ce n'est pas la bonne chose. Puis, j'en ai une autre qui va être plus sur est-ce que ça fit bien dans ce qu'on a, etc. Au niveau du code, je vais avoir la même chose. J'en ai une qui va être sur la simplicité, l'autre qui va être sur le design. Et puis, on peut en avoir encore d'autres. Mais donc, si c'est fait par Claude, si Claude a écrit le code, c'est Codex qui review, inversement. On peut faire ça aussi à l'intérieur d'une même famille. On peut très bien se dire, je vais avoir, je ne sais pas, Fable qui m'a codé un truc même du sonnette qui va review parce que lui il est bon pour lire et il va plus vite et donc, Entre ça, les linter, l'ensemble des règles qu'on lui impose. On devrait avoir quelque chose de bien. Mais, c'est là où il y a encore un truc, c'est qu'en fait ce n'est qu'une étape du process. Ce qui est arrivé avant, c'est aussi toute la discussion qu'on a eue avec les agents. Et c'est là où en fait, c'est pas juste « j'ai demandé un truc, je suis arrivé à la fin et hop, j'ai lancé une review de mon agent et c'est bon ». Non, en fait, on discute avec les agents. On discute, on dit, ben voilà, je veux faire telle fonctionnalité. Et puis, l'agent va proposer des choses, et puis on va discuter de design. Moi, je discute de design technique avec mes agents. On va faire comme ci, comme ça, ben non, la variable, elle va être ici, elle va être là. Donc, en fait, toutes les questions que j'aurais eues ou qu'on aurait pu avoir dans la review, elle est déjà là. Si je dois écrire le code à la main, je vais plus souvent, d'ailleurs, pousser déjà une première version, et ces discussions vont arriver à la review. Parce que c'est long tout ça. Mais l'agent me facilite la vie avec ça. Donc je pense qu'aujourd'hui les revues doivent être faites par les agents. Ça c'est une certitude. Ouvrir une pull request sans avoir fait de review par des agents et des agents indépendants qui n'ont pas le même contexte, qui ont des focus différents. On ne devrait pas le faire. Et la revue finale humaine, elle peut être sur des points de détail, des points d'architecture, mais elle doit être beaucoup plus haut niveau. Est-ce que c'est vraiment la fonctionnalité qu'on veut ? Est-ce qu'elle sert à quelque chose ? Est-ce qu'elle est organisée de la bonne manière ? Peut-être qu'il faut aller plus dans le détail. Est-ce que l'architecture est la bonne ? Mais là-dessus, quand j'ai des questions, je vais relancer un agent qui va justement être très bon pour me tracer le code. Ça, je le fais régulièrement. Je vais lui demander « Tiens, tu me prends telle fonction, telle action. Tu me sors un diagramme de séquence sur main, sur cette branche. Tu me les compares. Tu m'expliques les différences. ». Ça va appeler telle fonction d'abord et c'est là en fait où j'ai besoin de mon cerveau pour dire oui c'est ce que je veux ou non ça c'est pas bon, le code en lui même aujourd'hui les agents sont bons pour écrire du code donc on a plus comme avant des trucs complètement alambiqués d'ailleurs on a moins de problèmes par exemple de compilation ou autre ça passe quoi, mais donc voilà donc en fait on a plus les mêmes types de revues, et on pourrait pas supporter en fait la cadence mais on a des revues qui deviennent d'ailleurs en plus intéressante ? Est-ce que c'est vraiment la fonctionnalité que je veux ? Peut-être qu'à un moment donné on va avoir des revues qui d'ailleurs vont sortir un peu plus des ingénieurs et vont retourner un peu plus vers par exemple les PM ou les designers, au moins partiellement. Ok c'est mes agents qui ont implémenté mais la fonctionnalité elle est là, est-ce que ça ressemble à ce que tu voulais ? Et celle-là elle devient.

Bruno — J'ai vu ce matin, donc c'est vraiment, c'est tout, tout frais. J'ai vu ce matin sur LinkedIn un truc que ça m'a un peu... Je trouve ça assez fascinant. C'était Marek Kallik de Théodau, qui est déjà venu à ce micro, que je réinvite parce que vraiment, il dit trop de choses intéressantes. Il explique qu'en fait, si tu n'as pas confiance dans l'agent qui te génère du code, c'est problématique en fait. À ce moment-là, écris le code toi-même. Tu ne servais pas avant à relire le code qui est généré par ton agent. Mais du coup, ce qu'il propose, c'est de ne plus faire de code review, mais de faire des conversation review. Et que du coup, l'humain, t'es un humain qui review la conversation que t'as eue avec ton agent, qui a permis de générer le code qui est derrière. Parce que c'est là aussi, déjà où il y a du transfert de compétences.

Yves — Ah, très intéressant.

Bruno — Parce que c'est là aussi où il y a toute une phase de définition des choses. Et que, comme c'est ce qu'on fait majoritairement, on ne devrait pas aller vérifier l'output de la machine, mais vérifier l'input de l'humain dans la machine.

Yves — Oui, c'est très très intéressant. Ça pose pas mal de questions, de nouveau en termes d'outillage aussi, comment on fait ça. Mais oui, oui, finalement, c'est... En fait, je pense que ça dépend aussi à quel stade on est dans l'utilisation des agents. C'est-à-dire qu'au début, on commence, on a un agent et on lui donne des instructions. Fais-ci, écris ça, etc. Une fois qu'on passe sur de la software factory, on change déjà complètement de domaine, puisqu'en fait, on lui donne un but. Fais-moi telle fonctionnalité. Corrige-moi tel bug. Et ça déjà en fait on n'est plus dans l'instruction exacte de l'agent, on n'est plus en train de lui dire rajoute moi un test unitaire pour tel truc, corrige moi telle fonction etc, là on était intéressé par le code, on est dans résous moi tel problème, et donc je pense que ça rejoint cette histoire de conversation parce que c'est ça qui est intéressant on va avoir résous moi tel problème, l'agent va dire j'ai 5 façons de le faire, laquelle tu prends c'est là où est, le truc, c'est là où il y a l'intérêt. Alors, je sais que je, parfois, pas tout le temps, peut-être qu'il faudrait que je fasse plus, j'ai un agent supplémentaire, au moment où je pousse une nouvelle pull request, j'ai un agent spécifique qui me fait ça, c'est-à-dire que je lui demande, ok, explique-moi, explique-moi les changements. C'est même, non, ce n'est même pas explique-moi, c'est explique-le pour un autre humain qui n'aurait pas écrit driver ce code. Et ça me sort un document pour un humain, qui n'est pas le diff, et qui va reprendre quels problèmes on cherche à résoudre, quelles étaient les différentes options, laquelle on a choisi. Ça va inclure par exemple des données qui viennent de main, voici quel était l'état, et voilà ce qu'on va changer dedans. Et puis ça va me faire le flow complet le flow qui lui d'ailleurs dépend probablement d'éléments que je n'ai pas modifiés, donc qui ne sont pas dans le diff, et donc ça veut dire qu'à part aller plonger dans le code je ne peux pas le savoir, mais ça va me dire, le flow dans tel cas on appelle telle fonction, telle fonction et celle-là, hop, elle a changé on est allé appeler autre chose, et voici le diff qui lui correspond, etc et ça en gros je lui dis mais raconte-moi une histoire raconte-moi cette pull request que je puisse la comprendre, et ça c'est un document qui normalement on devrait pouvoir le lire, sans avoir le contexte préalable et se dire bah ok voici les choix qui ont été faits c'est pas vraiment la conversation parce que la conversation elle-même, elle peut être longue, elle peut être alambiquée c'est comme c'est comme quand on est absent deux jours et qu'on revient, dans un thread slack des fois. Je peux pas avoir le résumé vous êtes passé par trois versions différentes, moi ce que je veux c'est là où on en est et pourquoi ? Et bien cet agent va être capable de le faire. Et donc je lis ça je le publie genre sur un gist et hop je lis dans ma pull request et si quelqu'un veut la comprendre on lit ça et on sait où on en est, on sait quels choix ont été faits, quels j'ai perdu le mot quels compromis on a fait qu'est-ce qui n'est pas couvert, quel impact y compris négatif il peut y avoir parce que parfois bah oui mais, on est d'accord de le prendre et ça c'est hyper intéressant je trouve et c'est ça qui je trouve permet de donner de transmettre cette connaissance, sans avoir le besoin d'être très profond dans le code, mais on est quand même à un niveau où on parle de diagramme de séquence, on parle d'architecture, on parle de fonctionnalité on parle de diff on voit des extraits de fonctions etc quoi, donc ça c'est une solution, je pense que je vais le remettre un peu plus.

Bruno — Pour terminer parce que si on imagine qu'on a.

Yves — Notre code.

Bruno — Qui est généré par une IA qui est review par un ensemble.

Yves — D'IA.

Bruno — Qu'on a notre CI qui est entièrement automatisé et qui check les marques et qui passe du coup à la CD qui déploie toute seule quelle est la place de l'humain encore dans tout ça si tant est qu'il y en ait une ou qu'il faille en garder une ?

Yves — La première place de l'humain de manière globale, elle est même au-dessus de la génération de code et tout. C'est vraiment quel est le logiciel qu'on veut faire, quels problèmes on veut résoudre. Ça, on ne le remplacera pas. Quelle ergonomie on veut, qu'est-ce qui est important ou pas. Parce que des fois, on a des sujets qui sont très vastes, mais on voudrait tout faire, mais en fait, ça n'a pas de sens. Donc toutes ces fonctions là de toute façon sont encore plus importantes qu'avant, parce qu'en fait au plus vite on va pouvoir créer du logiciel au plus on va leur demander de nous donner des inputs sur ce qu'on doit faire. Après il y a finalement tout ce qu'on vient de dire c'est pas parce qu'en fait on a une machine qui nous crée du code qui a pas des questions d'architecture d'organisation de passage à l'échelle d'efficacité, mais ça demande une compréhension un peu différente qui était parfois un peu noyée, dans le code parce que le code par la force des choses nous prenait tellement de temps, que c'était dur de passer du temps là dessus alors je vais dire il y a un bémol là dessus, il y a un truc qui est complexe aussi c'est ce que je raconte je pense que ça marche très bien pour des gens seniors, parce qu'on a ce background qui fait qu'on peut discuter d'architecture y compris avec un agent pour des juniors c'est une vraie question comment les juniors vont apprendre, vont récupérer l'expérience ?

Bruno — Alors là-dessus, sur les juniors, moi, ma théorie, qui vaut ce qu'elle vaut, c'est que les juniors, ils vont apprendre comme nous, comme on a appris. Ils vont faire des erreurs, sauf qu'ils ne feront pas des erreurs d'avoir écrit du mauvais code, ils feront des erreurs qui auront généré du mauvais code.

Yves — Probablement.

Bruno — Donc, qui potentiellement auront peut-être un impact, un radius, je ne sais plus comment dire, un blast plus important que ce que nous, on avait quand on faisait une erreur de code. Mais au final peut-être pas tant que ça, mais ils vont apprendre comme nous, au travers d'erreurs et du coup ils progresseront vers un métier qui n'est pas le métier qu'on est en train de construire toi et moi.

Yves — Ouais, c'est possible mais voilà, sur tous ces sujets l'humain reste là, on a besoin de l'humain pour ça, on a besoin de l'humain pour, même si par exemple des LLM nous aident à comprendre y compris les bugs, les incidents, les incidents de production et tout, mais il y aura toujours des décisions humaines là-dedans parce que c'est ça sera, moins ça sera moins en fait sur le détail technique au niveau du code et beaucoup plus sur ce qu'on veut faire finalement le, le langage avec le LLM devient un autre code en tout cas j'espère qu'on va rester pertinent un peu partout, j'espère effectivement aussi.

Bruno — Merci beaucoup en tout cas Yves pour toute cette conversation j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager à l'ensemble des auditeuristes.

Yves — Et bien j'en ai deux mais il y en a un auquel j'ai pensé pendant notre discussion, c'est une conférence d'un de mes anciens collègues Maxime Clément chez Docker sur la flaquinesse des tests, alors comme je ne l'ai pas préparé, je n'ai pas le nom exact en tête comme ça, il l'a fait à Devox France il y a un an un an ou deux, quelque chose comme ça c'est hyper bien, vraiment ça montre, en quelques mots c'est la suite de tests de Docker Desktop, qui est fléquie pourquoi mathématiquement on n'arrivera jamais à la voir verte, c'est impossible il suffit de faire quelques calculs quelques stats, mais de les voir, moi je ne les avais jamais vus on est tous confrontés à des tests flakies mais de voir les chiffres on fait, là on a un problème et donc derrière comment finalement on vient embrasser cette flakiness et on se dit en fait ça doit faire partie, de notre procédure de thèse, de nos CI et il faut avancer avec et pas contre. Donc ça c'est une conférence vraiment que je recommande à tout le monde. Et j'avais prévu autre chose. Alors, c'est complètement différent. C'est un livre qui me suit depuis, je ne sais pas, 15 ou 18 ans, un truc comme ça. C'est de Pekka Imanem. Alors, je donnerai les références, mais je ne sais pas s'il est encore édité. Mais si on cherche bien, on peut le trouver. C'est sur l'éthique à cœur et l'esprit à l'ère de l'information. Je vais retrouver le titre exact. Alors c'est beaucoup plus philosophique. C'est finalement une critique de la théorie protestante du travail de Weber. Et c'est un truc, on en entend régulièrement parler, bien en dehors de la tech, de la valeur travail. C'est un sujet qui revient régulièrement et ça part de ce constat et de se dire mais pourquoi s'il y a vraiment cette valeur travail, cette éthique protestante du travail, pourquoi on a des gens qui par exemple font de l'open source, qui vont produire quelque chose de leur labeur qui n'est pour autant pas la définition du travail au sens où on fait quelque chose et on est payé pour ça. Et donc comment ça se trouve qu'il y a des gens qui, après leur travail, font du travail ? Et ce bouquin est absolument génial. Il peut être lu bien au-delà du monde de la tech, même s'il parle de ça. Il y a une préface de Linus Torvalds dessus. Et voilà, c'est un bouquin qui est absolument génial. Moi, j'ai la chance de pouvoir bosser sur de l'open source, mais parce que c'est ce que j'ai toujours voulu faire. Mais ces questions ont toujours été centrales. Et donc, la relation au travail est hyper importante.

Bruno — Hyper intéressant.

Yves — Voilà, c'est un bouquin absolument génial.

Bruno — On mettra les liens bien évidemment en description dernière question Yves qui est la plus importante de ce podcast Yves est-ce que tu es plutôt espace ou tabulation ?

Yves — La blague ça serait de dire mixte mais non espace et je laisse mon idée gérée surtout pour Go qui s'est décidé en mettre 8 ce qui n'a absolument aucun sens mais.

Bruno — Espace merci beaucoup Yves et merci à tous d'avoir suivi cet épisode voilà effectivement l'IA impacte, tout dans notre métier y compris la CI qu'on doit effectivement intégralement revoir en tout cas en bonne partie revoir même si le principe bien évidemment reste le même c'est de s'assurer que ce qu'on produit reste exploitable et utilisable en production. Moi de mon côté je vous remercie toujours de partager ce podcast autour de vous c'est ce qui permet de continuer de recevoir plein de gens on commence déjà à bosser sur la série spéciale d'été, je pense que j'ai trouvé une idée pas mal qui peut faire un truc un peu fun mais ça va être un peu long en tout cas je vous remercie beaucoup je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.