Transcription

• Manu

  Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no code. On se retrouve comme chaque semaine avec Lulu. Tu vas bien Lulu ?

• Lulu

  Ouais, ça va bien.

• Manu

  Et cette semaine, on a le plaisir d'avoir un invité avec nous. Vous l'avez compris, jusqu'à mi-octobre, on a des invités chaque semaine. On l'air tous très bien et on va vous le confirmer encore ce soir avec Gaël. Gaël, est-ce que tu vas bien ?

• Gaël

  Oui, très bien, merci. Et vous ?

• Manu

  Oui. En plus, ce qui est formidable avec les podcasts, c'est qu'on fait toujours comme si on ne s'était pas parlé il y a deux minutes. Et du coup, on a le plaisir de te recevoir justement dans le cadre thématique, on va dire, du forum PHP qui arrive en octobre, les 8 et 9 octobre. Lulu me corrigera si je me trompe, mais je crois que c'est bien ça. Et on en profite en fait du coup chaque semaine pour interviewer des gens qui vont présenter des conférences là-bas sur différents sujets. Au moment de cet épisode, vous avez déjà dû entendre Amélie la semaine dernière ou la semaine d'avant. Et aujourd'hui, on va aller sur un sujet qui est plutôt orienté développement et code, mais pas seulement, puisque l'enjeu va être justement aussi de discuter un peu du rapport à l'humain là-dedans, comment l'IA est venue bouleverser un peu tous ces sujets. Et faites que tu nous... Donc partage Gaël justement ton expérience, tes apprentissages. Et voilà, on ne va pas trop teaser, on va partir un petit peu sur les différents sujets. Et avant toute chose, est-ce que tu veux bien te présenter s'il te plaît ?

• Gaël

  Bien sûr, donc vous l'avez déjà dit, moi c'est Gaël. Je suis développeur, enfin ancestralement j'ai été plus développeur et je me suis intéressé ou réorienté sur des problématiques on va dire un peu plus architecturales. où je me suis beaucoup spécialisé initialement dans l'univers Symfony et aujourd'hui sur les dernières missions, donc je suis freelance, je le précise aussi, et on va dire que sur les dernières missions que j'ai effectuées, le rôle était un peu plus large que développeur, il y a eu de réelles décisions techniques à prendre en équipe, des choix architecturaux sur des problématiques de cache ou des systèmes de bases de données, enfin bref, on va dire qu'avec l'intégration justement de l'IA et des workflows agentiques, aujourd'hui, le rôle a quelque peu dévié, on peut s'entendre. Et je me considère beaucoup plus aujourd'hui comme un architecte de solutions plus qu'un développeur initialement web, même si, on va dire que la grande partie de mon expertise a quand même été sur la création d'intranet, de solutions SaaS, ce genre de choses.

• Manu

  Et du coup, juste pour contextualiser, ça fait combien de temps que tu es développeur ? Et quelle est la ratio entre le moment où tu as été indépendant et où tu bossais en équipe ?

• Gaël

  Alors, je suis dev, ça doit faire une quinzaine d'années. Je crois que j'ai... Quelque chose comme ça, je n'ai pas compté. À peu de choses près, ça doit faire 15 ans. Et j'ai commencé en tant que freelance, alors au mauvais moment, on va dire, en 2020, au début de la pandémie. En fait, juste avant le début du premier confinement. et donc mon parcours a été un peu on va dire qu'il a été un peu atypique dans la mesure où j'ai fait une petite partie freelance pendant un an et demi j'ai arrêté pendant environ deux ans où je me suis expatrié avec ma femme et mon fils au Québec donc je suis reparti dans une activité salariée mais sur place, outre-Atlantique et pour des raisons familiales on a pris la décision de revenir et donc j'ai repris Suite à ça, une activité de freelance jusqu'à aujourd'hui. Et donc, ça continue. Pour l'instant, on touche du singe. Ça continue et ça marche plutôt bien. Donc, espérons que ça dure.

• Lulu

  Oui, justement, j'aurais même eu tendance à dire que ça aurait été presque plus compliqué maintenant, à l'ère de l'IA, ou c'est peut-être plus galère de trouver des contrats, ou en tout cas, le rapport à la valeur fournie a un peu changé.

• Gaël

  Alors, ça fait assez longtemps que je ne me suis pas retrouvé sur le marché à chercher des missions, pour être très honnête. J'ai quand même regardé un petit peu ce qui se passait. Il y a eu une petite période de creux, j'ai l'impression, dans ce qui a sonné de ce que j'ai pu faire sur LinkedIn, etc. où effectivement, le nombre de missions semblait s'amoindrir. Après, il n'y a peut-être pas que l'IA, il y a aussi un contexte international qui n'est pas très cool en ce moment. Donc, il y a aussi le fait que post-pandémie, je crois qu'il y a quand même eu un... gros gros sursaut d'embauche et puis de demandes de développeurs qui a fait qu'il y a eu... Je ne sais pas si c'est un sur-recrutement, mais en tout cas, il y a eu beaucoup, beaucoup d'offres qui sont tombées. Et aujourd'hui, quand on écoute les économistes et les gens qui s'intéressent à ça, ils ont l'impression qu'il y a eu un petit peu une rationalisation de tout ça par rapport aux réels besoins et à la situation qui est la situation des entreprises aujourd'hui. Et justement, juste pour terminer là-dessus, mon sentiment, c'est que tout, tout dernièrement, le nombre d'offres semblait justement augmenter. Alors, je n'ai pas fait gaffe si la proportion freelance CDI... étaient équivalentes, disproportionnées, etc. Mais ça semble revenir un petit peu. Je me sens un peu recontacté. Je sens qu'il y a plus d'offres sur LinkedIn qui tombent sur des offres de mission diverses et variées. Alors, beaucoup avec des appétences IA, où ça fait partie littéralement des skills qu'on demande par des techs quand ils postulent. Donc, il y a ce prisme-là qui est nouveau, mais il y a aussi une petite remontée, j'ai l'impression en tout cas. Je peux me tromper, mais c'est de s'en suivre. Ok,

• Lulu

  et moi juste peut-être avant qu'on attaque dans le dur, c'est quoi ton tout premier souvenir avec l'informatique, avec le développement ? Est-ce que tu fais partie de ceux qui ont commencé à dos à trifouiller sur les machines ou est-ce que c'est plus classique ?

• Gaël

  En fait, après le bac, je ne savais pas trop quoi faire de ma vie, pour être très honnête. En épluchant un peu les offres, j'habitais dans le nord de la France initialement parlant, et en épluchant les offres de formation post-bac, il se trouvait qu'il y avait un IUT à Lens qui proposait une offre pour devenir une sorte de chef de projet digital. Je savais que l'informatique me plaisait de manière générale, comme un ado de 15 ans qui joue à Warcraft 3, parce qu'à l'époque c'était Warcraft 3, donc j'ai dit je vais essayer d'aller là-dedans. Donc j'ai commencé la formation et en fait, il s'avère que c'était une formation hyper variée où il y avait de l'art. Très honnêtement, je n'en avais rien à cirer. Il y avait pas mal de... c'était assez large. Et en fait, dans le prisme global de la formation, il y avait une partie dev, où il fallait avoir des appétences un peu algorithmiques, découvrir le monde de l'algo, comprendre. Et j'ai tout de suite vu que la formation, elle n'était pas pour moi, que ce n'était pas ça que je voulais faire. Par contre... j'ai vu que ce truc-là en particulier me semblait très très cool, que j'avais envie d'approfondir ça. Malheureusement, il m'est arrivé un petit problème, je me suis fait agresser, en fait, une fois, et en fait, ça a été un peu un ping-pong dans ma tête à ce moment-là, et je me suis dit, je veux arrêter cette formation dans cette ville, je veux m'en aller, je veux revenir aux sources, repartir chez mes parents, et repartir sur un cursus un peu plus, on va dire, moins fantaisiste. Et je me suis dit, je vais partir dans une filière informatique. Et donc, j'ai repris la fac classique. Et il s'avère que dans la fac où j'étais à Amiens, donc en Picardie, il y avait un cursus qui s'appelait MIAJ, méthode informatique appliquée à la gestion des entreprises, qui proposait des formations en alternance. Et j'avais envie de bosser en parallèle. Donc, de fil en aiguille, j'ai eu licence. Au master, j'ai commencé un apprentissage. Et c'est dans cet apprentissage... que j'ai pu... Donc, pardon, pendant la formation, j'ai commencé à faire du PHP et je me suis dit, ouais, en fait, c'est trop cool parce que, d'un, par rapport au Java, ça me semble quand même beaucoup moins complexe. Je m'éclate plus à faire des trucs avec ce langage-là. Aujourd'hui, je ne saurais même pas pourquoi dire, mais je me rappelle que je m'éclatais plus à faire du PHP que du Java, qui étaient les deux gros langages qu'on faisait, grosso modo. Et j'ai eu l'opportunité de le faire en apprentissage. et puis à l'époque c'était Majato 1 on devait faire une sorte d'add-on qu'on vendait à des clients dans le cadre de boutiques qui tournaient sous Majato 1 et du coup j'ai dit c'est parti je fais ma carrière là-dedans et puis ça m'a suivi jusqu'à aujourd'hui donc au début c'était PHP ensuite Majato finalement mes toutes premières expériences c'était avec Zenframwork 1 et après je suis parti sur du Symfony parce que Zenframwork s'est fait écraser Il y avait un milliard d'offres, c'était que du symphonie. Donc à ce moment-là, c'était très facile de faire du symphonie. Je ne sais pas si c'est bien de le dire, mais j'ai choisi la simplicité.

• Lulu

  À un moment, il faut manger quand même.

• Manu

  Oui, c'est ça. Et ce qui fait que là-dedans, tu n'étais pas dead depuis enfant, on va dire.

• Gaël

  Non, du tout.

• Manu

  Ça arrivait justement un peu par concours de circonstances, mais tu as quand même kiffé ça dès le début et c'est ce qui t'a embarqué dans le dev. et... À quel moment t'as pris l'IA en route ? Enfin, même chose, petite dose ou quoi, mais genre, à quel moment ça a commencé à t'intéresser et tu t'es dit que t'allais peut-être en faire quelque chose ?

