Transcription

• Manu

  Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no code. On se retrouve comme chaque semaine avec Lulu, qui est prête pour cet épisode.

• Lulu

  Ah bah oui, très prête.

• Manu

  Oui, et on a le plaisir de recevoir aujourd'hui Xavier. Xavier, est-ce que tu es prêt aussi ?

• Xavier

  Ah oui, plus que prêt.

• Manu

  Bon, parce qu'on vient d'avoir quelques minutes d'échange avant de commencer cet épisode et on a plein de choses à vous dire, on a plein de choses à discuter. Donc ça va être, on est toujours, pardon pour remettre un petit peu en contexte, vous avez dû entendre la semaine dernière notre épisode avec Amélie qui est directrice opérationnelle de l'AFUP. Puisque jusqu'à mi-octobre, on reçoit chaque semaine un ou une invitée qui va participer au forum PHP qui aura lieu les 8 et 9 octobre à Disneyland Paris. et c'est l'occasion d'aborder avec eux différents sujets, qu'ils soient techniques ou pas d'ailleurs, et orienter vraiment sur la partie humaine, et comment on s'approprie la tech aujourd'hui, quels sont les enjeux d'un point de vue événementiel, comme on l'a abordé avec Amélie, d'un point de vue technique, et les changements vis-à-vis aujourd'hui d'une agence de dev, comme on va l'aborder avec Xavier. La semaine prochaine, on aura encore d'autres aspects. Et voilà, donc déjà... Merci Xavier d'avoir accepté notre invitation et on va rentrer dans le vif du sujet. Est-ce que tu peux nous présenter un peu, enfin est-ce que tu peux te présenter et nous présenter un petit peu

• Xavier

  ELAO également ? Moi c'est Xavier Gors, j'ai une cinquantaine d'années et ça fait maintenant pratiquement 20 ans qu'on a monté ELAO sur Lyon. Et nous on fait de l'applicatif métier sur mesure. Donc on n'est pas une agence, on n'est pas intégrateur de solutions, on ne fait pas non plus tout ça. qui est CRM, on fait très peu d'e-commerce, on ne fait vraiment que de l'applicatif métier sur mesure, web et mobile. Historiquement, avec une grosse compétence PHP Symfony, on a commencé il y a 20 ans sur PHP Symfony, et on a toujours, sur cette stack-là, côté back-end, on a la chance de ne pas avoir eu besoin de se disperser là-dessus. Et côté front, on fait du React et du React Native, et pareil, on ne fait essentiellement que ça. On est une petite équipe, on est une petite quinzaine sur la partie vraiment dev. On a une autre activité aussi dans le groupe où on fait plus de l'infrastructure. On fait du cube et tout ça, enfin voilà, avec un peu le même ADN. Et on n'a pas de clients particuliers. Nous, les projets qu'on aime bien, c'est la petite société qui a envie de faire passer son fichier Excel à être utilisé par plusieurs personnes. Mais oui, c'est des trucs qui sont importants parce que c'est du métier. Il y a des contraintes qui sont là, c'est du quotidien. Et nous, on aime bien ça parce qu'on aime bien avoir celui qui veut utiliser en face, on aime bien avoir celui qui peut prendre une décision en face. Donc, on cherche plus une topologie d'organisation de clients que des clients et des métiers en tant que tel.

• Lulu

  Donc, aussi de l'outil interne et voilà.

• Xavier

  C'est de l'applicatif métier. Nous, typiquement, en interne, on n'a que depuis peu des compétences sur la partie vraiment créa. on n'a pas de DA nous en interne on ne fait pas de création par contre on a la partie UX on est assez sensible à l'accessibilité aussi sur les projets mais on fait très peu de sites très peu de sites enfin on ne fait pas de sites vitrines on ne fait pas de CMS enfin on est vraiment nous voilà sur le métier et ce que je dis toujours c'est que si on résume nous notre métier de manière un peu atomique on va prendre la donnée quelque part on la transforme et on va la remettre quelque part d'autre on la prenne dans une page web Euh... qu'on la remette dans une base de données ou l'inverse. C'est ce qu'on fait depuis 20 ans et les façons de traiter ça ont changé énormément depuis qu'on a aussi l'IA, qui est un gros sujet qu'on va discuter.

• Manu

  Oui, justement, on va y venir parce que tu as déjà animé plusieurs conférences pour faire des retours d'expérience de l'adoption de l'IA au sein de l'AO. Avant qu'on aille justement sur le rapport à l'équipe et comment vous vous en êtes emparé, est-ce que ça a changé pour vous ? Parce que là, tu viens... de parler aussi justement des projets et ce que j'en ai vu c'est que la taille des projets aussi que vous preniez avait changé qu'il y avait des choses qui avaient vraiment bousculé un petit peu vos habitudes vis-à-vis des nouvelles possibilités et du coup avant de rentrer dans ce rapport comme ça à l'équipe déjà ton rapport à toi personnel au niveau de l'IA à quel moment en fait ça a commencé à titiller ta curiosité tu t'es dit tiens ça vaut le coup de mettre les mains dedans alors comme beaucoup nous l'IA Oh !

• Xavier

  on la voyait avant avec les grands yeux du machine learning du deep learning dans des projets en même temps ça serait cool on aimerait y aller mais la marche elle était monumentale pour nous d'un point de vue applicatif On l'a effleuré quand on a essayé des outils, des algos de recommandation et tout ça derrière, mais on avait fait un gros projet pour l'optimisation de planning de rendez-vous. Donc là, c'était des modèles en tant que tels. C'était bien, mais ce n'était pas notre cœur d'activité. Et donc, on n'a jamais poussé ça. Après, je pense que je ne vais pas être très original, mais nous, la révélation IA, c'était fin 2022 avec ChatGPT en fait. Et pas tant l'outil que tout début 2023, la dispo des API. qui sont arrivés. Et c'est vraiment là où moi, j'ai commencé à jouer avec, avec déjà un truc qui anime pas mal le sujet là, c'est, tiens, est-ce que ça ne peut pas nous aider dans toute la rédaction des specs et tout ça ? Est-ce que ce n'est pas quelque chose qui peut arriver à nous enlever les pignes du pied de la documentation fonctionnelle qu'on n'est jamais arrivé à gérer et à vivre parce que ça peut nous aider à l'écrire, à la lire, à la maintenir ? C'était un peu ça le fil conducteur patent parce qu'à l'époque, ce n'était pas le code en tant que tête, c'était... pas ça en fait, c'était un autre usage le côté conversationnel était aussi sympathique dans ça, et puis donc on a, enfin j'ai surtout levé un peu le capot utiliser les API, essayer de comprendre ça, et il y a un moment où moi ça m'a fait c'était GPT-3 à l'époque, donc c'était bien mais pas top on va dire et il y a un moment où quand GPT-4 est arrivé et quand je lui ai commencé à lui dire, tiens ces specs là tu peux même sortir les auto-tests pour ça, enfin je veux le faire essaie de me dire comment tu vas tester ça Et quand je l'ai vu aller dans des coins que généralement tu vois arriver plus tard et tu dis mais comment est-ce qu'il fait pour aller trouver ça avec juste les infos que je lui ai données ? Et là, on était obligé un peu de soulever le capot, d'essayer de comprendre ce que c'était, ce que ce n'était pas. Et après, autour de ça, on a commencé nous à construire un petit projet, produit. On faisait nos assistants. On a des clients qui l'utilisent encore. On était capable justement de construire. On faisait juste un assemblage de promptes et on facilitait. la disposition de ça pour l'utiliser sans avoir à les faire à l'époque c'était encore on était encore prompt ingénieur c'était un montant tu parles bien des assistants gpt nous on a commencé à faire ça avant chez gpt on a fait une plateforme où on faisait nos assistants à nous avec api et tout ça en fait on fait un assemblage de contexte et de prompt déjà pour éviter pour que le rendre accessible à des personnes ouais c'est un peu un

• Lulu

  pré-agent, enfin, ce qu'on appellerait aussi... Oui,

• Xavier

  c'était l'égyptise, à l'époque, tu étais là, tu étais capable d'aller, tu les assembles, tu mets son contexte, tu lui mets des instructions, et après, tu es capable de le rendre actif à des personnes qui ne s'attendent pas à ce qu'il y avait derrière. Et ça, c'est vrai que ça nous a permis vraiment d'aller sur le côté, de dire qu'est-ce qu'on en fait en tant que tel. Et après, vraiment, la grosse bascule, ça a été moi, fin 2024, début 2025, où j'ai commencé C'est mou... moi, à utiliser Loveable et à me dire, ah, ça y est, j'ai des super pouvoirs maintenant. Dix ans que je faisais plus de code, alors que j'ai un wagon de technique et tout ça, mais j'étais sur fonctionnel. Ça y est, j'ai enfin les capacités d'arriver à formaliser ce que j'ai dans la tête de manière assez efficace en en connaissant les limites, parce que vous savez les limites, mais on les voyait, parce qu'on voit le code et tout ça, mais la phase de prototypage, la phase d'expérimentation. C'était juste hallucinant. Et peu après, il y a Cloud Code qui est arrivé, avec des « attends, en plus, on est capable potentiellement de le cadrer un peu, on est capable de l'amener là où on voudrait aller. » Et ça en est suivi. Après, je crois que c'était début de l'été 2025, avec l'équipe, on s'est dit « est-ce qu'il serait capable d'écrire le code qu'on produit ? » Et une fois qu'on a fait ça, on avait mis une loi dedans, et puis la réponse était oui. C'est pas si simple que ça, mais la réponse était oui. et puis là Ça fait un an, plus d'un an maintenant qu'on a commencé cette bascule-là, et ça fait depuis fin d'année dernière où absolument tous les projets de toute l'équipe sont passés sous ce mode-là. Même des anciens, on se disait que ça allait être compliqué de les ramener. En fait, une fois que tu as basculé, tu ne peux plus revenir. Donc, si je grossis le trait, ça fait que l'équipe est entièrement basculée depuis pratiquement un an sans écrire de code. C'est plus elle qui écrit le code.

• Manu

  Oui, parce que ça,

• Lulu

  c'est vraiment encore un peu disparate dans les entreprises. Mais après, voilà, c'est toute une conduite du changement. Il faut une vision, il faut...

• Xavier

  Je suis entièrement d'accord. Il faut voir qu'on a eu de la chance. Moi, j'ai l'impression, quand je regarde un peu derrière, que ce qu'on a construit en 20 ans, autant sur le côté code et autres, c'est-à-dire que nous, on était sur une seule techno, on avait des passionnés qui étaient là, on avait la chance d'avoir passé du temps pour faire de l'ingénierie logicielle. Tous nos projets étaient sur la même façon de coder. On avait cette culture-là de faire les choses bien. On avait déjà... Nos écosystèmes de tests étaient déjà très poussés parce que c'est... c'était notre façon de faire. Donc l'IA est arrivée comme énorme facilité lors que ça, on a juste eu beaucoup d'efforts à écrire ce qui ne l'était pas, à formaliser ce qui ne l'était pas, mais c'était déjà le début du harness de comment tu dois bosser. Donc ça n'a pas du tout changé ce qu'on était et ce qu'on faisait.

• Lulu

  C'est là où il y a vraiment la vision. Il faut une vision à la base et là même récemment, j'avais vu une étude, enfin plus, sur les impacts à l'échelle de la... l'environnement et tout ça, mais qu'en gros, l'IA, elle vient amplifier le système sur lequel elle vient se mettre. Et voilà, donc si c'est du bordel, même si on lui dit de ranger, ça restera quand même. Mais par contre, s'il y a des valeurs, il y a une vision, elle va venir amplifier cette vision si c'est bien fait, justement.

• Xavier

  Et l'autre point qui est aussi important, là je te parlais de la technique, mais surtout, c'est même encore plus important, c'est que j'avais l'équipe, j'avais l'humain qui était capable. de faire ce shift-là, parce que tu as beau avoir la meilleure doc, les meilleurs outils, si tu n'as pas l'équipe qui a envie de se remettre en cause en disant, moi j'ai la chance d'avoir des personnes, c'est des concepteurs avant d'être des développeurs. Donc c'est ce qui a fait aussi accélérer, c'est que mes équipes, elles sont en prise avec le client, nous on est là pour trouver des solutions et des besoins, et donc les équipes, elles sont en prise directe avec le client. J'ai des projets où il n'y a pas de chef de projet, c'est l'équipe qui est en prise directe avec ça, et qui discute et qui... qui comprend et qui développe et qui fait évoluer derrière. Donc là, ça n'a pas changé grand-chose, si ce n'est que c'est la phase de dev qui a complètement changé, parce qu'on l'a déléguée à l'outil. Mais notre process pour trouver des solutions à des besoins, les fondamentaux, on ne joue pas bouger. Et on n'aurait pas pu en être là où on en est maintenant si on n'avait pas eu à la fois la culture et surtout l'écosystème humain des personnes qui avaient... qui ont eu confiance, qui avaient envie de bouger et de se mettre un petit peu un moment en porte-à-fond en disant, attends, je change de métier quand même, parce qu'on l'a fait à l'équipe en trois mois, t'arrêtes heureusement des chaires de côte, donc c'est pas anodin quand t'as fait ça depuis plusieurs années.

