Bruno:
Faire du code qui fonctionne, on sait faire. Faire du code qui fonctionne longtemps, au final, c'est notre expertise. Faire du code fiable, c'est pas tout à fait la même limbonade. Déjà, qu'est-ce qu'on met derrière le mot fiable ? Est-ce que c'est un code qui tient la charge ? Au final, on délègue ça aux ops. Est-ce que c'est du code qui renvoie tout le temps le même résultat ? Notre code est déterministe, on sait faire. Qui est imperméable à toute attaque ? Oui, bien sûr, en tout cas, aux attaques qu'on connaît. Parce que si on demande à tous les devs leur niveau de confiance sur des sujets de cybersécurité, au fond de nous, on sait tous qu'on n'est jamais à ces ceintures bretelles. Mais alors, pourquoi DevSecOps n'est pas la norme par défaut ? Peut-on vraiment laisser à GitHub et à tous nos frameworks le soin de faire la police ? Et surtout, si l'IA produit le code, relit le code et cherche les failles, au final, qui surveille l'IA ? Pour répondre à ces questions patchées, je ne reçois pas Mr Robot, mais il s'y connaît en faille pas si fictive. Thug, bonjour.
Tug:
Bonjour.
Bruno:
Alors Thug, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Tug:
Je suis Thug Dual Graal. Thug Dual c'est un prénom breton. La plupart des gens m'appellent Thug ou Thug aujourd'hui, c'est plus simple. Et je travaille actuellement chez GitHub comme copilot spécialiste sur la partie développement avec l'IA. Mais c'est un rôle que j'ai pris il y a quelques mois. et avant j'étais solution engineer sur GitHub depuis 5 ans où je travaillais justement sur la mise en place, l'adoption avec nos clients, avec nos prospects et le côté meetup autour de l'utilisation d'une plateforme DevSecOps que vous connaissez très bien qui est GitHub.
Bruno:
Ok très bien, du coup pour commencer directement dans le vif du sujet, on entend souvent le terme DevSecOps, toi tu le définirais comment ?
Tug:
En fait, c'est amusant la façon dont je le définirais parce que quand j'ai commencé, moi je viens du développement applicatif. Je ne suis pas un ingénieur Ops ou DevOps, peu importe comment on va l'appeler. Moi, ce que j'ai aimé faire dans le passé, c'est toujours développer des applications, même si mon CV est un peu product management, etc. Mais je me considère toujours comme un développeur d'applications. Et quand je suis rentré chez GitHub, il fallait se former au DevOps. Et pour moi, DevOps, il y avait la sécurité dedans. C'est-à-dire que systématiquement, si on a automatisé des choses, la sécurité fait partie des automatisations. Et c'est là où j'ai découvert que ce n'était pas toujours le cas. Donc le DevSecOps, c'est ce que les développeurs imaginent du DevOps, c'est-à-dire l'automatisation pour la qualité, permettre d'essayer d'automatiser de plus en plus de choses pour potentiellement déployer en continu, mais sans jamais oublier la sécurité. Et la sécurité, ça va être la sécurité, comme tu l'as dit, des failles. Mais qu'est-ce que c'est une faille, la sécurité au niveau de ce qu'on a mis dans notre code en termes de données en termes de token ou de secret d'authentification pour des API et donc le DevSecOps c'est de faciliter cette partie là pour que les développeurs n'aient pas trop à s'en soucier et que ça devienne comme la qualité dans le workflow habituel du développeur ou de la.
Bruno:
Développeuse quand on parle d'automatisation on a cette idée de fiabiliser un peu notre usine logicielle, et on a plus souvent une démarche de se dire comment on fait pour s'assurer que notre code fonctionne en toutes circonstances, plutôt que de vraiment appréhender tous les contextes est-ce que quelqu'un sera capable d'aller extraire de l'information d'une manière qu'on n'avait pas forcément anticipée et ça je sais pas si c'est quand même, tu disais qu'on délègue ça en gros DevOps ou NCICD ou tout ce qu'on veut mais je sais pas si on prend compte vraiment des notions de sécurité quand on délègue.
Tug:
En fait, le problème, c'est que la sécurité, c'est vraiment quelque chose de compliqué. C'est un domaine d'expertise. Et surtout, un vrai, vrai domaine d'expertise. Et un peu comme la performance, c'est un domaine d'expertise. Alors, à la différence de la performance, on peut rajouter les grosses machines et on se dit, bon, allez, on va déléguer, entre guillemets, à plus de CPU, plus de mémoire, etc. S'il y a une faille, la faille est là et peut être exploitée. Mais moi ce que j'ai trouvé dur en tant que développeur c'est quand je travaillais il y a très longtemps chez Oracle en tant que développeur sur la plateforme Java, on avait des audits de sécurité la moitié des choses je ne savais pas ce que ça voulait dire, il y a des choses où c'était très bas niveau sur l'exploitation de la mémoire etc, en fait on a besoin d'être accompagné sur cette partie là et l'automatisation c'est essayer de capturer ça et le rendre, compréhensible par l'ensemble des développeurs l'ensemble des développeuses que ce soit en front ou en back et rendre la chose facile à fixer et savoir dans quelles priorités il faut la fixer.
Bruno:
Ça c'est vrai que moi j'ai eu la chance dans mon parcours à quelques occasions d'avoir des pen tests sur les systèmes qu'on avait déployés, et c'est vrai que je trouve que c'est une source d'apprentissage phénomène, c'est-à-dire qu'on apprend des choses d'un point de vue technique sur, tu vois, pas que la gestion de la mémoire mais aussi sur comment est-ce que des gens peuvent détourner des accès sur des trucs qui existent ou pas, je trouve que c'est toujours hyper intéressant.
Tug:
Et en fait c'est ça que je trouve intéressant pour moi, si on revient au DevSecOps, l'outil qu'on va devoir mettre en place c'est pour essayer de sensibiliser à ça, mais aussi d'en apprendre quelque chose c'est que ça devient un automatisme, non pas dans la machine mais dans l'humain, où on va se dire je sais que je faut que je fasse attention à ça, et se former parmi les choses qui fonctionnent bien c'est quand on fait du pen testing ou quand il y a d'autres outils qui vont participer c'est qu'on essaye de comprendre comment ça va être exploité, et je disais que je faisais du copilote beaucoup c'est mon métier principal aujourd'hui et une des choses que j'invite les gens à faire, L'IA n'est pas un outil pour trouver les failles de sécurité, ils vont en trouver quelques-unes, mais ce que je trouve vraiment très intéressant, c'est ce côté où quand il y a une faille qui a été trouvée, peu importe par quel outil, où quelqu'un a regardé ton code et a dit fais attention à ça, c'est utiliser l'IA justement pour se former. Poser la question, on va faire le truc tout bête que tout le monde, même les non-développeurs vont comprendre je ne sais pas s'il y a beaucoup de non-développeurs qui vont écouter le podcast, mais quand on parle d'injection SQL, comment ça peut être exploité ? On pose la question on discute, on découvre, et en fait on arrive à se sensibiliser sur cette partie-là, et moi c'est quelque chose que je montre fréquemment sur pourquoi c'est important et comment se former, entre guillemets, et on va apprendre, et après il y a d'autres, des projets open source des. Outils qui permettent justement d'utiliser un peu une gamification pour, à partir d'une vulnérabilité qui aurait été trouvée par des outils, inviter le développeur à faire un petit test, une petite formation pour comprendre s'il a vu l'impact. Et la sécurité, c'est pour tout le monde. On est tous des responsables de sécurité. C'est comme ça qu'il faut le voir. Et après, il y a ce qui se passe en amont et en aval. C'est-à-dire qu'on est tous les ans, il faut qu'on soit formé. Je ne sais pas comment, donc vous, dans vos entreprises, dans vos équipes, vous l'êtes. Chez GitHub et Microsoft, on a des formations sur la sécu qui ont fait tous les ans, tous les ans, tous les ans. Moi qui ne suis pas sur le cœur du produit, on ne va pas avoir le même niveau de formation que les gens qui développent le code en tant que tel, mais c'est aussi la responsabilité de l'équipe de la plateforme DevOps, avec l'équipe de CISO dans l'entreprise, de faire le travail pour faciliter la tâche du développeur. On n'est pas capable de tout savoir.
Bruno:
— Ouais, mais là, en fait, tu décris aussi une organisation avec un niveau de maturité, une obligation de maturité sur la sécurité qui est hyper forte, où, effectivement, il y a une compréhension de la formation de la sécurité. Ça doit être sur tous les maillons de la chaîne, parce que la sécurité, c'est un sujet qui est global, en fait. — Oui. — Mais la majorité des organisations aujourd'hui, on va être très clair. Je pense pas que autant de boîtes aient un tel niveau de maturité sur la notion de la cyber.
Tug:
Alors juste alors moi je vais parler que de la partie que j'arrive à comprendre qui est le parti vraiment la partie développement d'applications. Je vais pas aller la sécurité sur nos machines, la sécurité sur le cloud ou les machines en production. Ce qui se passe, c'est que, justement, à la différence d'il y a quelques années, je pense qu'aujourd'hui, c'est facile à mettre en place, à activer les outils de sécurité. Ce qu'il ne faut pas faire, c'est qu'on met en place toute la sécurité et on bloque tout. On va mettre en place les outils de sécurité. Moi, je travaille pour GitHub. Si vous avez des projets open source, si vous avez des projets sur des repos publics, vous allez dans la partie settings, sécurité, vous pouvez tout activer. Et vous allez voir ce que c'est que de regarder le code, de scanner, tout le monde a reçu des alertes avec des pendabots au moins, donc la partie sur l'analyse des dépendances. Et cette partie-là, pour moi, est vraiment importante parce que ce n'est pas très compliqué à mettre en place. L'objectif, au début, ce n'est pas de tout bloquer, mais plus de sensibiliser. Et plutôt que de dire on sait que la sécurité, c'est le problème de tout le monde, si on a un outil qui peut nous aider en relevant un petit peu des alertes et petit à petit, au fur et à mesure où la maturité, justement, va, grossir, on va être plus sensible, on va être capable d'être alerté, on va avoir confiance dans l'outil par rapport à des faux positifs, etc. Pouvoir la mettre en place à l'échelle. Mais c'est marrant parce que le commentaire que tu fais, alors attention, là je parle comme si moi j'étais quelqu'un de super strict, non, non, moi je suis pas quelqu'un de très, dans mes projets, perso c'est la catastrophe, c'est pas bien testé, c'est probablement pas sécurisé. Sur la partie mais Et le discours qu'on a autour, que j'ai là, c'est le même qu'on avait sur la qualité il y a quelques années. Oui, tu attends à ce que la boîte soit super mature. Non, plus on va le faire tôt. Mais ce qu'il faut, c'est que ce soit facile à faire. Et dans une petite équipe, dans une petite boîte, trouver des outils à droite à gauche qui vont pouvoir le faire dans l'open source ou à des coûts moindres au début pour sensibiliser justement les équipes. Mais pour moi, le point qui va être clé, c'est de ne pas bloquer. Parce que sinon, ça devient un conflit entre l'équipe ou entre guillemets le responsable de la sécu, le développeur, l'architecte, etc. Où on va se taper dessus, on va attendre, je ne comprends pas ton problème, j'ai compris que la sécurité c'est important, mais tu ne m'aides pas à résoudre. Et donc c'est trouver cette façon de travailler en collaboration et avec les humains et avec l'équipe.
Bruno:
Les outils Alors je trouve qu'il y a quand même une, je ne sais pas si c'est une ambivalence, je ne sais pas si c'est le bon terme, mais parce que tu évoques qu'effectivement il y a un tas d'outils qui te permettent de très simplement en fait avoir de la surveillance de l'audit ou même de l'amélioration de ton code, tu as évoqué le cas des injections SQL, pour moi c'est un sujet qui est intéressant parce qu'aujourd'hui pour la majorité des développeurs on utilise des frameworks avec des ORM intégrés, qui nous protègent de manière native d'une bonne partie des injections SQL possibles ou des injections XSS ou ce genre de choses, c'est forcément hyper intéressant qu'on ait réussi à simplifier la manière dont on peut se protéger de ces attaques là mais ça veut dire aussi, tu en l'évoquais tout à l'heure quand tu reçois ton rapport de pentest t'apprends énormément de choses et donc au final en l'automatisant, en le simplifiant, tu prives aussi des gens d'apprendre quelque chose qui peuvent aussi les rendre meilleurs sur tout un tas d'autres sujets, et je trouve que ça donne aussi une espèce de sentiment de confort en disant moi je suis safe parce que j'utilise les outils à la mode, parce que j'utilise des trucs qui font tout ça à ma place donc j'ai pas besoin de faire attention, mais pourtant moi sur ce podcast on a reçu des gens qui nous ont expliqué qu'il y a quand même, tu as parfois des failles d'un niveau de complexité qui sont hyper élevés que tous ces systèmes là ne sont pas capables de catcher en fait.
Tug:
Oui mais en fait le niveau c'est si on prend l'exemple de l'agriculture actuelle qui aujourd'hui ne devrait plus trop arriver parce que les frameworks le cachent, La faille dont tu parles qui va être de très bas niveau, de toute façon, que je sois formé à cette vulnérabilité autour du SQL ou le bas niveau, j'ai pas la compétence. Ce qu'il faut, c'est alerter et être capable de réagir. C'est plus ça pour moi qui est important parce que c'est-à-dire que... Quand on se forme, c'est intéressant d'être sensibilisé à ça, donc trouver des outils qui vont prendre des failles de sécurité de base pour se former, tout à fait d'accord. Quand on développe une application, on a autre chose à faire, si on peut l'automatiser derrière. C'est parce qu'en fait, plus ça va, de toute façon, plus on a de l'abstraction.
Bruno:
Oui, parce que je réagissais quand tu disais que ce sont des choses qu'on n'a pas le temps de faire, ce n'est pas forcément notre priorité. C'est discutable en fait est-ce que c'est pas aussi là que notre expertise elle peut avoir de la valeur c'est d'être capable d'avoir une approche très systémique, holistique des choses.
Tug:
Alors sauf que oui, sauf que la plupart des développeurs ne sont pas, et moi je me mets dedans en premier, les développeurs à AWS comme moi on est pas des experts en sécurité, on est pas des experts en qualité on est pas des experts en performance, et on nous demande de développer de plus en plus de choses, et c'est encore plus vrai, avec l'arrivée des outils autour de l'IA donc on doit produire, produire, produire donc pour 100 développeurs, pour 10 développeurs t'as un expert de la sécurité 2 experts de la sécurité donc il peut pas faire son travail ou alors il va être complètement débordé donc faut que lui soit aidé et qu'il puisse transmettre un certain nombre de, transmettre les bonnes pratiques à ces fois 10 développeurs avec qui il travaille, et c'est ça en fait le défi aujourd'hui pour moi c'est qu'en fait on doit développer de plus en plus d'applications je ne te parle même pas de la dette technique des vieilles applications qui sont à traiter c'est comment on fait en sorte pour que le code qu'on va écrire qu'on écrit aujourd'hui soit le plus sécurisé possible, les bons choix de framework il y a les bonnes pratiques de développement qui sont très importantes mais il y a après est-ce qu'on peut automatiser certaines tâches pour remonter parce que le pen testing il arrive à la fin, Et il y a toute une partie aussi qui est avant le pentesting, ou pas avant, ou en parallèle de ça, si on parle tout bêtement, parce que ça, c'est quelque chose qui est énorme. Exploiter une faille de sécurité dans le code, ça peut être très compliqué. On se souvient tous du log4j, donc il faut déjà que ça soit la bonne version, que le port soit ouvert. Non, il y avait tout un tas de trucs pour exploiter ça. Il faut déjà savoir que la faille existe, donc on peut automatiser et faire des robots qui le font. Mais normalement, on va avoir une sécurité périmétrique, etc., qui va faire qu'il y a une autre partie. Tu as des choses tout bêtes où moi, je suis vraiment, vraiment surpris. C'est que moi qui ne suis pas un hacker, je ne suis pas quelqu'un qui sait casser quelque chose. Mais si je vois du code dans lequel il y a des clés d'API que je peux utiliser directement, je n'ai pas besoin d'être un gourou pour exploiter ça. Et tu vois il y a ce niveau de sensibilité pour moi qui est le plus important c'est à dire qu'il y a des bonnes pratiques qui sont avant même de se dire qu'on va exploiter une faille de très bas niveau où là on va devoir avoir un expert ou un système expert, il y a des bonnes pratiques dans le développement et comment on se protège et il y a des choses qui sont intéressantes à faire c'est prenez vos sources code, passez un outil de scan de code pour trouver des clés d'API dans votre code. Alors idéalement il faut trouver dans tout l'historic git parce qu'en fait des personnes vont penser oh bah oui mais c'est bon je l'ai effacé Non, il est dans ton historique guide, tu récupères, tu prends toutes les branches, tout l'historique, tu peux aller scanner pour vérifier si tu as des clés. Ça, pour moi, c'est beaucoup plus, cette sensibilité-là, quand on voit ça... Parler de sécurité à bas niveau sur de l'injection de quelque chose qui est très bas dans l'application, je me concentrerai là-dessus au début. Parce que ça, justement, là, c'est la responsabilité du développeur, cette partie-là de la développeuse, de la personne qui va configurer l'application. Les failles de très bas niveau, en plus, souvent, elles vont arriver sur des parties du code qui ne sont pas nécessairement les nôtres. Parce que ça aide de plus en plus d'API. C'est pour ça qu'on va mettre à jour des frameworks, d'ailleurs. C'est parce que Log4G est un très bon exemple. Ça traînait de partout dans toutes les applications. Personne ne savait que c'était là. En tout cas, personne ne savait qu'il y avait ce module-là, LogSH, je ne sais même plus comment il s'appelle, mais on ne savait pas qu'il était là. La faille, on a été tous touchés par ça, alors que personne n'a touché à ce code-là dans tous les gens qu'on a fréquentés. Et on a tous été impactés. Là, c'est vraiment une faille de sécurité à traiter d'un point de vue purement. J'ai une faille de sécurité dans du code qui ne m'appartient pas. Je pense quand même qu'on a de moins en moins de failles de sécurité dans le code qu'on décrit parce qu'on a des frameworks modernes. Par contre tout le reste autour la mise à jour des dépendances parce qu'on traîne des choses qui vont les nouvelles failles arrivent et quelqu'un va le fixer il faut le partager et les secrets dans le code, et je sais pas si on a tous accès à GitHub ce que vous pouvez faire un jour vous vous amusez à, créer un secret dans une de vos API Azure, AWS, Google un path token vous le désactivez juste pour éviter essayez de le pousser sur un repo public vous allez voir ce qui va se passer. Immédiatement, vous allez être alerté, il va être désactivé. Tous les pushs qu'on fait, on essaye de trouver que vous faites, parce que nous, on ne les fait pas, que vous faites sur GitHub, quand c'est un repo public, vont être scannés, pour vérifier. Parce qu'il y a quelques années, ça doit dater de 2007, non pas 2007, parce que GitHub n'existait pas, donc je ne me souviens plus, je pensais, j'avais vu un poste en disant, quelqu'un qui disait, GitHub n'est pas sécurisé, bah oui, tu avais mis des clés publiques d'AWS dans ton repo public, donc c'est pas un problème de GitHub, c'était un problème de pratique de développement. Et... Là, je pense qu'on ne regarde pas le problème au même niveau, toi et moi. C'est-à-dire que moi, je vais avoir un truc très basique dans l'éducation. Parce que les failles de très bas niveau, je pense que ça doit être traité avec l'aide d'un expert.
Bruno:
Alors, le cas que tu évoques, en fait, est marrant. Je suis obligé d'en parler parce que c'est un vieil épisode. Si vous ne l'avez pas écouté, je vous invite à aller écouter l'épisode 66 avec Olivier Dupuis. Je vérifie que c'est le bon niveau. C'est sur Love Forger ? Non, c'est sur les clés AWS. Et en fait, Olivier nous raconte comment est-ce qu'un jour, sur sa boîte, il y a un des devs qui a publié dans un guide public les clés AWS de toute leur infra, sur un site qui s'appelle Inter-Enchères, qui fait la vente aux enchères d'objets d'art. Et notamment, il explique que... En fait, il y a effectivement... Alors, à l'époque, quand on a enregistré ça, c'était en 2000... Épisode 66, donc c'était en 2023 ? En 2020, pardon, il y a un petit moment, il expliquait qu'il y a des routines sur GitHub qui tournent toutes les 3 minutes pour effectivement écluser ce genre de système-là, mais du coup, il y a des attaquants malveillants qui scannent GitHub toutes les 2 minutes pour essayer de choper les clés qui passent entre les mailles du filet. Et donc, eux, ils se sont fait choper, et donc, ils nous racontent minute par minute comment ils ont récupéré, l'accès à leur système, parce que forcément, l'eau de Murphy fait que tu as tous les problèmes qui s'enchaînent, le téléphone pour la MFA qui n'a pas de batterie, bref, toutes les situations. Je vous invite à aller écouter cet épisode qui est un cautionary tale, comme on dit, de ces éléments-là.
Tug:
Et pour moi, c'est important, quand on parle de niveau de sécurité, il y a des choses de base qui sont faciles à mettre en place. Pour moi, on commence par là.
Bruno:
Mais tu vois, le fait qu'on soit obligé, alors obligé, bien évidemment, c'est nécessaire que on ait des frameworks qui nous mettent des ORM pour utiliser les actions SQL, bien évidemment c'est top qu'il y ait des outils comme GitHub qui viennent empêcher la publication de clés AWS, Azure ou autre parce que ça peut faire des gros dégâts, mais tu vois le fait qu'on délègue cette responsabilité à des outils ce que tu disais en fait tu vois cette, log4g où on n'avait pas la maîtrise de ce truc là ça fait qu'en fait, c'est le sujet qu'on a aussi avec l'IA aujourd'hui On laisse les IA coder, on laisse les IA scanner notre code. Mais qui est-ce qui contrôle tout ça ? À force de déléguer la responsabilité, on n'est plus capable de faire les choses nous-mêmes.
Tug:
C'est aussi parce qu'on a rajouté de la complexité sur la complexité et qu'on nous demande de faire de plus en plus de choses. C'est-à-dire que si on revient au DevOps, DevSecOps, c'est qu'une grosse partie de notre travail, ça a été d'essayer d'automatiser les tâches. Ça a fait 32 ans que je travaille. J'ai commencé comme développeur dans un petit éditeur de logiciels. Et ce qui était amusant, c'est qu'on n'avait pas le temps de faire les tests. On a tous connu ça. On ne va pas en parler de sécurité, on va en parler de qualité. Ce que moi, j'espérais, c'est qu'en vieillissant, quand mes collègues qui ne sont pas restés développeurs sont devenus des managers, puis des CIO ou des CTO, puis des patrons de boîte, se rappellent de ce temps-là. Ou quand on est développeur, on se plaint, on n'a pas le temps de faire des tests, on n'a pas le temps de faire la sécurité, on n'a pas été formé sur les choses. Ça arrive tout le temps, ça. Donc, sur le principe, je suis entièrement d'accord avec toi. Il y a la partie qui me perturbe, c'est qu'on manque de temps. Et en plus maintenant avec l'arrivée de l'IA on est capable de développer des applications de plus en plus rapidement il va y avoir une compétition entre les vendeurs, je suis éditeur d'une application SaaS qui fait X ah oui mais il y a 3 services qui se sont faits en parallèle donc il faut que je continue d'accélérer donc il va y avoir une pression de plus en plus grande sur les développeurs, les créateurs, à ce moment là j'ai envie de dire créateurs d'applications est-ce que ce sont des développeurs ou autre chose je ne sais pas. Mais sur cette partie c'est vraiment sur le principe, moi je suis d'accord avec toi mais moi dans mon temps, si je regarde dans ma journée de travail, j'ai peu de temps pour me réserver à une partie qui m'intéresse mais sans plus, alors je ne devrais pas dire ça il y a 5 minutes j'ai dit la sécurité c'est le truc le plus important, mais c'est qu'on est obligé de choisir des priorités sur ce qu'on va approfondir, et sur la façon et la sécurité en plus c'est quelque chose de très très compliqué, donc c'est quelque chose où je travaille avec un de mes collègues qui s'appelle Adrien qui fait le même métier que moi mais spécialisé sur la partie sécu son métier c'est justement d'être un peu plus dans la profondeur pour pouvoir quand moi je fais mon petit vernis lui il arrive où il va, passer plus de temps sur cette partie là et surtout faire le pont entre l'équipe sécu dans les grosses entreprises l'équipe sécu et les développeurs et si on prend une petite équipe une société où il y a un CIO ou un CISO qui n'a pas d'équipe, qui n'a pas de personnes qui vont vraiment travailler sur cette partie-là, comment tu fais ? Mais les gens, on est curieux par nature. La plupart des gens qui travaillent dans le développeur, les développeuses, qui restent dans la technique année après année, c'est parce qu'on est curieux. On est curieuse, on a envie d'apprendre des choses, on a juste besoin de choisir certaines parties. Moi, je me souviens, quand j'ai commencé à travailler, la partie réseau ne m'intéressait pas. et pourtant aujourd'hui s'il n'y a pas de réseau il n'y a rien.
Bruno:
J'aurais beau faire l'application.
Tug:
La plus belle du marché le réseau c'est ce qui va faire tourner on se, ça fait partie des choix qu'on a à faire, mais il y a aussi toute une partie où on ne se pose pas trop la question et je pense que juste sensibiliser les gens déjà c'est très important.
Bruno:
La question se veut un peu je ne vais pas dire provoquante mais un peu absurde à dessin parce que effectivement la sécurité tu l'as dit c'est un sujet d'expertise, et que ça se complexifie énormément avec le temps mais est-ce que d'une certaine manière, la recherche de failles et les attaques se sont beaucoup complexifiées avec le temps parce qu'en fait on a réussi quand même à écluser une bonne partie des failles simples c'est-à-dire que comme l'injection SQL est quelque chose qui est de moins en moins accessible au possible sur des grosses infrastructures ça oblige les attaquants, entre guillemets, à aller chercher des failles plus complexes. Est-ce qu'on n'aurait pas un moyen simple d'arrêter la recherche des attaquants ? Ce serait de faire des systèmes, au final, moins bien protégés, qui permettraient du coup aux plus gros de se protéger plus facilement.
Tug:
Je ne sais pas. Là, je ne sais pas. Mais sur la partie... Étant d'une nature optimiste comme on développe tous de plus en plus avec l'IA je pense qu'on va simplifier, on va développer plus mais on va diminuer le nombre de frameworks le nombre de langages, le nombre de façons de développer parce qu'on va tous se standardiser un petit peu, je vois ça de façon optimiste il y a des personnes qui vont voir ça de façon catastrophique, et là je pense qu'on aura une opportunité peut-être pour justement les failles seront plus faciles à découvrir et à répondre à contourner ou à fixer je n'arrive pas à trouver le mot on.
Bruno:
Va tous utiliser à peu près les.
Tug:
Mêmes patterns les.
Bruno:
Mêmes frameworks et donc du coup.
Tug:
Si une.
Bruno:
Faille qui est détectée elle sera vite déployée.
Tug:
Partout je pense, la faille comme le fixe oui aussi la faille le moins vite possible, le fixe le plus vite possible.
Bruno:
Tu nous as évoqué parce que maintenant tous les épisodes d'YVTTD ont la capacité de terminer dans un MCP qui va pouvoir guider les développeurs directement dans leur IDE. Tu nous as donné ces conseils sur éviter la fuite des clés dans le code. Est-ce que du coup, tu peux aussi nous donner d'autres petits conseils simples et efficaces sur comment fiabiliser un peu le code qu'on produit ?
Tug:
Alors, il faut se rappeler, je travaille pour GitHub. En plus, c'est la seule plateforme que je connais. C'est-à-dire que je n'ai pas eu l'occasion de travailler avec d'autres plateformes DevOps puisque quand on a quitté Subversion quand je travaillais chez ExoPlatform, on a quitté Subversion pour passer sur GitHub et depuis je n'ai jamais quitté GitHub. Je vous invite, parce qu'on a tous l'occasion de faire des repos, c'est de se mettre dans une situation d'un développeur, d'une équipe, d'une développeuse, d'un développeur, d'une grosse équipe qui doit avoir un projet sécurisé, dès le début. Donc moi, ce que je vous invite à faire, c'est vous regarder les fonctionnalités de sécurité qu'il y a dans GitHub sur les projets open source, parce que tout est gratuit, pour se sensibiliser à, justement, comment on scanne et comment on se protège pour éviter de pousser des nouveaux secrets, des nouveaux clés d'un pays dans le code, comment on répond aux problèmes. Et typiquement aujourd'hui, si on reprend l'exemple d'AWS qu'on a cité précédemment, ça va désactiver la clé automatiquement quand c'est public. Ça n'a pas laissé le temps aux gens d'attaquer. La même chose sur le code, c'est-à-dire qu'on a un outil, un scanner de code qui s'appelle CodeQL, qui est fourni avec GitHub, comme ça. Donc vérifier, voir comment ça fonctionne. Après, dans votre entreprise, vous aurez peut-être des autres outils, ou quand vous allez choisir dans le futur, prendre un autre outil. Mais c'est se sensibiliser à ça. dépendre d'un bot pour mettre à jour les dépendances donc vérifier que la première solution les deux premières choses à mettre en place pas de secret dans le code, les dépendances à jour et le troisième c'est scanner le code mais pas uniquement pour la qualité mais pour la sécurité et on peut le faire et on peut découvrir ces fonctionnalités là dans GitHub et après vous pouvez une fois que vous avez compris, partager ça avec d'autres personnes et moi je trouve que là ça va être aussi un bon moyen d'apprendre parce que quand vous allez commencer à prendre vos projets surtout s'ils sont vieux et vous allez les activer vous allez voir des failles qui vont. Remonter et en fonction de la curiosité et de la compétence vous allez soit fixer sans trop comprendre soit apprendre en disant j'ai envie de comprendre pourquoi cette faille est importante et elle doit être.
Bruno:
Fixée tout de suite et donc forcément devenir meilleur.
Tug:
Avec la particularité qu'on a beaucoup beaucoup de choses à apprendre en ce moment, moi j'ai 3 enfants qui sont développeurs ce qu'ils doivent apprendre en quelques mois en tout cas moi j'aurais mis plusieurs années à apprendre, à cause, ou grâce à l'IA, je sais pas si c'est... Donc on va devenir meilleur, mais en parallèle de ça, on va se prendre d'autres vagues sur lesquelles on va devoir travailler.
Bruno:
Après, il y a peut-être aussi le fait que toi et moi, on a peut-être mis des années à apprendre tout ça, mais c'est aussi parce que tout ça est apparu au fur et à mesure de toutes ces années, en fait. Donc mathématiquement, on ne pouvait pas tout engranger d'un coup. Mais c'est vrai qu'on a évoqué plusieurs fois sur ce podcast la complexification de notre métier, et notamment parmi le fait qu'on nous demande de faire du code qui fonctionne, qui fonctionne longtemps, qui soit sécurisé. Qui gèrent des notions de performance, de scalabilité. Donc c'est vrai qu'on a beaucoup plus de techno qu'avant. Qui nous rajoutent de l'abstraction, mais qui nous permet de faire des choses. On prend souvent l'exemple de Cube, en disant que Cube, c'est une technologie qui est complexe. Mais comparativement, faire un cluster aujourd'hui, par rapport à ce que c'était en 1992, ça n'a rien à voir en termes de simplicité. C'est-à-dire qu'en gros, en quelques clics de souris, tu as un truc qui est scalable à travers le monde, alors qu'avant, c'était un boulot de 200 personnes.
Tug:
Alors la raison pour laquelle je rigole, je suis entièrement d'accord avec toi, mais la raison pour laquelle je rigole, je dis oui, mais on n'a pas nécessairement tous besoin d'un cluster pour bien.
Bruno:
On est d'accord.
Tug:
Parce qu'il y a aussi cet effet où on va rajouter de la complexité de par notre nature. Moi, je développe une application, en étant très prétentieuse, le Strava de la planche à voile. J'aurais pu faire un truc quasiment statique. Les gens mettent en ligne leur trace GPS, analyse, etc. Donc, c'est pour ça que je dis quasiment. Mon architecture, elle est ultra compliquée. Mais parce que, un, j'ai envie d'apprendre. Deux, ça me permet aussi quand je discute avec d'autres développeurs et des gens qui travaillent sur des applications réelles de me comparer mais on a quand même une nature, à complexifier les choses ça fait partie on a envie d'apprendre ou de découvrir quelque chose, c'est assez amusant que tu parles de Kubernetes parce que moi j'en fais quasiment plus et je fais des outils où on fait juste des conteneurs qu'on déploie sur le cloud moi ça me suffit pour mes applications et je pense qu'il y a beaucoup d'applications où ça pourrait suffire en effet.
Bruno:
En tout début de podcast t'as eu une phrase que j'ai trouvée surprenante sur laquelle je souhaiterais revenir tu as dit que l'IA n'était pas un bon outil pour détecter les failles, alors ce qui m'a étonné déjà parce qu'on a vu là on enregistre ce podcast en émis avril, il y a eu Claude Mythos qui a fait une annonce alors je sais que c'est des effets d'annonce de machin et compagnie mais ils ont annoncé que du coup ils ont détecté énormément de failles dans des projets existants Je suis étonné de... Je sais pas si tu peux clarifier un peu.
Tug:
— Oui, je pense que j'ai peut-être été trop direct. En fait, mon commentaire, il est plus de dire « aujourd'hui ». Ne considérez pas, parce que vous avez demandé à votre IA, quelle qu'elle soit, de scanner votre code pour la sécurité, que le résultat soit suffisant. C'est-à-dire que plus on va avoir quelque chose de déterministe, il y a des outils qui ont été prouvés et qui vont comprendre la code base. Alors là, je parle vraiment sur l'analyse du code, plus ça sera intéressant. Je pense que c'est complémentaire. Mais par contre, la façon dont moi je travaille dans mon code, c'est quand je suis avec Copilot, je vais lui demander ce que tu peux vérifier avant de comité, je vais lui dire scanne-moi mon code pour faire une code revue de ma branche en cours et donne-moi les failles ou ce que tu trouves autour de la sécurité et de la qualité systématiquement. Donc il va me donner des choses, donc il va me trouver des choses aussi. Alors oui, si, en Java il m'a trouvé, il m'a trouvé des trucs qu'il a qualifié de sécurité. Par contre, je dis ça pour ne pas remplacer le côté, par exemple, les scans de secrets. Il faut être certain que le pattern qu'on a, ça soit un vrai secret, etc. Et sur le scan de code, les outils quand même modernes sont capables de remonter dans la chaîne d'exécution pour savoir est-ce que c'est quelque chose qui peut être exploité et l'expliquer. Je pense qu'aujourd'hui, ça peut être intéressant et être complémentaire. Mais d'ailleurs nous chez Github l'équipe des ingénieurs autour de ces outils là utilise l'IA pour aider à écrire les règles en fait on appelle ça des queries, des requêtes sur code QL, c'est complémentaire je pense que j'ai été effectivement un peu extrême dans ce traitement mais c'est plus le côté, aujourd'hui c'est pas suffisant gardons en compte parce que sinon on va, en plus tu as parlé d'un modèle qui n'est pas encore accessible donc ça veut dire que si moi je le fais avec mon cloud opus mon GPT-5.4 en disant est-ce que tu as trouvé les failles de sécurité il me dit non il n'y a rien ça ne veut pas dire qu'il n'y a rien c'est plus dans ce contexte là et ça va changer tous les mois l'IA change toutes les semaines et tous les mois.
Bruno:
On peut même supposer d'ailleurs que même ce fameux modèle mythos de Claude ne détecte pas tout, c'est juste qu'il a un modèle qui lui permet de détecter certains éléments mais comme bien souvent en fait parce que, les failles sont multiples Beaucoup sont inconnus, le resteront peut-être toujours. Pour poser ma question autrement, est-ce que tu penses qu'on arrivera un jour à avoir un système qui est réellement 100% fiable ?
Tug:
Non, je ne pense pas.
Bruno:
On est d'accord.
Tug:
Par contre, ce que tu viens de dire est vraiment important. Parce que justement, la partie, tu vois, je n'ai pas pensé à le mettre en avant quand tu parlais du MCP, par exemple, ou d'exposer l'information. Parmi les choses que vous allez voir quand vous allez mettre en place la partie scan de code, ça va créer un nouveau pipeline, un nouveau workflow GitHub. Et il y a deux choses. C'est tu scannes à chaque push et tu scannes une fois par semaine. Et ça, c'est important. Parce qu'en fait, ce qui se passe, c'est que les failles de sécurité dans notre code, on en a peut-être, mais qui vont être découvertes. Par des ingénieurs, des grands spécialistes, soit des hackers ou des spécialistes qui adorent ce côté, le bug-bunkey, chercher les failles. Pourquoi c'est important, même sur du code qui ne bouge plus, parce que tu parlais du code qui est fait pour durer, ça veut dire qu'il y a du code qu'on ne va pas retoucher, qui n'a pas de faille, je ne sais plus quelle date on est, en 2026, mais si ça se trouve, en 2027, sans que vous ayez touché quoi que ce soit, il y a une faille qui a été pas introduite, qui a été, découverte. Elle était là, elle était découverte.
Bruno:
Disons qu'il y a quelqu'un qui a réussi à l'expliquer.
Tug:
Quelqu'un qui a réussi à l'expliquer et trouver cette code. Et le fait d'avoir les outils qui scannent régulièrement, le code existant, donc nous par défaut c'est une fois par semaine, donc à chaque push, tout ce qui a été modifié va être scanné, et une fois par semaine on rescanne tout. Ce qui permet le jour, comme nos règles évoluent, donc c'est une fois que quelqu'un, alors moi, là ça va dépasser ma vraie compétence, c'est comment on publie une faille, si vous trouvez une faille, s'il vous plaît, n'allez pas sur Twitter, n'allez pas dire j'ai trouvé une faille non non, vous prévenez le projet de façon privée, ils vont vous remercier, ils vont travailler sur la faille, sur le fixe une fois que c'est fixé publiquement il y a un fixe et on met à jour, et typiquement quand cette faille aura été trouvée, et le fixe trouvé, toutes les règles quand la faille est trouvée et donc ce qui va se passer c'est que les outils de scan sont mis à jour et quand on va re-scanner on va dire ah bah oui là il y a une faille qu'il faut faire.
Bruno:
Qu'il faut fixer.
Tug:
Le fixe, c'est vous changez votre code ou vous mettez à jour la librairie. Et c'est quelque chose qui bouge tout le temps.
Bruno:
Et du coup, quand vous faites une analyse à chaque push, vous analysez que ce qui est modifié ? Parce que c'est-à-dire qu'on peut, du coup, aussi, au travers d'un push, en fait, tu peux, de par une succession d'éléments, tu peux introduire une faille, mais du coup, pas dans ce que tu modifies.
Tug:
Alors, ça, justement, ça revient. Alors, ça va dépasser un peu mes compétences en termes de comment ça fonctionne à l'intérieur. Mais par contre, c'est là où justement les outils comme le scan de code QL lui va remonter, c'est-à-dire que vous avez changé du code il ne va pas uniquement faire le diff sur ce qui a été changé il va regarder le diff mais le diff remonte dans c'est appelé par ça, sur ce schéma-là il y a effectivement une vulnérabilité Ok.
Bruno:
Canon Je pense qu'on n'a pas le choix, il faut effectivement évoquer le changement de notre métier avec tous ces outils qui arrivent, où effectivement on produit du code de manière, phénoménale par rapport à ce que c'était avant c'est ce que je disais en intro on a l'IA qui génère le code, l'IA qui relie le code l'IA qui recherche les failles, tu l'as évoqué un peu tout à l'heure que ça va peut-être un petit peu uniformiser nos pratiques, mais on voit aussi quand même beaucoup de gens dire j'ai publié une app et en fait en 24h ils se font retourner dans tous les sens parce qu'en fait, c'est quand même surprenant que tous ces outils d'IA qui génèrent du code de manière native génèrent du code au final comme nous c'est à dire avec plein de failles alors qu'ils pourraient du coup avoir ça de manière native de faire du code sécurisé d'emblée ?
Tug:
Alors oui et je pense que ça s'améliore à chaque release de nos produits. Et ce qui se passe, c'est qu'il y a deux parties dans le changement de notre métier. Il y a cette partie-là où, en fait, je ne sais pas si tu connais Didier Girard de Sphère, quand il parle de l'IA pour les devs, je le cote, mais j'ai la même opinion, écrire du code deviendra un antipattern. J'ai pas dit pour tout mais pour les applications métiers business, je pense effectivement que demain parce qu'il faut bien quelqu'un qui écrive le coeur du produit en dessous, le moteur de base de données etc, dans ce contexte là, effectivement pourquoi il y a des failles de sécurité si on a quelque chose et il faut avoir confiance de plus en plus d'outils en fait et on le voit vont écrire du code et après s'auto-corriger. Et dans une des fonctionnalités de GitHub qui s'appelle le Cloud Agent, c'est quelque chose je ne sais pas si certains d'entre vous ont déjà testé c'est que si vous avez une GitHub Issues, une spec ou autre vous la donnez à GitHub, il va créer la pull request il va créer la branche travailler, créer la pull request, mais avant tout ça avant de finir de créer de proposer la revue soit par l'IA, soit à l'humain mais généralement les deux les dernières phases, c'est qu'il passe l'outil de sécurité, donc il s'auto valide, mais pas avec l'IA entièrement, avec l'IA plus l'outil. Donc, je pense que le commentaire que tu as fait, il y a aussi deux choses. C'est que je pense que ça évolue beaucoup. Ça serait intéressant de reprendre la personne qui s'est fait exploser son SaaS développé en 20 minutes en 2026. En janvier, en février, il faudrait refaire avec les nouveaux modèles et les nouveaux outils. Mais il y a une autre partie aussi. Et c'est là où, en fait, moi, je ne suis pas inquiet pour notre métier. Ça dépend si on pense que notre métier, c'est pisser la ligne. Il faut changer. Par contre, on a besoin, ça revient de pourquoi on ne peut pas devenir des experts de sécu tous. On a besoin de plus en plus d'applications de les déployer de plus en plus vite alors je ne sais pas si c'est bien ou c'est mal c'est le marché, et ça veut dire que on a toujours besoin de gens qui vont avoir une sensibilité je fais un produit et j'aime le créer, nous les développeurs on va devoir qu'ils sont plutôt moins techniques c'est à dire moi on va s'intéresser plus au métier pour accélérer par contre on a toujours besoin d'une personne pour combien de temps je ne sais pas je ne suis pas visionnaire, mais une des raisons pour lesquelles il y a ces problèmes c'est que c'est pas le tout d'écrire le code c'est pas tout même si le code est sécurisé si tu sais pas comment déployer oh bah tiens j'ai vu un mec qui a fait du Kubernetes je vais demander à l'IA de me faire un Kubernetes, oui il va le faire mais toutes les bonnes pratiques de développement et qui sont pas de la sécu au sens code dans ce cas là mais vraiment de la sécu plus ops et SRE, bah là c'est une compétence qui est vraiment nécessaire.
Bruno:
Tu veux dire sur le pourquoi on fait les choses.
Tug:
Non ça c'est pour le dev je parle pour la sécurité. Pourquoi ces services sont attaqués ? C'est aussi parce que la façon dont il a probablement déployé, la façon dont il a pensé l'authentification, il ou elle a pensé l'authentification. Tous ces trucs-là, en fait, c'est aussi une compétence d'architecte, de tech-lead dont on a toujours besoin. Mais on se fera aider, pareil, par l'IA.
Bruno:
Toi, à quel point est-ce que tu vois l'IA impacter, effectivement, peut-être le travail chez GitHub, mais de manière générale, nos différents métiers ?
Tug:
Alors, ça impacte tous les métiers, et pas uniquement nos au sens des techos, ça va du product manager au marketing, au développeur, à la sécu, etc. Et là, je vais faire entre guillemets un peu, c'est pas de la pub, mais c'est, moi j'utilise, je suis passé à la ligne de commande, la GitHub Copilot CLI, quasiment 95% de ce que je fais aujourd'hui, c'est dedans. Parce que je vais répéter des chiffres qui avaient été donnés lors d'une présentation que le responsable de ce projet a fait, à 10 développeurs ils font 500 pull request par semaine donc l'impact c'est, on change complètement la façon ça impacte tous les métiers quand on fait ça, parce que ça veut dire et je discutais avec la personne qui travaille sur ce projet, le responsable du projet, et le problème c'est que tu as une release par jour au minimum, une release par jour ok, nous les développeurs à la rigueur pourquoi pas, on a mis nos garde-fous, on a automatisé tout c'est très bien, mais il faut mettre à jour la doc il faut mettre à jour les supports de formation, il faut annoncer les nouveautés, ça aussi il faut l'automatiser, c'est pour ça que si on prend cet exemple là, les doc writers sont également impactés par ça, si tu as une release par jour hier matin dans le train j'ai vu qu'il y avait deux nouvelles fonctionnalités que j'aimais bien qui ont été rajoutés, qui étaient ask, le côté conversationnel, pas uniquement, c'est rigolo parce que le monde va à l'envers. Copilote on a commencé par la complétion, puis après le chat, puis après l'agent, la CLI c'est le mode agent, ça fait tout en automatique, et on vient de rajouter le ask, ce qui me permet de ne pas avoir besoin d'aller dans mon IDE pour avoir des questions basiques, peu importe, ça tu vois, c'est sorti hier, je suis sûr que je n'ai pas pris le temps aujourd'hui de regarder le changelog, tout ça, toutes ces nouveautés là, il faut pouvoir les documenter, il faut pouvoir avoir, La partie, l'IA change vraiment toute la partie du SOM.
Bruno:
J'ai fait un refactoring la semaine dernière. En fait, le refactoring, c'est je propose à mes invités de revenir trois ans après pour faire un refactoring de leur épisode. Et donc, on a fait un refactoring avec Thomas, Thomas Bonenfant. Je vous invite à aller écouter l'épisode. Et donc, lui, à la base, il y a trois ans, il faisait des formations no code. Maintenant, il fait beaucoup de formations autour de l'IA parce qu'en fait, tous ces deux écosystèmes se sont un peu bien rencontrés, on va dire. Et il m'a fait un propos que je trouve hyper intéressant, c'est qu'il dit que ce qu'on voit actuellement, les entreprises ont une désillusion vis-à-vis de l'IA, c'est que en fait, la majorité des gains de productivité qu'apporte l'IA ont été capturés par les individus. Et qu'en fait, il y a beaucoup de gens en entreprise qui utilisent l'IA parce que du coup, ça leur permet de travailler plus vite et donc d'avoir plus de temps qui prennent pour eux, pour se reposer pour et autres et qu'en fait, ça crée un problème parce que c'est l'entreprise qui paye pour les outils d'IA et qui n'envoie pas le retour parce qu'en fait ça rend les gens meilleurs mais du coup ça permet aux gens de garder un peu de distance ou même de reprendre de la distance avec ces éléments là.
Tug:
Alors j'ai un gros sourire quand j'entends ta question j'ai deux mon cerveau il est diviseur en deux.
Bruno:
Il y.
Tug:
A d'une part alors c'est très bien il y a une partie qui est plutôt sur le codé peut-être que c'est très bien et il y a l'autre partie c'est pas ce qu'on vit chez Github, C'est nous, ça nous permet de faire plus de choses pour le produit. Donc, est-ce que par moments, ça va nous soulager ? Oui, ça nous soulage. Notamment, il y a des tâches, mais il y a plein d'autres impacts. Ça aussi, à côté, moi, pendant que je suis en train de te parler, mes collègues qui font le même métier que moi, ils sont en train de créer des applis. Je vais me connecter. Oh là là, je n'ai pas vu comment ils ont fait. Ça va me mettre une pression indirecte. Donc peut-être que c'est aussi pour ça qu'on a besoin de ce temps un petit peu. Mais on est vraiment en phase de construction sur cette partie-là, de construction pas des outils, parce que les outils, effectivement, sont aussi en construction. Mais comment ça impacte le travail et moi je veux me concentrer sur la création d'applications je ne vais pas parler des autres métiers là c'est en train de complètement changer il y a 5-6 mois, je ne disais pas qu'on allait plus toucher le code quand j'ai dit je citais Didier qui disait, écrire du code sera un anti-pattern c'est pas un discours qu'on avait il y a quelques mois maintenant on peut se permettre de le dire Attention, ce n'est pas pour toutes les applications, ce n'est pas pour tous les systèmes, et encore, on verra ça dans trois ans. La phase qui est difficile, c'est que tu vois par exemple, j'ai eu la chance de rentrer chez GitHub en février 2021. Copilot est sorti en juin 2021, moi j'ai commencé à l'utiliser en septembre 2021. La façon dont tu en as utilisé l'IA entre ce moment-là et aujourd'hui est complètement différente. Et la plus grosse frustration que j'ai eue en tant que dev, moi je suis tombé amoureux du truc tout de suite. Tu vois bien dans mon discours que je ne suis pas nécessairement quelqu'un qui va plonger très bas pour comprendre. Ma compétence et ma curiosité, elle va être très horizontale plutôt que verticale. Je ne vais pas devenir l'expert des failles de sécurité, de la JVM, du JDK 25. J'avais avoir un vernis très très large. L'IA, moi, m'a changé ma vie pour ça. Je me suis mis à faire des choses que je ne pouvais pas faire auparavant, je commence à développer en C sur un système embarqué pour un petit GPS pour la planche à voile avec un copain, l'IA m'aide énormément, ça change ma vie, j'apprends plein de choses. Maintenant, il faut qu'on arrive à passer cette façon de travailler dans les entreprises pour aussi que ça permette de créer plus. Après, le gros gros du travail, c'est comment on fait ce changement-là. Et je vais me répéter, j'ai trois enfants qui sont développeurs, alors c'est trois fils, et je ne leur ai pas dit, il faut changer votre métier, votre métier est mort, devenez boulanger, ou menuisier, ou plombier, ou autre. La plombier, si on fait du code, on l'est. Bon, c'est l'usine à gaz. Peut-être on verra comment ça sera dans le futur. Mais c'est juste que le métier change énormément, énormément. C'est passionnant. Il faut juste s'intéresser soit à l'architecture globale, soit au métier, un peu plus que ce que certains développeurs font aujourd'hui. Pas nécessairement les gens qui écoutent les podcasts. C'est une question de curiosité, en fait. C'est-à-dire que les gens curieux, à mon avis, il n'y a aucun souci. Il va y avoir des phases un petit peu de reality check en se disant, effectivement, mon métier change, il faut que j'accepte. Est-ce que c'est bon ou est-ce que c'est pas bon, j'en sais strictement rien. Mais une fois qu'on a accepté ça, on va accélérer.
Bruno:
Moi, ça me va. Si on dit que écouter FTTD, ça devient un argument vendeur pour dire que c'est une meilleure carrière, moi, je suis preneur. Il y a un discours aussi que je vois popper depuis quelques semaines, c'est qu'il y a une espèce de fatigue que ces outils génèrent, et moi je le vis aussi, c'est qu'avant quand tu codais, tu avais un bug à corriger qui te prenait 3 heures, et quand tu l'avais corrigé, tu avais un vrai sentiment de fatigue, de travail, et puis tu avais le vrai sentiment de dire j'ai fait un truc, je peux arrêter ma journée, j'ai fait un truc. Aujourd'hui, effectivement, tu fais 500 pull requests par jour, tu corriges 30 000 bugs, et puis en fait, arriver à 18h, 19h, 20h, 21h, 1h du matin, t'es pas fatigué tant que ça, parce qu'en fait, t'as au final, t'as l'impression d'avoir peu contribué par rapport à ce qu'on faisait avant, et ça fait qu'on a une espèce de, on a des journées à rallonge, du coup, on a une fatigue autre qui s'installe. Je sais pas si vous vivez ça aussi chez GitHub.
Tug:
Alors, chez GitHub, je ne sais pas. Je ne peux pas en parler. Mais par contre, oui, c'est quelque chose qui est ressenti. Alors là, je ne te parle pas des ingénieurs de GitHub parce que je ne suis pas en contact. Je n'ai pas posé cette question. Ça serait intéressant d'ailleurs. Je vais en discuter, tiens, quand je vais rencontrer, je dis comment vous le vivez cette partie-là. Ce qu'il y a de certain, c'est que, moi la fatigue, à titre perso, je ne la vis pas exactement comme ça. C'est plus le côté un peu compétitif. Je fais mon IA Med à faire des tas de choses, c'est top. Après, je passe beaucoup de temps actuellement à plutôt faire de la formation, du DevRel et de l'adoption. Après je suis un vendeur, le but c'est que ça soit utilisé, donc c'est beaucoup de temps à expliquer pourquoi ça impacte notre métier, soit dans les écoles, soit chez les clients, et pourquoi c'est très important de le faire. Et quand je reviens, quand je vais me reconnecter après notre discussion, je vais dire, oh zut, j'ai raté plein de trucs, j'ai pas eu le temps de faire. Et comme ça bouge vite vite vite vite la fatigue elle vient aussi non pas uniquement parce que tu n'as pas l'impression d'avoir fait ton travail, dans ce que tu as décrit qui était où là j'ai vraiment analysé un problème travaillé dessus résolu et j'ai une certaine satisfaction il y a aussi la satisfaction quand même de faire quelque chose que ce soit un bug, on n'a pas fait grand chose entre guillemets par contre moi la fatigue elle vient quelquefois sur le côté, je suis nul quand je regarde tout ce que font mes collègues j'arrive pas à suivre. Après j'ai la chance d'être d'une nature optimiste d'être expérimenté en nombre d'années d'expérience de prendre du recul, regarde ce que t'as fait, t'as fait autre chose t'as apporté de la valeur d'une autre façon t'as contribué à une autre façon mais ça c'est vraiment fatigant, et l'autre partie et là j'ai la chance entre guillemets pour moi c'est une chance, moi je travaille chez GitHub j'ai un produit à regarder qui s'appelle GitHub Copilot et la plateforme GitHub, et les autres produits je les regarde en concurrence pour comprendre comment ça fonctionne et mon métier c'est ça mais si on prend les développeurs les développeuses les architectes les product managers tous ceux qui vont avoir à utiliser de l'IA c'est. Toutes les semaines, il y a quelque chose de nouveau, quand ce n'est pas tous les jours. Donc, en dehors du travail, c'est ce côté comment on fait pour se tenir à jour, comment on fait pour savoir ce qui est important ou pas important. Et ça, c'est aujourd'hui, moi, je pense qu'il n'y a pas de réponse et c'est très, très dur. Il faut accepter de rater les choses et le point le plus important, c'est le partager. Donc, ce que tu fais dans le podcast, par exemple, est clé. C'est qu'une des grosses discussions qu'on a, c'est comment on partage ce savoir, comment on forme les gens. Moi, je ne sais pas former des gens sur quelque chose qui est nouveau toutes les semaines. On se serait vu au mois de septembre, je n'aurais pas pu pas. J'aurais dit, tiens, on travaille sur une CLI. Je n'aurais pas pu te dire, maintenant, mon travail, c'est 90-95% sur la CLI. Donc, comment on forme ? On ne forme pas. Il faut partager, partager, partager. Et cette partie-là, pour moi, est vraiment le plus important. Mais c'est aussi quelque chose qui apporte de la satisfaction. Tu sais moi là quand il y a quelqu'un qui me dit c'est à la fois bien et pas bien c'est quand quelqu'un revient vers moi en disant je ne savais pas que Github ou que Github Copilot savait faire ça, est capable de faire ça c'est satisfaisant parce que j'ai contribué à quelque chose, d'un point de vue purement marketing ou d'un point de vue produit, c'est zut on a raté quelque chose mais d'un point de vue à titre perso ma satisfaction va venir de là, c'est un plaisir qui va être un peu différent mais ce que tu as dit là, sur le côté fatigue, je vais prendre mon fils aîné comme exemple, il m'a appelé un jour et il m'a dit « Papa, ça ne te dérange plus de ne plus coder, de ne plus écrire tes lignes de code. », Et on discutait. J'ai dit, moi, aujourd'hui, ça ne me dérange pas. J'ai dit, mais d'un autre côté, ça fait 32 ans que je bosse. Des lignes de code, j'en ai écrit plein, plus ou moins belles. Je sais que je ne suis pas un bon développeur. Il ne faut pas me faire confiance quand je mets quelque chose en prod. Mais par contre, je sais que si je me prends un problème, je vais réussir à le résoudre. Un problème d'informatique de gestion, des business apps. Et que si j'ai besoin d'apprendre une nouvelle techno, que ce soit sur du code ou déployé sur un cube quand j'ai appris Kubernetes, comme on est tous passés par là je vais m'en sortir et je vais apprendre de façon vraiment traditionnelle en me prenant les pieds dans le tapis, mon fils aîné, lui il aime coder ça fait partie de tout ce que nous on a connu où ça nous libère, on se repose c'est une phase de... Je ne sais pas comment dire, c'est pas de la méditation mais c'est une partie où on s'isole et ça on est en train de le perdre, et je lui ai dit oui je comprends je comprends ta question j'ai pas la réponse par contre ce qu'il faut c'est garder ta curiosité trouver les différents outils et aussi comprendre comment toi tu vas faire en sorte que les outils que tu vas choisir vont coder comme toi tu le veux ou plus important comme t'es un junior, comme ton entreprise ou ton équipe veut que tu codes et tu partages ça avec tes tech leads etc qui vont t'aider à orienter le travail de lire C'est une autre façon de penser.
Bruno:
– Canon. Merci beaucoup, Thug, pour toute cette discussion. J'aurais deux dernières questions pour toi, qui sont les questions rituelles de ce podcast. La première, c'est est-ce qu'il y a un contenu que tu serais partagé avec l'ensemble des auditoristes ?
Tug:
J'ai pas pris le temps de réfléchir à cette partie-là. J'ai raté comme ça, à chaud. Est-ce que tu peux me donner un petit peu ?
Bruno:
Oui, ça marche.
Tug:
Je peux réfléchir.
Bruno:
Pas de souci. Ce qu'on peut faire, c'est du coup, si tu veux, ça je t'ai un peu plus de temps, on pourra mettre en description. Les gens pourront découvrir en description la surprise de ce que tu veux partager. Et dernière question la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ?
Tug:
Espace.
Bruno:
Espace, très bien. Merci beaucoup, Tug.
Tug:
Merci.
Bruno:
Et merci à tous d'avoir suivi cet épisode la sécurité comme toujours c'est un sujet qui est primordial, tu nous as donné plein de petits conseils pour améliorer déjà au quotidien de sécurité, il ne faut pas surtout se reposer sur votre IA en tout cas pas encore pleinement. Le côté déterministe a quand même un côté hyper important donc allez checker les différents outils notamment disponibles sur GitHub. Mais peut-être sur d'autres aspects, mais GitHub ils sont gratuits et ils sont disponibles en open source pour beaucoup donc profitez-en, moi comme toujours je vous remercie de partager ce podcast autour de vous et si vous voulez rendre votre cloud code votre copilot votre curseur meilleur vous pouvez avoir tous les conseils de thug directement dans votre IDE grâce au MCP ifttd donc n'hésitez pas à aller checker en description pour voir comment accéder à tout ça je vous remercie beaucoup je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.
