La révolution du code ouvert chez Alan

Bruno:
Pendant des siècles, accéder à un métier passait par le compagnonnage, des années à balayer l'atelier, à observer le maître avant d'avoir enfin le droit de toucher l'outil. Et le code, au final, c'était un peu pareil. On ne committait pas en prod le premier jour, on méritait ses accès, on devait faire ses preuves. Et puis l'IA générative est arrivée et soudain, tout le monde dans l'entreprise commence à pouvoir tenir le rabot. Mais alors, comment fait-on pour que tout le monde puisse pousser du code sans que l'atelier ne prenne feu ? Faut-il repenser entièrement la CICD, les garde-fous et la revue de code ? Ou est-ce que les filets de sécurité existants sont suffisants ? Et surtout, le meilleur contributeur de demain sera-t-il celui qui n'a jamais écrit la moindre ligne de code ? Pour répondre à ces questions d'atelier ouvert à tous, je ne reçois pas M. Jourdain, mais il fait du commit sans savoir. Alexandre, bonjour.

Alexandre:
Bonjour Bruno.

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

Alexandre:
Oui bien sûr, du coup je m'appelle Alexandre Gerlich, je travaille chez Alan maintenant depuis quasiment 7 ans et je suis en charge des équipes engineering. Et avant ça, j'ai travaillé dans différentes, principalement des scale-ups en Europe et aux Etats-Unis.

Bruno:
Donc, tu viens nous parler d'un projet assez fou chez Alan qui s'appelle Everyone Can Build, de Souvenir. Avant d'aller diguer un peu dans ce projet, est-ce que tu peux nous détailler un peu comment est organisée l'équipe technique d'Alan ? C'est combien de personnes et comment est-ce que ça fonctionne ?

Alexandre:
Oui, bien sûr. Alors, en quelques mots, chez Alan, déjà, notre mission, c'est vraiment d'aider nos membres à vivre mieux, plus longtemps, en bonne santé. Et donc on est leur partenaire santé pour les aider dans cette direction aujourd'hui on supporte un million de membres et pour ça on est une équipe engineering que j'estime formidable de 150 personnes et qui du coup est divisée en différentes équipes et je dirais que l'ADN qu'on a c'est d'essayer de concevoir les équipes les plus petites possibles mais qui sont par contre parfaitement autonomes pour prendre un problème de A à Z ça c'est vraiment au coeur de notre façon de fonctionner, et voilà et pour l'anecdote un autre aspect qui est au coeur de notre façon de fonctionner c'est qu'on prend l'ensemble de nos décisions à l'écrit et donc il y a un aspect qui est assez intéressant parce que je pense que dans notre façon d'opérer ce qu'il y a de plus proche du monde open source puisque, tout se passe à l'écrit dans des issues GitHub quelle que soit la décision, que ce soit des décisions techniques, que des décisions business elles ont lieu dans des issues GitHub.

Bruno:
Donc c'est du coup une boîte qui est quand même un ADN tech très fort, c'est le mot qu'on puisse dire.

Alexandre:
Totalement.

Bruno:
Quand tu nous parles d'une équipe de 150 personnes, d'une équipe tech de 150 personnes, c'est 150 software engineers ou tu inclues aussi l'équipe produit dans cette...

Alexandre:
Non, non, c'est uniquement 150 software engineers. Si j'inclus l'équipe produit, alors je ne serais pas parfait sur les chiffres, mais je pense qu'on doit être autour des 250 ou sens large, puisqu'on a aussi une équipe data, une équipe de product management, une équipe design et une équipe opération avec lesquelles on interagit tous les jours pour construire les meilleurs produits possibles.

Bruno:
Et donc, tu mènes ce projet Everyone Can Build chez Alan. C'est quoi cette idée folle que tout le monde peut builder de l'application ?

Alexandre:
C'est une idée qui est arrivée, je pense, en juillet de l'an dernier, en fait. C'est vraiment le moment où je l'ai communiqué à l'ensemble de la boîte, donc ça a mûré un peu auparavant. L'idée, c'était de voir que... L'IA nous permettait finalement de construire de manière de plus en plus autonome et aider les ingénieurs à construire de manière plus rapide. À partir de là, en fait, je me suis dit, il y a peut-être une opportunité qui est de, plutôt que de demander finalement aux mêmes personnes qui sont habituées à coder toute la journée, d'aller plus vite. Est-ce qu'on peut avoir plus de personnes qui vont contribuer à l'expérience à l'âne, aux produits qu'on construit ? Et est-ce que ça va nous permettre de construire des meilleurs produits pour nos membres ? Donc c'est partie de cette question-là que du coup, j'ai partagé avec quelques personnes chez Alain et j'ai trouvé quelques volontaires qui m'ont dit, allez go, on va essayer, on n'a jamais codé. Voyons jusqu'où on peut arriver.

Bruno:
Est-ce que du coup quand cette idée a commencé à prendre place est-ce que déjà quasiment l'intégralité voire l'intégralité des software engineers de chez Alan était déjà très consommateur de ces produits ou est-ce qu'il y avait encore un peu de friction.

Alexandre:
Alors en termes d'adoption je pense qu'on était déjà en passe d'avoir plus de 80% d'adoption sur les outils de l'époque, parce que je dis de l'époque parce que ça va tellement vite maintenant. Donc à l'époque, c'était principalement copilot et cursor encore sur lesquels on était, et donc l'ensemble de l'engineering était à un niveau d'adoption très fort, ce qui ne veut pas dire qu'il y avait un niveau d'impact très fort encore à l'époque, on pourra en reparler si tu souhaites, mais ça nous a permis de voir ce que ça donnait pour l'ensemble de l'engineering assez tôt.

Bruno:
Tu fais bien de remettre un peu de temporalité dans le sujet. Tu nous dis que l'idée a germé en juillet 2025 et on enregistre cet épisode en mai 2026. En fonction de quand est-ce qu'il est diffusé et quand est-ce que les gens l'écoutent, il y aura peut-être encore plein de choses qui auront changé d'ici là parce que ça va effectivement très vite sur ces outils-là. Du coup, justement, quand on parle de l'accélération de ces outils, tu as parlé de juillet 2025, on a vu Cloud Code, qui a complètement explosé et qui a commencé à être un game changer à partir de septembre-octobre 2025, est-ce que ça a accéléré du coup aussi ce projet de Everyone Can Build chez Alan ?