• Manu

  Et justement, comment ça s'est fait ? Là où je voulais questionner, t'as pas eu de réfractaire dans l'équipe ? Comment ça s'est fait naturellement justement cet engouement ?

• Xavier

  Non, il n'y a pas eu de réfractaire. terre parce qu'il y avait déjà la confiance qui était là. Ce qu'on a construit, là où on voulait aller, on était OK sur ce que ça allait changer pour nous. C'était juste pour qu'on soit encore meilleur sur ce qu'on fait pour nos clients et que même nous aussi, on a la chance dans l'équipe d'avoir que des passionnés. Un truc nouveau qui arrive, tu as envie d'y aller et on en reviendra un peu après sur la PACTE. Ça, c'est un contre-coup de la passion qui fait très mal sur eux. tout l'achat connectif qu'il y a, mais je sais qu'on va aborder le sujet. Donc non, ça, la bascule, par contre, la bascule qui s'est faite, c'est que j'ai pris, la personne avec laquelle on a commencé à bâtir les fondations de tout l'écosystème et de tout le harness et le workflow qu'on met en place au quotidien, c'était une des personnes qui disait, ben ouais, mais moi, mon plaisir, c'est d'écrire du code. À un moment, si je prends plus de plaisir à écrire, si je prends plus de plaisir... de plaisir dans le quotidien, c'est ça de faire dev. Et à la fin de l'été, quand on a réussi, alors qu'on n'écrit plus de code, il s'est rendu compte que le plaisir n'était pas dans le code, in fine. Il a toujours été d'en trouver la solution et être capable de répondre à un besoin. Le code n'était qu'un moyen, au final. Donc là, c'est encore compliqué de lâcher. Tu vois, là, la décision qu'on a prise, on en parlait tout à l'heure, on en reviendra peut-être, mais de dire, il faut qu'on arrête de passer autant de temps sur les reviews parce que c'est juste pas... possible, la valeur elle est plus là en fait c'est plus ça, c'est que la valeur elle est peut-être plus à ce niveau là, je dis pas qu'il faut pas en avoir je dis pas qu'il faut pas contrôler, mais plus comme on le faisait avant

• Manu

  Oui parce qu'après, même tu vois en étant orienté sur le besoin en étant orienté sur le fait de répondre justement à l'usage de la personne en face, il n'empêche que techniquement, il y a des gens qui ont fait d'oeuvre parce que justement toute la logique et les... Le cheminement pour arriver à cette solution passe par le code et par ce qu'il y a à mettre en place techniquement et tout.

• Xavier

  La grosse, tout qui a changé, c'est qu'on a déplacé énormément de sujets bien avant le code. Ce qu'il faut voir, c'est que tout le pipeline de code qu'on fait, le moment de production de code, c'est devenu le truc le plus petit en temps dans toute la production de structure. Donc, ce qui fait, c'est qu'on a déplacé énormément d'énergie et de temps en amont sur la conception. Et ce qui fait qu'il y a des moments, il y a des questions et des sujets qu'avant, tu te posais quand tu étais devant le code, quand tu étais en train d'implémenter, quand tu étais en train d'aller là-dessus. Et là, maintenant, on est obligé de se les poser en amont avant. Et ça, par contre, c'est une démarche institutionnelle qui a été... ce qui n'est pas facile, parce que tu n'es pas devant le code. Toi, c'est encore vachement abstrait fonctionnellement, donc tu n'es pas encore dans l'implémentation. Donc il y a des choses que tu ne vois pas. L'IA t'aide beaucoup aussi à aller trouver les zones grises. On y reviendra aussi, mais c'est un vrai avantage. En tout cas, oui, ça a déplacé beaucoup de trucs qu'on faisait là-dessus. Et quelque part, la production de code, c'est la première chose qu'on a complètement lâchée en disant toute la phase de production de code, on ne regarde pas et on n'intervient pas. Parce que le framework qu'on a mis en place fait qu'on a à peu près sur une feature une cinquantaine potentiellement de points de contact dans tout le développement. qui garantit que la responsabilité du dev est toujours là, parce que c'est lui qui a fait ces choix-là, et quelque part, l'écriture du code, alors qu'avant, à chaque étape, il nous demandait de contrôler, maintenant on sait qu'on lui dit « Fais tout, on a mis ce qu'il faut après pour contrôler, on va les regarder globalement, mais on ne va pas les regarder à chaque étape que tu as décomposée. »

• Manu

  En tant que développeur, on va continuer à se poser les mêmes questions, on va juste se les poser à des moments différents et sous une forme différente.

• Xavier

  Oui, et surtout, tu vas remonter sur des questions qui sont un peu plus au niveau d'archi, donc d'architecture de l'information. Putain d'archi technique, le côté du code et de la technique autant que telle est quelque chose qui, moi, à mon sens, va tendre à s'effacer, voire à disparaître. Je ne sais pas le pas de temps, mais en tout cas, c'est ma conviction. Mais en tout cas, non, le cheminement de l'information, les cas particuliers qu'on va avoir, les points de contact.

• Lulu

  qu'on va avoir les problèmes de performance et tout ça c'est des choses qui sont toujours là il y en a certaines qui sont dépendantes du code et au-delà il y a toujours ce lien là mais c'est plus le code en premier c'est plus le code qui est au centre de tout ouais là c'est vraiment on se rapproche on essaye encore de mieux répondre aux besoins des utilisateurs des personnes qui vont utiliser ça et c'est plus forcément de faire du beau code et plutôt se demander comment est-ce que je peux bon bah architecturée, comment est-ce que l'information, par quel chemin elle va passer, est-ce qu'on peut voir différemment, est-ce que je peux prendre plus de temps pour creuser avec les personnes, quitte à les faire jouer aussi sur un prototype. Le temps gagné, c'est pas on produit beaucoup plus de codes et on fait plus de projets, mais le temps ça réduit la fenêtre et ça a permis de la déplacer ailleurs.

• Xavier

  Là où il y a plus de valeur, en fait. Oui. Si on a divisé par 10 le temps de production de code, et peut-être même des fois plus que ça, on n'a pas du tout divisé par 10 le temps qu'il nous faut pour répondre à un besoin. Par contre, ce qu'on voit, nous, là, ce qu'on pense avoir, c'est qu'on arrive, par rapport à avant, à produire le même code qu'on aurait fait. Et nous, c'était le point de départ. Toute l'expérimentation qu'on a eue, c'était de se dire est-ce qu'on arrive à contrôler, guider, pour que le code qui est généré par... par Claude ou n'importe lequel, ce qu'on aurait pu générer nous dans sa structure, dans la tuile. Est-ce qu'on arrive à contrôler ça ? Et c'est là où on a mis énormément d'énergie à aller faire du context engineering, à aller être capable de donner la bonne info au bon moment pour être sûr qu'il arrive bien à structurer le code comme nous, on lui avait formalisé, comme nous, on avait formalisé nos pratiques.

• Manu

  Et d'ailleurs, justement, tu en parles dans des conférences, on les mettra d'ailleurs en lien de l'épisode pour que les gens puissent arriver. aller voir justement le détail, parce qu'on en parle de manière plus détaillée, plus longue et tout. Et donc, au moment où vous avez fait cette bascule, il y a un truc justement qui m'a vachement parlé dans ce que tu disais en conf, c'était le fait que ça vous a aussi permis, et vous vous êtes questionné sur ok, il y a des projets qu'on ne prenait pas avant, est-ce qu'aujourd'hui on se les permet et on y va, et de quelle manière on y va ?

• Lulu

  Les projets moins matures, où le besoin était moins mature notamment.

• Xavier

  Oui, et il se dit, bon, Pour remettre en perspective ça, nous, avant, on était sur des projets, allez, on va dire de 100 jours hommes sur la phase de build et avec un équivalent d'une équipe de 2-3 personnes sur 2 à 3 mois. Je fais des gros trucs, mais c'est à peu près la topologie de projet qu'on a dressée. On faisait de l'applicatif métier, c'était quand même... On avait, nous, un ticket d'entrée et c'est pour ça que l'ingénierie logicielle qu'on avait développée était adaptée à ça. C'est des projets métiers, donc il fallait que... l'arche hexagonale, l'isolation, tout ça, pour nous faciliter à tester le métier et à point de dépendance, répondait aux enjeux des applications qu'on développait. Et donc, toute cette partie-là nous a permis de faire l'orchestration et de faire cette bascule-là.

• Manu

  Du coup, ce qui vous a permis d'aller prendre des projets plus petits.

• Xavier

  Et donc, nous, tous les projets, je vais donner un chiffre, mais les projets sont des 10 à 20 000 euros. Le coût d'Init pour comprendre EOT et mettre en place notre socle, on n'avait jamais trouvé la bonne équation. Et c'est vrai que là maintenant, j'en parle à la bonne réponse, mais c'est que les trois premiers projets qu'on a fait là-dessus, c'était des projets, la première phase qu'on a fait nous d'utilisation de notre framework était très axée sur le front. On n'a pas voulu adresser les deux chantiers front et back en même temps, ça aurait été illusoire de pouvoir partir. Et donc, nous, pour aller vite là-dessus, on a commencé à faire des projets avec Supabase, Supabase qui était déjà la stack sur laquelle on avait fait notre plateforme d'assistants. Donc, on la connaissait un peu, on l'avait expérimentée. Ce n'était pas notre plateforme de projet classique, mais donc, on a eu des projets qui sont arrivés qui avaient besoin d'aller très vite, qui étaient à une certitude très forte sur ce qu'ils allaient faire et qui étaient typiquement adaptés à ce qu'on aille vite, de manière efficace là-dessus. Et donc, on a eu trois projets qui sont partis. sur un couple, notre framework sur la partie front et du super base en back. Et qui nous appartient, nous, de pouvoir maintenant avoir des projets où la première marche, elle est beaucoup plus faible qu'avant. Et on est capable de pouvoir répondre à des projets qui ne sont pas plus petits, in fine, parce que dans tout ce qu'on fait, la vision du projet final sera toujours la même taille. Par contre, la première étape est beaucoup plus légère. Et ça change profondément ce qu'on...

• Manu

  la façon de vendre les projets maintenant mais bon en tout cas de ce que tu dis j'ai une petite question justement sur la partie Supabase par curiosité du coup c'est du Supabase que vous utilisez en version cloud ou vous hébergez vous même ?

• Xavier

  On l'utilise en version cloud là dessus nous c'est vrai comme on a une activité sur la partie infrastructure c'est quelque chose qu'on regarde c'est pas anodin de faire de déployer une infrastructure Supabase il y a quand même beaucoup de choses Et nous, en plus, on est côté infrastructure, on est certifié ISO, on est HDS. Donc, on a un niveau pour aller, l'effort pour aller au niveau de tout l'écosystème est loin d'être anodin. On y pense fortement pour des raisons de souveraineté parce que c'est un vrai truc qu'on a là-dessus. On est un peu trop petit pour dire on fait une offre souveraine sur le Supabase. La version open source de Supabase, elle n'est pas faite pour héberger plusieurs instances, plusieurs clients en même temps. Il faut que tu déploies une instance complète pour chaque projet, donc avec beaucoup de ressources pour un projet. Pour l'instant, non, on ne l'héberge pas. On a essayé, mais on n'est pas encore outillé dans toute notre stack pour dire qu'on n'a pas une offre dédiée d'hébergement souverain à Superbase. Et en plus, le ratio coût pour 20 ou 30 euros, ce qu'ils offrent, eux, en hébergement, le seul souci, c'est que c'est une boîte US. Ce n'est pas si mensal ce qui pose un souci. Après, leur service est cool, ça va bien.