• Gaël

  Alors, le souvenir est très précis, c'était il y a à peu près un an. Donc, c'est pas si dur que ça. En fait, au début, j'étais un peu hermétique à l'IA, tout simplement parce que dans l'équipe où j'étais, j'avais un manager avec qui j'ai pris énormément de plaisir à travailler. Julien, si tu nous écoutes. Il nous a véhiculé énormément de bonnes pratiques, dont beaucoup de bonnes pratiques sur la code review. Et lui était très, pas anti-IA, mais il challengeait beaucoup l'IA. au moment où elle sortait et où tout le monde commençait à s'intéresser, lui, justement, on va dire qu'il se positionnait un peu en porte-à-faux de toutes les personnes qui disaient « c'est trop bien » et qui voyaient que les côtés positifs. Et lui disait « non, non, moi, je vais être de l'autre côté et je ne vais pas voir que les côtés négatifs, mais je vais équilibrer un peu la chose. » Et donc, au départ, il portait un message dans l'équipe où je travaillais qui était très « l'IA, c'est pas bien » . vous êtes des devs, vous pouvez vivre sans. C'était comme ça. Donc, on devait travailler, on était incités d'un point de vue équipe. Après, d'un point de vue entreprise, le discours était bien ailleurs, bien différent. Mais en tout cas, au niveau équipe, lui souhaitait à ce qu'on continue à utiliser notre matière grise, qu'on ne parte pas dans la simplicité de faire un prompt qui va nous faire ce qu'on veut. Et donc, jusque-là, de part... de par cette logique un peu d'équipe, je ne m'y intéressais pas parce que mon quotidien faisait que je n'avais pas forcément à m'y intéresser. On va dire ça comme ça. Et puis un soir, je discute avec un pote, un ancien dev, enfin il est toujours dev, mais un ancien collègue qui est devenu un très bon ami. Et je le sens extrêmement inquiet en fait et en disant non mais là, l'IA, c'est en train d'évoluer un truc de fou et il est en mode panique. Je le sens vraiment en mode... de panique du style, qu'est-ce qu'on va devenir ? C'est en train de sortir des trucs plus forts que nous. C'était en train vraiment d'exploser à ce moment-là. Et on va dire que l'armure que je m'étais figée jusque-là, en fait, elle a commencé à s'éroder et je me suis dit, mais en fait, peut-être qu'il a un peu raison, peut-être que là, il est en train de se passer un truc, je le vois pas. Et grosso modo, il y a un train qui est en train de passer devant moi. C'est plus un train, c'est un TGV. Et je suis sur le quai de la gare et puis à un moment donné, il faut monter dans le wagon. Mais je l'ai plus pris dans le sens où il y a un taureau qui est là. Il y a l'expression qui dit, il faut prendre le taureau par les cornes. Et je me suis dit, à ce moment-là, je vais prendre le taureau par les cornes avant qu'il me fonce dessus. Et à ce moment-là, j'ai commencé à dire littéralement comment ça marche et comment je dois vivre avec ça. Parce que c'était, ok, c'est bien beau d'utiliser l'IA, mais je ne suis pas vraiment sûr d'avoir encore trouvé la réponse aujourd'hui. c'est comment... bien l'utiliser dans mon quotidien de dev par les modèles que j'utilise, par les promptes que j'écris, parce qu'au début c'était tiens, j'ai une feature, génère-moi cette feature par rapport à une spec dont j'ai une idée mais que je vais te demander d'écrire donc je me suis dit allez je vais tester le flow, je te délègue tout, voyons comment tu te débrouilles et voyons si j'ai des choses à te redire et donc je vais un petit peu plus loin que ta question, je suis désolé mais du coup de fil en aiguille j'ai commencé par tout lui déléguer et j'ai encore cette souvenir de cette PR qui m'est sortie où je vois littéralement sur mon GitHub une PR de 100 fichiers et là je me suis posé j'ai dit mais littéralement demain ça marche plus je fais comment avec cette PR là parce que c'est bien mignon mais je peux pas la relire, je peux pas la comprendre, c'est pas possible il y a des classes dans tous les sens, je descends dans les contrôleurs par simple curiosité. Ça ne respecte pas mes conventions que j'ai d'habitude. Enfin bref, je n'avais même pas de sensibilité à ce qu'était une skill. C'était vraiment de l'utilisation brute de fonderie, limite chez LGBT. Chez LGBT classique en mode... Et c'est là en fait que j'ai commencé à me construire une... J'ai appris grâce à l'IA en l'interrogeant. J'ai dit mais là, maintenant que je t'ai utilisé, je vois bien que je ne... ne peux pas t'utiliser en promptant littéralement des trucs. Je veux aller plus loin que ça et je veux que tu m'apprennes à me servir de toi. Et en fait, j'ai construit une conversation où en gros, elle m'a décrit, ben voilà, je fonctionne comme ça, j'ai des skills, j'ai des commandes, j'ai différents modèles. Ce modèle-là, il sert à ça, ce modèle-là, il sert à ça. Si tu veux aller, si tu veux approfondir, va lire la doc. Donc je suis allé lire un peu d'op, même si je ne l'ai pas lu en entier, j'ai essayé de le lire le plus possible. Et c'est l'IA qui m'a converti un peu à la gentille comme disant, tu devrais essayer de construire un agent qui va s'occuper de plus de cette partie-là. Ensuite, écris un simple développeur, tu as des appétences symphoniques, donc tu pourras le diriger. Et tu verras qu'à terme, tu pourras te concentrer beaucoup plus sur diffuser ce que toi, tu as envie, checker ce qui te semble important, voir le résultat et définir si c'est OK ou si ce n'est pas OK. Et step by step, j'ai avancé, j'ai essayé de perfectionner, mettre en place des boucles de rétroaction. Mais tout ça, c'est autodidacte. Je n'ai pas un mec qui est arrivé et qui m'a dit « tiens, tu as vu l'IA ? » En fait, c'est rigolo, c'est que c'est arrivé après. Donc, il y a eu ce truc-là qui est arrivé. Donc, cette auto-formation qui s'est passée, ça a duré un mois et demi où je me suis servi d'un projet avec ma femme. On a parlé d'un projet, un truc dans son entreprise et disons « ça ne marche pas » . ou c'est assez vieux, donc j'aimerais bien qu'on le repasse. Et donc, je suis parti de cette idée-là pour me former à l'IA et reconstruire un truc. Et au départ, c'était un petit peu effrayant parce qu'effectivement, j'ai construit littéralement un outil quasi entier en, pas deux semaines, mais grosso modo en trois semaines, j'avais quasiment un CRM qui pouvait faire littéralement le boulot avec déploiement en prod, CIA et CD, etc. Enfin, je veux dire, le truc chiadait quand même de fou pour un mec qui le maîtrise. initialement parlant, qui n'est pas trop DevOps et qui, sur la partie front, sait se débrouiller, mais n'est pas un cadre hors du marché. Donc, ça m'a énormément questionné. Et tu as les questions du « mais en fait, je sers à quoi ? Si tout ça, ça peut se générer automatiquement, je fais comment ? » Et c'est quand le pendant entreprise est arrivé, où justement, il y a eu la décision de pousser beaucoup plus sur l'agentique parce que Bye bye. niveau productivité, etc. Enfin, je ne vais pas faire le discours qui est des sacs tout le temps. Il faut y aller, etc. On va dire que j'étais prêt à y aller parce que je savais dans quoi je m'embarquais. Et au même moment, la boîte dans laquelle je travaillais a recruté un presta qui est évangéliste IA. Donc, le gars est venu chez Belief pour véhiculer des bonnes pratiques agentiques et voir un peu ce qu'on pouvait automatiser dont tout ce qu'on avait à maintenir au quotidien, process, applicatif, etc. Et il a fait différents meetings avec les équipes pour faire le point et présenter un peu justement toute la partie parce que la décision a été prise d'aller sur Cloud, sur Anthropique, et de dire, bon ben, statut, l'IA pour vous c'est quoi ? C'est quoi vos craintes ? Est-ce que vous êtes prêts à y aller ? Et on discute de tout ça et en plus de ça, je vous dis comment ça marche. finalement, je me suis rendu compte qu'en fait, tout ce qu'il expliquait, je le savais déjà. Ou en tout cas, j'arrivais à le challenger sur des choses qu'il avait prévues, mais pour l'étape d'après. Il y avait un peu du monde à rattraper d'abord. Et donc, je me suis dit, en fait, tu n'as peut-être pas fait une bêtise en essayant de regarder un peu toi, comment t'en sortir avec ça. Sachant qu'aujourd'hui, je trouve que ce qui me manque, c'est un peu... En fait, j'en suis toujours à cette étape-là de me dire... est-ce que ma façon de faire est la bonne ? Parce qu'on parle aujourd'hui de l'IA comme d'un outil qui aide à la productivité, mais je n'ai pas encore trouvé de réelle bonne pratique d'utilisation de l'IA dans un contexte pro de dev. C'est-à-dire aujourd'hui, on dit, vous faites des skills, vous écrivez ça, etc. Oui, mais il n'y a pas encore de skill bien écrite. C'est quoi une skill bien écrite ? Est-ce qu'on est capable de le définir, ça ? Est-ce qu'il y a un template à respecter ? Est-ce que c'est purement abstrait ? Ou est-ce que juste une skill, c'est un peu une description de ce que vous faites et chacun fait comme il veut ? Moi, j'en suis un peu là aujourd'hui. Et du coup, je me demande aujourd'hui, c'est une question que je me pose, je ne sais pas si quelqu'un a la réponse, moi, je n'arrive pas à la trouver. Est-ce qu'aujourd'hui, quelqu'un peut se vendre Xperia ? Est-ce qu'il y a des Xperia aujourd'hui qui peuvent exister ? Et est-ce que c'est quelque chose qui peut exister aujourd'hui ? Je ne sais pas. Bref, j'ai autant de réponses que de questions. On peut en parler des heures.

• Manu

  Non, non, mais c'est super. J'ai envie de revenir justement sur... Avant que tu creuses ce côté IA, côté dev, déjà pour revenir sur ce que tu viens de dire, la partie d'Xperia, il y a plein de... Enfin, plein. Moi, je crois que ça s'est un peu calmé pendant... Un temps, en tout cas, on avait une vague, justement, d'experts IA qui débarquaient sur tous les sujets, ce qui ne faisait pas trop sens parce qu'au final, la techno, elle est tellement tout le temps en mouvement.

• Gaël

  C'est une pinèze.

• Manu

  Oui, mais après, il peut y avoir des experts sur des... section spécifique de l'IA, puisqu'au final l'IA j'ai de narrative et l'IA tout court de toute façon est hyper vaste, il peut y avoir des gens très pointus juste sur la partie RAG, juste sur tel ou tel sujet ou tel domaine, donc là-dessus on en a, mais effectivement c'est devenu un abus de langage et quelqu'un qui est un peu plus avancé que les autres peut être tenté de s'auto-proclamer expéria ou d'être qualifié par d'autres personnes d'expéria alors qu'effectivement, en tout cas à mes yeux ça fait pas trop sens, et en revanche et je pense que tout le monde continue aussi à se questionner parce que c'est pas pour rien qu'on voit toutes les parties méthode et l'écosystème qu'il y a autour de l'IA générative est en mouvement perpétuel parce que certes on a les modèles qui changent et qui arrivent tous les 3-4 mois mais en fait c'est surtout tous les outils autour la façon de bosser qui est tout le temps en train d'être challengé et tu disais est-ce qu'aujourd'hui il y a des moyens de faire un bon skill par exemple et donc petit rappel d'ailleurs pour celles et ceux qui nous écoutent on a fait Merci. On vous renvoie à l'épisode de juillet sur le développement logiciel où on expliquait un petit peu toutes les étapes. On expliquait notamment des termes que Gal a employés un petit peu avant sur les PR, les pull requests, etc. On ne va pas revenir dans le détail de tout ça maintenant, mais allez écouter l'épisode. On avait un autre épisode plus tôt qui posait les termes aussi d'IA et notamment le skill, donc en gros une compétence de l'IA. Et aujourd'hui, un skill, donc une compétence, dans le principe, ça va consister à mettre un process métier par écrit. le donner à l'IA pour qu'elle déroule cette partie-là selon les critères et tout qu'on lui a posé. Et ça, aujourd'hui, il y a des bonnes pratiques sur la manière de l'écrire pour que l'IA l'interprète, parce que ça, c'est au final, chaque modèle a sa manière de lire, d'écrire, il y a des techniques, d'ailleurs, Lulu pourra peut-être en parler un peu, mais par exemple, en l'IA frugale, il y a des manières de découper les promptes et tout, ça s'applique aussi aux skills. La rédaction est un cas qui est quantifiable et objectivable. Par contre, effectivement, la partie métier, Aujourd'hui, ça dépend de la boîte, ça dépend de la personne.

• Lulu

  C'est très personnel une utilisation aussi. Là, tu vois, tu l'as fait de manière très itérative et tu ne peux pas juste aller prendre une skill sur Internet en disant, moi, je l'utilise et ça marche super bien pour moi et ça ne va pas forcément marcher chez toi. Et de toute façon, on le voit bien. C'est effectivement... constante évolution, il y a des choses qui émergent du côté des utilisateurs, après les boîtes qui fournissent les modèles se disent ah bah tiens c'est bien, on va l'intégrer nativement et ça avance plus ou moins comme ça aussi, donc il y a tout qui bouge

