OK, on est enregistré. Alors, pour t'expliquer rapidement le but de notre projet, nous on a été mandaté par Renault dans le cadre du partenariat entre les SEC à Accenture de délivrer une étude sur l'impact de l'IA dans votre process SDLC. Est-ce que tu es je pense que tu es familière avec le concept ou tu veux que je te rappelle rapidement ce que c'est le concept ?
Quel concept du SDLC ? Oui. Oui.
Super. Et bien en fait Renault voulait se demander quels sont les impacts au niveau de vos tâches quotidiennes mais en plus au niveau du process organisationnel contre justement l'implémentation de l'IA dans l'ensemble du process. Et euh nous pour ce faire, on a effectué différentes études, d'abord quantitatives et qualitatives à partir de données publiques et privées.
Donc on s'est penché sur beaucoup de finkt tank de d'articles également publiés par des cabinets de conseil comme Accenture, comme BCG, comme Bin mais on trouvait que ça manquait un peu voilà d'insight pertinent compte aux utilisateurs et bien réel, c'est-à-dire vous. Et c'est pour cette raison qu'on a voulu justement mener ces interviews pour euh identifier notre principal but, c'est vraiment de repérer euh les points de friction chez Renault dans le process SDLC afin de voir en fait comment on pourrait les améliorer pardon grâce à l'IA et gagner du temps. des points de friction typiques.
Si je dois te donner un exemple, c'est euh et bien par exemple l'équipe A attend une réponse de l'équipe B mais sans cette réponse l'équipe A ne peut avancer. Ça c'est un point de friction qui est récurrent dans pas mal d'entreprises. Et justement Renault voudrait se demander comment faire pour euh et bien réduire ce temps de latence.
Et je vais te poser la première question qui est assez banale je trouve mais qui nous apporterait beaucoup. Est-ce que tu peux nous raconter ta journée typique ? Hm.
Réunion. Oui. Oui.
Oh non. Après moi ma journée typiquement euh c'est euh dans le work du dev, c'est enfin il y a pas mal de revues de code, il y a pas mal de de d'analyses, pas mal de enfin voilà, pas mal de discussions du coup pour challenger telle ou telle solution. Après effectivement pas mal de réunions euh et un petit peu de dev à côté.
D'accord. Et euh est-ce que tu pourrais développer un peu plus dans la partie réunion par exemple ? Quels sont les sujets des réunions la plupart du temps et qu'est-ce que quel principal sujet abordé et même les seconds inéresserait parce que ça répondrait du coup à la problématique que tu as posé tout à l'heure, c'est que la plupart des réunions c'est pour résoudre des dépendances.
Donc c'est pour justement voir avec des euh des euh des enfin les dépendances externes pour aller récupérer telle ou telle information, pour aller résoudre tel ou tel euh enfin par exemple faire des demandes pour avoir accès à des choses sur le projet par exemple ou faire voilà des réunions aussi pour discuter tel ou tel choix à mettre en place. Sinon, en 2è lieu et des réunions euh pour spécifier euh techniquement certains besoins, par exemple pour les tests de charge, pour les tests de PA, les pain test, test de penetration test. Euh grosso modo, c'est autour de ça en fait, les réunions.
D'accord. H donc principalement des réunions pour des choix d'architecture, on va dire un peu concernant le software. Euh architecture, non, c'est en second lieu, je dirais plus pour euh résoudre certains problèmes euh techniques, par exemple ou pour faire pour demander certains euh enfin pour résoudre certaines dépendances avec les DevOps, avec la CQ, avec euh avec les les QA euh c'est voilà, c'est principalement ça.
OK, d'accord. Et euh est-ce que tu pourrais euh me parler un peu plus justement de ton allocation de temps au quotidien ? Donc par exemple, d'après toi, si tu peux me donner une une estimation du nombre d'heures que tu passes justement à communiquer avec ces équipes et du nombre d'heures que tu passes à réellement produire du code.
Alors à produire du code euh enfin à communiquer ben en moyenne en moyenne ça serait euh 50 % du temps. Si ce n'est pas plus parce que là j'ai 50 50. Ouais.
50 % de ma semaine en réunion. D'accord. Voir des semaines où c'est c'est plus après enfin il y a des interview que je fais aussi enfin des pour des recrutements.
Il y a il y a pas mal de réunions qui rentrent en plus et il y a les cérémonies les cérémonies scrum donc qui rentrent aussi dans dans cette cat enfin dans dans mes réunions. Après pour produire du code, je dirais 20 %. OK.
Production du code. Ouais, d'accord. Bah, ça m'étonne un peu.
Je j'y pensais pas. C'est étonnant. Oui.
Et et pour le reste après, il y a des reviews, il y a des explications, il y a des directives à faire, enfin des à donner, des c'est des des euh des recommandations. Euh donc enfin voilà, c'est c'est des réunions aussi, mais pour moi c'est pas forcément des réunions, ça fait partie aussi du cycle de développement. c'est euh pour que les euh les les développeurs puissent euh enfin pour qu'on puisse avoir pratiquement tout le monde les mêmes pratiques de dev ou pour expliquer certaines choses euh notamment sur les surtout la sur la sur la partie GitLab ou sur la partie cubernetes.
Donc voilà. OK. D'accord.
Donc si je résume, ça fait 50 % du temps passer dans des réunions pour communiquer et se synchroniser, 20 % à produire du code et 30 % pour des autres tâches comme euh la transfert de connaissance et cetera, on va dire. Voilà. Revue code, transfert de connaissance.
Ouais. D'accord. OK, super.
Et euh deuxème question, est-ce que tu pourrais me parler des principaux skins que tu as besoin d'utiliser dans ton métier au quotidien ? beaucoup de logique. Euh beaucoup de logique.
Faut avoir surtout euh déjà une bonne connaissance des bonnes pratiques de dev parce que c'est très c'est primordial pour pouvoir justement avancer très rapidement dans les revues de code par exemple et du coup de pas trop traîner, de faire des recherches pour savoir si ça si tel ou tel code est bon ou non. Donc il faut les skill enfin ça fait pour moi c'est primordial comme skill. faudrait aussi être assez pragmatique euh et surtout surtout euh quand quand on est dans une réunion cibler vraiment euh le sujet de de la réunion ne de pas trop sortir de de du contexte pour ne pas trop du coup perdre le fil et finalement sortir avec rien du tout de la réunion.
Donc savoir du coup euh comment on pourrait comment on pourrait appeler ça ? lit d'une réunion avec efficacité. Voilà.
Exactement. Exactement. Je dirais ça exactement.
Euh donc il y a aussi euh h alors la un des styles que je qui est essentiel qui est essentiel de d'avoir qu'on doit avoir, c'est de savoir accepter euh d'autres points de vue, d'autres solutions, de savoir aussi argumenter pour tel ou tel choix technique ou tel ou tel choix architectural. donc de d'apporter les arguments nécessaires et surtout de de pouvoir accepter les autres solutions aussi. OK, super intéressant.
Donc si je résume un peu ce que tu viens de dire, on a besoin beaucoup de quelqu'un de pragmatique, quelqu'un qui a de l'efficacité mais aussi de l'efficience si je résume. Oui, c'est ça. OK, super.
Maintenant, c'est la prochaine question, elle va être assez longue, je pense parce que je voudrais vraiment qu'on fasse un petit deep dive sur celle-ci. Est-ce que tu pourrais me dire tes principales difficultés que tu rencontres chaque jour dans la réalisation de tes tâches justement dans d'abord ta communication, vu que c'est euh euh le domaine où tu accordes le plus de temps et ensuite euh dans les les autres domaines dont on a euh abordé tout à l'heure. Oui.
Euh je pourrais effectivement alors euh le fait que je sois assez souvent dans des réunions mais qui soient pas forcément lié donc pas le même contexte, pas forcément le même sujet ou autre, je suis tout le temps obligée de enfin j'ai mon blocnne devant moi. Je saisis tout le temps les informations à la main. Tout le temps à écrire, tout le temps à écrire.
ensuite à organiser tout ce que j'ai écrit par thème, par sujet, par euh par tout dou, enfin voilà, par euh donc voilà d'étiqueter mes notes. Donc ça c'est une des choses que je trouve qui me ralentit un petit peu et du coup de suivre ce que j'ai écrit parce qu'il faut que je revienne à chaque fois sur ce que j'ai écrit pour du coup ne pas louper les choses des choses et pour pouvoir du coup les mettre en place ou les voilà les intégrer dans mes dans mon dans ma journée, dans mes tâches de la journée. Euh qu'est-ce qui est enfin rappelle-moi la question j'ai peut-être et tes principales difficultés au quotidien ?
Voilà, c'est ça. Donc une deuxième difficulté, je dirais euh je dirais je dirait euh la gestion des dépendances parce que c'est vrai que aller solliciter quelqu'un pour avoir tel ou tel pour générer tel ou tel token, pour avoir tel accès à tel ou tel outil ou autre. Donc tout ça, ça passe par moi.
Euh et pour le faire, il faut que effectivement il faut demander, relancer, redemander, relancer et ne pas oublier de relancer. Du coup, tout ça aussi, je dois prendre note pour et euh et on n'est pas en tout cas c'est pas forcément euh on n'est pas sûr d'avoir la réponse rapidement et tout de suite alors qu'on est par on est un petit peu par exemple bah on est tenu par des délais. Donc il faudrait que ces dépendances soient euh gérées et soient résolues.
Et donc euh parfois le fait de relancer les personnes concernées pour résoudre ces dépendances ces dépendances là, ça peut parfois être un petit peu un petit handicap du coup. Mais ça se comprend parce qu'effectivement eux-mêmes ils sont un petit peu sous l'eau donc ils peuvent pas répondre à tous les toutes les demandes très rapidement. Oui, mais c'est Ouais.
D'accord. Donc là, tu as tu as principalement abordé tes tes difficultés, on va dire interéquipe. Mais est-ce que tu as des difficultés intraéquipes ?
Intraéquipe, il y a Oui. Oui. Une grosse euh un gros problème serait la communication.
Euh pour t'expliquer plus, on a pas mal de canaux mais on n pas forcément l'information sur ces canaux là. D'accord. Donc il peut y avoir des des changements ou des modifications justement par exemple récemment sur les sur les méthodes de déploiement ou ça pourrait être une communic enfin voilà une montée de version ou quoi que ce soit.
Euh et on n'est pas forcément à jour avec ces informations là. Donc la interéquipe, je le dirais, c'est vraiment les ça pourrait être ça en fait, c'est le manque de communication et je dirais que c'est pas un problème voulu, c'est pas intentionnel, c'est peut-être aussi le l'effet surprise ou l'effet un manque de temps ou oubli de communication. Donc il y a ça et soit euh il y a un autre sujet que je dirais quand il y a des réunions où on est plusieurs équipes à partager des choses euh parce qu'on a besoin bien sûr de les avoir euh bah il y a des réunions qui sont un petit peu longues et ça peut dépasser les 1h.
Il y a des réunions de 2h ou même pendant 1h du coup on perd l'information on peut pas se concentrer forcément on peut pas tout suivre. Et euh et ça ça pourrait euh en tout cas euh enfin moi personnellement je vois que ça peut avoir un impact et sur la concentration parce qu'on peut pas se concentrer pendant toute une heure sur plusieurs sujets. Si c'est un seul sujet, c'est pas grave.
Mais si c'est plusieurs équipes qui vont communiquer communiquer sur ce qu'ils ont fait, ce qui sur le blocage, sur ce qu'ils ont sur le quoi ils ont avancé et cetera, euh bah on perd très facilement le fil et on n'est pas forcément on n'est pas forcément capable de de réagir très rapidement si on nous pose des questions parce qu'on a pas forcément tout entendu et c'est pas euh et c'est normal. C'est l'être humain, on perd facilement la concentration. Tout à fait.
OK, c'est c'est super intéressant parce que je pensais notamment, tu sais, que dans des métiers techniques, on va dire comme celui de Dev, la perte de temps principal venait de vos activités comme bah le le code à écrire ou un problème que vous n'arriviez pas à gérer. Donc là, tu me dis plutôt que c'est plutôt la perte de productivité vient plutôt d'une insuffisance au niveau de la communication et surtout la synchronisation entre tes équipes et des dépendances que tu as besoin, mais aussi au niveau de ton équipe elle-même euh avec les montées de version et cetera dont tu me parlais. Oui, c'est bien ça.
Ouais, c'est ça. OK. parce qu'aujourd'hui si tu veux euh même enfin en terme de dev d'écriture de code enfin je dirais même parce que ce que je disais l'autre tout à l'heure au tout début j'ai dit la logique parce qu'effectivement si on n pas la logique derrière et qu'on a pas forcément en tête qu'il faut tenir tenir compte des performances des des de pas mal de choses euh là c'est sûr qu'on va écrire du n'importe quoi.
Si dès dès dès le départ, on est on est conscient de ce qu'on veut faire et de d'où est-ce que où est-ce qu'on veut atterrir, euh le code en lui-même, c'est pas forcément ça qui va faire perdre du temps au développeur. C'est vraiment un développeur, il a besoin d'avoir un il ne doit pas être coupé dans sa réflexion et surtout dans l'implémentation de son code. Dès lors qu'on est coupé, surtout pour les juniors, je trouve les confirmés, dès lors qu'ils sont coupés dans leur réflexion, c'est pas facile pour eux de reprendre.
Alors du coup, pour moi, je suis pas très partisante du fait que on inclut tout le temps les dev dans toutes les réunions. Euh c'est c'est perturbateur du coup et ça ralentit la productivité du coup des des développeurs. Ouais.
OK. Extrêmement intéressant. Donc tu fais une réelle, on va dire séparation euh des tâches entre un dev senior et un dev junior.
Vous vous occupez pas du tout le même poste. Bah oui, enfin un dev junior, il a besoin de comprendre. Par exemple, si je peux faire la la la comparaison, un dev junior, il a besoin de comprendre ce qu'il est en train d'écrire.
Un dev confirmé et surtout un dev senior ou expert, il sait ce qu'il est en train d'écrire mais il a besoin de tester et de valider ce qu'il est en train de faire. Donc effectivement euh le temps il est nécessaire pour les deux mais pas forcément pour faire la même chose. Euh après euh moi c'est je le dis tout le temps les réunions, ça fait perdre beaucoup de temps et ça va couper et le dev junior et le dev senior dans leur réflexion pour terminer leur tâche.
Et je préfère du coup que ça soit écrit quand c'est une information à partager qu'elle soit écrite. quand c'est un besoin de clarifier que la question soit écrite plutôt que d'aller appeler la personne ou appeler l'équipe ou appeler les autres équipes pour faire les pour faire le enfin pour avoir l'information pour faire le nécessaire quoi. OK.
Donc est-ce que tu c'est ça c'est c'est intéressant aussi. Est-ce que tu pourrais un peu plus développer justement sur ce que tu voudrais dans un univers parfait on va dire en terme d'organisation ? H en terme d'organisation.
Moi, je vous ce que je vois aujourd'hui, c'est que euh tout le monde porte le chapeau de tout le monde, d'accord ? Et du coup euh ce qui devrait être gestion de dépendance avec ou gestion communication avec les architectes par exemple ou autres, là aujourd'hui tout le monde le fait. H et on passe plus forcément par le Techlead ou par le ladde dev ou par le PO ou par je ne sais pas qui pour demander telle ou telle information.
C'est bien en soi, ça peut permettre de monter en compétence mais ça ralentit un petit peu la la productivité et on fait pratiquement on se retrouve à faire la même chose tout le monde à faire la même chose chacun pour soi. OK. Pour soi-même.
Euh il y a donc en fait ce que je dis enfin ça c'est Ouais, ça peut être un pour comme ça peut être un un contre. Il faut vraiment qu'on sache qu'est-ce qu'on veut et comment le comment on le fait. Et s'il y a une personne qui peut le faire à notre place, tout simplement demander à cette personne de le faire et comme ça on continue sur la tâche sur laquelle on est en train de bosser.
Donc il y a ça. Et autre chose euh dans les réunions, personnellement, je te dis, je te cache pas, quand je préfère quand parce que nous on est sur Teams et sur Teams, on a le facilitateur. Franchement, je me base sur ce que le facilitateur remonte de de de la de la réunion plutôt que de ce qui est en train de se dire pendant la réunion.
Et ça ça me simplifie énormément euh la compréhension du sujet de la réunion et surtout euh de d'avoir le résumé et les points importants euh de la réunion. Donc ça pour moi par cont par contre je vois que c'est une grande avancée euh et ça permet de d'alléger énormément euh certaines tâches euh et certaines réunions OK qui sont trop chronophages pour euh ce qu'elles sont et surtout euh le but servie ex d'accord et si tu pouvais on va dire mettre un processus en place pour justement corriger tous ces problèmes, ce serait quoi vraiment axer sur le facilitateur ou euh autre chose pas que axer sur le facilitateur parce que le facilitateur il ne va pas forcément c'est de l'a lia elle est elle se trompe elle elle écrit des choses qui sont pas qui sont pas celles qui ont été dites donc il faut prendre ça avec avec précaution il faut savoir pour pour lire le compteu du de de du du facilitateur il faut déjà savoir ce qui est en train de dire de se dire connaître le sujet et surtout avoir quand même participer un petit peu est parti enfin on est toujours obligé quand même de participer à la réunion et de comprendre ce qui est en train de se dire euh pas enfin on va pas juste allumer la réunion et ensuite ne rien écouter et ensuite aller lire ce qui a été généré par Guia. C'est pas c'est pas ça c'est pas possible.
C'est pas possible. Pas du tout. Aujourd'hui en tout cas c'est pas du tout possible.
Il y a des noms de projets qui sont modifiés par LIA. Il y a des prénoms qui sont pas forcément euh euh bien retranscrit, voilà, exactement bien retranscrit ou quoi que ce bref, il y a pas mal de choses quand même. Il faut faut prendre avec euh Ouais.
des pincettes. Exactement. OK.
Euh donc moi, je mettrai pas ça en tant que dans dans l'axe de mes de mes de mes objectifs. Pour moi, c'est vraiment euh la communiserai la communication. Qu'est-ce qui pourrait être dit et pourquoi et et quand et à quel moment diminuer le nombre de réunions euh pour faire les synchronis les réunions de synchronisation par exemple ?
Pour moi, ça a pas lieu d'être enfin on a des des des ch enfin des canaux, des channels où on pourrait écrire ou poser des questions. Euh je mettrai aussi euh il faudrait du coup laisser la place et convenir avec l'équipe sur les moments calmes où on voudrait vraiment ne pas être interrompu et ne pas venir tout simplement aller poser une une réunion au beau milieu de la journée alors qu'on a besoin enfin telle ou telle personne a besoin d'avoir d'être pleinement concentré. Euh moi c'est tu vois mon problème c'est euh ce serait plutôt de l'organisation et pas forcément de la de comment faire les euh de l'optimisation.
De l'optimis. Ouais, c'est ça. Euh ce que je dirais de plus.
Oui. Enin. Euh OK.
Je Oui. Bah je je cerne totalement ce que tu dis. C'est c'est vrai que avoir des réunions toute la journée à bout de champ pour des choses aussi inutiles, parfois ça perd beaucoup de temps et ce temps-là, on est obligé de le rattraper soit le soir, soit sur le lendemain et c'est pénible.
Et c'est surtout c'est surtout euh fatiguant parce qu'elle à la fin de la journée euh à la fin de la journée, on est fatigué de parler et parce que c'est un grand effort. C'est vraiment un très grand effort. C'est vrai.
Bon, ça c'est vraiment vrai. Euh, j'aurais une autre question moi ou c'est ça concerne un peu plus le cœur du du sujet. Lia, comment tu l'utilises dans tes activités quotidiennes ?
Alors, Lia, LIA, moi j'utilise beaucoup LIA, surtout pour les sujets techniques. Euh, je sais, enfin quand c'est des choses qui sont assez simples, assez faciles à trouver sur internet, j'irai j'irai chercher sur internet. Je voudrais pas verser une bouteille d'eau dans la nature comme ça parce que j'ai pas envie de d'aller écrire et faire de la recherche moi-même euh parce qu'après tout euh une question à chat GP, c'est une bouteille d'eau gasée.
Oui. Oui. Euh donc il faut vraiment il faut vraiment euh savoir quand est-ce qu'on doit l'utiliser Lia.
Euh c'est quelque chose qui est très euh enfin c'est un sujet qui me qui est très important pour moi. Donc du coup euh par contre pour tout ce qui est génération de code, j'irais pas euh notamment les tests d'intégration enfin les tests unitaires. Oui.
Notamment pour les tests unitaires, les tests d'intégration, les tests n to enfin les tests quoi. Aujourd'hui, c'est très pratique d'aller demander à Lia de le faire à notre place et c'est très bien. C'est très bien mais il faut aller regarder derrière qu'est-ce qu'elle a généré.
Du coup, elle va générer pas mal de choses qu'on va virer et c'est du coup de la génération pas 100 % utile. Donc il faut bien cadrer euh nos promptes, il faut bien cadrer nos instructions. Euh donc pour moi, c'est très important et c'est qu'une enfin c'est euh c'est une pratique qui devrait être connue de tout le monde.
On va pas juste utiliser l'IA parce qu'elle est utilisable. Il faudrait savoir comment l'utiliser pour justement qu'elle te génère quel ce que tu voudrais être généré et qu'après ta relecture, ta revue de code derrière Lia, elle ne soit pas fatigante ni pour ni pour la personne du coup qui l'a utilisé, ni pour les les dev qui vont faire la revue de code derrière. Euh je l'utilise du coup dans ce contexte-là, mais en l'encadrant.
Euh je l'utilise pas mal aussi pour euh la partie pour comprendre certains certains bouts de code euh que je peux ne pas comprendre, que je peux ne pas connaître. Justement, par exemple, là je suis euh je suis sur Python. Avant j'étais sur euh sur Java.
Python, je connais un petit peu mais il y a des choses qui il y a des fichiers de conf que je connais pas forcément ou je connais pas leur utilité. Donc il y a m'aide beaucoup à le à comprendre ce que ce que ça peut faire et euh me dire aussi s'il y a des choses qui vont pas et ça c'est trop bien. Ça peut ça m'aide énormément aussi ça.
Je te parle du quotidien de mon utilisation de mon IA. Si c'est pas si je dévie, tu me dis tu m'arrêtes non du tout, t'inquiète pas. OK.
Et euh chose autre chose que je pour laquelle je l'utilise, c'est vraiment quand j'atterris sur enfin quand j'ai un projet euh GitLA par exemple que je viens de récupérer ou que je voudrais comprendre facilement, très rapidement, que j'ai pas le temps d'aller regarder dans tout le code et de d'avoir toutes les fonctionnalités dedans et dont le Rytmi n'est pas forcément à jour, Lia, elle a elle aide énormément là-dedans pour avoir et les technos, l'architecture, les fonctions et les fonctionnalités. qui sont développées, ce que ça permet de faire. Donc ça c'est c'est extraordinaire.
Ça c'est vraiment quelque chose que j'utilise assez souvent quand j'ai besoin d'utiliser un projet que je connais pas forcément ce qu'il fait ou ce que comment c'est fait et et surtout pour avoir le chemin architectural de la de la solution si je veux voilà du coup savoir comment ça a été fait. OK. Donc un mix di pédagogique et euh produit de productivité de code.
Exactement. Ouais. J'ai j'aimerait revenir sur ce que tu as dit tout à l'heure sur euh justement comment encadrer Lia.
Est-ce qu'à Renault on vous a euh on va dire donné quelques cours de prompt ou pas ? Oui, on a eu des cours de prtes. Alors, je ne sais pas si ça a été généralisé à tout le monde ou non parce que là aujourd'hui, c'est utilisé pratiquement par tout le monde.
Euh mais oui oui oui, on a on a reçu une formation. Euh après, elle n'est pas vraiment très très très technique dans le sens où euh peut-être que pour les dev, il faudrait une formation pour leur montrer comment écrire des fichiers de trompe, des fichiers d'instruction, euh des développeurs qui sont pas forcément liés au développement de d'agents ou de enfin voilà euh des euh qui ne sont pas en lien direct avec les euh avec l'IA, mais qui l'utilise de savoir du coup euh parce que nous on utilise dans notre écosystème euh on utilise Gitup Copilote. Donc ça serait intéressant par enfin on fait hein on fait euh on a pas mal de euh on a une session guitup copilote tous les mercredis pour expliquer comment on peut utiliser LIA, comment on peut on peut écrire un promte, quel est comment c'est ça pourrait être efficace, comment configurer, comment comment ça c'est très bien mais j'ai l'impression qu'il y a pas beaucoup de monde qui participe.
Donc est-ce que ça serait pas un problème de communication ? Euh pareil euh parce que moi-même je l'ai pas vu. Enfin c'est vraiment un collègue à moi qui me l'a qui me l'a qui m'en a parlé pour pour euh à vrai dire.
Donc voilà. H D'accord. Mais oui oui, il y a des il y a des choses qui se font.
Il y a des formations qui sont aussi available. Comment on dit ça en français ? Qui sont disponibles.
Merci. Ouais. Euh dans notre dans notre comment dire euh Ripo euh formation, enfin je je sais plus trop, je trouve pas le mot, on a euh on a des euh pas mal de supports de de learning euh et qu'on peut aller chercher dedans.
Donc est-ce qu'on le fait tous ? Je ne sais pas. Mais oui, Renault nous fournit pas mal de choses pour le pour structurer nos enfin pour connaître le maximum d'information sur l'I.
Oui. OK. Et autre question, tout à l'heure, tu m'avais aussi parlé du tu sais du fait que vous consacrez du temps justement à la review du code généré par Lia.
Oui, il y a une sorte d'évolution parce qu'avant voilà les deveniors, review les codes des juniors, ça prenait du temps. Mais maintenant, de plus en plus ce qui se passe, c'est qu'on consacre du temps à review même les juniors, le code généré par Lia. Est-ce que tu pourrais euh m'estimer justement cette euh c'est ce temps utilisé ?
Euh je pour être honnête, quand je vois que c'est du code qui est généré par l'IA, je regarde même pas. Dès que je vois qu'il y a des choses qui sont pas compatibles avec notre avec la la les euh comment dire les euh Oh là là, je trouve plus le mot, les euh les voilà, non, les Clean Code Conventions et tout ça de l'équipe. OK.
Je vois qu'il y a quelque chose qui qui est généré par LIA dans ce contexte là. Par exemple, par exemple, pour te donner un exemple, dans un dans un projet sur lequel j'ai bossé, euh on mettait pas de commentaire dans le code. Normalement, c'est les noms de méthodes et les noms des variables qui devraient exprimer ce que ça fait.
Donc on permet pas d'avoir du code explicatif en commentaire euh pardon du des commentaires pardon des commentaires explicatifs du code. Et donc dès que je voyais dans une MR du code explicatif euh enfin du des commentaires explicatifs euh c'est bon pour moi c'est de l'IA. Ça a pas été revu par le développeur, je regarde même pas et euh je condamne pas du tout.
Pourquoi pas ? Mais pour moi déjà enfin il y a des qu'on puisse utiliser l'IA mais qu'on regarde pas ce qu'elle a généré derrière. C'est c'est même pour moi c'est c'est dangereux.
Acceptable. Ouais. C'est pas acceptable.
Non, c'est pas acceptable. Il faut que ça soit déjà comme je l'ai dit tout à l'heure, il faut que ça soit bien encadré les bien instrumenté euh les le le promte bien expliqué le rôle et cetera. Mais dès lors que euh je vois que c'est pas ça a pas été bien euh fait, je regarde même pas et je dis voilà, il faut refaire la MR euh voilà sans rien enfin ou bien nettoyer ou bien revoir ce qui a été écrit.
OK. Euh je suis intransigente sur cette partie-là. Après euh après rien n'empêche, comme je l'ai dit hein d'utiliser Lia.
Moi-même, je l'utilise je l'utilise pour faire euh pour faire certaines certaines tâches euh notamment par exemple dernièrement, il y avait des variables endures qui étaient écrites dans le dans le fichier de déploiement Cubernetes alors qu'on pouvait les mettre dans le customiz dans le customization enfin le fichier de customization. Donc voilà, Lia le fait très bien et le fait très très rapidement en plus. Donc ça c'est ça facilite énormément les choses mais il faudrait du coup pour les codes review que ça soit euh que la la code review ne soit demandée que lorsque l'IA elle a bien fait les choses.
Après, je sais qu'aujourd'hui il y a pas mal de personnes qui utilisent la review par Lia. Oui. Ouais.
Oui. Il y a des agents, il y a des il y a des promptes qui permettent de faire la revue par par LIA. Euh personnellement euh je suis d'accord, j'aime bien parce que ça ça va ça va aller voir des choses qui ne sont pas forcément vu par le l'œil humain, mais pour moi, il faut quand même que le l'être humain euh puisse revu derrière ce qui a été revu par Li bien sûr.
Voilà. OK, super. Donc tu es plutôt favorable, on va dire, à l'utilisation de l'IA explicative qui nous montre comment faire les choses plutôt qu'une a proactive et dont on devient trop dépendant et qu'on laisse tout faire quoi.
Alors non non non proactif si qu'elle puisse faire les choses oui mais qu'elle soit contrôlée et qu'elle soit revue. Donc c'est pas normal que quelqu'un écrive un promte voilà génère-moi telle ou telle chose. Ensuite, hop, en guit là BMR et là voilà, j'ai fini ma tâche, reliser mon code.
Non, ça c'est pas possible. Ou bien on on donne à la à Lia de faire la revue du code et on corrige qu' a corrigé. Hop, on enfin et on met les commentaires et c'est tout sur la revue.
Non non non, il faut que vraiment que l'être humain soit au-dessus de tout ça et que ça ça soit l'être humain qui lui prend la décision de qu'est-ce qui est pris, qu'est-ce qui est fait, qu'est-ce qui est pas fait. D'accord. Mais la Lia, elle aide énormément à générer pas mal de choses.
C'est c'est impressionnant mais n'empêche, il faut que l'être humain, c'est lui qui c'est c'est l'être humain qui donne son accord et qui rev qui revoit derrière. Ouais. OK.
Euh on va rentrer dans la dernière question. Est-ce que tu pourrais me décrire tes tâches les plus répétitives sur Li surt au quotidien ? Ah, au quotidien.
réunion qui sont qui sont euh bah qui sont pas forcément tu sais automatisés par l'IA ou pas genre vraiment une description globale de tes tâches les plus chronophages et répétitives que tu as qui sont pas faisables par Lia euh faisable ou non. Ouais. Euh alors mes tâches répétitives hein, comme je viens de le dire, c'est surtout euh c'est soit euh de bah de mettre en place la fonctionnalité, enfin le de créer euh et de générer le code qui est demandé dans le dans le ticket, soit bah c'est des tâches de dev ou de le dev en fait, soit de d'aller demander en résoudre des dépendances avec les DevOps, avec les architectes, avec enfin Voilà.
Euh soit j'aurai une question après justement sur cette dépendance. OK. Et ouais, vas-y.
Non non, vas-y, pardon, je t'en prie, termine. Ouais. Et surtout enfin surtout non, qu'est-ce que je fais euh de très répétitif ?
Bah les codes review et c'est normal. euh les discussions sur les choix arches, sur les stratégies, sur euh voilà et bien sûr le transfert de le transfert de connaissances. OK.
H OK, super. Alors euh ma question justement pour cette gestion des dépendances, tu pourrais me décrire comment ça se passe justement quand tu vas poser, on va dire, une question ou demander euh un accès à un fichier de compte à par exemple un architecte ou un DevOps ou un membre d'une autre équipe ? Est-ce queil y a un process défini clair carré ou c'est vraiment j'envoie un message team ?
C'est j'espère qu'il me répond. Il y a plusieurs il y a il y a plusieurs process now. OK.
Euh on va faire la demande par exemple pour accès pour des demandes d'accès d'accès à Volt pour les demandes d'acc donc donc voilà des ticket service now. Exactement mais c'est spécifique à certains services donc c'est pas tous les services qui sont euh enfin pour lesquels on pourrait faire ça. Soit euh si c'est par exemple des problèmes d'VOPS, on pourrait créer des tickets gira mais ça prendrait pas mal de temps.
Et du coup à ce moment-là, ça sera d'aller contacter directement les DevOps de qui sont concernés. OK. Chose que je fais assez souvent.
Et sinon, on a un autre enfin sinon voilà donc ça serait via Teams. Donc voilà, c'est c'est nos trois moyens. C'est soit du prervice now, enfin pour les tickets qui sont sur service now, soit gira en ticket de support.
On appelle du coup faut ça sera en ticket de support s'il y a un problème de déploiement ou quoi que ce soit. Mais généralement euh enfin pas que les DevOps he même pour les pour les détiquer Girac pour d'autres pour d'autres projets. Euh soit sinon voilà directement sur Teams.
Ouais. D'accord. Parce que si on revient dessus rapidement du coup, c'est parce que vous prenez trop de temps à ouvrir des tickets sur Gira, c'est ça ?
Non, mais ça dépend en fait si tu veux pour les DevOps, je parle surtout pour les Devops parce que pour les Devops c'est des tickets gira généralement. OK. Peut prendre du temps pour être lu et résolu.
Et du coup, moi personnellement, je te cache pas que je le fais pas. Je vais directement pinguer la personne. C'est plus rapide.
Ah bah c'est plus rapide effectivement. Oui. OK.
D'accord. Et ben écoute, j'ai je crois que j'ai pas d'autres questions. On a fait un grand tour.
Super. Je voudrais te remercier parce que ça m'a apporté beaucoup d'insight sur tes principales difficultés que je pensais que je m'imaginais pas du tout. C'est très instructif.
Ben c'est super. Je suis je suis contente que tu autant puisses bénéficier. Enfin, j'espère en tout cas.
Oui, bah ça nous sera tellement utile pour pour notre rapport, je pense. Un grand merci Linda pour le temps accordé et je te souhaite un bon courage pour toutes tes réunions. Merci parce que là à 16h j'en ai une là jusqu'à tu vas me rendre compte du coup que je viens de t'en ajouter une malheureusement avec la mienne.
Ah t'inquiète c'était c'est avec un grand plaisir en plus qui est une personne agréable donc t'inquiète ça s'est très très bien passé en tout cas pour moi. Bah c'est réciproque en tout cas. Merci beaucoup pour tout ce que tu m'as appris et pour le temps prix surtout.
Avec grand plaisir. Avec grand plaisir. Merci.
Merci à toi aussi. Bonne semaine. Merci à toi aussi.
Salut. Salut. Alors gérer l'enregistrement.
Arrêter l'enregistrement. M.