• Manu

  et pour le prix que ça coûte c'est difficile de trouver mieux quand même ah oui non c'est sûr je m'interrogeais parce que du coup après c'est des projets plus petits des scopes plus petits mais du coup là j'ai fait l'essai en fait d'aller migrer ça et passer par un outil qui fait l'infogestion pardon de ça et d'aller justement sur la version open source et qui s'avère en fait tourner quand même très bien mais effectivement ça implique un VPS une instance et tout ce qui va avec le côté infra et voilà mais oui après le jeu

• Xavier

  techniquement l'outil ShubaBase même dans sa version cloud comme tu le disais marche très très bien c'est juste la question de la botte après l'enjeu pour l'héberger soi-même il n'est pas le temps dans le fait de faire tourner il est temps de s'assurer que tout l'écosystème de tous les différents c'est-à-dire il y a au moins 6 ou 7 instances Docker qui doivent tourner quand tu veux tout utiliser il faut être sûr que tu as l'observabilité pour tout le pilotage de tout et c'est ça qui coûte finalement c'est le de... assurer la même cohérence que tu as alors qu'avant, tu avais juste une instance web et une base de données. Tu avais deux trucs à gérer et là, tu en as quand même un peu plus derrière. Ce n'est pas technique à monter, mais il faut être sûr que tu es capable de la gérer dans le temps et de pouvoir assurer ça sur des besoins clients de résilience qui peuvent être compliqués ou qui sont très chers par rapport à la version hébergée.

• Manu

  Super. Et du coup ? À quel moment, parce que pareil, tu en parles aussi dans la conf, à quel moment vous vous êtes dit bon là, c'est mort, on fera plus machine arrière, on a changé de façon de bosser et voilà, on va adapter à partir de maintenant notre manière de travailler au niveau de la boîte, toujours avec cette logique-là. Quel moment vous vous êtes dit, bon c'est bon ?

• Xavier

  Quand on est arrivé à faire écrire le code qu'on aurait fait avec le code, c'est-à-dire que moi c'était la fin de l'été dernier. L'équipe ne l'avait pas encore, mais quand on était avec Maxime, quand on avait construit ça, quand on a vu où on l'avait amené. et puis l'impact, parce que ce n'est pas que écrire le code, on a changé aussi radicalement, on a remis la doc au milieu, il y a eu quand même beaucoup de choses qui ont changé, et ce n'est pas tant le fait de ne plus écrire le code, c'est le fait d'avoir changé tout le process complet de réalisation d'un besoin jusqu'à sa mise en ligne. C'est ce que tout a changé sur toute la chaîne.

• Lulu

  Oui, justement, moi j'avais regardé la... La conf qui était début d'année, où vous alliez initier les projets, les plus petits projets. Et la question, c'était, est-ce que sur les plus gros projets, vous alliez continuer ? Par exemple, avec du super base kit à mettre, plus la partie bac sur du PHP, mais peut-être sur des données sensibles. Mais en même temps, tu disais que côté architecture métier, ou en tout cas dépendance, c'était mieux d'avoir quand même... tout au même endroit et peut-être pas avoir sur des choses séparées et commencer aujourd'hui sur peut-être des plus gros projets en termes de back-end ?

• Xavier

  On a à la fois des nouveaux projets qui sont partis avec le côté PHP symphony classique derrière et il y a même les anciens projets qui plus ou moins, alors ils ne sont pas à la stade complète mais au fur et à mesure on les a remontés en réintroduisant tout le workflow à l'intérieur. pas pour tous encore, mais en tout cas, même les anciens, maintenant, c'est que du cloud code et tout ça derrière. On n'a pas encore tout le framework qui est terminé parce que les projets qui bougent peu ou pas, l'effort n'est pas anodin d'aller tout reconstruire. Mais en tout cas, il n'y a pas un projet qui bouge sans que le code ait été écrit par cloud. Oui,

• Lulu

  et après, même sur la partie op... Open source, je ne sais pas comment ça a évolué aussi par rapport au début d'année, du coup, où tu disais que vous utilisiez beaucoup d'open source et de potentiellement transmettre les acquis que vous aviez eus et toutes les connaissances. Je ne sais pas comment ça a évolué aussi sur cette partie-là.

• Xavier

  L'ADN open source, nous, on l'a depuis très longtemps parce qu'on s'est... Puis, à un moment, Maxime, avec lequel on a construit ça, il faisait partie de la core team Symfony. Il avait du temps pour contribuer. C'est un truc important pour nous. Et même, on a beaucoup pris à l'open source. On s'est construit avec Symfony, avec PHP. Donc, même le temps qu'on donne à côté, le temps que je donne à l'AFUP en tant que bénévole, est aussi une contribution à mon niveau de redonner à la communauté ce qu'on a pris à l'open source. Donc, nous, la volonté à un moment de partager ce qu'on a fait là, on ne l'a pas encore... parce que là, c'est pas... tout ce qu'on a fait, c'est des plugins cloud, c'est du cloud, il n'est pas... Enfin, ce qu'il faut voir, c'est que ce qu'on a fait là, ce n'est pas quelque chose que tu réutilises tel quel. Complètement. Le côté technique est très peu là, c'est juste qu'on a écrit ce qu'on était, ce qu'on faisait qui correspond à notre taille, nos projets, notre culture et notre équipe. Par contre, on va ouvrir certains trucs, ce qu'il y a, c'est que ça prend du temps à le mettre à un niveau et ça encore, on est capable de le donner. Le problème, c'est que ça bouge tellement vite que rien que ce qu'on a là actuellement, ça bouge toutes les semaines. Nous, on a quand même toutes les semaines, deux heures, toutes les semaines ensemble pour discuter que des retours expérient, de ce qu'on modifie et de comment bouge l'écosystème d'une autre.

• Lulu

  Justement, j'allais demander comment est-ce que c'est maintenu parce qu'il y a moyen de faire un peu des boucles et d'adapter ce qui est en place. Mais à un moment, il y a besoin aussi de réfléchir. Est-ce qu'il y a une partie qui est un peu automatique dans l'évolution du framework ou c'est décidé en équipe ?

• Xavier

  C'est expérimenté, chacun l'expérimente. À un moment, il y a une décision de dire est-ce qu'on le partage, est-ce qu'on le remonte dans le socle et est-ce que ça a du sens là-dessus ? Je vais carrément, mais on est quand même encore en grosse phase de R&D. Il n'y a rien qui est sec, ça bouge de tous les côtés, chaque nouveau modèle. Même les... Les orchestrateurs, les cloud codes et autres, leurs outils bougent, leur spectre d'impact bouge aussi de tous les côtés. En fait, ça ne se terminera jamais. Je pense que ça ne se terminera jamais. Et donc, il faut qu'on ait nous, mais là, il faut qu'on budgétise à un moment de R&D, il faut qu'il soit tout le temps là, il est constant, parce que ça bouge tout le temps et tu bouges tout le temps en tant que tel. Et ce qui est important, c'est qu'on partage.

• Lulu

  Oui, et vous avez essayé un petit peu d'aller aussi sur des solutions open source. pour la partie développement, comme par exemple OpenCode ? Et si oui, est-ce que ça a été probant ?

• Xavier

  On n'a pas encore l'énergie pour se dire on va essayer autre chose.

• Manu

  Moi, j'aimerais qu'on arrive à ne pas être dépendant et d'un outil et d'un fournisseur, mais je suis confiant avec ça. C'est-à-dire qu'à un moment, s'il faut qu'on mise dessus, je suis persuadé qu'en plus, la moitié des usages d'LLM qu'on a pour coder pourraient être exécutés par des modèles qui tournent sous nos Macs. C'est-à-dire que les petites tâches de modif de coder, tout ça, on n'a pas besoin d'utiliser Opus et tout ça derrière pour lui demander d'aller... réécrire, copier ou modifier un fichier. Ce qu'il y a, c'est que là, maintenant, on n'est pas au stade d'aller optimiser à ce niveau-là. On n'a pas besoin, même d'un point de vue financier, mais il suffirait qu'on paye vraiment le coût que je vois là où tous les mois, en coût API, on est sur les abonnements, on arrive à rester dedans avec un petit peu de leur quota, mais quand on voit le vrai coût API qui proche, moi je vais être 7 000 euros par mois en équivalent API, le jour où on paiera vraiment ça, naturellement, on va devoir optimiser ce qu'on fait.

• Lulu

  Voilà tout ce qui est préparé actuellement, ça va faciliter.

• Manu

  Je sais que le jour où on aura besoin d'optimiser entre les modèles open source et les solutions d'orchestrateurs pour l'open code, on a ce qu'il faut pour un moment changer ça et on ne changera pas le fond. C'est-à-dire que nos skills, notre connaissance et tout ça, il faut juste qu'on change un petit peu les rapports qu'on a faits pour exploiter ça. Le quotidien ne changera pas. Ce n'est pas quelque chose qui est important, mais quelque chose qui est critique, qui fait qu'il faut absolument qu'on y passe tout de suite, sinon on va tout perdre. On va y passer, j'aimerais bien, mais pour l'instant, on n'en est pas là. Il y a d'autres priorités.

• Xavier

  De toute façon, après, tu l'as dit, l'écosystème IA n'est pas encore stable, de toute façon, et il est en mutation permanente. On a vu les modèles qui s'accélèrent, qui sortent tous les trois mois, mais au-delà des modèles en eux-mêmes, il y a justement tous les outils autour. typiquement les contextes, les harnais, les techniques qu'il y a autour, la façon de gérer les skills, etc. Tout ça a changé énormément en un an et continue de changer tous les deux mois. Mais du coup, en tout cas, ce que tu as déjà observé, c'est que ce que vous aviez comme logique et fonctionnement de boîte, vous avez pu l'adapter à l'IA. Votre façon de bosser, vous la requestionnez régulièrement pour l'améliorer sans cesse, mais en tout cas, ça nous permet quand même d'avoir un workflow de production qui est quand même constant et permanent.

• Manu

  Et qui est cohérent avec toute l'équipe. Ça, par contre, c'est quelque chose qui est important. Il fallait qu'on garde cette cohérence-là parce qu'à un moment, les équipes bougent. On essaye aussi qu'elles ne soient pas clasonnées. On est à venir sur les projets qu'ont fait les autres. Et ça, par contre, ça fait 20 ans qu'on y prête beaucoup attention à cette cohérence-là. Et c'est ce qui a fait, je pense, que la capacité qu'on a pu aller vite de cette partie-là, c'est qu'on n'avait pas 36 technos. On avait un truc qui était cohérent. Et c'est... Voilà. Donc, ça, on veut le cultiver et on sait qu'il nous faut du temps pour l'entretenir. Et c'est ce qui fait que l'idée de quelqu'un est capable de profiter très rapidement à tout le monde parce qu'on en repartage ça au truc d'après et c'est capable de le cultiver. Et le plus gros problème qu'on a là, c'est d'arriver à faire rentrer dans la boucle de tout ce qu'on a fait là, tout ce qui est non-tech. Toute la partie UI, UX, gestion de projet, client, on va dire. Et ce qui arrive après aussi sur la recette parce que là, pour l'instant... c'est super dur en fait parce qu'ils sont, plus qu'ils ne sont pas tech, ils sont déconnectés, ils n'arrivent pas à suivre ce qu'on avance. Nous, on essaye, là, typiquement, on a alterné, au lieu de toutes les semaines faire un point tech dev, IA, on fait une semaine dev IA et une semaine IA transverse. C'est-à-dire qu'avec tout le monde, qu'est-ce qu'on peut mettre en place, qu'est-ce qu'on peut faire ça pour les faire monter et qu'ils ne soient pas non plus à la traîne et déconnectés de ce qui se passe là parce que... S'il n'y a que nous qui sommes outillés, à un moment, ça ne va pas passer. Parce que le maillon le plus faible, celui qui va faire le bout de l'étranglement, ce ne sera plus le dev, déjà. Donc, il faut être sûr. Et puis surtout, humainement, il ne faut pas laisser de côté les personnes sur des changements aussi profonds. Mais, vas-y.