Alexandre:
Alors en termes de temporalité au moment où je démarre Everyone Can Build Cloud Code n'est pas encore l'outil qu'on connait aujourd'hui et surtout, Opus 4.5 n'est pas encore sorti et donc Donc, on est vraiment en amont. Et c'est pour ça qu'on se base sur ce qu'on utilise à l'époque, c'est-à-dire un environnement cursor qui est utilisé par les ingénieurs. Et je vais rentrer un petit peu plus sur l'environnement qu'on a en termes d'environnement de travail. On s'est basé aussi sur Devbox, qui nous permet d'avoir un environnement qu'on peut reproduire facilement. Et cette base-là qui est utilisée du coup par l'ensemble des ingénieurs on a un ensemble aussi de process qui est mis en place pour le déploiement bien sûr avec code review mais avant ça il y a beaucoup de linter etc. Et en fait ça c'est la base sur laquelle on va reposer l'initiative Evon Can Build, en tout cas le début parce que, le parti pris c'est de se dire au moment où on se parle au moment où ça démarre l'an dernier, il y a énormément d'outils qui sont sur le marché, qui disent oui, ça va nous permettre de coder, etc. Plus facilement, il y a des lovable, il y a des bulk, il y a beaucoup d'outils je ne pourrais pas tous les citer, mais le parti pris c'est de se dire, notre compagnie aujourd'hui a un asset qui est formidable c'est via la prise de décision, via le fait qu'on fasse tout de manière transparente, on n'a pas de silo, Si on commence à utiliser des outils différents, en fait, on va recréer des silos et c'est exactement la trajectoire vers laquelle j'ai pas envie qu'on aille. Et donc, on fait le pari un peu fou de se dire. Les non-ingénieurs vont utiliser les mêmes outils que les ingénieurs. Et ça, ça nous apporte deux choses qui sont intéressantes. Déjà, le fait qu'on ne va pas créer de silo artificiel, comme on a pu le voir avec des expériences no-code dans le passé. Et on sait que le process marche. Et qui nous permet de shipper en prod de manière qualitative et sereine. Parce qu'il y a toujours cette question de si les gens peuvent coucher en prod alors qu'ils ne sont pas ingénieurs, qu'est-ce qui se passe ? Mais on se base là-dessus en se disant on réutilise les mêmes outils, on les connaît, ils marchent, et c'est ça qu'on va tester jusqu'où on peut aller grâce à ça.

Bruno:
Alors, autant, je me dis qu'avec un cloud code, je peux comprendre qu'on se dise, tiens, on va peut-être tester voir si des gens du produit ou des gens qui sont non-dev peuvent effectivement générer du code, parce que quand tu utilises cloud code, au final, tu ne vois pas vraiment le code. Alors qu'en juillet 2025, quand tu étais encore sur le cursor, l'IA Generative était vraiment sur le côté de ton IDE et tu étais vraiment dans le code donc tu avais quand même, c'était plus un outil d'assistance à la création de code que ce que font maintenant tous les outils avec toute l'évolution qu'ont eu ces modèles là et du coup je trouve ça encore plus fou que tu t'aies dit en fait on va mettre des gens dont c'est pas le métier on va les mettre face à un éditeur de texte, pour qu'ils ingèrent toutes ces lignes de code.

Alexandre:
Il y a quelque chose de formidable dans ce que tu viens de dire c'est que je pense que c'est vraiment la réflexion d'un développeur, l'Agentic au début et à l'époque de Cursor je pense ça a pas marché exactement à cause de ça c'était sur le côté il y avait le chat, le tab marchait superbement bien pour Copilot et du coup je pense que, les modèles étaient moins performants mais en fait c'était pas au coeur de l'expérience de développement et donc ça a pas marché.

Bruno:
C'est surtout que moi j'avais le sentiment de Cursor pour moi c'était un autocomplete sous stéroïde.

Alexandre:
Toi c'était et je pense que t'as raison et c'est exactement moi, à ce moment là c'est une frustration énorme parce que moi je commence à explorer du coup les aspects agentiques de cursor etc et je vois que cette barre à droite là elle devrait être au centre et d'ailleurs ils ont beaucoup évolué sur la UI de cursor à ce moment là je pense que toutes les semaines, ils mettaient à jour mais là on a vraiment je pense une, discussion autour du développement avec des ingénieurs pour des personnes qui n'ont jamais vu en IDE. L'approche est totalement différente. Je te leur dis, voilà l'interface, c'est un nouvel outil. On a discuté du coup sur comment tu peux interagir et en fait, l'aspect fichier, l'aspect éditeur de texte, c'était une partie de l'outil qui n'était pas très utile, mais ce n'est pas leur focus. Et donc, ce qui est pour moi un apprentissage, en tout cas de cette période-là, C'est que ce qui était limite un bloqueur côté engineering ne l'était pas pour les non-ingénieurs, pour utiliser de plus en plus l'aspect agentique.

Bruno:
Ok, canon. Comment est-ce que vous aviez essayé de fiabiliser de cette manière l'usage de ces outils déjà, du coup, à mi-2025 ?

Alexandre:
Tu veux dire côté engineering ou côté non-engineering ?

Bruno:
Côté engineering, oui.

Alexandre:
Côté engineering, en fait, ce qu'on a fait, c'est qu'on avait commencé forcément à mettre les règles en place assez tôt parce qu'on s'est aperçu que les modèles de l'époque permettaient déjà de faire des choses... Assez puissante, mais il restait l'aspect itératif qui, des fois, est négligé sur le fait que tu ne peux pas passer d'un prompt à une pull request de manière magique. Il y a un aspect itératif qui est au cœur de notre métier et qui est toujours là avec l'IA. Et d'ailleurs, c'est un peu moins le cas maintenant, mais tu as un aspect où, des fois, ton premier prompt, il est un peu déceptif. parce que ça ne fait pas du tout ce que tu espérais. Et ce qu'on s'est dit, c'est comment est-ce qu'on fait au maximum pour que lorsqu'on a un prompt qui ne marche pas bien, on ne le corrige qu'une seule fois. Et donc, ça passait par mettre de plus en plus de règles dans le cursor. Et donc, ça, c'était un des premiers points. Comment est-ce qu'on utilise ce nouvel outil et comment on le teste, comment on l'évalue ? Et le deuxième aspect sur lequel vraiment on s'est reposé, c'est nous on avait énormément de linter. Donc là c'était vraiment déjà au cœur de notre stack, de telle sorte que la façon dont on opère sur la stack etc. Soit testée en pré-commit avant qu'on envoie en PR. Donc ça c'est pareil, on s'est appuyé là-dessus on s'est dit, ah là c'est bizarre quand même ce qui se passe est-ce que si on rajoute un linter et que du coup l'agent appelle le linter est-ce que ça marche mieux ? Et donc on a commencé comme ça à mixer les différents outils alors c'était avant la vague MCP, Skills, etc si des gens écoutent alors qu'ils ont déjà ça en place, on trouvait ça un peu bizarre, mais, du coup on a commencé à combiner les outils de telle sorte que on est finalement quelque chose qui soit le plus fiable possible. Pour les ingénieurs mais ça ne suffisait pas pour les non ingénieurs.

Bruno:
Du coup j'essaie d'avoir un tableau un peu de où est-ce que vous en étiez au moment où vous avez ouvert ce scope aux autres personnes donc tu as évoqué aussi qu'il y a eu le déclic qui l'avait aussi amené par l'arrivée de l'agentique, qu'est-ce que ça a changé dans la manière de développer, cette arrivée du mode agentique.