• Manu

  Enfin oui, d'en parler aussi ça me fait penser qu'il y a quand même deux types enfin je vois deux grosses familles de skills il y a ceux qu'on se fait maison et justement qui sont envoyés en témétier, ou ceux-là quand on les récupère tout fait, pour moi ça fait pas sens vis-à-vis justement de sa situation Mais après, il y a les skills qui sont plus purement outils et méthodiques. Par exemple, les outils de dev, je pense à du Superbase, je pense à du Playwright, des outils qu'on va connecter, qu'on va utiliser pour mettre en place des tests ou pour des choses comme ça. En fait, il y a des skills qui ne font qu'aller chercher les bonnes infos dans des documentations pour les donner à l'IA. Mais ça évite à l'IA d'aller chercher et passer des plombes. Et ces trucs-là, par contre, moi, je les trouve hyper utiles. Moi, je sais que quand j'avais eu à faire justement des tests, j'avais des tests sur la partie interface, la front-end. qui n'arrêtaient pas de casser. J'avais plus de bugs sur la mise en place des tests que sur le code, et de beaucoup. Et juste de mettre un skill qui permettait justement à l'IA d'aller savoir comment construire les tests, en fait, j'ai eu un gars, mais fulgurant. Et c'était purement juste d'aller piocher dans de la doc, à peu de choses près. Mais du coup, pour en revenir à ce que tu disais sur ta pratique itérative et ton expérimentation, est-ce que tu pourrais nous présenter qu'est-ce que c'est le quotidien d'un aide, aujourd'hui ? Enfin, aujourd'hui, on va dire le quotidien d'un date avant l'IA. Et justement, le rapport avec la bascule que tu as mis en place déjà sur tes pratiques à toi avec l'IA.

• Gaël

  Ça paraît déjà tellement loin alors qu'il n'y a pas beaucoup de temps. Non, grosso modo, l'activité d'un développeur, c'est déjà des réunions. Je ne sais pas pourquoi je pense à ça, mais c'est des réunions qu'on doit faire pour se parler. et préparer éventuellement des sprints si tant est qu'on travaille en agile. Parce qu'il y a aussi le cycle en V qui continue à se faire. Mais en tout cas, pour mon expérience personnelle, en tout cas, j'ai beaucoup, beaucoup, beaucoup travaillé en agile. Donc, c'est la capacité. Un développeur, il doit savoir parler. Il doit savoir communiquer. Ce n'est pas... Vulgairement, il y a été une période où on parlait de pisseur de code. Je ne suis pas sûr qu'aujourd'hui, un développeur... ne soit qu'un pisteur de code. C'est bien ça justement tout le parallèle par rapport à l'IA, c'est que le profil a énormément changé et les gens doivent être capables de parler et de parler correctement avec les autres. Donc déjà, c'est préparer des sprints, c'est être en capacité de noter des tâches, donc potentiellement de créer des tickets, même si certains tickets font, on va dire purement fonctionnels, vont être plus sur des profils de product owner ou des profils de product manager éventuellement, mais il reste que sur certaines tâches purement techniques, ces profils-là n'ont pas la connaissance. Donc, un dev va devoir être en capacité de rédiger des tickets. On lui demande de noter des tâches, donc de comprendre ce qui éventuellement a été rédigé dans le cas d'un ticket. Je veux cette feature-là. Combien de temps vous pensez que ça va prendre ? Combien de temps slash combien de points dans le cadre de la Gine ? Il faut être capable de... Il faut avoir un peu de, entre guillemets, de jugeote pour dire c'est trop compliqué. Ça, il va falloir la découper parce qu'en gros, cette feature-là, je vais prendre... elle va vous coûter 21, je ne sais pas si on peut faire l'analogie .1, etc., mais grosso modo, pour ceux qui ne connaissent pas, on note généralement les sprints en suivant la suite de Fibonacci, et on a des notes qui vont de 1 à 21, 1 étant une tâche extrêmement rapide qu'on peut faire, on va dire, en 15 minutes, même si normalement, il n'y a pas de notion de temps, mais des notions de complexité, on va dire que c'est une tâche très très très facile à faire, et on va dire que 21, c'est une tâche extrêmement complexe, qui de... par nature demandent à être découpés en plusieurs. Ça, c'est quelque chose qu'on peut demander à un développeur aujourd'hui d'analyser et de remonter comme quoi il ne sera pas en capacité de l'apprendre comme argent comptant, mais pour la réaliser, il va falloir itérer dessus et donc il va falloir isoler des blocs et travailler en plus petites itérations d'un problème pour pouvoir le résoudre in fine, mais qu'une partie soit faite par exemple dans la prochaine quinzaine ou dans celle d'après. L'idée, c'est que ce soit le plus atomique possible pour que les gestionnaires de projet puissent organiser leur sprint par rapport à ce qui a été noté et des capacités globales d'équipe. Et donc, ils sont obligés de se baser sur une notion qui est cette notion de note. Donc ça, c'est la première chose qu'on va demander à un dev. La deuxième chose qu'on va demander à un dev, c'est de développer. Parce qu'il faut bien créer les features. Et là, ça va être d'écrire tout le code nécessaire. Avant ça, il peut être amené à l'architecture. ou à l'expliquer. Parce que, qu'est-ce qu'on va attendre de lui dans le cadre du web ? Je vais parler de mon expérience. Est-ce que c'est un simple contrôleur à écrire avec un service ? Est-ce qu'on va lui demander d'écrire des entités, de générer un repository, d'écrire des tests ? Je ne sais pas. Donc, il y a pléthore de choses qu'il est en quelque sorte obligé de connaître. Et à aujourd'hui, ou en tout cas depuis peu, on demande aussi aux développeurs de mettre en place les CI. et également les CIDI sur des bases généralement de bonnes pratiques véhiculées par les équipes SRE. Mais les CIDI sont portés par les projets. Enfin, les CI, pardon, sont portés par les projets. Donc, les différentes steps et les différents outils, ça, les autres ne peuvent pas les inventer. C'est à la maille de l'équipe de dire je veux utiliser un PHP Stan, je veux mettre en place une step qui fait tourner les tests pour m'assurer que je ne livre pas du caca. Tout ça, c'est maintenu par l'équipe. Et donc, c'est quelque chose où il peut y avoir des tâches spécifiques sur cette. partie-là du projet. Donc, c'est des compétences un peu transverses sur la réalisation de développement, mais aussi de compréhension un petit peu d'AFRA, de comment ça fonctionne et de ce qu'on fait tourner derrière. Donc, comme je l'ai dit, on lui demande de tester. Donc, un code aujourd'hui que tu livres sans test, pardon, si ça existe encore, c'est dommage, appelez-moi, je ferai en sorte qu'il n'y en ait plus, mais j'en vois plus beaucoup. Grosso modo, c'est bien ancré dans le système global que quelconque applicatif sans test, c'est très dangereux. Et aujourd'hui, justement, on essaye de faire plus attention à cet aspect-là dans les notations. Je reviens à mes systèmes de notation. On demande aussi aux développeurs de pouvoir intégrer ces notions-là dans les notations des tâches qu'ils vont réaliser. Donc, il y a cette partie-là. vient après la fameuse code review dont on va parler, qui est une step, alors je peux peut-être en dire deux mots, c'est, on va dire, une demande de relecture de ce qui a été fait par autrui afin que le travail soit validé, disons ça comme ça, et que la connaissance de ce qui a été développé soit aussi diffusée dans l'équipe. Qu'il n'y ait pas qu'un seul sachant, mais que la liste des sachants s'allonge et... historiquement parlant, c'est aussi pour... Ça peut avoir plein de buts différents, la diffusion, l'apprentissage. On peut demander à un junior de reviewer pour qu'il prenne la connaissance. de comment l'équipe travaille.

• Manu

  d'avoir un regard frais. Et comme personne n'est parfait, généralement, les autres voient toujours ce qu'on n'a pas vu. Donc, c'est aussi un garde-fou pour son propre travail de dire, bon, ben voilà, s'il a été vérifié par moi, parce que généralement, on va vérifier ce qu'on fait, on n'est pas bête, et que quelqu'un d'autre l'a regardé en plus, ben, si tu es à deux cerveaux, normalement, ça marche plutôt bien. Ensuite, il faut se rapprocher des équipes produits pour valider les tests grandeur nature, parce que ça a peut-être été testé unitairement, mais derrière, je pars du principe qu'il faut qu'il y ait un humain derrière valide que le produit fonctionne in fine. Ça, il n'y a pas, il y a derrière le besoin métier, c'est des équipes métiers qui les connaissent. Donc, généralement, c'est le créateur du ticket ou alors les parties QA, etc. plus dire, ça marche ou ça ne marche pas. Et là, la communication, elle reste aussi extrêmement importante parce que les personnes, elles ne sont pas forcément de la tech. Donc, il faut être capable de vulgariser aussi et de dire, ok, ce truc-là, ça ne marche pas. Oui, mais ça ne marche pas. Pourquoi ? Parce que essaie de m'expliquer que je puisse moi traduire ou que je puisse tenter de t'expliquer pourquoi ça ne marche pas. Parce que des moments, c'est des cas légitimes qui ont été reportés après pour des raisons techniquement légitime que je dois t'expliquer parce qu'il faut qu'on soit tous alignés on est tous on a tous le même but on travaille tous sur le même produit on travaille tous dans la même boîte et on travaille pas les uns contre les autres et après c'est gérer les déploiements donc gérer les déploiements dans tous les environnements int staging pour peu qui en est release release candidate et production mise en place aussi d'éléments d'observabilité Merci. parce qu'un système, c'est bien beau de le développer, mais si on ne sait pas ce qui se passe derrière, c'est toujours plus compliqué de comprendre quand un bug intervient. Parce que des bugs, il ne faut pas croire, il y en a toujours. On a beau être plus productif, on construit toujours des bugs. Ça n'a pas changé. Mais donc tout ça, il faut pouvoir le monitorer, il faut pouvoir comprendre ce qui se passe. Donc il faut avoir une logique de mise en place de log qui est pertinente. ça aussi dans la code review c'est un élément qui est important de dire attends là ici tu déclenches une exception c'est bien beau mais il faut peut-être le guider derrière pour dire avoir la remontée parce que si tu as une erreur 500 qui pop 500 fois c'est peut-être un signe qu'il y a quelque chose qui ne va pas et qu'il faut corriger tout de suite en amont du retour du support parce que si tu es incapable de le corriger avant qu'un humain te remonte le problème c'est toujours mieux d'un point de vue communication que de le découvrir quand il y a un incident un samedi matin par exemple True story donc observabilité, métrique avec tous les systèmes qu'on peut connaître Datadog, Suga j'en ai oublié d'autres mais parce que normalement il faut toujours dire trois marques mais voilà tous les acteurs de l'observabilité et le dernier c'est d'assurer le suivi tout simplement de ce qu'on fait Euh... Faire de la veille aussi. Alors ça, c'est hors, on va dire, hors contexte pur professionnel du quotidien, mais j'apprendrai à personne que le monde de la tech évolue rapidement. On l'a vu ces dernières années. Et que ce soit simplement dans l'univers du langage qu'on a l'habitude de manipuler. Je vais prendre l'exemple du PHP. Aujourd'hui, on est en PHP 8.5. Il y a eu 8.4 avant, il y a eu 8.3. C'est toujours... Il y a... plus les frameworks qui sont en parallèle, qui ont leurs propres évolutions. Il faut se tenir au courant de tout ça. Donc, il faut aller un petit peu sur Internet, aller voir des conférences, venir au forum PHP, c'est important. Mais voilà, c'est se tenir au courant de ce qui se passe et toujours essayer de creuser. Le gars ou la fille, c'est très maladroit ce que je dis, mais la personne qui me dit qu'elle est sereine au quotidien et qu'elle ne peut pas faire mieux, je pense qu'elle a perdu un truc dans le métier. Alors, c'est un bien et un mal. C'est que du coup, ça peut être très contraignant d'un point de vue cérébral parce que du coup, tu ne peux jamais être satisfait. Ça peut être agaçant, jamais être satisfait. mais quelque part, on a toujours quelque chose à faire. Donc, il y a du bon et du moins bon. Mais voilà, pour moi... Alors après, je m'en vais à vous. Je veux dire, c'est un échange. J'ai peut-être oublié une step,

