Bruno:
Quand le colonel Rhodes dit à des jeunes cadets que l'avenir du combat aérien, ce sont des avions sans pilote, Tony Stark lui propose des pilotes sans avion. Mais il est évident que tout le monde ne pourra pas finir pilote d'une armure d'Ironman. Dans un métier en pleine transformation, on peut se demander comment les géants font, surtout quand on a un produit utilisé par des centaines de millions de personnes à travers le monde, quand l'erreur n'est pas acceptable et que même parfois, même pas envisageable. Mais alors, comment AWS crée son code aujourd'hui ? Quels sont les retours de l'AWS Summit de la semaine dernière ? Et surtout, qui osera demander à Bedrock d'écrire un manifeste agile ? Pour répondre à ces questions de pilotage, je ne reçois pas tel striker, mais il s'y connaît en film de Gladiateur. Julien, bonjour.
Julien:
Bonjour, Brido.
Bruno:
Alors Julien, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Julien:
Il y a sûrement énormément de monde qui ne me connaît pas. Je suis Julien Lépine, je suis directeur de la technologie chez Amazon Web Services pour la France, ça fait un plus de 13 ans que je suis chez Amazon, et mes équipes travaillent avec les clients d'Amazon Web Services pour les aider à adopter le cloud, la data et l'IA.
Bruno:
Ok, canon. Donc la semaine dernière s'est tenu le AWS Summit, qui est du coup un peu la grande messe tech de AWS en France.
Julien:
C'est la plus grosse conférence cloud et IA en France avec à peu près 10 000 personnes qui viennent au palais des congrès chaque année. On l'a tenu le 1er avril, c'était pas une blague et on a eu du monde, heureusement, parce que S'ils ont bien compris que ce n'était pas une blague.
Bruno:
Donc c'était effectivement une grande masse. Tu as eu un planning assez chargé et assez intense. Ça a été quoi pour toi un peu dans ce contexte très changeant ? C'est quoi un peu ce que tu ressors de cette journée avec tous ces développeurs et développeuses ?
Julien:
J'en ressors trois jours sans voix après le Summit, ça a été le premier élément. Alors on dit le Summit, mais en fait pour AWS c'est plusieurs Summit, parce qu'on travaille avec les partenaires la veille, on a un dîner avec les directions générales la veille aussi, plus la journée du Summit, et après on a deux jours avec les équipes en interne pour faire ce qu'on appelle l'After Summit, donc je voulais dire un merci à mes équipes d'avoir organisé ça, donc c'est un grand événement pour nous, c'est vraiment le point culminant d'année, c'est le premier au monde aussi pour AWS, la France est le premier pays a lancé la saison des summits donc c'est Cocorico aussi c'est quand même évident, pourquoi le summit ? On l'a toujours vu comme étant un événement centré sur l'apprentissage alors effectivement il y a du marketing on va voir les nouveaux services et les nouvelles annonces mais plus de la moitié de nos sessions avaient des clients et donc le but, un peu comme tu fais dans ton podcast c'est d'avoir un sujet général où on va présenter la vision d'AWS de ce sujet là, mais plutôt que juste nous parler, c'est intéressant, on aime bien le faire mais c'est pas vraiment ce qui va faire bouger les foules, On a nos clients, et on avait des centaines de clients qui venaient, qui viennent présenter comment ils ont répondu à ce cas d'usage spécifique chez eux et quel en a été l'impact, ce qui a marché et ce qui n'a pas marché. Et donc ce que j'en ressors vraiment sur cette journée, qui est extenuante pour tout le monde, beaucoup de kilomètres marchaient, on commence très très tôt, on finit très très tard. Mais voilà, vraiment beaucoup d'apprentissage une énergie débordante dans l'écosystème tech on a des start-up, des PME, des grands groupes on avait des étudiants, on avait vraiment, tous les types de profils, une énergie débordante une envie d'apprendre, des questions sur l'avenir qu'est-ce que ça va devenir et comment on va, créer ce nouveau monde du développement mais voilà, une énergie dingue sur toute la journée et un summit qui a fait le plein aussi.
Bruno:
Alors, ce qui est hyper intéressant, en fait, de te recevoir, c'est que sur ce podcast, on a beaucoup parlé, effectivement, des changements du métier de dev, effectivement, un ensemble d'entreprises qui essaient de s'adapter à tous ces changements, à tous ces nouveaux outils qui sortent. Ce qui est un peu particulier avec AWS, c'est que vous êtes, effectivement, aussi dans cette transformation, mais vous y êtes aussi acteur. Et notamment, à travers la AWS Summit, vous avez annoncé des choses autour des différents outils pour les développeurs. Comment est-ce que vous participez justement à cette transformation de notre métier ?
Julien:
Amazon Web Services a énormément de développeurs en interne. Donc déjà, notre premier besoin, c'est nous. On fournit des services, on développe des services. Tu disais en introduction, on doit avoir la possibilité de... Enfin, on doit pouvoir fournir des services de qualité à une échelle absolument dingue. J'ai eu la chance et l'honneur de présenter une session sur un moment où ça n'a pas marché. Il se trouve que le 20 octobre dernier, on a eu un événement, ce qu'on appelle un large-scale event, où on a un de nos services DynamoDB qui n'a pas répondu pendant une petite durée. Alors pour vous ça vous parle peut-être pas en tant que développeur en France, parce qu'il n'y a eu aucun impact en France et sur les régions européennes, si vos enfants jouent à Fortnite le 20 octobre 2025, c'était le premier jour des vacances de la Toussaint, et il se trouve que Fortnite était indisponible. Ce service-là, il gère plus de 5000 milliards de requêtes par heure.
Bruno:
Ce qui n'est pas négligeable.
Julien:
Voilà.
Bruno:
Ce qui commence à être...
Julien:
Et donc, on est sur des échelles qui sont complètement folles. Et on se dit pourquoi c'est important, et entre autres l'IA. Je pense qu'on y reviendra. Quelque chose qui arrive une fois tous les milliards de fois. Quand on fait plusieurs milliers de milliards de requêtes par heure ou par jour. En fait, ça arrive tout le temps. Ça peut arriver plus de 1000 fois par heure. Donc, effectivement, moi, quand j'étais développeur, on me disait le truc, ça peut se produire une fois sur un milliard. Je disais, c'est bon, je suis confort, ça ne va jamais arriver. Là, en fait, on est à une échelle telle qu'on a effectivement ce risque-là. Donc nous, on a vraiment cet élément-là où on va produire des systèmes qui sont des systèmes extrêmement critiques, qui vont avoir un impact majeur, mais aussi on travaille avec nos clients. Et donc dans la deuxième étape, tu disais effectivement, on a un environnement de développement qui s'appelle Kiro. On a d'ailleurs mis des outils à disposition, on a des agents de sécurité, des agents DevOps qui ont été mis à disposition en GA, donc en general availability disponible pour tout le monde toute fin mars, le 31 mars donc la veille du summit, donc on a ces services là et mes équipes nous on va vraiment travailler avec nos clients pour essayer de comprendre c'est quoi leur problématique comment on peut les aider, comment on peut comprendre ce qu'ils font, pour aussi adapter les services parce qu'on ne veut pas avoir un service parce qu'il répond à nous c'est très intéressant on trouve ça très intéressant en interne mais on veut surtout avoir des services où on peut utiliser notre expérience et notre échelle, le rendre de manière simple à tous les développeurs Alors AWS a vraiment été créé pour rendre disponible le meilleur de la technologie à tout le monde. C'est la fondation même d'AWS. Et donc on continue à faire ça dans ce nouveau monde de l'IA.
Bruno:
Alors après il y a quand même aussi un sujet, c'est qu'on l'a évoqué avec quelques invités sur ce podcast, c'est qu'on voit parfois des startups qui se lancent. Et qui se posent des questions de scalabilité, de comment est-ce que je gère mon infra quand j'aurai un million de users simultanés sur la plateforme, alors que le site n'est même pas lancé, donc tu n'as même pas de users simultanés sur la plateforme. Donc tu vois, une notion un peu d'over-engineering, et des trucs qu'on aime bien, de toute façon, en tant que dev, on aime bien se compliquer.
Julien:
Avoir 400 microservices pour 12 utilisateurs, c'est très bien, mais ce n'est pas hyper pratique.
Bruno:
Mais donc justement, tu vois, si vous mettez tout votre savoir d'AWS à disposition de tout le monde, est-ce qu'il n'y a pas justement un risque que vous vous mettiez à disposition de l'over-engineering et qu'en fait, la solution pour... Parce qu'en fait, tu vois ce que tu évoquais tout à l'heure sur vos milliards de requêtes, c'est un problème que vous êtes peut-être 10 dans le monde à avoir ces problèmes-là. Et tous les autres, ça ne nous arrivera jamais, en fait, d'avoir ces... Donc, tu vois, de...
Julien:
Je vous souhaite que ça vous arrive.
Bruno:
Oui, on est d'accord.
Julien:
C'est quand même hyper fun. Non, justement, la raison d'être d'AWS quand on s'est lancé, quand on a lancé notre premier service en 2006, alors AWS vient d'avoir 20 ans, alors pour les geeks parce qu'il y en a quelques-uns, ou peut-être même nerds qui vont faire ça on l'a sorti le 14 mars, donc le 14 mars aux Etats-Unis ils écrivent les dates dans le sens inverse du node donc ça devient 3-14, donc pas idée le jour de pas idée, on a sorti Amazon S3 qui est le premier service sous la marque Amazon Web Services, et notre mission je disais, le but c'est de démocratiser l'accès à la technologie notre mission aussi c'est de on adore ce mot là, cet ensemble de mots c'est we take care of the, undifferentiated heavy lifting donc on prend tout ce qu'est. La plomberie, tout ce qu'est le travail difficile mais qui apporte pas de valeur nous notre mission c'est de le prendre en charge chez nous pour que les gens n'aient pas à le faire ce qu'on fait avec S3, ce qu'on fait avec Amazon EC2 ce qu'on fait avec tous nos services donc si nous on a des services qui sont difficiles à opérer le but c'est que l'API, pour les utilisateurs elle soit hyper simple, je prends S3, S3 il est sorti il y a 20 ans, l'API c'est je suis capable de faire un HTTP put et un HTTP get C'est pas très compliqué. 20 ans plus tard, on fait toujours un HTTP put, on fait toujours un HTTP get nous on avait commencé, tu parlais sur l'overengineering Werner il y a un peu plus de 10 ans avait sorti une analogie que j'aimais bien quand on a lancé S3, c'était l'équivalent de voler dans un petit Cessna, S3 maintenant c'est l'équivalent d'une flotte d'A380, mais pour les utilisateurs ça a été complètement transparent, et c'est vraiment ce moment là, nous on veut pas si vous voulez le faire overengineer, faites le mais si vous voulez commencer par avoir une application monolithique qui tourne sur une instance virtuelle parce que c'est ce qui répond à vos besoins, on est hyper heureux. Par contre, on va vous poser des questions. Est-ce que vous avez pris en charge la haute disponibilité ? Est-ce que vous avez pris en charge la sécurité ? Et souvent, en fait, notre métier, c'est plus de poser des questions que d'arriver avec des réponses. Et donc, on va poser plein de questions. On a un framework qui s'appelle le Well Architectic, donc des applications bien architecturées, où on pose plein de questions. Et pour beaucoup, on dit « C'est pas un problème. C'est peut-être pas pour maintenant. C'est peut-être pour toi. », Mais voilà, je reste persuadé qu'il ne faut pas over-engineer. Sinon, on ralentit alors qu'on a fait tout ça pour pouvoir accélérer.
Bruno:
L'objectif, c'est de pouvoir faire en sorte que le jour où ça devient un sujet, tu puisses d'un flip de switch activer les bonnes options, les bons paramètres pour que ça se scalde.
Julien:
Presque un flip de switch. Mais le but, effectivement, c'est de voir. On a des applications. Alors, si vous voulez faire tourner du PHP, vous avez des virtual private servers qui sont disponibles en un clic. Au moment où vous allez vouloir passer à l'échelle effectivement il va falloir mettre un load balancer il va falloir mettre plusieurs instances il y aura probablement des modifications sur le MySQL ou le PostgreSQL qui vient derrière pour avoir des services un peu plus managés nous on fournit les différentes briques ce qui est génial avec l'IA maintenant c'est qu'en fait ces chemins de migration on peut les automatiser en fait on a plein de markdown qui sont disponibles pour expliquer c'est quoi les bons chemins de migration et on a une session qui est une de nos sessions qui a été je pense le plus joué dans le monde entier depuis. Quasiment depuis que je suis chez AWS ça fait 13 ans que je suis chez AWS maintenant, et la session elle s'appelle Scaling for the First Million Users donc comment passer à l'échelle pour notre premier million d'utilisateurs et justement on commence par dire vous commencez par une instance, après vous avez deux instances après vous avez des problématiques de je vais protéger mon frontend de mon backend donc on met une file, après on se dit ouais mais j'ai envie d'avoir un cache parce que je commence à avoir un petit peu d'éléments, et en fait on va commencer à ajouter les briques, mais toute la session et on l'ajoute tous les ans. Depuis le premier ReInvent, qui est notre grande conférence internationale à Las Vegas, tout début décembre, tous les ans, elle existe, cette session. Et justement, on est très clair avec les utilisateurs et les développeurs en leur disant, vous pouvez aller très, très, très, très, très loin. Netflix opère une plateforme absolument dingue à une échelle que très peu ont vu, qui est intégralement basée sur AWS, et... Commencez pas par faire l'archi de Netflix. Clairement, c'est pas une bonne pratique.
Bruno:
Et de quoi, tu as parlé effectivement des outils d'IA pour les développeurs, que ce soit au niveau de vos clients ou chez vous, chez AWS. C'est quoi votre perception, chez AWS, justement, de cette adoption des outils d'IA par les équipes de devs ?
Julien:
Alors, je vais prendre une histoire qu'on a eue récemment. C'était justement en préparation du grand événement de ReInvent de décembre dernier. On avait une adoption assez disparate finalement au sein de l'organisation on est très micro-service, Vous pouvez probablement trouver sur Internet des histoires de Jeff Bezos qui aurait envoyé un mail avec un mandat en début des années 2000 en disant maintenant vous devez tous faire du SOA. Service oriented, on est début des années 2000, on n'est pas microservices. Mais qui étaient vraiment les prémices des microservices. Et donc nous on sait, pour ceux qui aiment la loi de Conway, les principes de Conway, il se trouve qu'un logiciel est un miroir de l'organisation humaine. Et donc on a décidé d'organiser comme on voulait avoir nos logiciels. Donc on a organisé très rapidement autour d'un concept qu'on appelle les pizza teams qui sont des équipes de une petite dizaine de personnes qui peuvent être nourries avec deux pizzas américaines des grandes pizzas. Sur ce concept là, en fait on le voit chez Amazon, chez AWS particulièrement quand vous voyez nos services finalement on a une espèce de constellation une des raisons pour lesquelles on a cette constellation c'est qu'à chaque fois on a des équipes différentes qui sont en charge ce qui leur permet de travailler vraiment en parallèle ce qui pose une question de l'adoption à large échelle. Comment on fait pour pousser une adoption à large échelle, quand notre modèle même d'organisation, c'est la liberté et l'autonomie. Donc ça, on le fait. Et donc, on voyait pas mal d'équipes qui l'adoptaient de manière différente. On a des équipes qui faisaient un peu de la code complétion. Voilà. On était sur du j'ai 10-20% d'augmentation de ma productivité, mais bon, globalement, j'ai pas changé mon modèle d'être. Et on a une équipe qui développe Amazon Bedrock. Amazon Bedrock, c'est le cœur du réacteur de l'intelligence artificielle générative chez AWS. C'est la plateforme qui gère tous les agents, c'est la plateforme qui gère tous les LLM. On a plus d'une centaine de LLM disponibles, de plein de fournisseurs différents, on a plus que doublé le nombre de LLM. C'est des plateformes qui gèrent des milliers de milliards de requêtes. Encore une fois, c'est vraiment une plateforme critique. Sauf que nous, on a commencé à le développer en 2023. Et on l'a lancé en 2023. Il se trouve qu'en 2025, les besoins de l'IA, pour ceux qui font de l'IA depuis un peu plus de deux ans. On ne l'utilise pas de la même manière. On était sur de la code complétion, maintenant on est sur des agents autonomes qui sont intégrés dans des systèmes complexes. Ça a complètement changé. Donc notre plateforme Bedrock ne répondait plus aux besoins. Clairement, il fallait la mettre à jour. Et donc on a une équipe pilotée par Anthony Ligori, qui est un de nos distinguished engineers. Chez Amazon, on a deux carrières parallèles. C'est un truc que j'adore aussi. On a une carrière de contributeur individuel où on peut aller jusqu'à senior vice president, qui dépend directement du directeur général d'Amazon. On a une personne qui s'appelle James Hamilton, qui est Senior Vice President et Distinguished Engineer. Donc, il est contributeur individuel. Il continue à faire de la techno. Par contre, l'impact de tous ces choix sont absolument énormes. Et après, on peut avoir une carrière plutôt dans le management, où effectivement, on devient directeur, vice president, senior vice president, avec des équipes. Mais voilà. Et donc, il y a vraiment deux carrières. Donc, on ne force pas les gens nécessairement à choisir entre l'un et l'autre. On peut vraiment prendre ce chemin-là. Et donc, on a un de nos Distinguished Engineer qui est l'équivalent d'un VP, mais contributeur individuel. Il s'appelle Anthony Ligori. Et qui a été mis en charge du redéveloppement de Bedrock. Alors il est arrivé avec sa vision traditionnelle, il a fait son analyse, il a fait ses schémas, il a dit, il me faut 30 développeurs, 3 pizza teams, et il va me falloir 18 mois. Et là la direction dit, c'est-à-dire que non, en fait, ce serait bien qu'on l'ait avant. Et en fait, il avait commencé à jouer pas mal avec ses modèles d'intelligence artificielle, il avait vu l'amélioration de la productivité, mais voilà, il t'est resté là-dessus. Et en fait il s'est dit mais en fait c'est peut-être une vraie opportunité et donc il a regardé vraiment plus la manière de travailler il a créé une équipe, je pense qu'on y reviendra il a créé une équipe de seniors initialement parce qu'on voulait avoir des gens qui avaient la connaissance de la code base des contraintes et de ces éléments là pour tester le but c'est on prend une équipe on les laisse en autonomie pour tester et il s'est dit tiens mais en fait si on utilisait ces modèles là pour redévelopper complètement bedrock et en utilisant une plateforme agentique il a réussi avec une équipe de six personnes. En 72 jours donc on était à 18 mois 30 personnes, là on est 5 fois moins de personnes avec 6 personnes et on est globalement à 7-8 fois moins de temps, parce qu'on le fait en 72 jours, il a été capable de redévelopper Bedrock, encore une fois une plateforme qui gère des milliers de milliards de transactions, on est sur une plateforme extrêmement critique, qui est au coeur de la plupart des applications, donc qui est du code en prod hyper sécurisé, super validé donc on n'est pas sur du vibe coding du tout on est vraiment sur une plateforme une plateforme de prône. En fait, ils ont été capables de développer ce système, de le mettre à disposition, de le tester, de le valider et de le lancer. Ce qui nous a permis d'accélérer énormément. On utilise aussi ces choses-là et dans la gestion du changement, il y a le concept de power user qu'on utilise beaucoup depuis longtemps dans la gestion du changement. En fait, c'est un peu devenu notre power user en se disant, je vais prendre une application qui est vraiment critique. On peut tous faire des pocs et des protos sur des applications qui sont simples. Je me rappelle de l'IoT, quand tout le monde me demandait si on pouvait mettre des caméras pour voir si les salles de réunion étaient prises ou pas. Ça, c'était 2015 à peu près, à l'IoT. Je ne pense pas qu'il y ait beaucoup de ces applis qui soient encore en prod, avec les boutons IoT pour faire les trucs. Là, on se disait, non, on ne veut pas un truc gadget, on veut un truc cœur de métier. Et donc, il a appris l'avenir de l'entreprise, clairement. La G&I est liée à Générative et à Gentil, que c'est clairement au cœur de la stratégie d'Amazon et d'AWS. il a redéveloppé ce système-là pour le mettre à disposition de tout le monde. Et donc ça, ça a été un de nos gros changements.
Bruno:
Mais comment est-ce que tu gères, parce qu'en fait, le grand écart que tu nous expliques, que tu nous montres, il paraît fou entre des gens qui font, en gros, de l'autocomplition plus-plus, et quelqu'un qui te redéveloppe quelque chose d'essentiel dans les services AWS aujourd'hui. Au final, en quelques jours avec quelques personnes, on est effectivement sur, un spectre d'usage qui est drastique, comment tu fais pour, l'idée c'est quoi, c'est ok maintenant on continue à laisser tout le monde faire un peu comme ils veulent ou est-ce que tu te dis, ceux qui font que l'autocompletion, en fait il faut les amener à ce qui a pu être fait sur Bedrock ?
Julien:
Clairement il faut les amener, on va pas les laisser en mode autocompletion, mais encore une fois chez Amazon on a très très peu de mandats top down qui disent, c'est comme ça qu'on va le faire. On a des contraintes en disant, par exemple, sur la sécurité, on a quelques outils très spécifiques qui sont des outils que tout le monde doit utiliser. Pour le déploiement, on a aussi quelques outils très spécifiques que l'on doit utiliser. Par contre, même les langages de programmation, finalement, on peut ajouter un nouveau langage de programmation chez Amazon. Par contre, on arrive à un ensemble de contraintes qui sont, il doit être opérable, il doit être débugable, il doit avoir de l'observabilité, il doit être sécurisé, il doit être patchable, il doit avoir du... Enfin, donc ajouter un nouveau langage, même si c'est possible.
Bruno:
Donc on n'arrive pas avec du brain fuck du jour au lendemain ?
Julien:
C'est ça, exactement. Et donc le but, c'est vraiment de se dire comment on va le rendre opérable. Et donc après, on a vraiment un côté communauté, où en fait on a le rôle de ces distinguished engineers, en fait ils ont la responsabilité souvent d'un service, d'un ensemble de services, mais leur deuxième mission, c'est d'aller travailler avec tous les autres services pour faire des revues, en se disant, si moi je suis dans mon contexte, je redéveloppe Bedrock par exemple, je fais mon système, je me doute que mon système va marcher, je vais avoir un biais cognitif de validation. Et donc au moment où je vais faire mes revues, il y a potentiellement des détails que je vais laisser passer. Donc on va chercher des distinguished, des principals, ou des senior principals, d'autres équipes, pour venir faire la revue. Donc déjà, en faisant ça, on s'assure que toutes les équipes, on a des échanges réguliers et chaque nouveau service qui doit être lancé doit avoir une principal review donc déjà rien qu'en faisant ces éléments là et en utilisant ce côté communautaire, on s'assure qu'on va avoir nos personnels les plus seniors qui se disent non mais moi aussi je veux faire 6 fois. Moins de monde et 5 fois plus vite ou 8 fois plus vite, c'est vraiment quelque chose qu'ils ont envie de faire, donc ça c'est le premier élément, le fait d'avoir ce maillage, vraiment intense au sein de l'organisation fait que ce partage de bonnes pratiques est très rapide après le deuxième on a réussi à créer une communauté on fait beaucoup de choses d'un point de vue communautaire on a un channel Slack avec 30 000 personnes qui sont dedans qui sont les bonnes pratiques pour adopter l'IA alors avec 30 000 personnes dans un channel Slack pour ceux qui utilisent Slack ça fait beaucoup de bruit donc du coup on a un deuxième channel Slack qui utilise de l'IA pour faire un résumé du channel Slack principal tous les soirs pour qu'on puisse avancer dessus mais voilà on est vraiment sur ces éléments troisième élément et c'est ce qui a été annoncé à reInvent par Matt Garman le directeur général d'Amazon Web Services, on a pour une fois décidé de standardiser sur un outil donc Amazon Web Services d'un point de vue développement a standardisé sur Kiro qui est notre IDE et Kiro CLI derrière une grande partie soit sur nos modèles soit sur... Ils utilisent beaucoup de Claude Sonnet et de Claude Opus. Mais en disant, voilà, on a aussi cette manière de faire. Encore une fois, on laisse la possibilité aux équipes de faire différemment si elles ont envie. On a des équipes qui développent de l'assembleur. Ils n'ont pas besoin d'avoir un super IDE. Ils ont besoin d'avoir des choses très très très précises. Mais par contre, on dit, voilà, le chemin par défaut. Maintenant, c'est ça. Vous pouvez faire différemment. Par contre, il va falloir expliquer pourquoi la différence doit être mise. Donc, on a vraiment ces éléments. À la fois, on met en lumière là où ça a marché. On a une vraie communauté d'adoption. et sur certains éléments on fait quand même du top down parce que c'est nécessaire.
Bruno:
C'est mettre à disposition le meilleur des outils.
Julien:
Possibles à.
Bruno:
Vos équipes de dev pour que personne n'ait envie d'aller parce qu'en fait tu peux pas trouver mieux ailleurs.
Julien:
Voilà et puis surtout je vais pas dire que Kiro c'est l'IDE qui va révolutionner tous les IDE j'en sais rien, je trouve que Kiro est très très bien avec Sassi et là et maintenant on a des interfaces web et on a un IDE aussi donc c'est vrai que c'est une chaîne complète qui vient s'intégrer aux différents points d'intégration du développeur et puis avec les.
Bruno:
Agents que vous venez de lancer en plus ça ajoute des.
Julien:
Expertises dès qu'on a des agents, dès qu'on a des expertises qui viennent, ça vient en plus on a des skills, on a des powers donc il y a l'équivalent du skill d'un cloud code par exemple, donc tous ces éléments on vient le faire par contre, ce qu'on sait c'est que si on met 30 000 développeurs en interne dessus on va avoir une communauté hyper exigeante qui va nous fournir énormément de feedback et qui va partager les bonnes pratiques et je pense que c'est vraiment un des points et on l'a vu sur plusieurs podcasts que tu as déjà sortis, cette communauté de pratiques, cette adaptation à un contexte spécifique, dans mon cas Amazon mais ça peut être d'autres entreprises, c'est là où on va vraiment avoir une valeur c'est quoi mes architecture decision records mes ADR, qu'est-ce que j'ai fait comment je fais une fois qu'on l'a mis en place, parce que finalement on a une personne qui l'a mis, qui l'a développé qui s'est amusé à faire un markdown c'est tout le reste de mon entreprise qui va le faire donc l'effet masse de l'adoption c'est plus finalement que, juste de la productivité, on crée un cercle vertueux, finalement, entre les différentes équipes.
Bruno:
Sur cette philosophie des bonnes pratiques, tu vois l'exemple que tu as donné avec cette réécriture de Bedrocks, grosso modo, vous l'avez fait quoi ? A peu près, c'est 80 fois moins de temps, si on fait le ratio entre la réduction de la taille d'équipe et le nombre de personnes. Il y a une question que je suis en train de me poser assez fortement, c'est que pendant longtemps, on a mis en place un ensemble de best practices sur la meilleure manière d'écrire du code. Parce qu'en fait, je suis convaincu qu'écrire du code qui fonctionne, c'est facile. Écrire du code qui fonctionne pendant longtemps, c'est beaucoup plus dur. Et qu'en fait on avait besoin d'avoir du code qui fonctionne pendant longtemps parce que, depuis des années écrire du code c'est long c'est fastidieux et ça coûte cher parce qu'on demande à des ingénieurs qui sont payés quand même des salaires plutôt intéressants d'aller avec leur petite mimine taper caractère après caractère.
Julien:
Ou copier-coller c'est ta cover.
Bruno:
Flow tu vois effectivement tu avais besoin d'avoir du code qui fonctionne pendant longtemps qui soit maintenable facilement pour que tu aies le moins besoin de revenir dessus mais là on rentre dans une époque où on peut littéralement chier 100 000 lignes de code, par jour, et donc en fait la notion de, tu vois, la valeur de la ligne de code en tant que telle est moins importante, mais du coup je me demande aussi, est-ce qu'on a encore besoin de toutes ces best practices, parce qu'au final si tu chip en pro d'un truc qui marche pas, au final en quelques jours voire quelques semaines pour des plus gros projets comme Bedrock, tu peux, entièrement tout réécrire s'il faut donc tu vois, est-ce qu'on a encore besoin d'injecter dans nos systèmes d'IA, cette notion de best practice et de qualité de code, alors qu'en fait, on pourrait se dire, en fait, je peux entre guillemets, régénérer ma code base tous les matins.
Julien:
Alors, on a parlé tout à l'heure du Well-Architected Framework, la possibilité d'avoir des applications qui sont justement bien architecturées. On a plusieurs piliers, donc il est effectivement très simple de pondre énormément de lignes de code. Par contre, les rendre sécurisés, les rendre cost-effectifs, les rendre maintenables quand même, même dans le contexte d'agents, on voit qu'il y a plein d'agents actuellement, je pense que ça changera, mais qui sont capables de générer énormément de codes, par contre quand on leur demande de recomprendre le code qu'ils ont généré pour faire des mises à jour, le contexte devient un petit peu trop gros et on voit qu'effectivement il galère donc ces principes là. Finalement on les avait parce que notre contrainte centrale c'était les humains mais les bonnes pratiques qui viennent derrière ça reste quand même des bonnes pratiques ne pas surconsommer, j'ai adoré, j'ai eu la chance d'être déjà chez Amazon Web Services quand on a lancé AWS Lambda pour ceux qui ne connaissent pas AWS Lambda c'est le serverless, le premier service serverless qui a existé, je peux écrire un bout de notre JS, je le déploie et ça va rien me coûter. Littéralement rien. Pas un centime tant qu'il n'est pas exécuté. Et quand il va être exécuté, je vais être facturé à la millisecondes. Moi, j'ai été responsable d'équipe de dev avant. Et on me demandait bien entendu toujours de faire plus vite et moins cher. C'est normal si on n'est pas responsable d'équipe de dev. Et en fait, la seule chose que je pouvais faire, c'était payer moins cher mes devs. Parce que, en tant que responsable d'équipe de dev, je ne pouvais pas faire grand-chose. Là, avec des plateformes comme Lambda, si j'arrive à diviser par deux le temps d'exécution de mon algorithme, en fait je vais littéralement payer deux fois moins cher sur ma plateforme et donc je pense que je vais reciter Kent Beck, Kent Beck pour ceux qui ne le connaissent pas c'est un développeur. Extraordinaire qui est un des co-signataires il y a 25 ans du Manifest Agile et ils ont utilisé beaucoup de ses expériences justement de développeur et le fait que le contexte soit long quand il a finalement pris le virage de la gentil en début de 2025. Il a dit 99% de ma valeur est devenue inutile par contre le pourcent restant a fait je crois x 1000 et en fait c'est vraiment ça c'est de se dire, la capacité à générer et à avoir du code spécifique c'est peut-être le mon... Ça reste important, il faut le comprendre et je reste persuadé qu'il faut avoir une vraie compréhension du code même s'il est généré par des IA par contre il dit sa compréhension du contexte sa compréhension des raisons pour lesquelles les choix sont faits l'architecture et le développement c'est des arbitrages, Au quotidien. Et donc voilà, cette valeur-là, il dit, ça a pris une valeur énorme, finalement, beaucoup plus que sa capacité à écrire. Donc, il faut le penser différemment.
Bruno:
Je ne sais pas si tu as vu, parce que c'était la semaine dernière, et je crois que la semaine dernière tu étais un peu occupé avec le summit, mais j'ai vu passer quelques actus avec des gens qui se disent que comme justement aujourd'hui on a du code qui est généré par des IA et surtout relu par des IA, c'est surtout des IA qui bossent dessus, qui essaient de créer des langages de programmation, pour les IA qui ne prennent pas en compte le besoin de lisibilité par un être humain avec son cerveau limité. Et de l'autre côté du spectre, je retiens très mal les noms, mais le créateur de Swift qui lui au contraire est aussi en train de créer l'ancien projet Mojo qui est aussi un langage, mais lui au contraire, il insiste sur le fait qu'il faut un langage qui reste lisible par des humains. Et du coup, il est en train, avec le projet Mojo, de lancer un langage qui est spécifiquement conçu pour cette ère dans laquelle on est en train de rentrer.
Julien:
L'ère de l'IA.
Bruno:
L'ère de l'IA, effectivement, avoir du code qui soit et lisible par les humains et par les IA et qui soit du coup très adapté à cette interaction qu'on a avec les outils. Je ne sais pas quelle est ta vision de ces projets-là.
Julien:
Alors ma grande question, c'est la responsabilité. qui va prendre la responsabilité si un jour quelque chose ne va pas bien il se trouve, alors je vais citer il y a un même sur Twitter sur tous les réseaux sociaux on voit. Une diapositive un transparent, parce qu'à l'époque c'était des transparents et pas des diapositives où on fait un ordinateur ne peut pas prendre de responsabilité sur ses tâches donc jamais un ordinateur ne devrait être en position de management, et en fait on en revient un petit peu au même élément c'est à dire on peut avoir des IA qui vont générer des choses absolument exceptionnelles le jour où ça va pas et même avec l'IA, il y a un jour où ça va pas aller il y a un jour où... Je vais reciter Werner Vogel, le CTO d'Amazon Everything fails all the time, donc tout plante à un moment ou à donner à un moment ou à un autre, alors Werner a souvent la fin donc planifier pour les erreurs et comme ça rien ne va tomber en panne il faut planifier pour, En fait, à un moment, il y a quelque chose qui ne va pas, il y a un humain qui va devoir regarder, qui va reprendre la responsabilité. Si on n'est pas capable de comprendre pourquoi quelque chose ne fonctionne pas, on ne va pas être capable de prendre la responsabilité de ce système-là. Donc, voilà, on ne parle plus binaire, on a eu la question avant, on ne parle plus binaire, on parle très peu assembleur, il y en a encore qui parlent assembleur, enfin, on ne parle pas, c'est qu'ils l'écrivent et qu'ils le lisent. Donc oui, c'est une nouvelle couche qui va arriver. par contre avoir cette capacité à comprendre ce qui se passe si on est effectivement sur une matérialisation du code qui est complètement incompréhensible pour les humains, bon après si on a fait du Perl, si on a fait du Erlang ou des choses comme ça, on peut se dire que déjà on a des systèmes qui sont absolument illisibles par les humains mais il y a au moins quelqu'un quelque part dans la chaîne qui est capable de comprendre ce qui se passe et pour moi c'est peut-être ma limite c'est la chaîne de responsabilité et puis après j'aime bien le code aussi.
Bruno:
C'est.
Julien:
Peut-être un biais personnel.
Bruno:
Mais tu vois si on reprend votre projet Bedrock qui s'est fait en quelques mois. Est-ce que vous savez quelle est la proportion du code qui a été généré, qui a été effectivement relu par un être humain ?
Julien:
Alors, ils ont relu, je ne sais pas s'ils ont tout relu, mais ils ont relu une grande majorité. L'intégralité du code a été générée par l'IA.
Bruno:
Parce qu'en fait tu parles de ce sujet de prise de responsabilité qu'à un moment il faut que l'humain sache ce qui est fait pour qu'il puisse assumer le truc, est-ce qu'il y a quand même un moment où vous vous dites on va effectivement littéralement te chier des lignes de code et on sera pas capable de tout relire parce que le volume de lignes de code qui est généré, est humainement impossible à appréhender enfin là on parle de PR déjà on le sait en tant que dev quand tu reçois une PR qui fait plusieurs centaines de lignes et là tu fais ça commence à chauffer alors là du coup que c'est un système comme Bedrock on imagine que c'est...
Julien:
Ça peut être des PR sur des dizaines de fichiers qui vont toucher des fonctions différentes effectivement c'est très très dur à relire et alors en fait j'ai pas la réponse, et c'est une des grandes questions qu'on se pose actuellement en interne et avec nos clients là on pense à la PR et on se dit bon bah si j'ai 10 fois plus la question c'est mais si on avait 1000 fois plus en fait on en parle, c'est plus facile de commencer à développer une application, une nouvelle application un nouveau service, de générer beaucoup plus de code et donc en fait les systèmes tels qu'ils sont actuellement, ils ne sont pas prêts pour gérer mille fois plus de code que ce qu'on est capable de générer actuellement donc il va y avoir une phase où effectivement les outils DIA vont venir aider on parlait de la sécurité, on parlait de ces choses là où il y a énormément de bonnes pratiques qui peuvent venir tester qui peuvent même attaquer très spécifiques mais en code. Après, est-ce que tout doit être relu par un humain ? J'ai envie de dire, est-ce qu'on relisait déjà l'ensemble des pillards de manière très très bien à l'époque où c'était fait à la main ? J'ai pas la garantie que tout ait été bien bien relu, on l'a vu, mais par contre il y a des challenges absolument importants qui sont en train d'arriver, on le voit sur le domaine de la sécurité, avec une explosion des attaques de type 0D, le jour même ou 1D, le jour même de la sortie en moins d'une demi-heure, on a une vectorisation des attaques qui sont en cours où en fait... On voit le risque de mettre de l'IA dans une chaîne de développement, parce qu'effectivement, on peut avoir une perte de contrôle, mais après, il faut aussi voir l'intérêt de mettre de l'IA. Et on dit, avant, il fallait, dans le monde bancaire, il ne fallait pas trop bouger pour être sécurisé. Maintenant, il faut absolument bouger vite pour avoir la capacité à rester sécurisé. Donc, je pense qu'on va trouver un équilibre. Il va y avoir quelques erreurs, il va y avoir quelques accidents, je pense, sur le chemin. Mais nous, on a des fondamentaux. Sur Bedrock, on a des fondamentaux. Et après, on va investir sur d'autres éléments. Je parlais de DynamoDB, qui est un des services que j'ai eu la chance de présenter au Paris Summit. DynamoDB, on a investi sur de la modélisation formelle. donc en fait il y a un ensemble de services ou même plus que lire le système ou le code spécifiquement pour s'assurer que ça va bien, on va utiliser d'autres codes en l'occurrence on utilise du TLA+, qui est un langage de programmation dédié à la modélisation formelle du code, qui permet de décrire tous les états dans lesquels un système doit être. Toutes les transitions d'état qui peuvent arriver dans un système, et on va garantir des invariants genre je prends DynamoDB, mes données doivent être stockées sur trois zones de disponibilité, voyez-le comme un peu trois data centers. Ensemble c'est des grappes de data centers différents, et en fait on va garantir par la modélisation que cet invariant il est toujours là. Et donc on va même utiliser l'IA pour nous faire ça et valider par de l'analyse statique et de l'analyse dynamique de code, qu'effectivement on va pouvoir le faire. Donc, Je pense qu'on va trouver des nouveaux systèmes et des nouveaux éléments qui vont nous permettre, sans nécessairement aller jusqu'à lire la ligne de code, et toutes les lignes de code, garantir finalement par d'autres méthodes la fonctionnalité que l'on doit avoir. Donc du test, des choses comme ça.
Bruno:
Mais est-ce que cette formalisation que vous avez, qui vous permet de garantir une fiabilité de votre code, elle n'est pas... Parce que ce qui est intéressant avec les IA, c'est qu'effectivement, tu as un effet d'échelle, mais tu as aussi une capacité, une prise en compte de contexte et de connaissances qui est disproportionnée par rapport à ce qu'un être humain est capable de faire. Et qu'au final, toute cette formalisation que vous mettez en place, elle est contrainte par nos petits cerveaux d'être humains. Et du coup, elle peut, entre guillemets, du coup, limiter la capacité d'une IA à, en fait, faire popper une solution qui serait peut-être plus intéressante, non ?
Julien:
Peut-être, mais nous, on a choisi un modèle organisationnel sur lequel, par design, on va limiter la surcharge cognitive qui est associée à l'opération d'un système. Et ça, ça fait depuis très très très longtemps. On a commencé, comme toutes les entreprises, Amazon avait un monolithe. On lui avait même donné un joli nom, il s'appelait Obidos. Obidos, c'est le point le plus large où tous les affluents du fleuve Amazon arrivent. Et en fait il se trouve que ce système là il mettait plus de 24 heures à builder, et c'est le moment où on a dit c'est pas possible chaque commit qui prend plus de 24 heures à builder ça arrive pas et donc nous on a décidé organisationnellement de se dire on peut pas se faire confiance sur le fait d'avoir des code base qui vont être gérables donc on va structurellement, séparer les code base par équipe avec des mandats forts en disant les interfaces entre les différentes équipes doivent être par contrat le contrat doit être stable, il doit être documenté Et donc ça, on l'a forcé il y a 20 ans maintenant, plus de 20 ans même maintenant. Et ça nous permet finalement de limiter la surcharge cognitive qui est associée avec l'opération d'un contexte, parce qu'on sait que nos services, ils sont assez micro-services. Il y en a qui sont assez gros, on ne fait pas non plus du micro-découpage juste pour le fun, mais ils vont tous être dans un contexte et un domaine métier différent. On va avoir des tests qui vont être mis en place dessus. Donc en fait, on a déjà organisationnellement finalement mis ces bulles qui fait qu'on a pas. De systèmes où on va pondre des centaines de milliers ou des millions de lignes de code qui vont être un spaghetti indéchiffrable. On a déjà ces contraintes-là, on a déjà ces API-là, et on a la chance chez AWS de travailler avec des clients. Et dès que vous voulez avoir un truc qui est de l'entropie et qui ne puisse plus bouger, mettez-le à disposition d'un client. Parce que maintenant, c'est plus nous en interne qui avons la capacité de bouger. Amazon S3 a 20 ans. S3, les API d'il y a 20 ans, c'était un HTTP put, un HTTP get. 20 ans plus tard, c'est HTTP boot et HTTP get on ne pourra pas le changer parce qu'en fait on a ses aimants, par contre on a mis en place les bonnes pratiques qui disent que S3 on peut le changer complètement, et on l'a changé complètement plein plein plein plein de fois pour nos clients c'est absolument transparent et donc là on va pouvoir laisser typiquement des IA créer, innover et changer sur un environnement qui est un environnement contraint, et donc là effectivement on peut leur laisser beaucoup plus de liberté et avec les outils de modélisation formelle on va garantir que le système à la fin, et là pour le coup on le garantit, et les IA sont absolument géniales on peut leur donner une modélisation formelle leur dire analyse mon code et voir si mon code est en train de dévier de ma modélisation formelle parce que les problèmes qu'on a tout le temps c'est comme avec la documentation quand on commence un projet, on fait de la doc, elle est super puis 4 ans plus tard, on ne l'a pas mise à jour et on est toujours en train de parler de classe qu'on avait fait au jour 1 c'est la même chose avec les modélisations et l'IA va vraiment nous aider finalement plutôt que de répondre et nous donner la réponse on va lui poser des questions « Tiens, mais en fait, j'ai ce modèle-là, j'ai ce code-là, est-ce que ça diverge ? » Et là, l'IA est super forte pour dire « Ah oui, j'ai trouvé ça et ça comme divergence, va regarder ce qui se passe. » Donc on peut vraiment travailler ensemble et pas juste tout déléguer aveuglément.
Bruno:
— Ouais, je vois. Sur le sujet de la responsabilité... Il y a aussi des discussions en cours sur est-ce qu'on peut considérer les LLM comme des compilateurs, au final. Et qu'en fait, on considère que le langage naturel devient une nouvelle abstraction supplémentaire.
Julien:
La réponse à tous les problèmes en informatique, c'est d'ajouter une couche de tasse. En général. C'est un peu la base.
Bruno:
Mais tu vois, si on revient sur cette notion de responsabilité, aujourd'hui, personne ne va aller faire une review du code compilé. Quand tu fais ton programme en C, en Rust, en ce que tu veux, tu ne vas pas aller regarder ce que ton compilateur fait derrière.
Julien:
Certains vont le faire, pas beaucoup vont le faire mais certains vont le faire, mais non effectivement la vaste majorité, 99,999% des gens non on regarde pas la sortie du compilateur.
Bruno:
On délègue complètement cette responsabilité là en disant on part du principe que ce que j'ai énoncé comme principe est respecté par du coup ce qui va tourner en prod mais.
Julien:
Le compilateur est déterministe et c'est là une des vrais un des vrais.
Bruno:
Ton LLM peut être déterministe, tu mets une température à zéro un même input te mettra quoi qu'il arrive.
Julien:
Oui mais avoir un LLM et avoir des agents sur lesquels on les rend 100% déterministes on les a quand même hyper bridés parce que justement un des éléments intéressants c'est la capacité à prendre plusieurs contextes et avoir des éléments si on met une température à zéro le LLM finalement, il n'a que la capacité à ressortir ce qui a été dans son modèle d'entraînement au départ donc finalement, on revient de manière améliorée on revient quasiment sur de la complétion de code c'est à dire si le bloc de code tel qu'il est n'existait pas quelque part dans un modèle d'entraînement, la partie générative va quasiment disparaître. Il faut leur laisser, et je pense que c'est justement un des grands éléments, leur laisser cette capacité à créer, à mixer, à recréer quelque chose qui vient de plusieurs sources pour créer cette sortie. Si on les enlève, c'est un petit peu gênant. Par contre, je vois vraiment deux éléments. Il y a la partie, j'utilise un LLM pour générer du code, mais du coup, mon code, lui, il sera déterministe. Donc, ça, on a la possibilité de le revoir et tout ça. Après, on a aussi toute une deuxième pratique qui est, je mets un LLM au sein de mon application. Et donc le comportement même de mon application ne dépend plus du code que je génère mais dépend de la réponse du LLM au moment où je vais l'avoir et ça on le voit dans beaucoup d'applications métiers sur de l'intégration et des choses comme ça. C'est deux problèmes similaires finalement où on a du LLM et on a du code sauf que l'impact et le résultat sont complètement différents on se focalise en tant que développeur beaucoup sur le premier comment j'utilise des LLM pour générer du code, c'est très intéressant, c'est très important c'est un élément sur lequel on va avoir des changements dans les années qui viennent, parce que les LLM continuent à croître de manière exponentielle en capacité. Il faut aussi se poser la question du deuxième, parce que la question du deuxième, moi je trouve ça hyper intéressant, je ne suis plus tout jeune, malheureusement. Avant, on avait des applications transactionnelles, puis on avait une plateforme de données qui allait faire du change data capture, ou des éléments qui prenaient ces données opérationnelles, aller les mettre dans un dataware. Ça c'est pour ceux qui ont quelques années de pratique, maintenant dans un data lake, on a même le data ocean maintenant, qui est encore plus joli. Et après, on avait des plateformes analytiques qui allaient montrer des graphes et des choses comme ça à des humains et les humains allaient prendre ces décisions pour aller vers la plateforme transactionnelle et refaire le changement en disant ah bah tiens j'ai vendu plus que ça, je vais monter le prix, je vais baisser le prix, je vais changer, je vais en recommander. Maintenant ce qu'on voit avec les agents c'est qu'en fait on a des agents qui vont prendre ces données de la partie opérationnelle et analytique finalement et vont faire des décisions pour aller parler à mes systèmes transactionnels. Sauf que ces agents là potentiellement. Ils n'ont pas une température à zéro. Et c'est ce qu'on veut, parce que sinon, c'est un workflow glorifié. On revient il y a 20 ans avec des systèmes de workflow, ça marchait très bien. Mais ce qu'on voyait avec les systèmes de workflow, c'est qu'à chaque fois qu'on avait un changement dans notre process métier, on devait redévelopper tous les workflows. Et donc, l'outil de workflow qui était génial, parce qu'il nous permettait de simplifier la code base, devenait notre boule de blocage au milieu, ça devenait notre goulot d'étranglement. Là où les agents, finalement viennent simplifier ça. Mais du coup, eux, ils vont agir de manière probablement non déterministe au sein d'un système d'entreprise. Et ça, c'est un nouveau domaine dans lequel il faut aussi qu'on ait cette capacité à comprendre quel va être l'impact et comment on va travailler dessus.
Bruno:
Mais du coup, si je reprends le même que tu évoquais tout à l'heure sur la capacité de décision, au final aujourd'hui, on a des agents qui ont une capacité de décision, et qui donc, en soi, peuvent assumer une « responsabilité ».
Julien:
Alors, chez nous, il nous est arrivé effectivement d'avoir un impact négatif d'une action faite par un agent notre position est très simple c'est pas la responsabilité de l'agent c'est la responsabilité de la personne qui opère l'agent, et chez Amazon on a vraiment une culture du blameless post-mortem, donc c'est pas la faute de la personne, c'est la faute d'un système donc quand quelqu'un fait quelque chose, qui est à l'encontre de l'entreprise c'est assez rare, et on le voit dans les équipes, d'avoir quelqu'un qui se lève le matin et qui dit aujourd'hui je vais tout péter, Et rarement on le fait, souvent on se dit bon je vais essayer de faire un bon boulot. Sauf que ça c'est ce qu'on appelle des bonnes intentions. Et des bonnes intentions, on se lève tous le matin avec plein de bonnes intentions, je me suis encore levé avec plein de bonnes intentions ce matin, que je vais pas réussir à tenir pendant toute la journée. Et donc nous notre question c'est s'il y a quelque chose qui se passe mal quel est le système ou quelles sont les pratiques qui nous ont amené finalement à faire ce choix. Et donc on essaye de voir quels sont les systèmes et les technologies qu'on peut mettre en place il y a eu un événement pour ceux qui lisent les réseaux sociaux et qui sont connectés sur internet il y a eu un événement sur un système Amazon, Amazon le vendeur en livre de vendeur de, initialement de livre le vendeur d'à peu près tout maintenant sur la planète en ligne et donc ils disent ils se disent, ah là là, il y a eu une réunion, et il y a quelqu'un de chez Amazon qui a fait une grande réunion parce qu'il y a un système qui est tombé pendant quelques heures. Effectivement, il y a eu un problème. Il se trouve qu'effectivement, il y a un agent, mais en fait, l'agent, il avait trop de droits. L'agent, il avait le droit de faire des choses et des choix sur des systèmes qu'il n'aurait pas dû avoir accès. Et donc, la question qu'a posée le VP, Dave, de son prénom, c'était pas, bon ben on arrête tout. C'était, mais qu'est-ce qui nous a amené là ? Quels sont les garde-fous qu'on doit mettre en place pour s'assurer que ça ne revienne plus ? Et en fait, il se trouve que ces garde-fous, on avait déjà ces problèmes-là avec des humains. Donc en fait, on a remis des bonnes pratiques, genre, quand on fait un changement qui peut être impactant sur la prod, ça peut être proposé par un agent ou par un humain, ça doit être revu par quelqu'un avant de pouvoir avoir un impact potentiellement néfaste sur la prod. Donc en fait, on revient sur ces éléments. le côté mécanisme qui est un terme très Amazon systémique est vraiment un élément important pour nous.
Bruno:
Donc en fait dans cette expérience que tu décris on retrouve un peu ce que disait le CEO de Nvidia encore une fois je ne suis pas bon avec les noms Jensen, qui disait que l'avenir du métier de développeur ou de développeuse c'est d'être un RH d'agent, on est juste un gestionnaire mais au final on revient à cette idée de dans ce que tu évoques c'est que un agent qui prend une décision, il faut qu'elle soit validée par quelqu'un dans un certain type de décision.
Julien:
Ou qu'elle soit dans un scope qui soit suffisamment contraint pour qu'il peut prendre la décision A ou la décision B. Mais dans ce cas-là, on accepte et on limite. Ce qu'on ne veut pas, c'est qu'il prenne la décision C. C'est tout pourri, je vais tout effacer.
Bruno:
Ce qui est intéressant, c'est que ta phrase, c'était que tu as des contextes de décision où s'il y a une décision qui est prise, et ta phrase était qu'elle soit prise par un agent ou par un humain, il faut que la décision soit validée. Tu as un process de décision. Et donc, en fait, tu mets la décision de l'humain et de l'agent à peu près au même niveau en disant, quoi qu'il arrive, vu le contexte. Donc, en fait, tu rentres dans ce process un peu orienté RH où tu te dis, en fait, j'ai des humains, j'ai des agents qui collaborent un peu ensemble et qui sont soumis au même fonctionnement.
Julien:
Absolument. Il faut pouvoir contrôler la décision. Il faut pouvoir l'auditer. En plus, on voit l'IA en rentrée dans plein de domaines, mais de manière assez intéressante, les domaines à forte réglementation, on peut penser au domaine de la santé, on peut penser à certains domaines de la défense, ou toute la partie juridique. Ce sont en fait des domaines sur lesquels on peut adopter assez facilement l'IA. Pour deux raisons principales, la première c'est qu'on a déjà fait une classification des données. Quand on voit toutes les entreprises de commerce et choses comme ça, ils n'ont pas trop de classification des données. Ça peut être un problème parfois avec le RGPD. Mais quand on est dans des environnements qui sont des environnements à forte réglementation, en fait, ils ont dû déjà avoir un DPO qui ait une vraie classification des données, une gestion des applications. Donc ça, ça permet assez facilement de dire, ces données-là, je peux les donner à un agent parce que je suis dans un domaine de risque qui est limité. Celle-là, non, surtout, je ne vais pas y toucher parce que j'ai envie de pouvoir les contrôler. Et deuxième, ils ont toute une chaîne d'auditabilité. Donc quand il y a une décision qui est prise, si on est dans le domaine de la santé par exemple. La santé est assez rigolo, enfin rigolote, je ne sais pas si c'est rigolo, mais quand on fait une analyse biologique par exemple sur la santé, on doit être capable de la reproduire sur une durée, qui peut parfois aller jusqu'à 30 ans. Mais pouvoir la reproduire, ça veut dire qu'on a la possibilité d'avoir toute la démarche qui reste là, mais on va aussi avoir les équipements qui sont les mêmes, qui nous permettent de le faire pour vraiment pouvoir faire ça. Et donc, quand ils arrivent et qu'ils disent, moi, j'ai un agent qui va faire ça, en fait, ils documentent exactement, ils ont l'observabilité de tout le processus de décision de l'agent, et comme ça, ils sont capables de dire voilà exactement pourquoi la décision a été faite. Donc, plutôt que de contrôler l'agent, ils vont contrôler le processus des décisions et les décisions qui sont faites par l'agent, et ça, on a des systèmes potentiellement déterministes. Amazon, sur Bedrock, on a du raisonnement automatisé, qui permet, en fait, justement, d'écrire un cadre et de dire toutes les décisions qui sont faites par un agent qui utilise Amazon Bedrock on va le faire passer par ce crible et ce crible il est déterministe lui par contre il est mathématiquement prouvé comme étant fiable et donc on peut dire l'agent t'as le droit de faire ça dans tout ton contexte par contre je te rassure on va avoir une checklist derrière qui valide que tu ne restes que dans le domaine que nous t'avons, défini donc on peut faire les deux mais c'est des domaines qui sont encore assez naissants.
Bruno:
Pour terminer, qu'est-ce que tu vois comme changement en cours ou à venir sur le métier de développeur en tant que contributeur individuel, mais aussi sur l'organisation des équipes, parce que forcément, si on ne fait pas le même métier, on ne peut pas travailler de la même façon. Qu'est-ce que tu vois comme changements qui sont déjà en place et qui vont peut-être aussi s'accélérer ?
Julien:
Déjà en place, je vois un changement fondamental au niveau des PM, PO, Scrum Master et autres. Donc toutes les fonctions qui sont des fonctions tech adjacentes, alors qui sont tech, mais qui sont souvent un peu moins dans la production directe de code, on leur donne des super pouvoirs. Toutes ces fonctions-là, avant elles devaient écrire des specs, qui étaient rarement nécessairement super bien lues par les développeurs. Là maintenant, on leur donne la possibilité très rapidement justement d'utiliser le côté génératif et le côté créatif pour générer des protos, pour générer des tests, pour générer des choses comme ça. Après on va toujours avoir besoin des développeurs pour l'intégration, la sécurité la mise en place dans un système et des choses comme ça donc déjà ce qu'on voit c'est que on a cassé d'un certain côté les barrières de communication qui venaient autour des équipes où au lieu de faire avec 14 tickets JIR1 ou 12 entrées confluence, on a la possibilité de dire tiens regarde j'ai une démo je vois que ça pourrait marcher comme ça qu'est-ce que t'en penses et on a une base d'itération commune, pour les développeurs plus spécifiquement des équipes plus petites ça c'est vraiment un élément qu'on voit où en fait la vélocité est telle maintenant que. Les cérémonies qu'on pouvait avoir autour du Scrum ou du Safe avec des meetings quotidiens en fait en 24h on peut avoir énormément avancé donc on a des clients qui utilisent on a une méthode fournie par Amazon qui s'appelle la AI DLC Artificial Intelligence Development Lifecycle qui se dit les sprints au lieu d'avoir des sprints, il y a plein qui font des sprints de 2 ou 3 semaines, les sprints on peut en faire plusieurs par jour, et donc ça change un petit peu il faut changer la manière de communiquer sauf que si j'attends d'avoir une grosse cérémonie 3 fois par jour, je ne suis plus du tout productif je passe mon temps en meeting et je n'avance pas du tout et donc on voit souvent des équipes plus petites, avec des contextes qui sont un peu plus contraints et qui du coup vont avoir une communication plus efficace donc pareil ça un grand changement, une vélocité différente j'en parlais tout à l'heure se poser la question, qu'est-ce que ça veut dire si on fait 1000 fois plus de code en fait je pense que c'est peut-être l'élément, on fait déjà 100 fois plus de code qu'on faisait il y a 20 ans. Mais là si on refait un fois 1000 qu'est-ce que ça veut dire donc beaucoup de questions sur les topologies d'équipe, comment on va les faire travailler comment on les fait avancer et moi ce que, mon côté personnel mais du coup ça force les développeurs à avoir un petit peu plus d'empathie et un petit peu plus de compréhension du contexte on peut plus en tant que dev dans un environnement IA qui va aussi vite se dire ah ouais mais non mais c'était pas dans les specs, ça c'est pas possible, c'est pas quelque chose qui est acceptable et donc on doit vraiment avoir des développeurs qui vont plus près des PIO qui vont plus près du métier pour comprendre les nuances et le pourquoi ils vont le faire le risque si on le fait pas c'est que maintenant eux ils ont la capacité à le faire je reste persuadé qu'ils le feront moins bien on a vécu tous la révolution Excel, Powerpoint, enfin Excel et Access Microsoft Access, génial tout le monde avait développé ses applications en fait on est revenu quand même sur des standards de développement parce que effectivement en entreprise on a besoin d'avoir un contexte général et une connaissance générale et de l'ingénierie. Et donc voilà, si on a ça, les devs, enfin les pas devs justement, les métiers, ils vont aller faire du shadow IA. Et ça, on le voit déjà en entreprise. Donc comment on les aide sans nécessairement les brider ? Parce que ce qu'on ne veut pas, c'est avoir l'IT qui vient et qui dit, non mais moi j'ai raison, je sais ce que je fais, toi t'as tort et tu ne comprends pas. Parce qu'ils disent, ben non, je comprends très bien, mon fils il fait ça. Donc hop, ils y vont. D'ailleurs, on va travailler avec, je pense que c'est un des gros évanguels. Donc pour moi, c'est empathie, contexte, compréhension qui sont vraiment les vecteurs clés du futur du développeur, finalement.
Bruno:
Tu vois aussi la frontière entre les métiers tech et les métiers tech adjacent, comme tu dis, se disparaître.
Julien:
On a des gens du data center qui maintenant... Avant le DevOps, il fallait apprendre à développer. Maintenant, le DevOps, il faut apprendre à parler à l'élève. Mais même moi, quand j'ai des trucs à faire, des analyses de données, je me retrouve encore à ouvrir un VS Code pour dire tiens je vais me faire un petit truc en TypeScript ou en Python et en fait je l'ouvre et au bout de 4 secondes je fais mais c'est n'importe quoi arrête ça Julien, je prends ma CLI et puis je pose une question à Kiro et puis Kiro soit il me le fait directement soit il m'a généré le code et en 2 minutes je le regarde, je suis responsable, je regarde mon code, je regarde et en fait en 2 minutes il m'a fait une analyse croisée sur 14 sources de données et pouf ça marche et ça, je l'aurais fait je suis dev, ça fait plus de 20 ans que je suis développeur professionnel et tu.
Bruno:
L'aurais fait en 2 jours là où c'est fait en 2 minutes.
Julien:
Maintenant ça prend deux minutes, c'est juste génial.
Bruno:
Non j'avoue, c'est vrai qu'il y a un changement dans la manière de travail qui est assez fou. Juste que tu parles de réduction d'équipe, Est-ce que ce n'est pas aussi parce qu'on continue à appliquer, tu l'as évoqué tout à l'heure, ces méthodes agiles qui datent de 2001, qui sont liées à un contexte de production de code particulier, et qu'on est encore en train d'essayer de maintenir un peu ces best practices, et que donc ça nous oblige effectivement à réduire les équipes, à réduire le temps, parce qu'en fait la rapidité de création de code est complètement disproportionnée, et qu'en fait on va peut-être avoir un nouveau manifeste AIGIL je.
Julien:
Ne sais pas comment ça.
Bruno:
S'appellera qui va mettre en place des nouveaux types d'organisation je ne sais pas si vous avez déjà des choses en test chez Amazon.
Julien:
On a deux méthodes en test chez Amazon il y en a une qui s'appelle AI DLC qui reprend un peu le principe de Scrum sauf que d'avoir des sprints on a des Bolt qui sont une version accélérée du sprint, on a un raccourcissement de beaucoup de process autour de la définition et la gestion la récupération des besoins et choses comme ça où en fait on utilise l'agent un peu comme sparring partner, donc en fait il vient nous poser des questions et on va aller raffiner les différents éléments sur les besoins fonctionnels les besoins non fonctionnels, toute la partie design, donc en fait on a. Raccourci tous ces éléments là un des gros, alors deux éléments le premier c'est, on a quand même une limite qui est la taille de contexte, à la fois humain et machine, quand on commence à avoir des applications qui sont trop grosses, qui font trop de choses on voit que actuellement les LLM ils ont tendance à halluciner des choses pas très très bien, effectivement on va faire des erreurs donc là on voit un vrai mouvement de fond sur, on doit avoir des specs ou quelque chose comme ça, alors je me vois mal 25 ans après le manifeste agile, il faut faire des specs détaillés, non c'est fini mais effectivement en fait l'IA nous donne l'IA a complètement enlevé le besoin de rédiger des specs détaillés, parce que l'IA en fait elle va le générer pour nous et donc on est vraiment dans un dialogue sur la définition des besoins et l'analyse donc ça on voit vraiment un besoin hyper fort sur ces éléments là, Donc, EIDLC, en fait, touche un petit peu à tous ces éléments-là, de la partie récupération des besoins, design, développement, bien entendu, automatisé. Et maintenant, parce que le but, c'est d'avoir une flywheel, donc avoir un cercle vertueux qui vient reprendre les résultats de la prod. On a la même chose pour les product managers, justement, où on se leur pose la question, en fait, c'est quoi ton métier dans une RDA ? Et donc, on a des générateurs de démo, par exemple, où on leur pose trois promptes, un peu à la Lovable. Ils viennent générer des applis en vous alors Lovable fait des applis en prod ils sont capables de le faire très très bien mais voilà on va vraiment aider ces métiers là donc des méthodes on commence à en voir après. Le contexte humain il y a pas mal de discussions en ce moment sur Twitter aussi sur la charge cognitive et le risque de burn out il faut aussi le voir. Avant on a parlé dans la préparation de cet épisode on mettait 3h à corriger un bug à la fin des 3h, c'est bon j'ai fini et on s'arrêtait, là en fait l'agent il va corriger le bug en 4 minutes en ayant testé 4000 trucs différents, et en fait on se retrouve dans une position où on n'arrête jamais et il y a, un vrai risque, on a des clients qui ont adopté le EIDLC qui faisaient 3 volts par jour, et donc ça a avancé très bien, sauf qu'ils ont décidé sciemment de baisser leur productivité pour le bien-être de leur développeur en disant 3 c'est trop c'est une charge qui est trop importante, ils n'arrivent pas à processer le contexte, c'est une vraie fatigue c'est une fatigue dure, et donc voilà, avoir ces demandes et ça m'amène sur deux points. Les développeurs vont adorer, mais c'est un parallèle. Ce n'est pas nécessairement le cas. Mais on le voit beaucoup dans le monde du sport. Où en fait, il y a un mode de préparation et un mode de performance. Mais on l'a aussi dans plein de métiers, chez les pompiers, chez les pilotes, chez plein de choses comme ça. En fait, je pense que chez les développeurs aussi, il va falloir qu'on ait un élément où quand on est vraiment en phase de production intense, avec de la création, avec beaucoup de choses là, c'est un drain en termes d'énergie. Et donc avoir des temps de préparation et des temps d'action. Il y a plein de modèles qui existent. il y a un livre que j'aime beaucoup qui s'appelle Wiring the Winning Organization on donnera les références dans le podcast, qui explique justement ces différents modes mais d'un point de vue organisationnel comment on organise, une équipe pour avoir cette gestion de la performance comment on s'arrête, comment on pivote comment on accélère qui sont des éléments importants on découvre plein de choses, je pense que quelqu'un qui arrive maintenant et qui dit j'ai la réponse et la réponse c'est A.
Bruno:
Non c'est pas possible top merci beaucoup Julien pour 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 avec l'ensemble des auditeuristes.
Julien:
Alors j'ai fait un spoil du coup j'ai divulgâché un des livres c'est effectivement, Wiring the Winning Organization qui a été écrit par Jin Kim Jin Kim pour ceux qui ne le connaissent pas il a écrit une série de bouquins que j'adore le premier c'est The Unicorn Project, Il est sorti en 2012 et c'est une histoire sur comment le DevOps et l'Agile viennent se mettre en place dans une organisation. Pour pas spoiler, le livre commence, un nouveau DSI vient d'arriver, il est 5h du matin, son Pagerson, son entreprise est à la première page des journaux, ils ont eu un énorme plantage et il n'y a plus rien qui va. Le livre commence là-dessus et c'est une business novel, donc c'est pas une histoire complètement folle. Il a écrit ce bouquin-là, il a écrit plein d'autres bouquins, il a fait la suite qui s'appelle donc il y avait The Unicorn Project The Phoenix Project qui était le premier pardon le premier c'est The Phoenix Project il a sorti la suite qui est The Unicorn Project, spécialisé sur les développeurs même entreprise, même contexte par contre on suit le responsable des développements, super intéressant à voir, il a aussi écrit un bouquin qui s'appelle Accelerate avec Nicole Forcegren qui utilise les métriques d'Aura, qui introduit d'ailleurs les métriques d'Aura et il a écrit donc ce dernier ce dernier bouquin Wiring the Winning Organization et il vient de sortir un nouveau livre encore, il n'arrête pas, qui s'appelle Vibe Coding, extrêmement intéressant pour les développeurs. Si vous ne savez pas quoi faire, lisez les bouquins de Jim Kim, vous allez apprendre du Lean, vous allez apprendre du DevOps, vous allez apprendre plein de trucs super. Et le deuxième, parce qu'on a parlé de mécanisme, il y a un livre qui s'appelle, Atomic Habits, Radam Grant, qui est un professeur en psychologie. Et en fait, l'idée, alors le bouquin est génial et c'est pas du tout tech c'est pas du tout un livre tech mais c'est un, élément pour se dire quand on a des bonnes intentions et qu'on veut atteindre quelque chose en fait ça marche pas, et en fait on est aussi bon qu'on ne peut être aussi bon. Au niveau du système que l'on met en place. Et donc, en fait, il explique plein de techniques à mettre en place dans sa vie professionnelle, mais dans sa vie de tous les jours, pour atteindre ses objectifs. Et donc, comment en créer une habitude, comment en créer un nouveau comportement dans ses journées. Et il a plein de réflexions qui sont très intéressantes et qui vont au-delà du monde de la tech.
Bruno:
On mettra bien évidemment toutes les références en description de cet épisode. Et dernière question qui est la plus importante de ce podcast. Julien, est-ce que tu es plutôt espace ou tabulation ?
Julien:
Je l'ai redouté. Et en fait, j'ai le problème d'être polyglotte, j'ai travaillé sur plein de langages différents, et alors j'ai envie de dire, ça dépend de l'IDE du moment, et la plupart de mes IDE sont configurées en espace pas en table, mais j'ai commencé j'aurais toujours un amour invétéré pour Pascal, le langage, j'ai passé des centaines de milliers d'heures à faire du turbo Pascal et là j'étais effectivement en table j'ai quand même un petit attachement un peu aux deux mais par défaut, maintenant les IDE sont tous configurés en espace, finalement la question se pose plus trop.
Bruno:
Merci beaucoup Julien.
Julien:
Merci Bruno.
Bruno:
Et merci à tous d'avoir suivi cet épisode. Voilà, effectivement on a un métier qui se transforme. AWS, c'est intéressant d'avoir leur point de vue parce qu'ils contribuent aussi à ce changement. Je pense qu'il y a plein d'idées qu'a pu nous donner Junier qui sont hyper intéressantes. Effectivement, la frontière entre les métiers tech et tech adjacent se disparaît de plus en plus. Notre métier change et c'est plutôt une bonne nouvelle. Et je vous invite aussi à aller écouter le compilé qu'on a fait avec Julien qui devrait sortir dans quelques semaines où on parle aussi du besoin de communication. Il y avait une autre chose que je voulais dire, mais je ne sais plus. C'est pas grave. Allez écouter l'épisode de Julien sur le compilé de l'épisode de Jocelyn qui sort dans quelques semaines. Je vous remercie comme toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