• Xavier

  Justement, parce que là, j'aimerais bien... Alors, juste avant qu'on aille sur le sujet, justement, de ce que ça a eu comme impact humain, parce que là tu parles déjà du fait d'embarquer tout le monde et de faire monter en compétence tout le monde pour que ce soit équilibré au niveau de la boîte et avant justement qu'on aille davantage là-dessus et sur l'impact que ça a d'un point de vue cognitif et fatigue et épuisement et tout ce qui peut y avoir en retour je suis très curieux de savoir en fait le rapport que vous avez là avec vos clients depuis que vous avez changé de façon de bosser Est-ce que c'est quelque chose qu'ils ont ressenti ou pas du tout ? Est-ce que du fait qu'il y a un peu partout, les demandes de vos clients ont changé ou il y a plus d'attente ? Tout à l'heure, tu disais qu'au final, le temps que vous mettez à délivrer reste le même. Mais par contre, vous allez délivrer d'une bien meilleure manière qu'avant et d'une manière bien plus documentée. Même pour le client derrière, c'est beaucoup mieux. de par tout ça et tous ces leviers. Mais du coup, concrètement, est-ce que maintenant, aujourd'hui, ils vous en demandent le double ou le triple de specs ? Est-ce qu'ils sont vraiment dans un rapport peut-être de peur ou craintif ? C'est certain de vous dire est-ce que vous utilisez le LIA ? Du coup, on ne bosse pas avec vous ou alors si, mais de quelle manière ?

• Lulu

  Est-ce qu'ils arrivent à se rendre disponibles aussi pour toute la phase de besoin ? Ça, c'est un gros sujet.

• Manu

  Il y a beaucoup de questions là-dedans. Oui,

• Xavier

  pardon.

• Manu

  Beaucoup de sujets qui sont tous liés, mais si Jean-Loup Pouve... vous me les remontez. Déjà, le plus simple, tu parlais de la dispo client et généralement, je repars dans les confs. Nous, avant, historiquement, on avait un équivalent mi-temps côté client, côté PO, ceux qui nous alimentaient en besoin, étaient capables d'alimenter une équipe de dev, deux, trois devs, full time. Nous, par contre, c'est vrai que les projets, les personnes étaient dédiées, monoprojets, plus ou moins quatre jours par semaine dédiés à ce projet-là. Donc là, tu avais quand même une équipe de deux, trois, même à l'époque. on faisait du code, ça produisait quand même. Il fallait alimenter en besoin. Là, maintenant, pour caricaturer, la même dispo côté client ne m'alimente même pas un dev full-time. Et donc là, on est confronté, nous, à deux trucs qui sont assez compliqués. C'est d'une part, on s'est battu pour éviter d'avoir des projets monodev parce que ce n'est pas sain pour tout le monde. Pour la charge mentale du dev qui n'a que ça, pour la connaissance globale, pour la résilience du projet et tout. mais vraiment, même pour l'échange, c'est compliqué. Ce côté-là est vraiment problématique. Là, on est en train d'étudier des choses pour faire de la review croisée entre devs. On ne parle pas de revue de code, on parle même de « je te fais une démo de la feature pour t'expliquer ce que j'ai fait pour que tu puisses connaître le métier et en plus qu'on puisse parler de la solution que j'ai construite avec l'IA derrière, mais qu'on retrouve des échanges qu'on n'a plus parce qu'on ne fait plus de la review de fond de code. » Parce que ces juges-là, tu pourrais les aborder ou toi-même les découvrir quand tu faisais une revue de quelqu'un d'autre. Tu découvrais un pattern, tu découvrais une fonctionnalité et tu disais, tiens, la prochaine fois, je pourrais aller la chercher là-bas pour le faire. Comme là, on est en train de tenter potentiellement à diminuer ce truc de revue, il va falloir qu'on retrouve des points de contact pour rééchanger et tout ça à l'intérieur. Et pour revenir sur la création de valeur et la façon dont on a réagi avec les clients, je n'avais pas terminé tout à l'heure, mais quand j'évoquais un peu le cycle actuellement, on produit le même code. que ce qu'on faisait avant. On a un level-up énorme sur la documentation parce que c'est devenu le cœur, l'émotion fonctionnelle. En 20 ans, on n'était jamais arrivé à la maintenir. Là, maintenant, c'est la source de vérité de tout notre process, de toute notre harnais. C'est la doc technique et fonctionnelle. Et elle est dans le repo, elle est versionnée en même temps. Elle vit avec le projet. Et donc ça, avant, on avait peu ou pas, mais ça, c'est bien. Ce qu'on est en train de se rendre compte aussi, c'est que... Là, sur les features qu'on développe là maintenant, que ce soit avec l'IA ou même le fait que le coût du dev est un peu moindre, on a, sur la première version de la feature, on est déjà allé beaucoup plus loin dans les zones vise, les cas particuliers, qu'avant, qui est souvent des cas qui remontaient soit en recette ou soit dans le cycle normal de vie du produit, du projet, qui à un moment, ce client-là déclenche ce cas-là que tu n'avais peut-être pas vu au début. Et là, au final, on se rend compte qu'on a beaucoup moins de retours. de recettes et même de vie, de projet. Et là, par contre, il y a un énorme gain de valeur. Parce que ces retours-là, tu passais beaucoup plus de temps à gérer le retour qui a corrigé ce qui a été fait derrière. Et c'était un truc, en plus, qui était frustrant pour tout le monde à gérer. Gérer un bug, un retour, un trou, un petit sujet, c'est quelque chose qui n'est pas... Ce n'est pas là où tu prends le plaisir. Allez, je développe une nouvelle feature qui a de l'impact et qui fait plaisir à mes utilisateurs. Là, tu as envie d'y passer du temps. Donc ça... On est en train de se rendre compte de ça, parce qu'on le voit bien, puis c'est sûr qu'il y a nos aides à aller trouver les zones d'ombre. Et comme le coût du code, pour les prendre en compte, au début, il y a des fois, on le savait, et on était OK, en fait, le fait de ne pas prendre en compte ça, et que ça revenait quand ça revenait. Mais là, maintenant, souvent, c'est plus arbitrage fonctionnel, de dire on ne prend pas en compte cette partie-là parce qu'elle est trop impactante. Mais en tout cas, ça va plus loin. Donc, au final, on a... le temps en tant que tel pour faire une feature comme on le faisait avant n'a pas tellement baissé. Donc, le coût n'a pas tellement baissé, voire même, peut-être même un peu augmenté parce qu'on a des coûts d'IA maintenant qui se mettent dessus. Par contre, la qualité globale de ce qui est délivré a quand même fait un bond qui est quand même assez énorme. Donc, il faut être capable de trouver des personnes qui sont capables de comprendre ça et être capables de pouvoir se dire « Non, ce n'est pas parce que vous faites tout que l'IA que je vais payer juste de fois moins cher. » Oui,

• Lulu

  il y a ça aussi, parce qu'on peut se dire, bah oui, mais maintenant... pourrait donner une impression de faire baisser la valeur, sauf que le produit à la fin est meilleur que si ça avait été fait à la base. Mais est-ce qu'il y a un peu des frictions par rapport à ça avec les clients ?

• Manu

  Non, parce qu'on a la chance de... Je ne dis pas de choisir les clients, mais on a la chance d'avoir des projets clients où on arrive à établir une relation de confiance qui fait que ça, ce n'est pas un sujet. Ils ont confiance dans ce qu'on délivre, on a la vision du budget. On est capable aussi d'aller jauger les fortes valeurs qu'on met sur le projet par rapport au contexte qu'il a à lui en instant T. Et ça, c'est ce qu'on a toujours fait. C'était déjà ça, en fait, déjà avant. Donc là, ils nous font confiance. Et par contre, le gros changement qu'on a eu, nous, c'est qu'on a arrêté de vendre du jour homme. Et ça, moi, je n'étais pas à l'aise. Vendre du jour homme, c'est limite… C'est un peu… Moi, je vends des hommes, mais non. et ça fait des années et pourtant, à un moment, j'ai pris mon bâton de pèlerin pour dire, il faut qu'on arrête de faire du forfait quand on est sur des projets de notre taille à nous parce que c'est une hérésie de s'engager parfaitement sur des projets à 100 ou 200 000 euros. le client ne sait même pas ce que tu veux faire, tu es venu t'engager exactement en temps et en coût sur ce qu'il veut faire. Non. Donc, à un moment, on était en mode je facture, moi, à la fin du mois, le temps réel que j'ai passé sur le client. Et là, nous, on a changé ça avec justement les nouveaux projets IA où je ne parle plus du tout de jour. Maintenant, on a une estimation du projet qui reste en mode fourchette, allant souvent pas trop du top tout, parce que je dis, la fourchette basse, c'est si on restreint et qu'on va sur les barres des fonctionnalités, la fourchette haute, c'est si tu veux aller au bout, et la fourchette haute, dans un an, c'est le budget qu'il faut que tu aies, parce que quand on aura fait tout ce que tu veux, ce sera la fourchette haute. Par contre, si tu rapproches du MVP, si tu es capable d'arbitrer des simplifications fonctionnelles, on va tendre vers la fourchette basse. Mais c'est lui qui positionne le curseur entre les deux. Et nous, on dit, maintenant, une fois qu'on a positionné le curseur, une fois qu'on a fait l'aspect pour l'itération là, qu'est-ce qu'on va mettre dedans ? Moi, une fois qu'on a défini ça, je peux m'engager au forfait sur une fonctionnalité. Et je m'engage sur une fonctionnalité. Un truc entre 2000 ou 3000 euros. Parce que moi, j'ai plus d'incertitude là-dessus. En plus, on a formalisé l'aspect, elle est carrée, on a mis la haute hôtesse dedans. Il n'y a plus aucun aléa qui me fait dire qu'il ne faut pas que je... ne peut pas m'engager. Et donc là, et moi, je facture à la fin à la recette. Quand la recette a été faite, je facture la fonctionnalité. Donc, ça remet vachement d'engagement aussi côté client par rapport à ça. Je n'ai plus le truc de dire on vous fait un chèque en blanc parce qu'il me finit avant on avait, on est zéro risque, on facturait juste le temps qu'on passait sur le projet. Enfin, si ça marche ou si ça ne marche pas, on facturait. Oui,

• Xavier

  peut-être. Tu as quand même bossé dans l'histoire, tes gars ont bossé, donc tu en as besoin. Mais c'est vrai que là, en plus, c'est un cercle vertueux parce que tu factures du coup à ce qui est vraiment délivré et à la feature. Et donc vraiment besoin et l'implémentation. Et en plus, on a recette, donc vraiment quelque chose que le client va pouvoir percevoir. Début déjà quand il donne son avis et en plus, dès qu'il l'a dans les mains et avec ce que j'imagine être des cycles de devs du coup beaucoup moins longs. Parce que ça implique des recettes plus rapprochées et donc plus de moments où en fait il va être impliqué, il va être dedans. Et de par ce que tu expliquais avant, le fait que tu augmentes tout en termes de qualité, toutes les zones grises, donc tous ces moments qu'on avait du mal à anticiper, des cas clients un peu particuliers qu'on n'avait pas bien pris en compte, qu'on n'avait pas anticipé pour mille raisons, parce que dans la vie, il y a mille raisons, que ce soit métier, que ce soit technique, etc. Tous ces trucs-là, c'est du support au moins. Donc, c'est des choses qui vont faire que ton client sera plus content. Son produit va mieux marcher, donc il va être d'autant plus heureux derrière. Parce qu'effectivement, quand un problème qui survient et qui implique de passer par le support, globalement, tu as deux grosses familles. Ça va être soit c'est un problème métier et il faut expliquer à la personne comment servir du programme de la bonne manière pour arriver à ses fins. Et c'est là et c'est disponible. Soit effectivement, tu as un problème technique. Enfin, du coup, il y a trois ans, j'aimerais dire. Soit c'est un problème technique, un petit bug, un truc comme ça qui a été manqué, qu'il faut corriger. Soit c'est un problème lié à une mauvaise compréhension de base qui va devoir se faire questionner sur une fonctionnalité, mais qui va impliquer toucher à plein d'autres choses autour. Et c'est ça qui met le bordel, qui rajoute du temps, qui rajoute de la complexité à tous les niveaux.

• Lulu

  et qui fait repartir en plus du début il faut repartir du premier besoin métier pour le retraduire différemment et que ça marche avec tout le reste et le refacturer aussi parce que c'est presque une autre fonctionnalité et c'est pas de la maintenance de