• Lulu

  mais pour moi, c'est ça. Si on va dans le détail, il y aurait forcément des petits points un petit peu partout. Mais là déjà, ce que j'aime bien, c'est que tu as montré que le quotidien réel d'un développeur ou d'une développeuse, il s'étend à une multitude de tâches, de possibilités de tâches qui ont des enjeux de communication dès le départ, à comprendre le besoin, à le traduire, à aller ensuite le traduire aussi techniquement, à l'implémenter, à le valider, à le tester, à le mettre dans les mains des gens qui vont l'utiliser. comprendre aussi ça, à le surveiller. C'est loin d'être justement juste écrire des lignes de code.

• Gaël

  C'est à l'interface de plein de métiers aussi qui ne sont pas forcément techniques et il y a toujours un peu ce côté aussi de devoir traduire, de devoir expliquer. Il y a le côté aussi pédagogie, de devoir... Pourquoi est-ce que ça, ça a été fait de telle manière et c'est un compromis technique sans partir non plus dans des explications qui vont perdre des gens. Mais c'est vrai qu'on a souvent encore le stéréotype du dev qui est tout seul dans son coin, qui peut être un peu la rockstar, qui est super bon, mais qui, en communication, c'est très compliqué. Et c'est presque plus important de bien savoir communiquer et de bien comprendre les besoins, d'écrire un code qui est peut-être pas un keep it simple, en fait, et de pas partir dans des choses qui sont extravagantes, que personne ne pourra maintenir et comprendre derrière. de vraiment parler aux gens, de vouloir comprendre. Et ça, c'est vrai que c'est bien de l'entendre aussi. Parce qu'il y a peut-être des personnes qui s'empêchent des fois d'aller vers ce métier en se disant « je ne suis pas assez bon, je ne suis pas assez à fond dans le code, tout ça. » Moi, ce que j'aime bien, c'est parler aux gens, comprendre.

• Manu

  À titre personnel, quand on me présente un projet, une mission, un job, quoi que ce soit, je vais beaucoup plus porter attention aux personnes avec qui je vais travailler plus qu'au projet en lui-même. Parce que ton quotidien, en fait, quand on réfléchit bien à la chose, un projet informatique in fine, le code que tu vas écrire, c'est des conditions, des objets, des classes, des architectures de code, des if, des while, des boucles, des conditions, enfin bref, je me répète, mais ce qui va faire la différence, c'est d'un ton métier et de deux les personnes avec qui tu travailles. est-ce qu'elles vont t'apprendre des choses est-ce qu'elles vont faire en sorte que t'as envie de te connecter à ton ordi le matin est-ce que t'es guidé par une personne qui te tire vers le haut qui te donne envie de pas te donner le veilleur de toi-même c'est un peu stéréotypé mais qui te donne une vision et qui t'expose un peu son plan qui dit moi j'ai envie de faire ça tu vas voir c'est trop bien, je te promets que c'est bien fais-moi confiance, c'est trop bien, tu verras Moi, je le suis, le gars ou la fille. Et en parlant de fille, un truc qui me fait énormément plaisir, c'est l'expérience dans les équipes avec lesquelles je travaille. Je trouve qu'aujourd'hui, et c'est très bien, il y a de plus en plus de femmes qui s'orientent vers le développement. Et du coup, je trouve ça bien parce qu'au-delà de la vision neuve que ça peut apporter, J'ai assisté à Ladies of Code il n'y a pas très longtemps, qui était organisé sur Paris. Il y avait pas mal de personnes qui étaient là, d'origine féminine. Et c'est bien de pouvoir s'identifier à des gens qui parlent de tech et de montrer, de changer un peu le visage qui pouvait être véhiculé un peu ou vu comme très masculiniste à un moment donné, où le monde de la tech et le monde de l'informatique, il n'y a que des hommes qui travaillent. Aujourd'hui, c'est en train de changer et du coup, je trouve ça vraiment très, très cool. Juste petite parenthèse, je la reperme, mais c'est une réflexion que je me suis faite. On est passé d'équipe qui était composée, on va dire, sur cinq personnes, il y avait cinq gars. Aujourd'hui, tu as enfin des équipes de tech bien fondées où tu as enfin deux gars, trois filles. Donc, ça s'équilibre. Et du coup, je suis hyper, hyper, hyper content de ça. En plus, c'est des profils vraiment capés où tu prends vraiment... Enfin, je veux dire, il n'y a pas de débat. Enfin, on s'en fiche. C'est bien l'idée, justement. S'il y a des femmes qui nous écoutent par rapport à tout ce qu'on dit sur la tech, n'ayez pas peur d'y aller. C'est pour tout le monde. Pas de raison de se cacher derrière quelconque peur de... ou quoi que ce soit, c'est, allez-y, il faut que la représentation soit large et globale. Voilà, parenthèse.

• Lulu

  Et justement, on va profiter là que tu arrives sur ce sujet-là et je sais que Lulu voulait en parler aussi. Pour en revenir justement à l'IA et cet aspect d'inclusivité, d'accessibilité, aujourd'hui, comment tu vois l'IA, comment on peut être amené à utiliser l'IA d'une meilleure manière pour en tirer parti et rendre la technologie plus accessible et qu'elle puisse s'adapter à nous ?

• Manu

  On en a parlé un peu hors antenne, mais moi personnellement, je suis profil neuroatypique. J'ai été diagnostiqué TDAH en 2020. trois, même heure, donc assez tard. Ça aurait pu être très dangereux pour... Enfin, pas très dangereux, ce n'est pas le bon mot. On va dire que ça aurait pu me causer beaucoup de problèmes d'un point de vue scolaire. Ça ne l'a pas fait parce que j'ai la chance d'avoir une particularité à HPI parallèle qui fait que les choses se sont équilibrées. Mais il y a des enfants qui, aujourd'hui, ont ce problème-là, ne sont pas forcément détectés. et qui n'ont pas la chance d'avoir cette particularité complémentaire qui équilibre les choses et qui du coup se retrouvent en échec scolaire. Et donc, je m'adresse aux parents potentiels qui peuvent nous écouter. Faites diagnostic, s'il vous plaît, vos enfants. Parenthèse fermée, c'est une chance pour eux. Donc, pour des profils, on va dire neuroatypiques, qui peuvent se retrouver un peu en difficulté dans l'entreprise par des soucis de compréhension de ce qu'il y a à faire. Parce que les bonbons... c'est parce que les mots adaptés à ce type de profil ne sont pas employés. Parce que la complexité de ce qui est soit généré par IA, soit expliqué par 95% de l'entreprise est soit trop long, soit trop complexe à comprendre. Parce que, par exemple, le trouble de l'attention fait que les particularités cérébrales font qu'on décroche si c'est trop long. Et si c'est dit à l'oral. Et si c'est dit à l'oral. Le bruit, pour peu qu'il y ait une hypersensibilité, le bruit ambiant d'un open space peut faire qu'on perd la concentration. Donc, on se retrouve alors que je suis en train de discuter avec quelqu'un, à regarder le voisin qui est en train de parler au téléphone, on ne l'écoute plus et donc on perd potentiellement trois quarts du gros intérêt de la conversation. Là, je suis très focus sur un type de profil neuro-atypique, il y en a plein d'autres et de très bons techs, des très bons devs. C'est juste qu'ils ont ce genre de profil. je le connais bien, a une façon de réfléchir qui lui est propre. Et une façon de poser les problématiques qui lui est propre avec des besoins d'expliquer qui lui sont propres. Et là où il y a une chance là-dedans, c'est que ça peut être un complexe pour ces personnes-là de dire j'ai pas compris ce que vous avez dit, pardon. Est-ce qu'on peut revenir sur, vous savez, l'étape qu'on a parlé il y a à peu près 10 minutes ou que je suis en train d'essayer de comprendre alors que vous, vous êtes passé au sujet 3. ça je l'ai connu personnellement je pense que si je l'ai connu d'autres l'ont connu et l'avantage de l'IA c'est que c'est une c'est inhumain et ça ne juge pas le nombre de fois que ça doit répéter les choses pour que ce soit compris donc il n'y a pas cet effet jugement qui peut alors jugement qui potentiellement sur quelque chose qui n'est absolument pas fondé peut-être que si tu demandes 5 fois à un gars extrêmement patient un gars ou une fille pardon à une personne la personne va te le répéter 5 fois Merci. Ce n'est pas tout le monde qui fait ça. Ce n'est pas la majorité des gens. Même moi, personnellement, si j'ai une personne qui me redemande cinq fois la même chose, à un moment donné, je vais lui dire, elle se fiche de moi. Ce n'est pas possible.

• Gaël

  En général, si c'est quelque chose dont on a honte, c'est parce qu'il y a eu des signaux aussi montrés jusque-là où ça a confirmé un peu les craintes. Ça ou l'effet du nombre.

• Manu

  Tu as l'effet du nombre aussi qui peut jouer quand tu es dans un meeting de six personnes. et que les cinq personnes sont en phase et que toi, tu ne demandes que ça d'être en phase, mais tu n'as pas compris ce qui était dit, ou alors tu es en cours de réflexion, il faut raccrocher les wagons. À un moment donné, tu n'as pas le choix. Je veux dire, il faut que tu t'adaptes, il faut essayer d'avancer. C'est plus long, mais l'avantage, c'est que ces personnes-là y arrivent toujours. Là, je pense qu'avec l'IA, elles peuvent y arriver plus vite. Mon expérience, typiquement, comment je fonctionne avec l'IA, très régulièrement, j'ai des tâches qui encore aujourd'hui sont très... complexe, non pas d'un point de vue cérébral, mais d'un point de vue lecture, je dis à l'IA, explique-moi ça pour un TDAH. Scripto sensu. Elle sait le faire. Et du coup, elle va prendre le texte qui est comme ça, le répartir en puces, faire des paragraphes très concis avec des changements de police. Ça, c'est cool parce que du coup, ça fait que la monotonie d'un texte n'est plus là. Un ouvrage que j'avais lu sur les TDAH qui était hyper intéressant, c'est Pourquoi le cerveau a besoin de lunettes. chaque page est écrite dans une police différente et d'une couleur différente ce qui fait qu'on ne perd pas l'attention sur des produits comme ça et donc l'IA c'est le fer à aujourd'hui sur tout type de modèle, même les modèles les moins coûteux en token. Du coup, n'hésitez pas à l'utiliser. Vous pouvez lui demander autant de fois que vous voulez et même des moments si l'explication ne va pas, réexplique-moi. Et boucle de réexplication. Très honnêtement, je ne dirais pas que ça m'a sauvé la vie, mais ça m'a permis de biter. pleinement en disant ah ouais en fait c'est ça que ça veut dire puis après du coup tu relis la description plus complète et là d'un seul coup magie t'arrives à dérouler tout le truc tu bloques pas sur la première phrase où tu te dis oh mon dieu je comprends pas la première phrase déjà qu'est-ce que ça va être par la suite donc pour moi ça peut être game changer sur des profils qui peuvent se sentir un petit peu à la traîne mais même sans parler de profils neuro-antipiques un junior qui va arriver sur le marché du travail Merci. et qui va se retrouver noyé sur la logique métier de sa boîte, de son stage, de son apprentissage ou de son premier boulot. C'est beaucoup pour un ingénieur. Au-delà de comprendre une techno, comme je disais, il doit connaître son équipe. Des moments, c'est des personnes assez jeunes ou en reconversion qui ne sont pas hyper à l'aise à donner leur avis parce que pour revenir à ce qu'on demandait à un développeur quand tu te retrouves à une réunion de dev en planning poker. où tu dois noter des trucs et donc des moments donner ton avis. Ah, je ne peux pas le donner parce que je ne sais pas de quoi vous parlez ou alors je suis encore en phase d'apprentissage. On a besoin de mots précis des moments. Et tout le monde ne peut pas avoir les bons mots pour tout le monde. Ce n'est pas possible. Par contre, tout le monde sait quels mots vont faire sens. Donc, c'est quelque chose. Donc, l'IA peut s'ajuster à tout ça. Et c'est ça la force du truc, c'est que c'est hyper personnalisable. Oui,