Alexandre:
Alors le mode agentique à l'époque du coup à juillet 2025 à l'époque de Cursor, donc moi j'ai la chance de pouvoir faire quelques explorations et je me dis que là il y a vraiment quelque chose qui se passe qui est fabuleux j'arrive à avoir 2-3 PR sur des petites modifications, finalement qui sont quasiment auto-générées, je me dis qu'on va avoir un shift assez monumental, donc ça c'était la théorie et en pratique ça n'a pas marché comme ça en pratique, je vois que l'adoption des équipes elle est de plus de 85% donc les ingénieurs utilisent le cursor, utilisent le produit mais ils ne l'utilisent pas en mode agentique en tout cas chez Alan à ce moment là, et je pense pour différentes raisons, une c'est celle qu'on a évoquée la UX des produits était juste pas encore prête, c'était pas encore là, deuxièmement peut-être qu'en termes de de training l'approche était peut-être pas la bonne parce qu'effectivement le premier prompt était des fois plutôt déceptif et il fallait remettre l'aspect itératif. Et finalement, c'était un métier qui changeait aussi. Il y avait cette approche de maintenant, il y a un agent sur lequel je vais pouvoir partager ce que je veux créer plutôt que de comment j'ai envie qu'il le crée. Et ce shift-là, il a aussi mis du temps. Et je pense que ce temps était aussi peut-être nécessaire pour que petit à petit, on avance dans la bonne direction. Et le dernier point c'est je pense que il y a aussi un aspect dans l'industrie où, des fois sur les réseaux sociaux etc on peut voir des choses qui paraissent un peu magiques et ça c'est encore le cas aujourd'hui mais par contre quand on les teste nous même sur notre code base avec du legacy qui est plus ou moins grosse, nous en plus on a un mono IBO donc c'est un challenge aussi à rien que de le naviguer d'un seul coup il y a un gap énorme Il y a un gap énorme sur le fait que, ce qu'on voit potentiellement sur la ISO ou les petites vidéos de démo, ok, ça reste une vidéo de démo, mais ce n'est pas fiable, ce n'est pas là, ce n'est pas encore présent. Et ça, je pense qu'en tout cas, au début de l'ère copilot et passage vers Cursor, ça a eu un coup, en fait, parce qu'en tout cas, pendant quelques temps, ça a changé, je pense, depuis, mais les sceptiques ont eu raison sur le fait que l'IA n'était pas encore prête pour changer les choses.

Bruno:
Et donc tu évoques cette idée de 24 builds. Est-ce qu'il y a eu une levée de bouclier de certaines personnes, j'imagine plutôt côté dev, à dire non, non, c'est hors de question que quelqu'un d'autre que nous puisse commuter du code ?

Alexandre:
Alors, je ne pense pas qu'il y ait une levée de bouclier. Ce qu'on a essayé de faire dans un premier temps, c'est déjà de tester. Parce qu'au moment où je démarre, c'est une exploration. Moi-même, j'ai besoin de créer la conviction sur le fait que notre équipe d'opération, par exemple, qui utilise tous les jours des outils internes chez Alan... Il y a énormément de choses qui souhaitent modifier sur les outils internes, mais ce n'est pas priorisé dans notre roadmap. Est-ce qu'aujourd'hui, on va pouvoir leur donner un outil qui va leur permettre d'améliorer leur outil interne ? Et quand je dis améliorer, des fois, je me rappelle, une des premières PR, ça a été, on avait une drop-down. La personne, côté opération, cliquait dessus plusieurs fois par jour pour avancer sur le front suivant. et je disais, attends, mais si les deux éléments, ils sont inversés, mon expérience est meilleure. Je disais, mais pourquoi on n'a pas fait ça ? Ça n'a jamais été priorisé. Il y en a plein des exemples comme ça, je pense que ça parlera à tout le monde. Et donc là, l'idée, c'était de se dire, est-ce que demain, cette personne-là, elle peut faire la modification et l'envoyer en prod. Et donc. Les premiers essais ont été surprenants. Ils ont été surprenants. Parce que la génération de code n'était pas le problème. À partir du moment où le prompt était plutôt OK, le modèle de l'époque, déjà, permettait de générer du code qui remplissait sa tâche. Mais c'était tout ce qu'il y avait autour, en fait, qui était nouveau et à apprendre. Et notamment, qu'est-ce qu'une branche Git ? Si je veux faire une modification sur une code base, en tant qu'ingénieur, tu vas avoir des réflexions sur comment tu vas gérer ta branche, comment tu vas créer ta boule request, comment tu vas merger. Et du coup, un des apprentissages qui a été assez surprenant au début, c'était de se dire que le challenge n'était pas sur la génération de code, mais plutôt sur comment est-ce que je m'assure que ma branche est bien créée, que je ne vais pas avoir des conflits que je ne peux pas gérer parce que j'ai aucune idée de comment gérer les conflits, sur Git donc ça c'était le premier point, et le deuxième point ça a été, comment je sais que quelque chose est complexe à faire ou pas et ça je pense ça nous parle parce qu'il y a toujours cet aspect de j'ai envie de changer ça ça doit pas être très compliqué quand même et écoutez. Effectivement il y a ça mais du coup le modèle de données il faut le changer il y a une migration de base non en fait effectivement pour changer ce bouton là au point de vue expérience utilisateur tu peux penser que c'est quelque chose de facile par contre il ya voilà des choses derrière qui font que ça va être beaucoup plus compliqué et ça on l'a retrouvé lorsque la personne arrivait sur du coup qu'un ressort sur le prompt il ya bah j'ai envie de faire ça et mais sans s'apercevoir que en fait c'était une tâche titanesque qui même pour un ingénier expérimenté allait prendre des, Et donc là-dessus, notre réponse a été de se dire comment est-ce qu'on crée des outils et comment est-ce qu'on met aussi des limites de telle sorte que... Ce soit plus simple pour les non-ingénieurs de comprendre si quelque chose est très compliqué à faire ou pas. Et après, de s'assurer aussi que, dans un premier temps, on leur permette de faire des modifications sur les aspects front-end, aussi bien sur l'app mobile que sur la web qu'on a, mais pas sur le back-end et surtout pas sur la base de données. Et donc, pour en revenir à ta question, sur la levée de bouclier, en fait, je pense que ces aspects-là, ça a permis quand même d'atténuer les choses. Parce que tout le monde a vu qu'on n'allait pas ouvrir la code base en disant demain, on va avoir des gens qui n'ont jamais codé qui vont faire des migrations sur notre base de données ou en tout cas, essayer de le faire. On s'est dit, voilà, on va limiter le scope sur une partie de notre code base. On va fournir des outils. Et le point qui a été, je pense, le plus discuté, ça a été, mais du coup, ça veut dire quoi sur l'ownership ? Si demain, quelqu'un fait une modification. Qui en est responsable ? Parce que la personne ne va pas pouvoir le débugger en production. Là, on a une vraie réflexion. Et ce qu'on s'est dit, c'est, en fait, vous êtes déjà une équipe. Quand vous travaillez sur une modification, sur un nouveau produit, il y a déjà une discussion entre design, PM et engineering sur comment est-ce qu'on va avoir le meilleur résultat pour nos membres. Et si jamais ce résultat, il n'est pas bon, vous allez continuer à discuter, etc. Finalement est-ce que là ça change quelque chose est-ce que ce qu'il faut juste qu'on ait c'est un pairing qui soit clair sur le fait que si demain il y a quelqu'un de notre équipe opération ou design qui fait une modification qu'il y a un pairing avec un ingénieur de telle sorte que l'ownership reste au niveau de l'équipe, et que la code review a été faite par l'ingénieur et comme ça on s'assure que l'ownership soit, toujours identifié et c'est ce qu'on a mis en place et je pense que ça a, Ça a fonctionné dans 80% du temps. Il y a 10% du temps, ou de temps, il y a quelqu'un qui a créé une pull request en disant, bon alors j'ai eu cette idée-là. Et je vois, d'un point de vue, forcément un peu challenging par rapport à l'ownership, etc. Mais aussi d'un point de vue super positif. Parce que, pour moi, une des validations du succès d'Event Can Build, c'était de changer vraiment l'état d'esprit. Et de se dire, demain, on va avoir des gens qui utilisent les produits au sein d'Alan qui vont être capables de les améliorer. Et plutôt que de se dire, ah oui, j'ai vu ce bug-là, je vais faire un ticket, de se dire, ah, je vais ouvrir Cursor et je vais voir si c'est compliqué. Et si ça n'allait pas, je vais faire une pull request. Et ça, pour moi, c'était la définition du fait qu'on allait changer à quelque chose de très important dans notre manière de fonctionner.