• Manu

  toute façon un bug ça a jamais coûté cher à corriger technique ce qui coûte le plus cher c'est un désalignement entre le besoin et la solution donc un moment qui fait que la compréhension qu'on avait que l'équipe technique pour trouver la solution, il y a eu une incompréhension sur le besoin du client. Et là, vu qu'on a déplacé beaucoup de temps en avant sur la conception, on dérisque énormément ces sujets-là. Parce qu'on a plus de temps, parce que l'IA nous aide aussi à écrire, à formaliser, et que le client, quand il dit « Ok, ce qu'on va faire, je l'ai vu, je l'ai lu, je l'ai signé, je l'ai engagé, si ça change, je vais la valider en fait. » Et c'est pour ça qu'on doit trouver, c'est pour ça que nous on fait souvent, on va souvent essayer d'aller très tôt demander au client comment il va tester ce qu'il nous demande de développer. Parce que souvent, là, il y a un truc qui émerge. Il y a des trucs, il y a des trous, des zones grises qui sortent là. Quand on demande à quelqu'un d'exprimer son besoin, et quand on lui demande de dire comment tu vas vérifier que ce que tu lui demandes marche, il y a souvent des trucs qui apparaissent. Et si ils apparaissent lors de la recette, c'est ça qui peut faire mal. Si on les a en avant la conception, ça a zéro coût.

• Lulu

  J'aime beaucoup aussi la partie de se dire, parce que c'est toujours compliqué de dire, la fourchette, ça va être ça, mais il n'y a pas cette... vision, de se dire si j'en demande plus forcément ça va être plus cher, si j'en demande moins et là ça donne un peu aussi de la main au client de se dire ok je dois prioriser ça va coûter tant et c'est pas un ensemble et lui ça le force aussi à être peut-être plus partie prenante de se dire ok la prochaine fonctionnalité c'est celle-là et pas partir dans tous les sens et...

• Manu

  Le... le... Sur le côté budget, il y a deux choses. C'est que maintenant que le coût du dev est en train de diminuer, on observe, ce n'est pas encore là, mais on fait attention à ce qu'on ne tombe pas dans des traverses qui font qu'on essaye plein de choses et on se perd dans la vision produit. On parle de la place du PM dans les produits hauts, qui est important de garder la vision produit. Et moi, ce que je n'ai pas envie, c'est que les utilisateurs des produits de mes clients subissent. qu'on subit nous avec le cloud code où tous les jours quand tu le lances tu te dis tiens qu'est-ce qu'il va y avoir comme nouveauté qu'est-ce qu'ils ont ajouté qu'est-ce qu'ils ont enlevé c'est à peu près ça dès qu'on le lance ça change il y a de tous les côtés ça on l'accepte c'est notre outil mais un utilisateur tu ne peux pas lui mettre 4 fournités par jour en changer 3 et en enlever 2 donc cette vision là avant on avait le côté du budget qui permettait de restreindre et de canaliser le client il a changé un peu parce que le coût à la fois de réalisation et même d'expérimentation c'est tout ça la conception on diminue la capacité qu'on a à expérimenter des choses avant de le développer. C'est ce qui nous permet de dérisquer un maximum et d'être sûr qu'on soit aligné sur le vrai besoin et la vraie compréhension. On remet du temps de dev dans la conception pour faire des prototypes et tout ça derrière. C'est pour ça que ça coûte pas. Le prix n'a pas tellement changé. Par contre, on a dérisqué et la valeur a énormément augmenté. Et il faut trouver des clients qui comprennent ça ou qui ont confiance en toi. pour se dire que, oui, nous, on est sur des projets où ils sont là pour longtemps, en fait. On n'est pas là à faire du projet qui va être jeté. On peut, alors qu'on ne pouvait plus. On ne pouvait pas, parce que là, s'il faut, on peut. On peut dire à notre framework de dire, ne fais pas de test du tout. On fait en one shot. On fait des prototypes en mode jetable. On en fait plein, d'ailleurs. On en fait de plus en plus. Donc, on pourrait très bien en faire un qui soit, qui parte en prod, en pseudo-prod ou en mode MVP. C'est ça qu'avant, qu'on ne connaissait pas. Mais en tout cas, nous, on reste quand même à faire un projet qui est là pour durer et dans lequel tu as confiance et que tu es capable de dire je peux le faire évoluer et je ne vais pas serrer les fesses à chaque fois que je vais mettre en prod.

• Xavier

  Oui, ce qui reste le plus important.

• Manu

  Oui. Et encore plus pour le dev parce que si tu dis ça appartient en prod là, nous, il y a des projets et il n'y a plus de mise en prod dans la journée. Parce que tu as juste confiance. Tu l'envoies, tu l'envoies.

• Xavier

  Maintenant, du coup, Justement l'impact sur les équipes parce qu'on a vu tous les bienfaits tout ce que ça a apporté en tout cas chez vous, que ce soit côté client côté équipe, côté boulot, côté produit mais tu l'as évoqué un petit peu tout à l'heure ça implique déjà une nouvelle approche au sein de l'équipe pour que tout le monde monte en compétence en même temps et s'approprie ces nouvelles technologies en même temps et l'autre enjeu c'est avec ces nouvelles manières de bosser et ces nouvelles manières de délivrer et et le fait que l'IA permette de balancer et d'avancer sur plein de sujets potentiellement, enfin si on ne se met pas un cadre on peut se lancer dans 10 tâches en même temps même en restreignant du coup en fonction de l'implication qu'on va mettre dans chaque tâche etc, juste d'en avoir 2-3 en parallèle ça peut déjà être énorme comment justement vous l'avez vécu en interne et qu'est-ce que vous faites aujourd'hui pour que ça aille dans le mieux et vous adapter ?

• Manu

  Déjà le principal pas le truc qu'on a vécu, c'est, historiquement, on passait 80% de notre temps à faire le dev, à être tout seul. derrière son ordi, son écran pour faire le dev, et donc être capable de pouvoir gérer nos moments de respiration à notre rythme. Ce qui se passe là, c'est que maintenant, ces moments de respiration-là, on ne les a pratiquement plus. En tant que tel, on n'est plus maître parce que soit on interagit avec l'IA, et comme tu le disais, potentiellement avec plusieurs sessions en cours, ils te posent des questions et tout ça derrière, ou soit, et ce qui est cool, nous on fait beaucoup plus d'interactions ensemble, avec le client, avec des personnes, parce que c'est la conception et tout derrière. Mais ces moments-là, ils sont là. haute charge cognitive, ils sont hyper intenses, et en fait, si tu les enchaînes, nous là, on sait très bien que le rythme qu'on a là, si on continue comme ça, on va griller tout le monde. Et le pire qu'il y a, c'est que personne n'a du mal, on dit qu'il faut qu'on ralentisse, mais en fait, on a tous envie d'avancer, on a ces limites des patterns d'addictologie, avec la dopamine, j'ai mes super pouvoirs, j'avance, on ne se rend pas compte qu'on est en train de se griller par rapport à ça. Moi le premier. et l'équipe derrière. Donc, si on n'arrive pas à trouver une orga où on retrouve des moments de respiration, parce que faire de la conception 7 heures par jour, 5 jours par semaine, ça ne passe pas, en fait. Tu ne peux pas tenir. Et donc, nous, là, si on ne fait pas ça, on fait quoi, en fait ? C'est-à-dire que, jamais, je vous reciterai, c'est des discussions qu'on a avec l'équipe. On a fait des ateliers en disant comment on va retrouver ces moments de respiration-là, comment on va éviter de se griller avec des choses qui sont pas bonnes. assez commun pour éviter d'avoir quatre projets en cours et tu passes en plus d'un projet différent à chaque fois, donc le contexte switching est encore plus douloureux, on se dit peut-être qu'il faut... Qu'est-ce que je peux faire pendant que mon agent bosse ? Si je me dis... Et tout le monde dit, ok, fais autre chose. Mais souvent, quand il se fait autre chose, tu vas lancer une autre session sur autre chose derrière. Et là, on est en train d'explorer des choses en disant, peut-être que ça serait bien... On parlait tout à l'heure de la connaissance et on a formalisé la connaissance. Peut-être que pendant que l'agent travaille, on est capable d'en avoir un autre qui t'a permis d'explorer, de discuter, d'aller explorer le fonctionnel, d'aller explorer la technique, peut-être d'aller t'expliquer ce qu'il est en train de faire là avec des artefacts, quelque chose de visuel et haut de derrière qui te permet d'éviter de faire d'un contexte switching profond de technique et haut de derrière, mais qui t'a quand même meublé à toi et qui t'a permis de pouvoir éviter ça. Mais ça ne t'empêche pas le fait que... tu es quand même sollicité, tu es quand même grillé et que je pense, c'est un vrai sujet là, on parlait de retrouver des moments de respiration, on est en train de se dire, ces moments de respiration là, de toute façon, ça ne pourra pas être des moments clients, parce que tu ne vas pas respirer sur des moments clients, ça ne pourra pas être des moments de projet interne, parce que tu ne respireras pas pareil dessus, c'est juste la mèche ou voire même pire, même tout ce qui est arrêt des formations, c'est limite encore pire que pire. parce que c'est des trucs qui peuvent être à fond, qui peuvent être hyper intenses. Et donc, qu'est-ce qu'on peut faire pour respirer ? Il va falloir qu'on fasse des trucs qui ne sont pas directement liés à notre activité. Peut-être aller se dire, on en fait déjà beaucoup, mais faire des moments ensemble, le team building, aller faire des randos et tout ça. On est en train de se dire, ça serait peut-être sympa qu'on aille peut-être donner un coup de main à une assoce. Tiens, moi, j'adorerais, j'adore le bois et tout ça, j'aimerais bien aller peut-être voir quelqu'un qui fait de la menuiserie aller faire autre chose que ce que je fais là. Et je pense qu'en plus que tous ces moments-là auront aussi un apport sur ce qu'on est pour trouver des solutions à des besoins qui sont des trucs où tu as besoin un peu de changer. C'est quelque chose qui sera capable de nourrir ça. Le problème de ça, c'est qu'il faut trouver une équation économique à tout ça. Il faut trouver une orga qui va derrière. En tout cas, nous, c'est des sujets, ils sont sur la table. Là, maintenant, tout de suite, il y a trop de trucs qui ne sont pas assez figés pour qu'on soit capable d'engager. Parce qu'en plus, des chantiers comme ça, il y a des choses que tu peux... peu engagés qui seront très difficiles à être tricotés après. Donc, il faut être sûr que tu puisses avoir les moyens et le truc pour le faire. Mais en tout cas, on parle beaucoup dans l'IA de la réduction de temps de travail et tout ça. Moi, j'y crois fortement. Et que le truc, ça, c'est qu'on sera capable de produire assez de valeur sur ce qu'on fait à côté qui va nous permettre de respirer ça. Par contre, moi, ce que j'ai dit à l'équipe, c'est qu'on prend le côté du 4 jours pour simplifier. Il nous faut une journée de plus pour respirer. Moi, ce que je leur ai dit, c'est que moi, ce que j'aimerais, c'est que ça ne sera pas une journée de congé. C'est une journée, et là-haut, c'est une journée équipe. C'est une journée de choses qu'on partage ensemble, qu'on fait ensemble, et qui produit de la valeur sur le collectif aussi en tant que terre.

• Lulu

  Et pourquoi pas l'open source aussi ?

• Manu

  Oui, alors l'open source, ce que tu te chasses, ce n'est pas d'open source comme moi je le fais, d'aller donner des coups de main à des assos, d'organiser des événements qui te font quand même changer de contexte. Quand je parlais d'assos...

• Lulu

  Pas de temps d'écran, même de ne pas être devant un écran et de changer. Justement, j'avais vu... dans les différentes sources que tu avais envoyées, ça a renvoyé vers d'autres articles scientifiques sur... comment la résolution de problèmes, comment est-ce que l'innovation, elle arrive, et qu'il y a besoin justement de ces temps de pause. Et souvent, des temps de pause qui sont... Enfin, des temps de pause, on peut continuer à travailler, mais sur des tâches qui ne demandent pas beaucoup d'efforts cognitifs, potentiellement des choses qui sont assez répétitives. Et c'est là où il va y avoir un peu une nouvelle vision, qu'on va revenir sur un projet sur lequel on planchait. Enfin, vraiment, il y a un problème, on n'y arrive pas. Et plutôt que de rester devant et de partir dans l'IA, à essayer de questionner. de faire des boucles et puis de sperme, de juste s'arrêter, faire autre chose, mais vraiment autre chose qui n'a rien à voir, pas un autre projet et qui ne demande pas trop. Et c'est là qu'on voyait que justement, la créativité était d'autant plus poussée et quand c'est aussi des tâches qui sont divergentes, donc vraiment qui n'ont rien à voir et que ça inspire beaucoup et que ça peut aider à trouver de nouvelles solutions, de résolution de problèmes et de moins se fatiguer aussi.