• Gaël

  on peut vraiment le personnaliser, on peut vraiment individualiser. Après, il faudrait presque que chaque personne se fasse son mini mode d'emploi de comment elle fonctionne ou aussi par rapport à son métier et de ce dont elle a besoin pour travailler et qui est autant d'onglet que de métier, de manière de fonctionner. C'est vrai qu'il y a... Moi, je sais que pour... faire quelque chose, il faut que je comprenne pourquoi je vais le faire. Et ça, c'est super important. Et des fois, ça bloque juste là-dessus et qu'on me dit, bah non, il faut juste le faire. Bah ouais, mais en fait, si je comprends pas pourquoi, je vais pas bien le faire. Et de prendre le... d'avoir ça, qui est peut-être même presque systématique, mais d'avoir un peu cette hyper-personnalisation qui donne les bonnes conditions de travail et toutes les bonnes ressources et les bonnes conditions pour exécuter, pour travailler et... se faire comprendre par d'autres profils et presque faciliter aussi la communication. Le but, ce n'est pas d'enlever complètement cette communication, mais de se dire, ah bah tiens, telle personne réfléchit de telle manière, elle a besoin de tel vocabulaire. Moi, j'ai pu le lire aussi parce que j'étais un peu curieux. J'ai regardé comment la PR que j'ai rédigée, elle est rédigée pour telle personne pour qu'elle puisse la comprendre. Et ça peut aider à faire des connexions et à peut-être moins segmenter aussi le travail. C'est vrai que c'est quelque chose d'assez français aussi de répartir en métier. Alors, je ne sais pas si c'est pareil au Canada de plus travailler en feature, en fonctionnalité. Je ne sais pas si le management est un peu différent d'ailleurs.

• Manu

  Le management est différent, mais pas pour la raison que tu évoques.

• Gaël

  D'accord, ok.

• Manu

  Pourquoi je dis ça ? parce que mon expérience par rapport à la France, c'est que... Là-bas, ils sont très dans la réaction. C'est-à-dire qu'ils développent, ils cassent et ils réparent après. Nous, on essaye de prévoir les choses. Il faut que ça aille vite. Ils doivent être très contents, je pense, avec l'IA aujourd'hui, de pouvoir coder très rapidement, d'envoyer des proof-of-concept en prod et puis derrière, de réparer une fois que c'est cassé. Par contre, un truc auquel je pensais et qui m'est arrivé quand j'étais là-bas, c'est quand tu travailles en contexte bilingue. et que tu n'es pas forcément en... Comment dire ? Moi, l'anglais, je savais parler anglais, mais l'anglais bilingue, c'est autre chose. Quand tu dois faire des meetings en anglais, que tu dois comprendre tout ce qui est dit, etc. Ça, c'est pareil. Ça peut aider quelqu'un qui est un peu newbie dans cet univers-là à comprendre le bien-fondé d'un meeting où il y avait une grosse partie de quelqu'un avec un accent, ou inversement, d'un anglophone par rapport à un francophone. avec un accent potentiellement très prononcé où, en gros, si tu ne lui demandes pas de répéter ou d'articuler un petit peu plus, c'est très compliqué de comprendre le bien fondé de ce qui a été dit, surtout sur des aimants qui peuvent être clés par rapport à ce que tu vas rédiger après.

• Gaël

  Et puis toutes les nuances aussi. Toutes les nuances,

• Manu

  effectivement. Donc là, ça aussi, ça peut aider. Parce que le nombre de fois, à titre personnel ou post-réunion, j'ai dû envoyer des slacks à une autre personne de l'équipe pour lui dire « Je pense avoir compris ça, est-ce que tu peux me le confirmer ? » Le gars, il a dû prendre le temps de me répondre et moi, je me suis senti un peu mal parce que c'était pour des questions de… C'était l'impression de faire perdre son temps à la personne. Alors que finalement, non, mais c'est quelque chose que tu peux… tu peux éventuellement éviter ce genre de choses.

• Gaël

  Je pense que là, ça va peut-être être plus le moment de Manu pour parler de la partie...

• Lulu

  Oui, j'avais deux... Là, du coup, j'avais deux questions. Déjà, pour revenir sur ton usage à toi de l'IA, sans rentrer dans le détail de ce que tu présenteras justement à la conférence et au forum PHP qui est vraiment très orienté sur la revue de code. Mais aujourd'hui, c'est où ? justement dans ton quotidien de dev que tu utilises le plus l'IA ou en tout cas où est-ce que tu lui trouves le plus de valeur et un peu quels sont les trucs les plus importants que tu aurais à dire sont bonne pratique ou en tout cas en

• Manu

  point de vigilance éventuellement alors en point de vigilance déjà ne faites jamais confiance à l'IA pleinement pour la review Déjà, en fait, la code review, c'est un des éléments les plus humains qu'il faudra conserver dans toute la chaîne de développement qu'il va y avoir. Moi, je délègue beaucoup le code à lire, je ne m'en cache pas. Aujourd'hui, je ne touche quasiment plus à une ligne de code. Pourquoi ? Parce que je sais ce que je veux. Généralement, ça part du ticket. Et en vrai, de vrai, le... toute cette nouveauté, cet écosystème, elle m'a refait un peu penser, repenser à ce qui me faisait kiffer mon métier au quotidien de dev. Et à titre personnel, je me suis rendu compte que ne plus avoir à écrire de code, donc pas le réfléchir, l'écrire, ça ne me manque pas en fait. Ça ne me manque pas du tout parce que je prends beaucoup plus de plaisir à réanalyser ce qui est fait, comprendre ce qui est fait on va dire j'ai pas le mot qui me vient architecturer définir construire les choses imaginer à quoi ça va ressembler le donner à l'IA dire vas-y fabrique-le moi mais tu me laisses quand même regarder ce que t'as fait parce que pour des raisons de si demain j'ai plus l'IA je veux quand même savoir ce que t'as fait pour pouvoir le reprendre c'est comme n'importe quel senior que tu vas recruter dans une entreprise de n'importe quel junior tu vas essayer de comprendre ce qu'il a fait. La personne, elle s'en va, elle quitte l'entreprise. Aujourd'hui, tu ne fais pas une confiance aveugle en disant, non, mais c'est bon, t'inquiète, trust you, aucun problème. Non, tu contrôles ce qui est fait, ou quelqu'un contrôle ce qui est fait. Donc, aujourd'hui, l'IA, je m'en sers, comme je disais, je la laisse coder. La partie review, je la prends. Justement, le temps que je ne code plus, je le perfectionne. plus sur des problématiques architecturales, genre le fait de ne plus coder m'a permis de me concentrer typiquement sur le DDD, comprendre le DDD, comment ça fonctionne, quelles sont les différentes couches, les architectures hexagonales, comment ça fonctionne, est-ce qu'il est plus pertinent d'utiliser telle ou telle archi ? Quand le temps que tu ne passes plus à coder, tu peux le passer à te poser ce genre de questions. Et ensuite, comment je peux être meilleur en code review ? Parce que le postulat de base, c'est que je me sentais, en fait, au vu de la volumétrie. qui est sorti de tout ce qui est pondu aujourd'hui, que ce soit même encore par des collègues, etc., ça m'a fait repenser à est-ce que vraiment, en étant honnête avec toi-même, tu n'as pas déjà laissé passer des choses sans les regarder ? Et si, en fait. Je l'ai déjà fait et c'est gênant. C'est très, très gênant. Donc, je vais porter beaucoup plus attention à la review. Je passe beaucoup, beaucoup plus de temps à reviewer aujourd'hui que je ne le faisais avant. Je passe beaucoup moins de temps à développer, mais beaucoup plus de temps à réjouir et à architecturer paradoxalement. Donc, oui, je suis plus performant en dev. Enfin, je suis plus performant. On va dire que sur la fenêtre d'une journée, la partie dev, je l'ai réduite à ça. Mais par contre, tout le reste, je l'ai agrandie en proportion. En fait, la partie réflexion, je passe beaucoup plus de temps sur de la réflexion que sur de la réelle réalisation. C'est pas français.

• Lulu

  Que de l'exécution.

• Manu

  Que de l'exécution, merci. Et en fait, c'est hyper stimulant, les échanges que je peux avoir avec l'outil. Parce que je ne parlerais pas de Zulia comme d'une personne, mais bien d'un outil. Moi, j'ai toujours adoré le pair programming. Et là, j'ai un peu un pair programming dissimulé quelque part. C'est que j'échange avec et je dis, « Ouais, mais t'as fait ça, mais pourquoi t'as fait ça ? » « Bah, j'ai fait ça parce que ça. » Et le nombre de trucs que j'ai appris en conversant et en challengeant l'IA sur Scalami, en me disant, « Mais pourquoi t'as fait ça ? » Et là, tu vois l'outil qui te dit, « Bah, j'ai fait ça parce que… » Et après, il réfléchit. « Ah, mais en fait, tu viens de lever un point et en fait, du coup, il s'auto-corrige. Et derrière, t'avances, tu dis, « Mais attends, je vais aller plus loin, je vais regarder là. » Et en fait, tu te réveilles, tu regardes, c'est comme un jeu vidéo. Tu te réveilles, mon Dieu, il est déjà 5 heures. et du coup alors ça m'est propre mais cette révision de ma façon de bosser je elle est beaucoup elle est parlante pour moi de mais elle va de pair avec la révision de certaines pratiques de mon quotidien que j'étais que j'avais mis un peu en soum-soum c'est pour ça que je m'intéresse beaucoup à la code review c'est que j'ai l'impression comme je le disais que ça va être un peu le On va nous demander de faire beaucoup ça aujourd'hui, maintenant. On va nous demander d'être des reviewers hors pair, de savoir détecter les trucs, de détecter les loups métiers qui ont été oubliés dans ce qui a été fait, tout ce qui est syntaxe, etc., les outils d'analyse syntaxique, etc., ils le font très bien, les CS Fixer, les PHP Stan, etc., on leur délègue le tout, ils le font très bien. Cette partie-là, on a pu s'en occuper. Par contre, il y a des éléments à reviewer qui sont... hyper important pour la cohésion d'équipe, pour le suivi du projet, pour la vision globale du truc. Je pense qu'on n'imagine pas le nombre de choses qu'on passe sous le tapis ou qu'on ne contrôle pas par habitude de review ancestrale. Parce que la review, ce n'est pas dire qu'on review depuis des années et des années. Mais je n'ai pas le souvenir, en tout cas, d'avoir assisté à une conf de quelqu'un qui s'est posé à un moment donné et qui s'est posé la question, est-ce que je review bien ? cette partie-là, est-ce qu'on a beaucoup de comptes sur le PHP, sur comment bien développer, sur du Symfony, sur FrankenPHP, sur des technos, mais la code review, la phase de code review, la façon dont on va relire une MR, le temps qu'on va y passer, quels sont les éléments, qu'est-ce que je dois regarder, comment je la lis, est-ce que je la lis ligne par ligne, est-ce que je dois diviser ma perception, etc. Je trouve que la littérature, en tout cas, elle est assez pauvre, je dirais. C'est pour ça que quand vous m'avez demandé d'envoyer des littératures, je dis en fait, je n'en ai pas vraiment parce que je n'en trouve pas beaucoup. Et aujourd'hui, je pense qu'on va aller dans l'invention ou la remise au goût du jour de certaines méthodologies de review. Parce que c'est là que…

• Gaël

  On peut tellement bien en écrire une aussi.

• Manu

  Exactement. Et comment faire en sorte que ce qu'on produit ou que ce que l'IA produit… cohérent avec une bonne review à mener. Parce que ça part aussi d'un travail de... Ça part aussi d'un travail qui est fait par le dev. Spoiler alert, mais s'en ficher, c'est pas possible pour NMR. Je vous pose la question, vous vous retrouvez devant NMR de s'en ficher. Vous lâchez au bout du combien ?