Bruno:
À partir du moment où le projet se lance et tu commences à faire tes premiers tests, combien de temps il s'est passé entre le début de ce test et le premier commit en prod de quelqu'un qui n'est pas dev ?

Alexandre:
Je dirais 24 heures.

Bruno:
Et quand un software engineer junior arrive chez Alan, il met combien de temps à commit quelque chose en prod ?

Alexandre:
Alors, nous, on essaye que ta première pull request, elle parte en prod. Alors, c'est sur des petites modifications, mais dès la première semaine.

Bruno:
Et donc, ça veut dire que d'une certaine manière, ton projet, il y a quelqu'un qui a pu shipper en prod plus rapidement qu'un software engineer dans le processus usuel d'Alan ?

Alexandre:
Ouais, l'approche est un petit peu différente parce que le software engineer qui arrive, il doit apprendre beaucoup de choses sur comment marche Alan et comment naviguer. Alors que là, ce nombre dont on parle en termes de modifications qui ont eu lieu en 24 heures, c'est, en tout cas dans les premières étapes, ça a été la personne de l'équipe opération qui change l'outil qu'elle utilise tous les jours. Et après, côté design, ça a été des fois des layouts à changer, etc. Et donc, c'était déjà des domaines dans lesquels ils étaient experts. C'est là où je pense qu'il y a quelque chose qui est très intéressant entre potentiellement tu es expert d'un domaine, mais pas du code, contrairement à quelqu'un qui est expert du code, mais pas du domaine, qui va être le plus rapide à faire la première modification ? Ce n'est pas évident d'avoir forcément une réponse par rapport à ça. Le point qui est clé, je pense, ça a été de se dire est-ce qu'on peut avoir une feedback loop qui est... Qui permet à la personne qui modifie de voir le résultat. Et c'est pour ça qu'on a limité le scope sur le front-end, parce que c'était plus simple, en fait, de dire à quelqu'un qui n'avait jamais codé tu fais telle modification sur tel outil que tu connais par cœur, ça va reload automatiquement pour toi. La page web, et tu vas pouvoir tester. Et là, tu vois si ça marche ou pas. Et bien sûr, après, il va y avoir un ingénieur qui va réduire le code, etc. Mais déjà, tu vas pouvoir voir si le flow que tu as fait, il marche de la façon dont tu l'avais pensé initialement.

Bruno:
Ok. Hyper intéressant. Est-ce que ça veut dire que peut-être encore aujourd'hui, vous pouvez voir qu'en fonction, on va dire, du diplôme de la personne, de son parcours de formation, que chacun va toucher à des zones du code différentes, parce qu'effectivement, quelqu'un qui est plus côté UX va travailler beaucoup plus sur des notions de front que quelqu'un côté produit sera plus... Et qu'au final, de manière peut-être plus ou moins naturelle, sans être dans une notion de chasse gardée, mais que chacun va essayer de travailler sur le domaine qu'il maîtrise.

Alexandre:
C'est une bonne question. Je ne sais pas si j'ai la réponse actuellement à ça. Ce que je peux imaginer, c'est que côté engineering, effectivement, on passe plus de temps sur des aspects, on va dire, plus au niveau des API, des fondamentaux, des aspects de performance un peu plus critiques, puisqu'on va être capable d'avoir plus d'aide finalement des experts du domaine, et potentiellement ils vont aller plus vite parce que s'ils ont la bonne feedback loop, ils peuvent directement faire la modification qui est nécessaire et proposer, les changements qui pour nos membres sont clés. Est-ce que ça va faire des chasses gardées ? J'espère pas parce que comme je disais, dans notre ADN l'idée c'est qu'il n'y ait pas de silo et que ce soit simple pour un ingénieur de changer d'équipe, de voir autre chose et je pense que ça c'est aujourd'hui quelque chose qui est au coeur de notre ADN chez Alan.

Bruno:
Donc j'espère.

Alexandre:
Qu'on va pas le perdre.

Bruno:
Alors ma question c'était pas dans le sens de dire que le dev va dire ok tu peux bricoler sur la page sur le HTML de la page, mais dès qu'on touche aux API c'est moi qui m'en occupe je peux dire que c'était pas dans cette démarche là mais que en fait comme t'évoquais l'expertise de chacun, est-ce que c'est quelque chose qui reste encore ancré de dire en fait qu'il y a quelqu'un qui fait de l'UX, il va être fait au final faire des changements plus sur l'aspect du front où là maintenant ça fait quasiment un an que le projet est lancé, tu vois en fait des gens touchés à tout, à tous les côtés, sans aucune restriction.