• Manu

  Moi, mes meilleures idées que j'ai eues, c'est lors de mes trajets à vélo, je fais 38 mètres par jour, ces moments-là. Mais c'est vrai, tu parles du côté objectif, je suis déconnecté, je suis moi-même dans ma réflexion et autres. Et j'ai la chance en plus à Lyon d'être sur les berges du Rhône où j'ai moins d'attentif, j'ai moins d'attention aux autres, mais moins aux voitures et tout ça, parce que je suis isolé. C'est vraiment hyper privilégié là-dessus.

• Lulu

  Oui, en tout cas, ça permet aussi d'avoir la chose en fond. Ça, c'est quelque chose... Là, j'avais été à la NoCode Week cette année, donc c'est un rassemblement autour du NoCode. On va parler d'outils, il y a des conférences, des ateliers et tout ça. Et justement, on avait fait un hackathon. J'étais avec deux autres personnes et on avait eu le brief, on avait eu le problème auquel on devait répondre. C'était d'aider la ville de Francfort d'une manière ou d'une autre et après de mettre de l'automatisation derrière avec N8N. On a démarré le hackathon, on n'a même pas pris le temps de discuter et de regarder autour de nous comment est-ce qu'on… Et c'était tout de suite Claude Codd, donne-moi des idées pour aider. Ils ont balancé même les slides de présentation, ils n'ont même pas pris le temps d'expliquer le problème. Vas-y, juste de se poser, de discuter, de regarder. C'est triste.

• Manu

  Oui, mais ça va dans le côté de je veux optimiser, je veux aller vite. Mais quand on faisait des projets, on demandait aux clients, mais moi j'ai envie d'aller voir comment... dans quelles conditions sont les utilisateurs. Je veux les voir travailler, je veux voir les points de contact qu'ils ont avec leurs produits actuels pour être capable de me projeter sur ce qu'on va changer. Et parce que s'il y a un truc qu'on ne voit pas là, mais qui peut changer complètement, l'adoption est au derrière. Les comprendre est autre. Donc, tu as aussi ces moments-là où tu vas aller te balader, découvrir et autres derrière, qui ne sont pas autant des moments où tu es en stylie intense, en mode rapide, question-réponse. Et encore, il met des fois 10 minutes à répondre. Dans pas longtemps, quand il te répondra de manière immédiate, ça va changer aussi la donne.

• Lulu

  Ça, et puis même de parler plus avec le client, ça permet de donner plus de sens au travail, de te dire pourquoi est-ce que je viens au boulot tous les jours ? Pourquoi est-ce que là, dans ce moment difficile, j'ai quand même envie de continuer parce que j'ai envie de délivrer ?

• Manu

  Et donner plus de sens à la valeur que tu produis. On en revient à la discussion sur le prix et haute qu'on fait parce que nous, typiquement, on ne pouvait plus vendre de la journée alors qu'on ne maîtrise pas les coûts. d'IA qui peuvent changer du jour au lendemain. Le jour où, moi, mes coûts d'IA font x2, beaucoup de ma fonctionnalité augmentera, mais parce que c'est mécanique. Moi, l'avantage, du coup, de la fonctionnalité, c'est que potentiellement, même, en fonction de la valeur que je produis, si je bosse pour une asso, pour quelqu'un qui a une vraie vision et du budget, je peux faire la même chose avec deux prix différents, parce que ça dépend de la valeur que je produis. Et ça, c'est des trucs qu'on ne pouvait pas faire avec la vente de la journée.

• Lulu

  Oui,

• Xavier

  c'est clair. Et du coup, là, aujourd'hui ? Est-ce que justement, tu as des gens dans l'équipe qui se sont déjà retrouvés rincés en mode, il faut qu'on lève le pied dès maintenant ? Ou c'est encore, pour l'instant, vous êtes un peu plus... Non,

• Manu

  non, et le pire, c'est qu'il y a des personnes qui étaient, en plus des personnes qui étaient celles qui remontaient tout, qui avaient zéro filtre et c'est cool sur le truc, se rendre compte qu'elles se sont pratiquement grillées toutes seules, alors qu'on avait zéro pression de projet, zéro pression globale du truc. Mais elles étaient dedans, nous on se bat, parce que quand on voit les heures qui sont faites en plus, on se dit, mais non, arrête ! Ce n'est pas la peine, mais c'est très dur de la gagner. Donc là, quand on parle de ralentir, ça va être de vouloir ralentir. Et le problème, c'est qu'il y a un moment où ça va aller au point de rupture et qui va poser un problème. Moi, mon rôle, c'est de trouver, de le savoir, de faire attention et que collectivement, on arrive à s'organiser pour arriver à trouver la bonne équation. Je n'ai pas l'équation là, mais par contre, on sait qu'on est hyper vigilant là-dessus et qu'on a des petites expérimentations, ça va se faire par un petit truc. Et il va falloir naturellement repenser le quotidien autour de ça. Et ce qu'on vit là, nous, dans le dev, ça va arriver de partout pareil.

• Lulu

  Partout, oui. C'est ça, c'est qu'en fait... Tous les métiers techniques orientés développement et qui sont vraiment les plus au contact de l'IA sont à l'avant-garde de ce que tout le monde va se manger côté métier.

• Manu

  Et c'est pour ça que, toi, typiquement, les confs que je donne ou aller faire des podcasts comme ça, ça fait partie aussi de la responsabilité d'aller insuffler ça et faire prendre conscience que, attention, si toi, ta seule confiance est le gain de productivité que tu vas avoir sur ton équipe et ce qu'elle produit, ça va faire du mal. et ça ne marchera pas dans le temps.

• Lulu

  Et justement, j'aimerais bien avoir ta vision sur le... On ne peut pas être catégorique de toute façon et savoir exactement comment ça va se dérouler, surtout au vu des changements très rapides côté IA, mais quelle est ta vision un peu de l'IA, en tout cas à moyen terme ? Comment elle va évoluer, justement, côté taf ?

• Manu

  Tu parles globalement dans le métier tech ou globalement dans la société et un peu plus global dans ce qu'on vit même hors de nos métiers ?

• Lulu

  Comme tu veux, un peu les deux. C'est vrai qu'il y avait le point où justement, on a parlé un petit peu en off avant d'attaquer l'épisode, où tu imaginais l'équivalent d'un lovable pour tes clients qui viennent dans la logique justement de ce que vous proposez. Donc ça, c'est un des points, mais on a parlé aussi, pareil, un peu en off justement de la revue de code. Et ça, du coup... Si vous nous écoutez la semaine prochaine, vous aurez un développeur qui est orienté et qui la revue de code tient à cœur et justement qui a réinventé sa manière de faire la revue de code avec l'IA, qui en parlera également. Je sais que ma vision, elle se rapproche de ce qu'on s'est dit avant sur le fait que, pour moi, le code en lui-même va devenir, enfin, ce n'est même pas une commodité, c'est que je veux dire, ça va devenir quelque chose que les humains ne vont plus avoir à se soucier globalement d'ici. je ne sais pas, ça sera peut-être un an, deux ans, mais en tout cas, de manière assez proche, je pense que les enjeux, effectivement, ne seront plus dans la partie exécution technique du code et le code en lui-même, mais que tous les enjeux vont se faire autour et de manière différente. Et voilà, du coup, je veux bien t'entendre.

• Manu

  Alors, là où je te rejoins, c'est que oui, et moi, je partage la même vision, c'est que sur un avenir plus ou moins long terme, le plus ou moins peut être assez variable avec ce qu'on a, ce qu'on vit là, dans les rythmes IA. le code en tant que tel, nous, déjà, on le voit, n'est plus l'équation centrale qu'elle était depuis 20 ans dans nos métiers. Et il faut l'accepter, en fait. Et le plus dur, c'est de l'accepter pour les équipes de dev. Le gros du challenge, il est là. Et de tout ce qu'on voit, le gros du challenge va être dans la conduite du changement des équipes. Les outils, ce ne sera pas un souci. Les modèles ne seront pas un souci. Les capacités des organisations à encaisser des changements profonds de leur quotidien, c'est le plus gros du challenge. Donc, nous, dans nos quotidiens, là où on veut pousser, justement, maintenant, c'est aller au-delà, au-delà de la ligne de commande de Cloud Code, au-delà de l'appropriation et l'augmentation, finalement, des capacités en équipe. Parce que là, on lève la porte, ça rayonne un peu autour, mais pour l'instant, c'est quand même elle qui reste le maître de l'orchestration et tout ça. Donc, nous, l'objectif qu'on a, c'est de faire sortir ces outils-là pour qu'ils soient accessibles aux personnes non tech. à la fois côté interne chez nous, tout ce qui est UI, UX et côté produit, projet, et aussi ce qui se passe après sur la partie QA et tout derrière, que toute la chaîne soit capable d'aller interagir avec la connaissance qu'on a formalisée avec le produit, et je vais même plus loin, qu'elle soit capable d'aller aussi être capable d'aller modifier, participer à la vie du projet, du produit, dans le harnais, dans l'écosystème qu'on aura nous construit côté tech. pour garantir que les personnes qui interviennent qui sont non tech, on est capable de cadrer l'impact qu'elles vont avoir et qu'on soit capable de le mettre dedans. Mais je termine une de mes confs en disant, on va tous redevenir makers, on va avoir un seul métier, et chacun arrivera avec son expérience et son expertise pour interagir, lire et écrire dans un produit en tant que tel. Et ça, c'est nous en tant que tech, on a la responsabilité d'aller construire cet écosystème-là qui va permettre... tout le monde de devenir acteur des projets.

• Xavier

  Oui, justement, c'est vrai que je...

• Manu

  C'est un truc profond qui va... ça va changer tout, parce que le dev était un petit peu la porte où il fallait passer, et quand il n'y avait pas de dispo, ben t'attendais.

• Xavier

  C'est vrai que même nous, il y a eu le no-code, mais parce que ça restait quelque chose de très fermé, il fallait savoir développer pour faire des choses. Donc là, le no-code maintenant, l'IA permet d'ouvrir aussi ses portes et de se dire, je peux construire des choses et interagir aussi après avec d'autres métiers. Et ça, on en a parlé aussi un tout petit peu avant. Je crois que l'IA peut aussi être facteur d'inclusivité, d'accessibilité, de personnalisation aussi. Parce que la même information, une doc, tout le monde ne va pas l'appréhender de la même manière, que ce soit son fonctionnement, que ce soit son métier, que ce soit ses compétences. Donc comment est-ce qu'on peut amener de l'IA ou une autre techno pour personnaliser et que tout le monde puisse devenir un peu partie prenante du projet et appréhender les informations ?

• Manu

  Ça, c'est un des gros sujets qu'on a, notamment sur le côté des juniors. Comment on va faire monter en compétences, en connaissances là-dessus ? C'est un énorme... sujet, alors là je pense qu'il nous faudra encore une heure si on aborde ça et je serais ravi de refaire un sur ce sujet-là là-dessus parce que moi il est vraiment important Avec plaisir parce que je pense que beaucoup de personnes se posent des questions là-dessus. Et même globalement la transition du savoir, il va falloir revoir profondément beaucoup de choses pour encaisser ce qui va arriver. Mais en tout cas je sais que ce qu'on a construit là typiquement tout le parcours qu'on a construit des équipes entre le besoin et son code, en ne changeant pas grand-chose dans les instructions de ces agents-là, on pourrait lui dire, écoute, en face de toi, tu as un junior, en fait. Donc, tu vas expliquer, tu vas prendre le temps, tu vas peut-être même faire exprès de faire des erreurs pour voir s'il les voit. Et ce qu'il y a, c'est que ce cheminement-là, la finalité sera toujours la même. Que ce soit le senior ou que ce soit ça, le harnais qu'on a construit, tout ça, c'est juste un moment où le chemin pour arriver à la finalité qui sera différente et... Au final, ce qu'on est en train de dire, c'est qu'on va tous devenir, on devient tous des ingénieurs au sens propre du terme, de trouver des solutions à des besoins. Le côté technique n'est pas tant important. Par contre, la capacité de se projeter sur la découposition d'un problème pour trouver le truc le plus simple, pour essayer de l'attaquer. Et derrière, ce qui sont des trucs de pratique qui sont faits, tu ne pourras jamais l'apprendre, il va falloir le pratiquer, l'expérimenter. Ça va être ça, les enjeux qu'on va devoir avoir sur les juniors, leur capacité à tant de connaître les langages, du connaître comment utiliser et comment valoriser la chaîne entre l'idée et sa réalisation derrière.