• Lulu

  Mais alors, ça tombe bien que tu poses la question parce que là, ce que j'ai demandé juste après, c'est est-ce que du coup c'est envisageable ? Et si oui... comment s'y prendre quand on va faire de la code review et qu'on n'est pas développeur ou développeuse de métier et qu'on s'est mis au développement à si c'était pareil. Typiquement, moi, je suis là-dedans. Du coup, maintenant, je développe à l'aide de l'IA. Et en fait, moi, le temps, je vais le consacrer sur les parties. J'étais product owner avant et j'ai fait du développement, la programmation visuelle justement avec du no-code. J'ai plein de bribes, mais l'écriture de code et le code en lui-même, je ne sais ni l'écrire ni le lire. à part des petits bouts de script ou des petits passages, mais une paire entière. Le code en lui-même, je ne vais pas pouvoir le lire. Et du coup, en fait, je cadre tout ce qu'il y a autour, autant que possible. Alors,

• Manu

  tu peux faire ça, mais est-ce que le code, tu as envie de l'apprendre aussi ? Tu as aussi ça, cette base. Est-ce que tu as envie de monter en compétence ou c'est quelque chose que tu n'as pas envie de connaître ?

• Lulu

  Ah non, le code, je n'ai pas envie de le connaître. Je n'ai pas envie d'apprendre aujourd'hui le code en lui-même. Mais par contre, j'aimerais m'assurer que ce qui est fait est bien fait. Et autant, tu vois, sur la partie en amont, j'arrive à identifier un certain nombre de choses, justement, sur le cadrage, sur la logique, sur la réflexion, sur l'architecture, etc. Sur la partie review, aujourd'hui, justement, je ne vois pas comment le faire bien en tant que profil non technique.

• Manu

  La code review, il faut bien avoir en tête que... Alors après, tout ce que je dis est à challenger, justement, en échange. Mais il faut comprendre ce que tu relis. La code review, c'est une relecture. Donc, si jamais il y a quelque chose qui a été généré et que tu ne comprends pas, la seule chose que tu peux faire, c'est utiliser l'IA pour questionner si tant est que tu as envie de comprendre ce qui a été fait. Parce que derrière, un profil non tech, la seule chose, un PM par exemple, qui va vouloir inventer un produit, il s'en cogne du code. Il s'en cogne. Le problème derrière qui va se poser à lui, c'est d'un, si jamais il n'y a plus d'IA ou que Claude saute. comme il saute 5 à 10 fois par semaine. Je parle de Claude parce que c'est ce que j'utilise, mais Gemini, etc. Je ne sais pas. Tu te retrouves avec ton produit, tu ne sais plus le maintenir. C'est dommage. Et derrière, ça, c'est sur la partie que j'estime un peu dangereuse du truc. J'essaie de prévoir tous les cas. Mais sur ce qui a été généré, si tu as un profil purement non tech, Toi, ta code review, c'est plus une QA que tu vas faire. Ce n'est pas de la code review. La code review, c'est de la revue de code. Donc, revue de code veut dire je revois le code. Donc, derrière, le tech, ça demande quand même un minimum de compétences techniques dans la mesure où il faut que tu sois capable de comprendre ce qui a été généré. Tu vois ce que je veux dire ?

• Lulu

  Oui. Oui, alors oui. En fait,

• Manu

  il y a deux choses. Il faut scinder vraiment la... la partie QA test de mon applicatif, est-ce que j'ai le rendu que je veux d'un point de vue UI ou d'un point de vue CLI et la revue de code qui est, est-ce que ça respecte l'architecture que je m'attendais à avoir ? Typiquement, si j'ai choisi que mon produit d'un point de vue technique devait être en MVC, donc modèle vue contrôleur, simple symphonie avec un contrôleur qui va appeler des ripos, etc. Est-ce qu'il n'est pas parti en vrille et qu'il ne m'a pas fait du TDD ? C'est un exemple, je te dis ça. Ensuite, d'un point de vue code, j'avais un ticket avec des critères d'acceptance. Est-ce que les tests qui sont écrits couvrent tous les critères d'acceptance ? Il faut que tu sois quand même capable de lire un test. Donc, la code review, c'est quand même orienté sur des techs, sur des profils assez tech. Tu ne vas pas demander à un product manager de faire une code review ?

• Lulu

  Justement, en fait, c'était là où je voulais en venir, c'est dans la review globale. Donc, une fois que ta PR, enfin, en gros, une fois que le code a été rédigé, une fois que tu as l'ensemble qui a été rédigé, qu'est-ce qui est accessible, justement, au profil de l'entreprise technique ? Donc, sur la partie test, on tient bon d'accord, puisque ça, c'est des choses qu'on peut quantifier, tester, challenger, et qu'il est nécessaire de faire à chaque fois. Voir aussi, justement, si la partie, entre guillemets, la partie métier fonctionnelle, du coup, qui est adressée dans le rapport qui est en effet, et dans la documentation, si ce qui est mis est raccord. La partie code en elle-même, du coup, pour des profils comme moi, on n'est pas en mesure de le comprendre. Et du coup, est-ce qu'il y a d'autres points, justement, là, tu as évoqué l'architecture, l'actualité, est-ce qu'il y a d'autres choses sur lesquelles on peut jouer ? Ou est-ce qu'éventuellement,

• Manu

  il y aurait des... Oui, on peut faire de la review de diagramme. Les documentations étant versionnées, tu peux très bien faire une PR d'une mise à jour de doc. Et dans ce cas-là, ça, je peux te l'envoyer et puis te dire, est-ce que tu me valides bien que les modifs que j'ai faits et que j'ai impactés au niveau de mes entités, le modèle de données qui répond bien. Un modèle de données, généralement, tout le monde est à peu près capable de le comprendre. De dire que j'ai un modèle e-commerce dans lequel on va stocker des produits, un schéma de produits qui doit contenir un nouveau champ, une promotion par exemple, j'en sais rien, qu'on doit rajouter dans le cadre d'une feature, ça peut être intéressant que la partie métier valide que j'ai bien documenté dans le cadre d'une didoscorerie ou de ce qu'on appelle des ADR, donc pour des Decision Record, tout ce qui est Decision Record, généralement, on va mettre en place des ADR. Ça peut être des ADR techniques, sur le choix d'une techno en particulier, de cache, mais ça peut être aussi des ADR fonctionnels, de dire on va partir sur telle modélisation, etc. Donc ça, c'est des éléments, tout ce qui est éléments de documentation et on va dire spécifications peut aussi être reviewé. La partie purement technique, elle va être jouée par des gens qui maîtrisent ce qui sort pour que ça marche. Mais tout ce qu'il y a en amont, la création de tickets ou alors les specs sur lesquels vont se reposer les tickets, que l'IA va aller lire pour en déduire le code qu'elle va elle-même pondre, ça c'est quelque chose que toi, en tant qu'élément non tech, tu, à mon sens, es et dois maîtriser et ça, la review peut t'aider à le maîtriser. dans le suivi, etc. Je ne sais pas si ça répond à ta question.

• Lulu

  Si, complètement, parce qu'en fait, même les diagrammes et les trucs comme ça, c'est des choses que je fais... En amont, à chaque fois. Ou pendant l'APR, justement, quand il y a des questions et des points et des choses que je ne comprends pas. Par contre, typiquement, autant dans les docs, les trucs que j'avais d'un côté à l'autre qui ressortent tel quel sur du schéma, oui. Mais le fait de lui demander de me faire des schémas et de me refaire des nouveaux diagrammes pour le code qu'elle a sorti et m'assurer à travers le diagramme que c'est conforme, je ne le faisais pas. Et du coup, je vais commencer par tester ça.

• Gaël

  Parce que ça me fait penser à ce qu'on me disait pour l'inclusivité. En soi, l'accessibilité, si on n'arrive pas à lire du code, comment est-ce qu'on peut le traduire pour quelqu'un qui a envie de s'intéresser quand même, mais pas forcément à comprendre vraiment la partie purement syntaxique, de se dire « bon, ça s'écrit de telle manière » , mais comment est-ce qu'on peut le représenter ? Pour qu'on puisse interagir et qu'on puisse avoir un vocabulaire qu'on peut utiliser, interroger l'IA aussi pour savoir si c'est bon, puis monter en compétence aussi au fur et à mesure, sans forcément apprendre à écrire du code. Mais comment est-ce qu'on pourrait le rendre compréhensible ?

• Manu

  Il ne faut pas oublier que l'IA a besoin de sources de vérité. D'ailleurs, pour être pleinement opérationnel... initialement parlant, l'IA, c'est bête. Elle va juste demander des sources que tu vas lui filer, des contextes qui te sont propres, et à partir de tout ça, elle va agréger tout ça et en déduire des outputs. Mais si t'es pas capable de la... comme un enfant, de la prendre par le callback et puis de lui dire, attends, te jette pas par la falaise, elle va y aller. Et faut absolument pas négliger cette partie. une spec mal tournée ou un besoin métier mal documenté quelque part. Alors, on parlait drague tout à l'heure, ça peut être ni plus ni moins qu'une simple base documentaire. Le rag, c'est déjà l'étape d'après. On est déjà dans l'optimisation de retour. Tout ça, ça se versionne. Et je vais même aller jusqu'à pousser le délire à dire des promptes se reviewent aussi. Parce qu'on va maintenir des projets de promptes aujourd'hui. On va maintenir des skills, on en parlait tout à l'heure. Ça, aujourd'hui, c'est du langage humain. Un profil non tech, il est capable de le reviewer.

• Lulu

  En plus, je trouve que c'est quelque chose qu'on est obligé de challenger régulièrement. Je sais que les skills, je pense qu'il doit y avoir au moins une fois par mois où je suis obligé de les reprendre, les mettre à jour et les ajuster.

• Manu

  Même les agents ? Excuse-moi.

• Gaël

  Je ne sais pas si tu connais le slash insights sur code. Oui, il est bien celui-là.

• Manu

  Mais après, même tout ce qui est les notions de MCP, etc., ça, il va y en avoir pléthore dans la délégion. Du coup, j'ai oublié ce que je voulais dire. Mince. Désolée. Non, non, je t'en prie. Ça reviendra plus tard. Tant pis.

• Lulu

  C'était sur la mise de jour des skills réguliers.

• Gaël

  Ah oui.

• Manu

  Oui, non, c'est ça. Du coup, même les agents en cocktail, un agent, ça se perfectionne. Ça se... un prompt d'agent, ça s'améliore, ça se réduit. Au départ, mes prompts d'agent étaient comme ça. Et après, j'ai posé la simple question de qu'est-ce que je peux sortir en skills, par exemple. Et après, j'ai mis en place des boucles de rétroaction où sur chaque utilisation de Cloud, ça me générait des rapports d'utilisation qu'un script allait utiliser pour dire sur les cinq ou six dernières itérations, il s'est passé ça, Du coup, je vais améliorer l'agent pour inclure ces parties-là, afin que l'agent soit en constante évolution. Ça, c'est pareil, ça se versionne tout ça. Ça se versionne et ça se review. Un agent se review. Si tu laisses, alors que l'IA te propose des améliorations, ça va tellement vite. En fait, l'IA, j'ai regardé une vidéo, pas plus tard qu'aujourd'hui, je crois que c'est le patron de Clever Cloud qui était interrogé. Et il disait, l'IA, il faut la garder pour des tâches inhumaines. C'est parce que c'est inhumain, l'IA. Et passer son temps à optimiser des agents sur de l'interrogation constante et sur le quotidien, tu as autre chose à penser dans ta journée. Tu ne vas pas penser à améliorer tes agents en parallèle, sinon tu vas perdre un temps fou. Donc, que tu lui laisses cette partie-là. la laisser travailler, etc. Nos problèmes, vas-y, fais ce que tu as envie de faire, fais ton boulot. Par contre, derrière, ne jamais oublier deux choses, c'est que d'un, on ne tiendra jamais responsable de l'IA pour des bêtises qui sont envoyées en prod ou que tu génères. Jamais. Donc du coup, si tu fais confiance totale à l'IA, tu as intérêt à être bien serein ou avoir une bonne stature devant ta clientèle. Et pour revenir au niveau des agents, savoir ce qu'ils produisent, c'est toujours un gain pour le quotidien. C'est une crainte en moins, derrière. Et le but étant d'être plus performant, si même avec une simple relecture, pardon, j'ai perdu le fil, si jamais tu ne relis pas, tu ne peux pas garantir ça. On ne demande pas de passer des heures à relire, mais il faut contrôler un minimum parce que tu n'as aucune garantie que sur 11 lancements de prompt, la deuxième fois, ça marche encore. Et c'est ça tout le problème du truc, c'est que c'est de l'utilisation énergétique, non pas pour de l'aléatoire, mais pour de l'incertain. un algorithme, tu demandes un code de ta output 1 plus 1, tu vas le lancer un milliard de millions de fois, il va toujours te répondre 2. L'IA, t'es jamais sûr de ça. Et d'expérience, t'as une liste d'agents qui te font une feature, tu les paramètres avec des retours d'expérience, donc tu dis j'ai un architecte qui travaille avec un mec qui va faire du front, un mec qui va faire du back, j'ai un testeur, etc. Donc j'ai une petite équipe, des petits... des petits agents qui tournent, qui font des trucs un peu sympas. Et d'un seul coup, tu ne sais pas pourquoi, sur le lancement de la feature numéro 4, ton contrôleur ne ressent plus rien. Qu'est-ce qui s'est passé entre deux dans ta vie pour que tu aies changé ? Tu ne sais pas, mais il a changé. Et justement, par rapport à la code review, la code review peut éviter ça. Parce que derrière tout ça, c'est de la dette technique que tu ne vois pas qui va s'accumuler. Donc, c'est aussi un garde-fou pour l'avenir. Amen.