Alexandre:
D'accord, je comprends mieux. Alors il y a plusieurs aspects à ça. C'est rare que quelqu'un commence par dire alors moi j'aimerais bien changer tel endpoint de l'API. Toujours de l'expérience des membres et je pense que c'est bien. Et pour l'instant, on a gardé le scope sur le front-end. Par contre, une fois qu'il y a un pairing avec un ingénieur, ça descend dans la stack. Là, on le voit de plus en plus et pour deux raisons. C'est qu'un, les modèles sont meilleurs maintenant que ce que ça a été à l'époque. On leur donne beaucoup plus de contexte et je pense que notre pairing entre, les non-ingénieurs et les ingénieurs pour Evan Canbill est aussi plus efficace. Et donc, Donc, les changements que je peux voir sont plus ambitieux. Maintenant, peut-être qu'il y a deux anecdotes quand même à te partager là-dessus. C'est que je dis qu'ils sont plus ambitieux maintenant, mais déjà, au moment où on démarre, ça a dépassé mes attentes en termes d'ambition. Et j'ai deux anecdotes là-dessus. Le premier c'est que on avait un nouveau flot de NPS pour avoir les avis de nos membres qui étaient à faire. Et sur les personnes avec qui je teste Yvon Can Build au tout début, à un moment, il y a un des designers qui faisait partie de cette exploration qui me dit, regarde, j'ai changé tout le flow de NPS. Et en fait, quand j'arrive vers son bureau, je pense que ce n'est pas possible. Et là, il me montre que tout le flow a changé, qu'il a réussi à récupérer de Figma ce qu'il voulait, etc. Et donc là, je me dis, que c'est impressionnant.

Bruno:
Est-ce que c'était possible de t'évoquer tout à l'heure la difficulté à expliquer aux gens la mesure de la complexité d'une tâche ? Est-ce que c'était possible parce qu'il y avait cette jeunesse, cette fraîcheur ? Et qu'en fait, il n'avait pas la pression de se dire, en fait, modifier tout un flow, c'est compliqué. Et il s'est dit, juste, je vais le faire. Et il s'avère que ça va fonctionner.

Alexandre:
Exactement. C'est exactement ça. C'est-à-dire que moi, j'avais un pied sur le fait que c'était pas encore prêt, que ça pouvait pas marcher et il m'a montré que si, et ça m'a convaincu dans le fait que ok il est temps de partager ça à l'ensemble de la boîte, qu'on allait dans la bonne direction que maintenant il fallait accélérer et s'assurer que on continuait à avoir, le meilleur setup possible pour ce shift et une autre anecdote que je voulais te partager donc celle là elle est aussi marrant je trouve, c'est, un mois je vois une paire passer et je me dis c'est quand même très bizarre, nous on a un design système du coup qu'on a fait en interne qu'on utilise du coup partout chez Alan pour avoir une expérience qui est la même, et en fait il y a une des personnes avec qui on fait les premiers tests qui a souhaité modifier un outil interne qu'elle utilise régulièrement mais qui n'avait pas été migré sur notre nouveau design système, Et pour des raisons de priorité, pour des raisons de migration qu'on finit jamais, pour des raisons qu'on connaît tous.

Bruno:
C'est un truc interne, on se dit que c'est pas nécessaire.

Alexandre:
Exactement, et jamais on a fait la migration à 80%, on s'est dit, il nous reste ces outils internes, là ils marchent, du coup on n'y touche pas. Et du coup on l'avait laissé de côté. Et en fait ce qui s'était passé c'est que la personne avait démarré un prompt pour faire une petite modification. Mais du coup, l'agent, il avait vu qu'il y avait dans notre système de règles le fait que c'était important d'utiliser notre design system, qu'il était à jour et que si jamais il passait un moment sur un fichier où il y avait encore un component deplicated, de faire une proposition pour le mettre à jour. Et donc là, en fait, sa PR, donc un nom d'ingénieur, il y avait une petite modification et trois fichiers de modifiés pour mettre à jour le design système. Et donc là, par rapport à ce dont tu t'évoquais au début, sur le fait qu'en termes de qualité, tu peux avoir les ingénieurs qui vont dire qu'il y a un risque, effectivement. Là, j'ai trouvé ça assez marrant comme anecdote parce que sa PR, en fait, a amélioré la qualité de notre code base. Puisque non seulement on l'a mergé, mais en plus, ça nous a permis d'avancer sur une migration qu'on avait des priorisées.

Bruno:
Avec cette fameuse règle qu'on imagine tous où on se dit si je tombe sur un bout de code qui est plus à jour je le modifie, cette pratique qu'on appelle la pratique du boy scout où tu rends les choses plus propres, partout où tu passes mais qu'on fait en général pas parce qu'on n'a pas forcément le temps là il y a quelqu'un en fait qui n'a pas été pollué par des années de pratique du thème et qui l'applique en fait de manière naturelle quoi.

Alexandre:
Ouais totalement et du coup ces deux anecdotes pour moi voilà je voulais te les partager parce que pour moi elles sont assez parlantes des fois des propres biais qu'on peut se mettre aussi en tant qu'ingénieur et un peu représentant technique, de se dire ah ça c'est peut-être un peu trop compliqué, et puis, ça en fait, il y a peut-être un risque sur le fait que la qualité ne va pas être au niveau où on l'espère en fait c'est, voilà, on a eu d'autres challenges mais cette anecdote montre que c'est pas toujours.

Bruno:
Vrai Est-ce que le fait aussi justement de mettre ces outils là j'imagine que le temps avance, il y a Claude qui sort J'imagine que vous êtes mis à cloud code ou des outils équivalents. Ils sont tous plus ou moins alignés. Mais est-ce que le fait de mettre ces outils-là entre les mains de personnes qui ne sont effectivement pas dev, ça oblige au final à... À fiabiliser encore plus l'usage de ces outils-là aussi pour les devs, c'est-à-dire qu'en fait même un développeur, qu'il soit junior ou senior, va bénéficier de toutes les skills, tous les agents que vous mettez en place pour les gens qui sont non-dev, pour que tout le monde produise du code de la manière la plus propre possible.

Alexandre:
C'est exactement ça donc pour avancer un petit peu dans Wink & Bill on se dit qu'on y va, on commence à avoir plus de gens, qui installent l'environnement de développement qu'on a et on a, quelque chose comme 280 pull requests qui sont mergés sur un quarter donc on voit le résultat sur le fait que...

Bruno:
280 par rapport à combien, je ne sais pas, un an avant ? Tu aurais une idée à peu près de ce que ça représentait en volume ?

Alexandre:
Alors les 280 je pense qu'on a fait ça quand on a vraiment lancé One Can Build sur, l'ensemble des équipes design plus PM qui pouvait émerger en prod un an auparavant on avait zéro.

Bruno:
Oui mais c'est d'accord mais du coup tous tes software engineers eux ils font aussi.

Alexandre:
L'ensemble de PR tu veux savoir combien de PR ? c'est 280 PR.

Bruno:
C'est 280 versus 4000 ou c'est 280 versus 600.