• Xavier

  Oui, c'est presque un peu ce qui était fait avant avec le... Après, je ne sais pas si vous faites... Bon, c'est plus du pair programming maintenant, mais des sessions à deux, peut-être, avec la machine en face. Comment est-ce que ça a pu être réinventé, un peu, ce concept de pair programming ?

• Manu

  Alors, si tu es avec Claude, Claude, c'est ton père de tous les jours, en fait. Oui, oui, oui. Par contre, le côté du pair programming en mode de jeu partage, c'est ce qu'on disait tout à l'heure, nous, on est en train d'essayer d'aller l'expérimenter à plein de niveaux parce qu'on est en train de couper le côté du collectif. On n'a plus de review, on a des projets où on a moins de personnes en même temps sur le projet. On arrive à garder ce partage de la connaissance, ce partage de la connaissance du projet, des briques, de l'outil et de l'outillage. Et c'est pour ça qu'on multiplie, nous, les points de contact. Et là, on a même à un moment exploré le fait de dire que, techniquement, ce que je viens de faire là, je vais le faire recéder par un autre dev qui n'est pas parti du projet. C'est-à-dire que ma feature qui a été faite, il y a les autotests, ils sont là. Et en fait, c'est quelqu'un d'autre qui va le recéder. Ça lui permet de comprendre et de monter sur le projet et potentiellement d'aller le recéder en ayant vu le code pour essayer de comprendre aussi un petit peu l'implément qu'il y a derrière.

• Xavier

  Justement, moi, ça me fait penser, ça, c'est quelque chose que j'avais eu dans mon master et que... J'avais pas vraiment retrouvé ailleurs en discutant avec d'autres personnes. C'était un master en alternance, plus axé sur chimie, biologie, mais en sciences analytiques. Et c'était en apprentissage. Et une des choses que le responsable du master ne voulait absolument pas, c'est que notre alternance, apprentissage, notre domaine, conditionne ce qu'on allait faire derrière absolument. Et on revenait... à la fac toutes les deux semaines. Et toutes les deux semaines, on avait une présentation de quatre minutes avec des slides où on devait présenter une problématique qu'on avait rencontrée pendant nos deux semaines d'alternance. Et après, les autres étudiants devaient poser des questions. Et comme ça, tout le monde savait à peu près ce que chacun faisait, sans forcément connaître à fond le domaine, sans y avoir travaillé. Lui, sa conviction, c'était qu'après, en entretien, on était quand même capable d'en parler et de changer de domaine et pas rester conditionné et tout seul dans son coin sans savoir. Et on devait écrire après des rapports pour dire qu'est-ce qu'on a appris, comment est-ce que moi, ça peut m'aider dans ma pratique. Enfin, voilà, bon, c'était scolaire, mais je sais que moi, ça m'a aidé à avoir vraiment une vision globale sur tout. plein de domaines que je n'aurais pas pu autrement parce que ce n'était pas des personnes avec qui je discutais, on ne voulait pas forcément discuter de ça et on n'avait pas cette formalisation de comment on travaillait en entreprise.

• Manu

  Mais tu sais, ce que tu évoques là, je te disais, il y a un des sujets, c'est tout ce qui va être en amont, on avale du dev, on a encore du boulot à essayer d'aller adapter aux changements qu'on a prévus. Typiquement, on a Eva qui est la partie un peu plus Merci. proxy PO qui fait souvent, qui aide à formaliser l'idée du client, c'est elle qui souvent formalisait les besoins, faisait les tickets. Avant, pour ça, maintenant, il y a une partie de cette tâche-là qui s'est fait outiller complètement parce qu'on est capable de les formaliser, on est capable de les structurer, on a les comptes rendus automatiques de tous les ateliers qui sont là derrière. Il y a une grande partie de ces tâches, on va dire manuelles qu'elle faisait, qui sont maintenant outillées. Et le problème, c'est qu'elle, c'était ces moments-là qui lui permettaient de comprendre. et de saisir le projet. Si tu lui enlèves ça, tu ne vas pas lui dire d'aller lire la doc pour se mettre dedans. Ce n'est pas possible. Il faut faire pour assimiler. Et donc là, on est en train de se dire comment on ne va pas le dire, tu lis la doc pour lire la doc. À un moment, on se dit, peut-être qu'il y a autre chose à faire. Et là, l'édition qu'on a avec elle sur la nouvelle place qu'il va falloir qu'elle prenne, qu'elle trouve dans les projets, et moi, je pense qu'il y aura une tâche qui va être vachement importante, c'est la personne qui sera capable d'animer les interactions au sein d'un projet. on parle d'un projet, on parle de communauté, des sujets que j'ai eu beaucoup aussi avec Amélie, sur ces sujets-là, en fait, l'animation des interactions au moment où on a des outils qui nous permettent d'être encore plus ensemble, va devenir hyper importante, parce que si ce n'est pas structuré, si ce n'est pas animé, si ce n'est pas fait, elles ne seront pas efficaces. Et des réunions pas efficaces, ça ne sert à rien et ça grille tout le monde. Par contre...

• Lulu

  ça demande aussi de la rigueur la conception les ateliers la recette ça va être des sujets qui vont être importants on tient en accord sur le fait qu'il y a des enjeux ce qui va avec l'animation c'est l'échange humain et la compréhension des besoins et des besoins des autres et des besoins métiers etc et le fait de formuler et d'en discuter oralement implique de se poser des questions de rebondir sur les interactions Et c'est des choses comme ça, effectivement, qui font partie du vivant, qui font partie de ce que la machine ne pourra pas s'approprier de toute façon, même si elle nous aide à les faire sortir, à les traduire et tout ce qu'on veut. Et après, il y a un autre versant sur la partie PO, c'est peut-être aussi qu'une partie de son taf va évoluer vers peut-être davantage de concrétisation technique, en tout cas d'utiliser des outils pour aller, je ne sais pas, peut-être justement mettre en œuvre des... des composants ou des interfaces ou tu vas prendre une part de développement ?

• Manu

  On voit arriver, parce que là on est en pleine discussion justement sur faire le tour de là et essayer de se projeter en disant déjà qu'est-ce qu'on a besoin et est-ce qu'elle se projette là où on a des besoins, parce que c'est aussi important là-dessus. Il y a un truc qui vient d'émerger dans nos discussions là, qu'on a remonté avec l'équipe, c'est un des rôles qu'on avait peu ou pas, on parlait de la documentation, mais quel est celui qui est le gardien de cette documentation-là ? Notamment, c'est beau de l'écrire, mais il faut être sûr qu'elle soit... clean, qu'elles soient archivées, les trucs qui sont plus d'actualité, le curateur, celui qui est responsable de s'assurer qu'elle est ok et elle doit animer, puis au fur et à mesure que tu rajoutes des fichiers à un moment, ça va peut-être le coup d'aller les réorganiser, d'aller exploser certains pavés, donc ce côté-là d'animation, de responsable de la doc, je pense que c'est quelque chose qui va prendre de la place aussi, qui demande aussi de la rigueur, et qui permet d'assurer que tous les outils qui vont exploiter ça il soit OK et que ce ne soit pas juste un truc où on rajoute des fichiers de tous les côtés et à la fin, tu ne t'en rends pas compte parce que tu ne lis pas toi-même. Mais si ce n'est pas bien rangé, si ce n'est pas à jour, ça posera des soucis après dans le code qui est produit derrière.

• Xavier

  Et même se demander comment... Alors là, la documentation, c'est beaucoup de markdown, mais de se demander comment est-ce que je peux la présenter pour qu'elle soit lisible par d'autres personnes pour ne pas... Voilà, ça on en parlait aussi. On en parlait aussi. De ne pas se retrouver à lire... toute la documentation, tout le Markdown, mais de le présenter pour que ça soit encore plus accessible, plus visuel aussi.

• Manu

  Ça, c'est aussi des gros sujets qu'on a, de ne plus avoir à lire les Markdowns, mais d'être capable de trouver un canal. On parle beaucoup des artefacts qui sont des fichiers HTML qui sont capables de mettre en forme, d'avoir une interaction qui est beaucoup plus visuelle, voire même dynamique. On pousse le curseur encore loin, qui est personnalisé par rapport à moi. Cet artefact-là, il m'était généré pour moi. pour l'instant auquel j'y suis, parce que là, je suis en mode de conception ou en mode de validation en fonction du moment d'interaction avec le projet. Et peut-être même, le format dépend de celui que moi, j'apprécie le mieux pour le comprendre. visuels, audio et tout ça. En fait, et ça, l'IA est très très forte pour ça. Mais là-bas, ça sera toujours le fichier Marion qui sera l'exhaustivité de la référence de la source de vérité du contenu. Il sera là et je pense que nous, on en lira et on fait tout pour en lire de moins en moins dans son format brut.

• Lulu

  Il y a la manière dont ça arrive et juste la quantité. Parce qu'il y a des enjeux à ne pas se faire submerger par la connaissance avec tout ce qui est dévité. Parce que tu en parlais tout à l'heure justement de la... quantité de cotes qui va être produite, mais du coup, il y a la quantité de docs. Et si on la structure pas, qu'on la rend pas lisible, et surtout qu'on trouve pas des moyens de la réduire au strict minimum, en tout cas au strict essentiel pour les mains, c'est un coup de mien fou.

• Xavier

  Oui, puis on a une fenêtre de contexte aussi. À un moment, ça sature.

• Manu

  Ouais, mais tu vois, alors ça, ça, ça... On se rend compte que j'en vois beaucoup, certains qui sont en train de gueuler en disant j'ai cramé mon quota de 5 heures en 1 heure. Nous, on utilise Mania. hyper intense et je pense que la culture qu'on a, le fait d'aller chercher tout ce qu'il faut au bon moment, on n'a jamais envoyé toute la code base pour poser une question, on n'a jamais envoyé toute la doc pour poser une question et au final, on atteint très peu ces limites-là parce que je pense que l'architecture qu'on a mise pour aller chercher la bonne info au bon moment, outre le fait que ça t'évite qu'elle en ait trop et que ça te l'amène par erreur, ça nous permet aussi d'être vachement économes sur les tokens. surtout les tokens d'entrée, pour être sûr que tu n'en crames pas comme ça. Si tu poses la question sur contexte à chaque fois et qu'il va aller scanner ta base de code, c'est du temps. Et il y a un truc qui est monumental, juste pour lui demander quelle couleur était ce composant-là ou quelle est la réponse de la FAQ de cette doc-là.

• Lulu

  Après, en plus, je parlais plus pour nous en tant que personnes que pour l'IA, dans le sens où... Si tu arrives sur un intranet, tu as un SharePoint, un truc comme ça, que tu as des milliards d'infos et que la structure n'est pas bonne, tu es juste complètement perdu. Et voilà, de ne pas tomber dans ces mêmes travers-là. Et effectivement, après, en plus, techniquement parlant, ça a des vraies conséquences financières et sur les tokens et sur la productivité. Parce que du coup, si ta structuration d'information n'est pas bonne, ton agent, il va aller consommer les bonnes infos aux bons endroits et éviter de... justement de dire... Justement,

• Xavier

  j'avais vu une conférence de... C'était François Zaninotto de Marmelab qui parlait de faire du SEO mais dans le code et aussi dans la documentation pour dire ah bah tiens, là, t'es là mais ça renvoie à tel document si t'as besoin d'y aller, si c'est pertinent par rapport à ça et de tout bien architecturer, quoi, au final.

• Manu

  Voilà. C'est ce qu'on essaie un peu de faire. Nous, on est capable de faire des liaisons. On est en train de faire des tags sur nos docs. pour être capable justement de pouvoir rebondir, parce que sémantiquement, ça a du sens, et que ça aide les agents à aller chercher déjà par ce canal-là avant d'aller faire une recherche sur un mot en mode texte, pour savoir est-ce que l'info est déjà là. Ça fait partie du harness de structurer correctement l'information et de donner les outils qui ne sont pas des outils IA, qui sont des outils de code des fois, pour aller chercher les trucs relatifs, pour aller garantir que la structure du document qu'a généré l'agent, il est OK avec ce pattern-là. Nous, on a des hooks qui font que chaque fichier Markdown qui est écrit, c'est du code qui valide si, oui ou non, l'agent a le droit d'écrire ça, pour être sûr qu'il n'écrit pas un truc qui va péter son exploitation futur derrière. Et on traite le Markdown comme du code, en fait.