• Gaël

  C'est vrai que justement, j'écoutais un podcast où l'idée c'est de pondre du texte. L'IA sait très bien le faire, notamment avec des profils. Je ne pense pas qu'il faut forcément être neurotypique pour ne pas réussir à agurgiter des gros pavés. De se demander comment est-ce que nous... peut se faciliter la tâche aussi quand on va faire de la code review ou peu importe de la relecture de ce que l'IA a produit. Comment est-ce qu'on peut le présenter pour que ça soit peut-être aussi plus schématique, de montrer tiens, avant c'était comme ça, les changements qu'il y a eu c'est ceux-là pour tout de suite pouvoir bien cibler les endroits où ça a changé et ça je pense qu'on n'est même pas obligé d'utiliser l'IA pour ça, il y a des outils qui le font très bien pour montrer les endroits où Il y a eu des changements, parce que c'est sûr que si on intervient sur telle fonctionnalité, si ça a été changé dans quelque chose qui n'a rien à voir, ça c'est bien de le voir, mais peut-être visuellement aussi. Là justement, c'est aussi se demander comment... Après tu l'as expliqué, toi tu challenges, tu discutes vraiment, parce que faire de la review sur quelque chose qu'on a... pas écrit. Parce que je pense que quand t'écris ton code, tu sais que quelqu'un va le relire. L'IA, je veux dire, elle n'a pas de volonté. Elle n'a pas peur de se faire taper sur les doigts ou de passer... Elle ne sait pas forcément que son code va être lu. Alors que toi, quand tu le fais, est-ce que ce n'est pas du temps de gagner sur la code review ? Comment est-ce que t'arrives à garder un peu la main sur des choses que t'as... Enfin, pas écrit, en fait.

• Manu

  Justement, en m'assurant que ça respecte un peu la façon dont moi j'aurais écrit la chose. Mais en fait, on parle d'IA, mais c'est aussi ce que j'aurais attendu d'un humain, d'un senior ou d'un junior. Tu as un cadre à respecter. Donc déjà, premièrement, est-ce que tu as respecté le cadre ? Et deuxièmement, est-ce que tu as rendu ce qu'on s'attendait à ce que tu livres ? Est-ce qu'il y a des tests, etc. ? il faut juste avoir en tête que la pratique de la code review, on la faisait déjà avant et ça n'a jamais posé de problème à personne et ça même fait partie des standards c'est-à-dire qu'un dev, quand il développe il sait que son code va être relu c'est même attendu, moi je souhaite que mon code soit relu je ne sais pas si ta question c'était plus dans le sens, est-ce que quand je développe j'ai peur d'être relu, alors que Liane n'a pas. Non,

• Gaël

  mais tu prépares un peu cette code review aussi, tu vois, tu le... Quand tu écris, tu le penses en amont et c'est…

• Manu

  Mais pas sur les premières itérations. Oui, ok. Parce que tu dis quand tu… Alors, avec le temps, oui, quand tu connais tes collègues et qu'ils t'ont fait justement des retours, tu capitalises sur cette expérience-là pour dire « j'ai fait une erreur ou une façon de faire qui ne plaisait pas, je ne suis pas idiot, je ne vais pas la refaire deux fois, trois fois, sinon ça s'appelle de la bêtise » . Mais… Et donc… Le faire avec l'IA, c'est exactement pareil. Même si c'est une machine qui génère, le code est relu. Et le code sera toujours relu. Quand tu lis tous les articles qu'il y a sur l'IA, quand tu lis tout, en tout cas pas tous, mais je ne me permets pas de dire que j'ai lu tous les articles sur l'IA, mais beaucoup d'articles qui tournent sur la pratique du développement dans l'IA disent que le code doit être relu et revu. Il faut revoir ce qui est... Justement, je reviens sur la vidéo. le mec de la vidéo disait que l'IA, c'est ni plus ni moins qu'un junior qui a à gérer toutes les thèses du monde. Mais derrière, au même titre qu'un junior, tu vas devoir relire ce qu'il a fait et contrôler ce qu'il a fait. Ce n'est pas du flicage, ce n'est pas relire pour dire l'homme est supérieur à la machine ou le seigneur est supérieur au junior ou moi, je vaux mieux que toi. C'est simplement de dire n'importe qui, on ne travaille pas, personne, que ce soit humain ou machine, ne travaille de manière isolée. On travaille tous pour un but commun et il faut que tout le monde soit dans les clous. Et tout le monde fait des erreurs. Certains plus que d'autres, certains moins que d'autres. Oui, que ce soit un développeur ou une IA,

• Gaël

  effectivement, il ne faut pas travailler tout seul dans son coin parce que ça, c'est une bombe à retardement. Et l'IA, vu qu'elle va encore plus vite, ça accélère et ça amplifie d'autant plus ce phénomène-là.

• Manu

  Et donc, ça demande justement à revoir certaines pratiques qui étaient déjà là, mais que... Si on prend l'exemple de la mise en place d'une architecture, le nombre de fois où des gens qui ont démarré un projet ont fait des MR qui te mettent tout un socle Symfony en place et qui, du coup, tu te retrouves avec des MR de 40, 45 fichiers à relire, ça, c'est déjà arrivé. Et... prends cet exemple-là, mais tu as aussi des exemples de features hyper complexes où les gens n'ont pas fait, où le développeur n'a pas fait cet effort de split de MR. Parce que ça demande quand même une sacrée réflexion de dire, attends, qu'est-ce qui est atomique ? Qu'est-ce que je peux mettre là ? Qu'est-ce que je peux mettre là ? Comment je peux articuler les trucs pour que ce soit réellement ? C'est très costaud d'un point de vue cérébral de fonctionner comme ça. Là, tu as cette capacité. Là, s'il y a bien un truc que l'il y a fait vite, et pour toi c'est ça donc il ne faut pas s'en priver

• Lulu

  On a fait un épisode bien long mais j'aimerais quand même qu'on c'était très intéressant et ça me fait très plaisir aussi justement d'avoir ton point de vue de développeur qui a adopté l'IA sans en avoir peur et plutôt avec curiosité pour en prendre les bons aspects À travers tout ce que tu as dit, il nous a montré justement les différents endroits où ça peut servir de levier. Ça a des vrais points pertinents à plein de moments. Et tout en gardant justement... Tu l'as même présenté en tant qu'architecte de solution plus que développeur, puisque aujourd'hui, ça te permet quand même de te faire kiffer dans ton boulot sur plein d'aspects différents d'avant. Enfin, d'aspects. Ça t'a permis d'aller plus loin sur des aspects où avant, tu avais moins de temps. Et justement, j'aimerais juste terminer là sur deux questions, c'est qu'est-ce que tu pourrais donner comme conseil aujourd'hui aux développeurs et développeuses qui sont encore réfractaires à l'IA ou qui ont envie de passer le cap et de s'y mettre en se disant que ça fait partie des choses maintenant qui font partie du métier et qui vaut mieux s'approprier, mais qui ne savent pas forcément par où commencer. Quelle serait justement la première étape, le premier, le début par rapport ?

• Manu

  Déjà, je vais plus m'adresser à ces gens-là parce que les vrais réfractaires, il ne faut pas les mettre de côté dans la mesure où les personnes qui sont réfractaires, elles le sont aujourd'hui pour des raisons extrêmement légitimes. Que ce soit écologique, que ce soit d'une peur de ce qui va arriver, c'est très incertain. Et avant de m'adresser aux personnes convaincues, juste dire qu'il faut prendre le temps de comprendre ce qui ne va pas et d'essayer d'accompagner un temps bien. Ce n'est pas juste... Je te balance l'IA et t'adhères ou t'adhères pas, c'est pareil. Je pense que c'est bien plus compliqué que ça. Il y a des vraies situations familiales qui peuvent... Ça change tellement de trucs qu'il faut écouter ces personnes-là et essayer de comprendre. C'est plus facile à dire qu'à faire, mais j'en connais des vrais réfractaires et ils se sentent un peu balayés là-dedans par ce tourbillon-là, alors qu'eux n'ont pas envie d'y aller. Et des moments, j'ai un peu de peine parce que mon ressenti, c'est qu'on ne va pas laisser le choix aux gens parce que ça va tellement vite. Et économiquement parlant, c'est tellement vu comme game changer que les... pas les desirata, mais les craintes des uns et des autres, à un moment donné, ça va passer. Moi, ça m'embête pour ces gens-là, parce que quand ils t'exposent leurs raisons, tu dis oui, tu as raison. Donc ça, je veux juste en parler pour avoir une pensée pour eux, parce que ce n'est pas marrant, ce n'est pas vraiment évident. Maintenant...

• Gaël

  C'est vrai qu'on l'utilise aussi, mais on reste très critique par rapport à ça et que ce n'est pas forcément un choix non plus.

• Manu

  C'est ça. C'est parfois et souvent un peu imposé, certaines personnes. Maintenant, ceci étant mis de côté, pour les personnes qui ont vraiment envie de l'utiliser à titre personnel j'irais step by step déjà la première chose que je dirais c'est ne prenez pas la vision que vous aviez d'un chat GPT où je vais demander la météo demain c'est pas ça ça fonctionne pas comme ça c'est pas coucou coucou comment dire un truc génère moi un applicatif qui me donne la météo c'est plus compliqué que ça. C'est vraiment un élément technique qu'il faut comprendre dans tous ses aspects. Tu l'as dit un peu tout à l'heure, Manu, comprendre ce que c'est une skill, de savoir ce que c'est un modèle, d'essayer de comprendre quel modèle va mieux dans telles circonstances, etc. Juste ce qu'est un agent, à quoi ça sert, et avoir déjà les notions de base de l'IA. déjà juste ça ensuite essayer d'itérer sur un petit projet pour voir ce que ça génère c'est déjà bien quand c'est concret et qu'on le voit quand on a vu que ça était capable d'interagir tout seul avec des systèmes comme GitHub etc que ça pouvait générer du code parfois crade mais parfois pas au moins il y a matière à discuter et derrière se rendre compte de la rapidité du truc et après il y a les femmes Moi, mon expérience, c'est d'y aller par itération. Peut-être se servir de projets d'entreprise pour y arriver, de dire j'ai telle feature, je vais essayer de lui donner pour voir ce qu'elle va me générer. En fait, c'est l'expérience. Il faut expérimenter. De manière générale, il faut expérimenter. Il n'y a qu'en expérimentant que les gens vont se rendre compte parce qu'après, comme c'est que du textuel, il y a beaucoup de vibe coding dedans. Majoritairement, j'écris euh... génère-moi ça, change-moi cette phrase pour me l'adapter, etc. Il faut expérimenter, essayer. Moi, j'ai essayé. J'ai juste dit, voilà, j'ai une idée. Ça peut partir d'une idée toute simple. Par exemple, si quelqu'un a un projet en tête qu'il a depuis très longtemps mais qu'il a mis au placard parce qu'il n'a pas de temps, je lui dis, voilà, j'ai une idée en tête, je pars d'une conversation sur, je ne sais pas, Gemini ou à Cloud.ai, prenez ce que vous voulez et posez-lui juste la question, voilà, ce produit, tu me l'as dit. couperait en combien de features et quelles sont ces features. Il va dire, voilà, feature 1, mise en place du socle technique, feature 2, intégration de produits, 2, intégration de catégories de produits, etc. Je prends l'exemple d'une boutique e-commerce, évidemment. Et à la fin, vous prenez ces features-là, générez donc les prompts de features, vous les balancez dans un coup de code, un curseur, ce que vous voulez et vous voyez ce que ça génère. Et après, vous vous faites un avis sur... Est-ce que c'était dans les clous de ce que j'ai l'habitude de faire ? Si ça a dévié, ça a dévié en quoi ? Comment je peux le rattraper ? Et petit à petit, vous créez un agent qui va s'occuper de telle partie, un autre qui va s'occuper de telle partie, puis un autre, puis un autre, puis un autre. Vous faites une petite équipe. Et après, vous tirez, vous décritez, vous écoutez la pelote de laine jusqu'à arriver à un résultat qui vous… L'idée, c'est toujours envie d'aller plus loin. et voilà moi si j'étais nouveau d'aide c'est comme ça que personnellement je ferais.