Alexandre:
Ouais alors j'ai plus les chiffres exacts en tête mais je veux pas te dire de bêtises mais ça reste un petit pourcentage par rapport à l'ensemble des pairs engineering parce qu'on a une équipe à l'époque on devait quand même être déjà sans ingénieur je pense donc il y avait déjà pas mal de merger mais ce qui est intéressant c'est se dire que ces 280 pull request elles existaient pas il y a un an auparavant et on avait donné un nouvel outil en fait à des personnes qui ont, quelque part étaient bloqués dans leur démarche puisqu'elles devaient ouvrir un ticket prioriser etc, et donc on arrive à merger comme ça plus de 280 pull requests assez rapidement et, l'autre aspect du coup que tu évoquais qui est clé c'est finalement on améliore l'environnement de travail pour les non ingénieurs, mais ça l'améliore aussi parce que ça le rend meilleur pour les ingés, ça le rend plus rapide. Et on a cette feedback loop qui fait que finalement, l'environnement de travail est amélioré pour l'équipe d'engineering grâce à Yvonne Canby. On avait deux équipes, une qui était vraiment focus sur Yvonne Canby, une autre qui était vraiment focus sur l'environnement de développement. Et en fait, petit à petit.

Bruno:
Elle commence à converger.

Alexandre:
Elle commence à discuter sur le fait que là, on peut peut-être changer, telle partie telle l'inter telle règle de cursor et ça permet de faire d'accélérer toute la boîte et ça ça valide le le paris qu'on a pris en début le paris qu'on a pris au début de se dire on utilise le même outil parce que quand on va l'améliorer pour quelqu'un ça va permettre à toute la boîte d'en bénéficier.

Bruno:
Et donc, pour avancer dans la chronologie de ce projet, l'objectif, c'était d'arriver à ce que vraiment tout le monde chez Alan puisse effectivement « Everyone can build », où il y avait quand même toujours l'idée de se dire « on va limiter à des gens qui sont… » C'est-à-dire qu'on ne va pas proposer à des gens côté RH ou côté compta ou côté légal d'aller faire des choses.

Alexandre:
Alors tu as l'idée du projet comme elle était il y a en juillet 2025 et puis il y a aussi la vitesse de l'IA qui ont, eu un impact là dessus et notamment tu parlais de cloud code il y a opus 4.5, 4.6 qui sort il y a tous les aspects de skills qui apparaissent et donc là c'est de nouveaux outils qui, finalement nous.

Bruno:
Nous font prendre un step back aussi mais qui d'une manière générale vous donne raison c'est à dire que c'est des outils qui montrent que tu peux aller donner ces éléments là à des gens qui sont pas du tout dev parce qu'effectivement avec un cloud t'es beaucoup moins au contact du code, t'as une ergonomie qui est multipliée, effectivement comme tu le dis les skills les agents qui permettent en fait de donner aux outils de chacun des compétences pleines entières, au final, pour moi la sortie de cloud te donne raison sur cette vision que t'avais déjà quelques mois avant.

Alexandre:
En tout cas, elles nous permettent d'accélérer encore plus les choses et par rapport à ce que tu disais, ça y est, l'agentic est au milieu, c'est exactement ce que tu dis et donc côté engineering, je crois que c'est fin 2025 où tu as 4.6 qui sort et du coup l'update de Claude et là il y a un énorme changement en fait dans la boîte parce qu'on adopte ça assez rapidement. Et là, on a un shift énorme sur plein de dimensions différentes. Les sceptiques de copilot sont les premiers à pusher pour qu'on adopte cloud code au plus vite. On voit effectivement certaines métriques d'activité type nombre de pull requests, etc., qui d'un seul coup ont un shift énorme. Et ça valide en fait, comme tu dis, l'approche qu'on a de se dire ok, il y a des outils maintenant qui permettent de s'abstraire de la code base, et qui vont être encore plus faciles à appréhender pour l'ensemble des aleneurs. Donc le chiffre qu'on fait à ce moment-là, c'est de se dire dans un premier temps, il faut qu'on peut-être revoie notre outillage. Et s'assurer qu'on accélère à l'engineering, pour bénéficier en fait de ce shift sur Opus 4.6. Et donc ça, ça a été une des dimensions. Et la deuxième dimension auquel on a réfléchi à ce moment-là, c'est de se dire, est-ce qu'il est temps aussi qu'on construise nos propres outils ? De telle sorte qu'en fait, on voit les convergences, les synergies qui arrivent entre nos différentes équipes. Et on se dit, quand on combine tout ce qui est skills, Opus 4.6, etc., Comment est-ce qu'on en bénéficie au maximum ? Et on commence à se dire qu'on va investir encore plus dans cette direction, de telle sorte que notre façon de créer du produit, de le faire fonctionner, va diamétralement changer, en tout cas en 2026.

Bruno:
Et donc là, depuis début 2026, tout le monde chez Alan a accès à l'environnement de dev et peut déployer du code ou c'est encore réservé à certaines équipes.

Alexandre:
Alors pour répondre à ta question il faut qu'on précise quel est l'environnement de développement, Aujourd'hui, tu vas avoir l'environnement Everyone Can Build qui va être utilisé par ce qu'on appelle, nous, les product communities. Donc, ça va être APM, design, opération, pour leur permettre, du coup, de faire des pull requests qu'on va shipper en production. Mais on a aussi un environnement de développement qui est notre repository de skills qui contient non pas uniquement des skills pour coder, mais pour les autres parties du job, en fait. Et elles sont nombreuses en tant qu'ingénieur en fait on passe une partie de notre temps à coder mais on passe aussi du temps à préparer des meetings, pour coacher des gens et les aider à grandir il y a du reporting aussi pour savoir comment s'est passé la semaine ce genre de choses et donc on a un repository de skills qui partageait avec l'ensemble de la boîte et là pour l'anecdote. Une des pull requests qu'on a fait sur un des skills c'est une autre une personne de l'équipe people rh d'alan qui a fait la review et du coup qui a merger la pôle request qui nous permet d'avoir ce skill là qui est maintenant partagé par l'ensemble de la boîte et donc c'est intéressant pour moi parce que où est l'environnement de développement dans tout ça on en vient à finalement quelque chose qui était un petit peu au coeur des one can build mais qu'on n'a pas vraiment cité jusqu'ici c'est que le code est maintenant au coeur de tout et on le voit avec cloud code qui a un peu exposé en tropique qui a fait ce pari là de focus leur modèle sur le code mais avec ces repositories là on a effectivement un ensemble de skills un mix de fichiers markdown et de scripts qui fait aussi partie de notre environnement de développement désormais.

Bruno:
Ce qui veut dire qu'au-delà du « everyone can build », vous êtes aussi passé sur un « everything has code ». Tu vois ton exemple que tu donnes sur comment gérer un meeting one-on-one, qui va être des éléments qui sont revus par... Il y a une code review qui est faite, entre guillemets, par des gens côté RH. En fait, c'est que du coup, tout devient un peu du code et rentre dans des process de validation comme ce qu'on a sur notre code base de manière assez traditionnelle.