• Xavier

  Oui, c'est architecturé, oui. Et là, c'est là où on remonte d'un niveau plus proche du langage naturel, en fait. Et là... Je pense notamment en termes de besoin, de chercher là où est-ce que... Comment est-ce qu'on redessine un métier qui se fait remplacer ou en tout cas qui était outillé. Mais presque de se dire, si c'était de chercher les besoins et tout ça, de voir aussi avec les personnes les besoins qu'elles ont pour voir comment est-ce qu'on peut structurer l'information pour que ça soit personnalisé pour elles et de retrouver un peu aussi ce contact humain, créatif. Oui, non, c'est trop bien.

• Manu

  Mais ça, on en est qu'au début, de la capacité d'adapter, personnaliser tout ça. Dans ce côté emploi-là, moi, je parle beaucoup le terme d'augmenter, en fait. Ces outils-là nous augmentent en tant que tels. Ils ne nous remplacent pas, ils ne nous changent pas. Ils changent notre quotidien, mais surtout, ils nous augmentent sur des tâches qui sont des fois difficiles à encaisser parce que ça change tellement et que ça nous met dans des positions qui ne sont pas l'habitude. Déjà, ce changement-là est compliqué. Et après, il y a ce qu'on évoquait tout à l'heure sur ce changement-là. Tu ne peux pas faire ça tout le temps aussi. Donc, il faut être capable aussi de le voir dans sa globalité. Et malheureusement, tu vas avoir une personne qui ne sera pas du tout capable de rentrer dans ces moules-là, dans ces changements. Oui,

• Xavier

  mais après, c'est aussi de se demander comment est-ce qu'on leur présente. et d'aller comprendre les personnes au-delà de dire, ben voilà, t'as un outil, maintenant tu prends le train en marche, ou sinon tu te fais remplacer par ce même outil que tu dois absolument maîtriser, mais de revenir encore une fois à l'humain, parce que s'il y a une volonté de ne pas utiliser quelque chose, c'est qu'il y a des choses derrière, et d'aller comprendre ça, et il y a des choses qui sont tout à fait légitimes, parce que là, au Forum PHP, je vais faire une conférence sur l'IA frugale, justement. Donc, on voit les impacts environnementaux, on voit les impacts sociaux. Donc, il y a aussi tout ça à prendre en compte. Mais de voir comment est-ce qu'on peut se servir de cet outil qui n'est quand même pas un outil comme les autres, mais pour aller plus loin dans les valeurs qu'on a, plus loin dans l'impulsion qu'on a envie de donner et ne pas se perdre en chemin.

• Manu

  J'avais une ancienne collaboratrice qui, son credo, moi, qui m'a beaucoup... Je l'utilise beaucoup, je lui donne tout le crédit de ça. Merci Christelle. faire des choses bien avec des gens bien. Et tu vois, c'est un peu le credo de ce qu'on veut construire et quelque part, maintenant, nous, on s'est posé la question de dire, c'est très bien, on fait des gros produits avec des liens, parce que nous, en plus, on fait des produits, on fait du logiciel maintenant avec de l'IA dedans, on l'utilise pour faire le code, mais surtout que là, on a des process, on a du fonctionnel avec de l'IA qui est profond, on a des gros produits à l'intérieur. On s'est dit, mais est-ce qu'on ne fait pas des choses qui vont faire du mal, en fait ? Est-ce qu'on ne va pas faire des choses qui vont remplacer des pans entiers d'une équipe et qui va faire que le type va licencier les trois quarts ? On se dit, merci Xavier. ça a coûté 10 000 balles et j'ai licencié 50 personnes. Moi, ça me ferait du mal. Enfin, on s'est posé ces questions-là. Est-ce qu'on va là-bas parce qu'est-ce qu'on va être tellement aussi un bras armé d'un truc qui va faire du mal à des personnes, tu vois ? Et après, de toute façon, ces personnes-là, elles l'ont fait avant l'IA, elles le feront après l'IA. Et donc, notre objectif, c'est d'aller trouver, faire des choses bien avec des gens bien. Aller trouver des projets qui ont envie de faire des trucs bien, qui ont de l'impact et derrière, et en utilisant l'IA, en faisant attention aussi derrière. mais pas non plus en étant des atollas de dire non, non, je ne veux pas parce que c'est un impact. Après, chacun a sa position et c'est la nôtre, on la partage avec l'équipe et c'est des vraies questions qu'on a. Mais voilà, je pense que c'est chacun aussi qui se positionne par rapport à ça.

• Lulu

  Et justement, on est déjà presque bientôt une heure et demie d'épisode. J'aimerais bien qu'on boucle sur deux questions et là, suite à ce que tu viens de dire, pour les personnes qui aimeraient justement ces maîtres à l'IA qui n'ont pas forcément enfin qui n'ont pas encore franchi le cap ou qui ont regardé de loin mais qui ne savent pas trop par où commencer dans un contexte pro tu aurais une échelle d'équipe ou directement en prenant une échelle d'équipe qu'est-ce que tu conseillerais toi ? Quel est un peu le premier pas ou par quoi par quoi attaquer ?

• Manu

  C'est marrant parce que là on vient d'être sollicité on vient de lancer trois missions pour accompagner des équipes de dev dans leur bascule d'IA alors c'est pas un métier on le fait là parce que ça nous intéresse en plus c'est des éditeurs Merci. qui sont aussi un autre contexte par rapport à ce qu'on est. Donc, c'est assez intéressant, valorisant. Donc là, on commence l'émission là. Et tout ce que je dis là, c'est nous, on se positionne en tant que facilitateur de l'état d'esprit. Et surtout, c'est ne pas se dire je vais prendre cet outil-là et je vais utiliser cet outil-là. Et c'est ça qui est compliqué. C'est qu'il faut être capable déjà de se dire comment je vais fonctionner, comment je fonctionne. L'IA sera qu'un outil qui va augmenter ça, qui va nous permettre de s'outiller là-dessus. Mais si on n'a pas les fondamentaux de réflexion, et surtout à plusieurs, parce que si on a une équipe de devs où chacun avait sa vision, et chacun faisait comme il voulait, et bien ça, tu prends l'outil que tu veux, ça ne marchera pas. Et ça va encore plus mettre en exergue que rien ne va, parce que ça va aller plus vite, et ça va augmenter l'impact de quelque chose qui est déjà passé. Donc la première étape, c'est déjà se dire, est-ce que sans IA, est-ce que déjà, ce qu'on fait, nos process, c'est ce qu'on est déjà tous OK par rapport à ça ? Est-ce qu'on est déjà d'accord sur là où on va ? Et puis après, on va s'outiller pour commencer à aller un peu plus loin et surtout y aller étape par étape, autant sur le scope fonctionnel et autant sur les personnes qu'on va embarquer nous derrière. Un des trucs qui a hyper bien fonctionné, c'est le fait que j'ai pris Maxime, qui était mon lead dev, pour commencer à faire ça et ce n'est pas moi qui suis allé embarquer le reste de l'équipe, c'est lui. parce qu'il était convaincu, parce qu'il est allé embarquer le reste de l'équipe, il était beaucoup plus légitime que si c'était moi qui aurait dû après aller les embarquer. Donc, trouver le bon contexte, ce n'est pas simple, c'est facile à dire. Un bon petit projet qui n'ait pas trop d'impact, avec les bonnes personnes qui ont envie d'essayer et qui arrivent à s'approprier ça pour être capable d'aller le diffuser également et surtout ne pas laisser tomber ceux qui sont avant et après le dev. Parce que sinon, à un moment, ça va raccroisser.

• Lulu

  Trop bien. Merci pour ce conseil. Et justement, notre petite question de la fin. Est-ce que tu aurais une recommandation culturelle ? Alors, de ton choix, ça peut être un livre, un album, un film, ce que tu veux, à faire à nos auditeurs auditrices.

• Manu

  Moi, j'ai un bouquin que je relis régulièrement. Alors, qui est aussi, moi, ma vision qu'on a d'équiper tout ça, c'est un bouquin de Frédéric Lalou, qui vraiment se... pose, on reparle de plaisir, on reparle de place des personnes dessus, qui je pense là, maintenant, encore plus d'écho avec ce qu'on vit là. Et que c'est entièrement des interactions où l'humain va être encore plus important dans la valeur produite par les équipes. Tout le monde aura les mêmes outils et c'est ce qui fera nos différences en tant que telles. Et ce n'est pas les différences singulières d'une personne, c'est l'équivalent du collectif qui fait ça. C'est la différence de savoir comment il a structuré sa façon de travailler, comment il a structuré sa façon de produire. le code et sa façon d'interagir avec le reste. Et c'est ça qui va être important. Et c'est pour ça que je pense que ce qu'on vit là est une vraie opportunité pour les petites organisations, parce que c'est elles qui auront plus de résilience à encaisser un changement et à embarquer avec elles déjà une équipe qui sera beaucoup plus la même de se mettre ensemble pour changer ensemble qu'une boîte qui a 500 personnes et qui, je pense, va être très très compliquée pour ce type de grosse organisation. Je ne connais pas assez pour me projeter, mais je...

• Lulu

  je pense que ça va être compliqué avec tout ce que ça veut dire d'une grosse boîte une boîte qui a 500 dev pour aller faire un virage comme on l'a fait je ouais comme tu l'as dit un peu après l'autre de toute façon il faut y aller par étapes mais ouais c'est sûr que de toute façon de par là si il y a un mot c'est l'humain avant tout ça

• Xavier

  peut pas être descendant enfin un moment on peut pas juste imposer et puis dire bon bah maintenant c'est comme ça et puis vous utilisez ces outils là spécifiquement de cette manière là Merci. Sans laisser explorer aussi.

• Manu

  Je dis oui ou non, mais ça s'est toujours fait en fait. Le top down de dire, maintenant allez hop, on change, vous dégagez, vous ne posez pas de questions et on change tous les process. Ça s'est toujours fait et ça continuera de se faire. Après, est-ce que c'est efficace ou pas ? Moi, je ne pense pas, mais bon.

• Lulu

  En tout cas, j'aime bien ta conclusion, l'humain avant tout. On va rester là-dessus. Lulu, est-ce que tu veux ajouter autre chose ? Tu avais une dernière question peut-être ?

• Xavier

  Non, c'est... Non, j'ai... plein de nouvelles idées en tête, mais ça m'a fait du bien. On a passé un temps entre humains, entre êtres humains, à partager des visions. Moi, je suis trop contente.

• Manu

  C'est partagé, en tout cas. J'aime bien discuter de ces sujets-là, en tout cas.

• Lulu

  Merci beaucoup, Xavier. C'était trop cool. J'invite vraiment les gens qui nous écoutent à aller regarder tes deux conférences sur la langue, sur la courbe, sur les deux. Les deux sont trop bien. dans lesquelles justement tu vas expliquer davantage chaque étape de votre adoption et c'est vrai qu'elles sont très très bien donc on vous mettra les liens en commentaire de l'épisode allez les regarder et de toute façon on te retrouve au forum PHP du coup les 8 et 9 octobre à

• Manu

  Disneyland et puis si je peux aussi je suis le 22-23 à Gilles-en-Seine et je suis le 1 et 2 à Volkamp à Clermont sur ces deux là

• Lulu

  Tu fais la tournée de la France.

• Manu

  Oui, mais là, moi, c'est... Toi, indirectement, je pense que ça fait partie aussi de... On a eu la chance d'être un peu en avance sur tout le monde. Moi, il y a des... On en est là aussi parce qu'il y a des conférences. J'ai tout qui m'a inspiré. Moi, je suis toujours allé voir beaucoup de conférences et tout ça. Et donc, moi, j'estime que c'est important aussi d'aller redescendre ça, d'aller peut-être replanter la graine chez certains et surtout d'essayer de replanter une graine qui va faire que ça fera peut-être moins mal. à certaines personnes ces virages-là. Si ça peut juste aider une orga, une équipe, moi, ça me suffit. Je pense que c'est un peu notre possibilité aussi à avoir.

• Lulu

  On ne peut pas mieux conclure.

• Xavier

  Encore une fois.

• Lulu

  Encore merci. Merci à toutes celles et ceux qui nous ont écoutés. On vous souhaite une bonne journée, bonne fin de journée. Quand vous nous écouterez, on vous retrouve la semaine prochaine pour un épisode avec Gaël. Je vous dis son nom comme ça, vous le découvrez. la nature et la thématique de l'épisode. On va rester dans la partie technique et dans la partie développement. Très bonne semaine et à bientôt.

• Manu

  Merci,

• Xavier

  au revoir.