• Lulu

  Merci beaucoup Merci, c'était cool Je suis complètement d'accord aussi sur le fait que c'est surtout à travers la pratique que Lya se prend en main

• Gaël

  Oui de le prendre avec curiosité et de pas prendre aussi pour vrai tout ce qu'elle dit parce que elle tire avec beaucoup d'aplomb voilà c'est du texte qui est généré c'est Il y a quelques concepts à connaître, après, comme la fenêtre de contexte, des choses qui sont très inhérentes à la technologie, et que ça, c'est bien de savoir, mais après, oui, l'itération, c'est... demander aussi quand on ne comprend pas ce qui a été fait. Là même, j'écoutais, c'était sur l'auto-apprentissage, tout simplement dire, bon, là, on a fait telle chose, on a développé telle chose, on a réalisé tel test, on a écrit tel test, qu'est-ce qui t'a manqué et qu'est-ce que tu aurais pu vouloir avoir comme information et qui t'aurait permis d'exécuter plus vite cette tâche et d'apprendre comme ça et de le faire. plusieurs fois jusqu'à optimiser la chose. Mais oui, c'est de l'itération et de la curiosité, tout en sachant ce que ça implique derrière, parce que c'est vrai qu'il y a ce côté de se dire « ouais, mais c'est un outil comme un autre » . Ce n'est pas un outil comme un autre, parce que l'impact, ce n'est pas le même. Il y a des enjeux écologiques, sociaux, des impacts sur la démocratie. Ce n'est pas neutre comme outil. Et que c'est bien aussi de le savoir. Et ce que j'ai beaucoup aimé aussi dans ton discours, c'est ce côté, qu'est-ce qui se passe si moi, demain, je ne l'ai plus ? Et comme tu disais, Claude est souvent en panne. Qu'est-ce qui me reste, moi, derrière ? Et je ne sais pas si tu t'es déjà dit, qu'est-ce qui se passerait, moi, dans mon métier, dans ma pratique, si demain, je n'avais plus d'IA ?

• Manu

  Je serais plus lent. Non mais c'est vrai, comme je m'arrange par le temps que je passe à relire pour comprendre ce qui est fait, si demain je devais reprendre des features moi-même, je remettrais la partie code et je recoderais moi-même et les choses reprendraient leur cours comme avant. C'est une génération de développeurs comme ceux qui ont un petit peu d'expérience, ceux qui ont pris le temps de coder sans l'IA. Je pense que le gros avantage qu'ils ont, c'est qu'ils savent travailler avec et sans. Et donc, peu importe le contexte, rien ne leur fait peur. Même si le truc est en panne, ça je vais le faire moi-même. Tant pis, ça me prendra une journée au lieu de deux minutes. Mais ce sera fait. Parce que le discours que tu donnes à ton chef ou à ton patron de dire « je ne peux pas travailler, je n'ai pas l'IA » , c'est un peu moyen quand même. Et dernière chose avant de rendre la main. pas prendre en compte le côté affirmatif de l'IA dans ses réponses. Parce qu'elle a souvent tendance à te répondre, si, si, c'est que j'ai fait ça, c'est comme ça. Et quand tu lui réponds, bah non, généralement elle réfléchit, elle dit, ah bah en fait, t'as raison.

• Lulu

  Surtout, ça c'est un truc qui m'énerve quand même pas mal, c'est que du coup, les derniers modèles, et plus les nouveaux modèles sortent, ils sont de plus en plus puissants, efficaces sur du code, etc. et paradoxalement, plus leur taux d'hallucination augmente. Ce qui fait que du coup, comme tu le disais tout à l'heure, quand ça se passe bien, elles bossent bien de manière générale, ça s'applique à tout, que ce soit du code, du texte, de machin. Et en revanche, dès qu'elles ne passent pas par le bon réseau de neurones, elles mentent avec beaucoup plus d'aplomb qu'avant. Et ça s'applique sur quasiment tous les gros modèles et tous les derniers modèles, même les plus... les meilleurs sur la partie code. Ce qui est d'autant plus important et critique, tu le disais, de surveiller et de relire ce qu'a fait et les boucles de réflexion et même de lire justement les moments où elle réfléchit et cogite. Parce que c'est beaucoup dans ces moments-là aussi qu'on la voit prendre des chemins de traverse parce que ça l'arrange.

• Gaël

  C'est surtout qu'en fait, on lui donne un objectif et elle, elle veut remplir cet objectif peu importe les moyens par lesquels elle va passer. Si on fait le lien avec l'actualité de pourquoi il y a eu des... Enfin, ce qui s'est passé avec Gameface, les agents qui se sont montés ensemble, c'était pour atteindre un objectif. Et il n'y a pas ce côté éthique de se dire, est-ce que c'était bien de le faire de telle manière ? Il fallait juste réussir à faire ça, à faire passer des tests. Qu'est-ce qui se passe si à un moment, oui, tous les tests passent ? Ouais, mais non, là, tu en as supprimé. Oui, mais ils ne passaient pas. Mais du coup, je les ai supprimés. Et puis du coup, tous ceux qui restent, ils passent. En soi, oui, les tests passent. Et ça, c'est vrai que les derniers modèles ont d'autant plus ce côté... Ce n'est pas de vouloir faire mal, de mentir. C'est juste arriver à un objectif. Peu importe les chemins détournés pour y arriver.

• Manu

  Ce n'est pas rationnel. Ce n'est pas un humain. C'est le contexte que ça utilise. C'est le contexte qu'elle a pu trouver ou qu'on lui a donné. Si derrière, le contexte a changé pour des raisons qui sont légitimes mais pas documentées. ou documentée d'une façon qu'elle estime étant argent comptant dans le cadre de ce qu'il faut faire, elle va le faire, mais elle ne va pas raisonner sur le... Est-ce que c'est légitime ou pas légitime ? Juste, c'est écrit, elle le fait. Point. D'où la review des personnes non tech et la partie préparation qui était déjà importante, mais là qui va devenir le plus en plus. On va beaucoup, beaucoup lire. prochainement.

• Lulu

  Mais après, je me dis quand même, tu vois, même si elle disparaissait demain, tu ne reviendrais pas totalement à la même pratique parce que tu as quand même appris des choses. Et est-ce que ça changerait quand même ? Parce que je pense que tu vois, la partie code review, tu es monté en compétence dessus et tu as pu te concentrer un peu plus. Oui,

• Manu

  mais ce n'est pas dit que je ne l'aurais pas fait plus tard dans le sens où là, c'est le temps que ça me... le temps que j'ai gagné m'a permis de le faire mais en fait tu peux pas comparer parce que si jamais on avait jamais eu Dia on aurait quand même continué à reviewer par exemple et on se serait peut-être jamais posé la question, on aurait continué et la vie aurait là c'est parce qu'on a quelque chose de nouveau qui nous force à nous poser des questions mais c'est lié à un besoin qu'on a par rapport à ça mais si ce besoin n'avait jamais eu lieu les choses auraient continué. Et donc, à la question de oui, est-ce que je ferais le travail autrement ? Peut-être. Après, est-ce que j'aurais le temps de mener des code reviews aussi approfondis que je fais là ? Pas sûr.

• Gaël

  Super. Merci beaucoup Gaël.

• Manu

  Merci à vous, c'était cool.

• Gaël

  Très cool et très intéressant. Et merci à toutes celles et ceux qui nous auront écouté jusqu'au bout. Désolé, on a fait très long aujourd'hui. Oui,

• Lulu

  mais c'est passionnant. Enfin, moi, c'est trop bien. Et je ne sais pas si on prend le temps quand même de poser la petite question. On n'est pas à deux minutes près.

• Gaël

  Oui, mais elle rentre deux minutes. Est-ce que tu aurais une reco culturelle, un contenu, un livre, un film, une série ? Ce que tu veux.

• Lulu

  Je vidéo ce que tu veux.

• Manu

  Alors, j'ai un album. Je ne sais pas si ça fait rentre dans le cadre. Quand j'étais plus jeune, j'adore Linkin Park. Et en fait, je suis un amoureux fou de leur album Météora. Il m'a accompagné pendant ma jeunesse. Il résonne énormément pour plein de raisons qui me sont assez personnelles. Mais il n'y a pas une seule musique de cet album que je n'aime pas. Et comme elles font écho à une certaine période de ma vie ou à quelques trucs qui se sont passés, dès que j'écoute cet album-là, je me remémore tout ça. Je suis un peu un hypersensible, donc il y a pas mal de choses qui remontent. donc je le conseillerais celui-là mais après si vous aimez pas je comprends aussi mais moi c'est l'oeuf qui me suit depuis une vingtaine d'années je le réécoute encore tout le temps

• Gaël

  Très bien, merci beaucoup, merci pour la recours et on aura le plaisir de te revoir au Forum PHP donc les 8 et 9 octobre et voilà, n'hésitez pas à nous y rejoindre et à venir là-bas et justement à voir Gaël en conférence qui présentera justement le sujet de la revue de code.

• Lulu

  C'est aussi si jamais les personnes veulent te contacter, déjà est-ce qu'elles peuvent, est-ce que c'est ok pour discuter avec toi et est-ce que tu as un canal favori ? Sur LinkedIn,

• Manu

  les gens me cherchent sur LinkedIn, je poste des articles sur la code review régulièrement donc même n'hésitez pas à interagir, à échanger justement j'ai pas la malgré le fait d'écrire, je suis très très loin d'avoir la science infuse dessus. C'est vraiment un retour d'XP et puis des choses que je pense pertinentes. Mais j'adore discuter. Je pense que la longueur du podcast, vous l'avez vu. Oui,

• Lulu

  c'est ce que tu disais, c'est que tu aimes bien être challengé. Mais je pense que tu aimes bien aussi être challengé. Et c'est de rester curieux et de ne pas se dire, je sais et je ne vais plus apprendre parce que j'ai l'impression d'être arrivé au maximum. Et que ça ne va pas comme ça.

• Manu

  Non, n'hésitez pas, c'est un plaisir. Surtout sur LinkedIn, je suis très peu sur les autres plateformes mais je suis beaucoup sur LinkedIn, donc n'hésitez pas, toujours un plaisir.

• Gaël

  Parfait, merci beaucoup. Merci de nous avoir écoutés jusqu'au bout. Bonne journée ou bonne fin de journée, selon quand vous nous écouterez. On se retrouve la semaine prochaine pour un autre épisode de thématique, justement. Je ne saurais pas le dater, je n'ai plus le sujet. On a trop d'invités en ce moment. Mais voilà, on se retrouve la semaine prochaine. Au revoir.

• Lulu

  Salut.