Alexandre:
Exactement. Et ça, c'est un shift qu'on a, commencé finalement j'ai l'impression que ça fait longtemps mais c'est très récent en fait l'aspect skills etc ça date de premier quarter 2026, là on commence à structurer les choses il y a eu beaucoup de changements aussi qui ont été faits par, les différents outils que tu peux utiliser que ce soit cloud code, codex etc mais effectivement pour nous c'est un des shifts qu'on est en train de prendre et qui est au cœur finalement de notre ADN parce que chez Alan on prend nos décisions à l'écrit on a tout qui est public et ça nous permet comme ça finalement d'utiliser les skills, et de maximiser le contexte qu'on peut donner à nos agents, et donc c'est un accélérateur énorme pour l'ensemble de la boîte. Plus uniquement sur l'aspect coding là c'est vraiment sur l'ensemble de, nos process et nos façons d'opérer et on est en train de voir jusqu'où on va et ce que ça veut dire, et sur le code en tant que tel, il y a aussi énormément de choses là sur lesquelles on travaille pour, se dire maintenant que si on se dit que la génération de code est quasiment faite, c'est qu'une partie du problème parce que assez rapidement on se dit comment on va faire les code review comment est-ce qu'on va déployer en production et donc là on a shifté une partie en tout cas, des ingénieurs qui travaillaient sur la partie VWN Can Build de génération de code sur ok demain comment on valide qu'est-ce que ça veut dire de valider un changement, sachant que ce changement peut être fait par différentes personnes avec différents profils et comment est-ce qu'on s'assure du coup de le faire scale et le baser encore une fois sur des fondamentaux, qui sont clés pour s'assurer de la qualité et du fait qu'on ne va pas introduire dans notre code base des changements d'enjeun.

Bruno:
Alors c'était effectivement ma question suivante, c'était sur quels changements ça engendrait sur votre CI-CD ? Tu as commencé effectivement à y répondre, mais du coup, ta réponse me fait comprendre que quand tu as lancé ça en juillet 2025, tu es parti du principe qu'on va faire en sorte que tout le monde puisse shipper du code, mais sans adapter ta CI au fait que n'importe qui peut effectivement shipper du code. Donc ça veut dire qu'il y a quand même une période où toutes les PR sont entrées dans la CI traditionnelle et donc avec une code review humaine traditionnelle, et donc tout ça a été revu et peut-être est encore revu à chaque fois quoi qu'il arrive par au moins un être humain ?

Alexandre:
Totalement. Et je dirais que c'est au cœur de cette approche-là. Il y a un moment où il faut être aussi très pragmatique. Pour que Everyone Can Build marche, il faut se baser sur les choses qui fonctionnent déjà. Et ce qui fonctionnait déjà très bien, c'est d'avoir des ingénieurs qui font des pull requests, qui sont review par d'autres ingénieurs et d'avoir un CICD avec énormément de tests. Et c'est pour ça que, notamment d'autres approches avec différents outils qui ne nous permettaient pas d'avoir ce système-là, ont été beaucoup plus dangereuses pour mettre en place quelque chose comme Iwant Can Build. Là, on a vraiment pu se reposer sur ce socle-là. Et donc, on n'a rien changé là-dessus. Toutes les pull requests, même les typos ont été revus à chaque fois par l'équipe Engineering. Par contre, ce qu'on s'est dit assez rapidement, c'est qu'on avait dû avoir du mal à le faire scale. Et tu as les deux aspects, c'est-à-dire qu'on commence à avoir des centaines de pull requests qui sont faits via Evoyant Can Build, et en même temps, on a Cloud Code qui nous permet de générer beaucoup plus de pull requests, donc on doit les review. Et donc ça dépasse un peu le change uniquement d'Evoant Can Build, c'est qu'en fait, on doit faire scale absolument notre système de code review. Il y a aussi des aspects donc là qui sont liés à l'âne sur le fait d'être ISO 27001 etc donc tu as des aspects de comment est-ce que tu vas pousser un changement en production qui sont régulés et donc là il y a une nécessité de prendre un peu de distance et de se dire demain en fait à quoi ça, ressemble de faire un changement de le valider, at scale pour nous et donc là c'est c'est notre focus acteur.

Bruno:
Mais tu as aussi un sujet c'est que tu as code review que tu fais à quelqu'un qui est plutôt côté product, tu ne peux pas lui faire les mêmes feedbacks qu'un dev qui a effectivement écrit son code. Lui dire d'utiliser tel composant plutôt que tel composant ou de faire des choses d'implémentation différentes, ça ne lui parle pas à quelqu'un qui est côté produit. Il n'a pas la même, compréhension de ce qu'il a lui-même généré de cette manière.

Alexandre:
C'est très vrai quand tu essayes notamment de faire grandir aussi des ingés juniors, c'est exactement l'approche que tu vas avoir, mais je ne sais pas si c'est l'approche qu'on doit avoir maintenant avec le client. C'est-à-dire que si on voit le fait d'avoir une feedback loop qui nous emmène à achever un changement, après il va arriver en prod, il doit être testé auparavant, au moment où tu fais la code review, tu as envie de te dire est-ce que ce n'est pas déjà trop tard ? Est-ce que si aujourd'hui avec l'IA qu'on a et le fait de les modèles, la performance qu'ils ont, le contexte qu'on peut leur donner, pourquoi est-ce que le code généré n'est pas déjà... Qu'est-ce qui manque ? Et du coup, la question pour nous, elle est plutôt là. Comment est-ce qu'on fait pour que demain, que ce soit un ingénieur ou un non-ingénieur, finalement, à partir d'un prompt, soit capable de générer du code qu'on estime être de qualité irréprochable et comment on met ce système en place de telle sorte que petit à petit, finalement, on puisse améliorer la façon dont on utilise nos modèles pour s'en rapprocher. Et donc, c'est plus là-dessus, en fait.

Bruno:
Donc l'idée c'est pas tant que ça d'améliorer le process de code review ou toute ta CI mais c'est de faire en sorte que tu sois dans un système où tu peux te passer de la code review ou de ta CI complètement alors.

Alexandre:
Je sais pas si on pourra s'en passer.

Bruno:
Mais tu peux être suffisamment confiant pour te dire, là on a un système de génération de code qui est tellement solide que si on était un peu foufou on pourrait débrancher la CI on serait quand même un peu je.

Alexandre:
Pense que ça doit être notre objectif en gros notre objectif aujourd'hui ça doit être Se dire comment est-ce que finalement on apprend des feedbacks qu'on donne de telle sorte que finalement Claude se trompe qu'une fois. Et comment on fait pour faire que ça soit un système qui à la fin puisse être une boucle fermée et qu'elle fonctionne. Je ne sais pas si on en sera capable en tout cas, mais ça doit être notre objectif. Parce que le truc auquel je crois pas aujourd'hui c'est d'avoir, un focus uniquement sur être capable d'améliorer, de faire ce qui est les codes review. En fait, c'est le système des codes review, etc. DPR, il marchait très bien et voilà, toute ma carrière, j'ai fait ça, donc j'en suis très content. Mais aujourd'hui, à l'ère de l'IA, je pense qu'il faut aussi se dire, voilà, il y a des choses qui vont changer et il ne faut pas rester trop bloqué, par le process qui marche actuellement.

Bruno:
C'est pas parce qu'on faisait comme ça avant qu'il faut continuer à faire ça demain.

Alexandre:
Exactement.

Bruno:
Vous avez quand même forcément un usage de ces outils-là qui est quand même plus intense que la moyenne. On va pas se mentir, je pense que t'en es conscient. Vous les poussez calme dans les retranchements, vous les exploitez beaucoup. C'est à dire que vous avez une culture de l'écrit, donc vous avez beaucoup de choses qui sont écrites. T'as évoqué tout à l'heure que vous aviez un monoripo. Est-ce que l'avènement aussi de ces outils-là, commence à vous faire poser question sur certains choix techniques qui ont été faits dans le passé tu vois par exemple est-ce que l'idée du monorepo, en fait dans un contexte de, full AI et donc avec des contextes Windows qui sont limités on se dit peut-être qu'on va passer sur vraiment du microservice, à complètement éclater les trucs, gérer les responsabilités différemment est-ce que ça vous amène aussi à des choix techniques que vous faites sur votre code base pour supporter ces nouveaux usages ?

Alexandre:
C'est une question que je me suis posée à de nombreuses reprises. Plus on avance vers l'IA qui finalement gagne en autonomie, à quel point, à un moment, l'IA va décider des choses avec lesquelles qui optimise pour l'IA ? Mais pas pour les êtres humains. Est-ce qu'on est toujours sûr, finalement, que ce qui bénéficie à l'un va bénéficier à l'autre ? Je pense que la question est ouverte.

Bruno:
Je ne sais pas si tu as vu, mais il y a des projets qui se lancent. Il y a des gens qui ont créé des langages spécifiquement pour les LLM, qui ne sont du coup pas forcément hyper compréhensibles par les êtres humains, mais qui sont parfaitement adaptés à la manière de... Je ne vais pas dire de réfléchir, mais à la manière de générer du code par les LLM.

Alexandre:
Oui, j'ai vu rapidement un langage de programmation, je crois, qu'ils ont bougé. Pour l'instant, quand on regarde, effectivement, l'IA, elle se base quand même sur tout ce qu'on a fait dans les années passées. Donc, il y a cet aspect où, notamment sur la code base, plus elle est clean, mieux elle est testée, etc., plus c'est facile en tant qu'être humain et plus c'est facile pour l'IA aussi de se balader et naviguer là-dessus. Mais c'est une vraie réflexion. Je ne sais pas si c'est quelque chose où à un moment, lorsque aujourd'hui l'IA fait quelque chose qui n'est pas finalement cohérente avec notre définition de bon, on édite son cloud.md et on s'assure que ça ne se reproduise pas. Mais effectivement il y aura peut-être des challenges pour converger au bout d'un moment. Sur le fait qu'on soit totalement aligné.

Bruno:
Mais donc pour le moment, pas d'envisager de passer à des microservices pour faciliter les contextes Windows des LLM ?

Alexandre:
Oui, c'est une bonne question. Sur les contextes Windows, là, ça a beaucoup évolué. Maintenant, c'est assez simple d'avoir un contexte Windows d'un million de tokens sur Cloud Code. Les discussions que j'ai eues avec d'autres entreprises, notamment j'ai discuté avec, Spotify il y a quelques semaines je pense était plutôt sur le fait qu'il n'y ait pas un monorepo les freinaient plutôt qu'autre chose parce que du coup finalement ça empêchait le modèle de pouvoir vraiment modifier, les différents aspects dont il y a besoin de savoir, et d'être plus efficace là où je me pose une question c'est plus sur. Les abstractions qu'on peut créer pour nous-mêmes en mémoire garder un certain nombre de tokens, en tant qu'être humain, on va avoir plutôt tendance à se dire, plutôt que d'écrire la même fonction dans le fichier A et le fichier B on va écrire une seule version qui va être partagée, etc. Et comme ça, si on doit faire une modification, on le fait à un seul endroit plein de pratiques qui je pense sont nécessaires à mesure qu'on fait grossir une code base. Maintenant, s'il y a 20 agents qui en parallèle font les modifications, etc., est-ce qu'ils auront toujours la même optique pour dire que c'est comme ça qu'on fait scale la code base ? Je sais pas. Pour l'instant, on reste en tout cas sur nos principes d'architecture qu'on a du coup encodés dans nos fichiers de règles, de telle sorte que les agents les suivent.

Bruno:
Ok. Canon. Merci beaucoup Alexandre pour cette discussion fascinante 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 voudrais partager avec l'ensemble des auditeuristes ?

Alexandre:
Contenu, alors forcément, je suis obligé de parler de notre blog Medium. On partage énormément de choses sur le blog Medium d'Alan. Et c'est directement les ingénieurs qui contribuent dessus. Et je pense qu'on essaye de partager le max dessus.

Bruno:
OK. Est-ce qu'il y a autre chose, un autre type de contenu que tu veux partager au-delà du blog d'Alan ?

Alexandre:
Laisse-moi réfléchir un instant.

Bruno:
Peut-être un dernier film que tu as vu ou un bouquin que tu as bien aimé ou le bouquin que tu recommandes à toutes tes équipes.

Alexandre:
Alors le bouquin que j'aime bien il s'appelle Five Dysfunctions of Team, c'est de Patrick Lantioni et c'est sur comment mettre en place une équipe la plus efficace possible et quelles sont la nécessité de mettre en place de la confiance de la comptabilité etc c'est un livre sur lequel je reviens de temps en temps, parce qu'il y a la technique mais il y a aussi comment est-ce qu'on collabore, les uns avec les autres où des fois il y a des challenges importants et c'est bien d'avoir, quelques principes sur lesquels on peut se reposer.

Bruno:
On parle beaucoup d'agents mais on fait un métier très humain.

Alexandre:
Et de.

Bruno:
Plus en plus canon, on mettra bien évidemment les liens en description, dernière question et la plus importante Alexandre, est-ce que tu es plutôt espace ou tabulation ?

Alexandre:
Effectivement, question clé. Je pense que la réponse c'est de se dire du moment qu'il y a un aspect qui est gardé parmi ça, c'est le principal pour éviter d'avoir des diffs à rallonge, mais je resterai sur les tables.

Bruno:
Très bien. Merci beaucoup Alexandre.

Alexandre:
Merci beaucoup Bono.

Bruno:
Et merci à tous d'avoir suivi cette conversation. Projet fou de se dire que tout le monde peut shipper du code aujourd'hui chez Alain. Ce sera très certainement le cas de plus en plus dans le contexte, donc il faut s'y préparer, mais comme on l'a dit avec Alexandre c'est aussi un très bon moyen d'améliorer nos propres outils et d'améliorer aussi notre expérience, donc cette developer experience, c'est quelque chose qui va se transformer peut-être en user experience au sens employee experience. Pour tout le monde, de mon côté je vous remercie comme toujours de partager ce podcast autour de vous, n'hésitez pas à aller checker les différents liens sur tous les trucs qu'on sort à côté de tout ça je vous souhaite une très bonne fin de semaine, je vous donne rendez-vous la semaine prochaine et d'ici là, codez bien.