Comment l'IA va transformer les pratiques DevOps et SRE | Better Stack Podcast Ep. 12
BBetter Stack
컴퓨터/소프트웨어튜닝/매니아경영/리더십재택/원격 근무정신 건강AI/미래기술
스크립트
00:00:00Je formulerais les choses ainsi : ouvrez un projet Claude Code et demandez-lui de vous concevoir un pont
00:00:05ou un gratte-ciel.
00:00:08Et ensuite, je veux que vous preniez ce design et que vous alliez le construire.
00:00:12Et après, je veux que vous alliez vous y asseoir. Serez-vous vraiment à l'aise de faire ça ?
00:00:16Serez-vous à l'aise de rouler sur ce pont qu'il a conçu ?
00:00:19Exactement... jusqu'à ce que vous arrêtiez de secouer la tête. Nous avons besoin de ces ingénieurs sur place.
00:00:25Bienvenue sur le podcast Better Stack, où nous discutons de développement logiciel, d'IA et de toutes sortes de nouvelles technologies.
00:00:32Je suis l'un de vos hôtes, Andris, et je suis rejoint aujourd'hui par Wishes. Bonjour et...
00:00:38Amin Astani. Salut Amin. Comment ça va ? Ravi de t'avoir ici.
00:00:44Oui, euh, merci de m'inviter. C'est un très grand plaisir. Alors, d'après ce que je sais de toi,
00:00:51je pense un peu que tu es
00:00:53un peu comme un sorcier du SRE. Tu es très ancré dans ce domaine, tu animes ton próprio podcast sur le sujet,
00:01:01alors nous sommes curieux de savoir comment tu as débuté dans ce domaine et quel a été ton parcours à travers
00:01:08ta carrière en développement logiciel jusqu'à présent.
00:01:11Oui, bonne question encore Andris, Richard. Merci de m'accueillir. Oui, comment j'ai commencé ?
00:01:17Eh bien, quand j'étais au lycée, la mère de ma petite amie m'a fait découvrir Red Hat Linux.
00:01:23Elle suivait un cours d'informatique dans un collège communautaire et elle
00:01:29m'a juste montré son bureau, qui n'était pas Windows. Ce n'était pas un Mac. J'étais très confus. C'était un bureau KDE tournant sur
00:01:37Red Hat Linux, et j'étais fasciné. J'ai commencé à m'y intéresser dès le lycée, en première année de lycée,
00:01:44puis j'ai eu mon, euh...
00:01:47diplôme en informatique et je me suis beaucoup intéressé à l'infrastructure, aux systèmes d'exploitation et à l'apprentissage des ordinateurs
00:01:55pour faire des choses que nous ne pouvions pas contrôler auparavant. C'était donc le début.
00:02:00Tu as donc toujours été un partisan du logiciel libre, j'imagine, si tu utilises Linux.
00:02:06Oh, à 100 %.
00:02:08Linux est mon système principal
00:02:10depuis plus de deux décennies maintenant, depuis
00:02:122005.
00:02:15D'accord. Oui, et à quel moment as-tu commencé à t'intéresser sérieusement au SRE ?
00:02:20Oui, c'était il y a environ 10 ans. Avant cela, j'étais un professionnel des opérations classique dans une entreprise SaaS en forte croissance
00:02:29appelée Acquia. Si vous avez déjà entendu parler de Drupal, le fondateur du projet open source Drupal
00:02:34a fondé une entreprise qui fournissait les services professionnels, l'hébergement et le support pour les sites web Drupal.
00:02:38J'étais donc dans leur équipe des opérations, mais à mesure que l'entreprise grandissait — et c'était une croissance fulgurante —
00:02:45beaucoup, beaucoup de grands clients dont vous reconnaîtriez les noms, cette échelle a entraîné énormément de tâches manuelles répétitives. Voilà !
00:02:51Maintenant, on parle de SRE. Il y avait beaucoup de travail manuel fastidieux. Il y avait beaucoup d'incidents.
00:02:55Nous commençions à nous heurter à la réalité d'un fonctionnement à grande échelle par rapport à l'architecture initiale
00:03:01avec laquelle nous avions commencé et aux processus que nous avions mis en place. J'ai donc commencé à lire The Phoenix Project, je me suis mis
00:03:09à la pratique de l'administration système cloud, qui était le premier livre sur le SRE.
00:03:12Ce n'était pas le livre de Google sur le SRE, le SRE y occupait quelques pages et contenait 12 pratiques.
00:03:17Encore une fois, j'étais très, très intrigué et j'ai commencé à le pratiquer.
00:03:21Et je ne sais pas vraiment ce qu'est The Phoenix Project. Oh, mon Dieu !
00:03:26Oui, oui. The Phoenix Project était en quelque sorte le livre original sur le DevOps,
00:03:31et c'est un très bon livre.
00:03:34Oui, c'est une histoire et ça parle de
00:03:39l'informatique et du directeur des opérations informatiques qui doit faire face à des problèmes organisationnels importants
00:03:45et qui, grâce aux conseils d'un mentor mystérieux dont on découvre plus tard qu'il est membre du conseil d'administration de l'entreprise,
00:03:53lui enseigne
00:03:55des concepts
00:03:56de fabrication d'usine de la vieille école et comment ils s'appliquent directement à l'ingénierie logicielle et aux opérations informatiques.
00:04:05Cela a introduit de nombreux concepts que j'utilise encore aujourd'hui et dont je parle aux clients aujourd'hui parce qu'ils sont extrêmement pertinents.
00:04:11Donc oui, c'était le livre original, mais au-delà
00:04:13de ça, j'ai lu tout un tas de choses, notamment dans le monde du management.
00:04:18Ainsi, en plus de tout ce que je lisais sur le plan technique pour progresser en tant que SRE et ingénieur logiciel,
00:04:24il y a aussi la gestion, car le DevOps et le SRE sont une pratique sociotechnique.
00:04:29Vous comblez le fossé entre ce que la technologie peut faire et la façon dont les humains l'utilisent pour obtenir de bons résultats commerciaux.
00:04:36Et j'imagine qu'il y a beaucoup d'erreurs humaines impliquées là-dedans et à gérer, n'est-ce pas ?
00:04:42Je veux dire, oui, absolument. D'ailleurs, il y a un livre sur l'erreur humaine que tu devrais probablement lire aussi.
00:04:50Oui, il y a un monsieur — son nom m'échappe malencontreusement en ce moment — mais c'est un
00:04:57professeur à Sydney, en Australie, et tout ce dont il parle, c'est des accidents d'avion et de l'importance de l'erreur humaine.
00:05:05C'est très utile dans la culture des post-mortems : l'erreur humaine n'est pas là où l'on s'arrête.
00:05:10Si vous dites : « Oh, oui, la raison pour laquelle nous avons eu cet incident de production, c'est l'erreur humaine »,
00:05:16non, c'est le début de la discussion, ce n'est pas la fin. Quels facteurs ont contribué à
00:05:21ce que cette personne, à cet endroit, tape de travers une commande et réduise à néant la base de données de production ?
00:05:27Devait-elle avoir accès à la base de données de production ? Les outils étaient-ils ergonomiques ? A-t-elle dormi la nuit dernière ?
00:05:34À quelle fréquence a-t-elle été bipée ? Vous voyez, il y a toutes sortes de choses.
00:05:38Mais oui, quand les gens disent « erreur humaine », je m'identifie immédiatement à ce livre. Il faudra que je te donne un lien pour les notes de l'épisode.
00:05:45Oui, je crois me souvenir de ma première
00:05:49introduction aux tests de bout en bout. J'écoutais un cours où quelqu'un parlait
00:05:54d'un incident où un logiciel avait été développé pour
00:05:58des chirurgiens et où il fallait cliquer sur les boutons dans un certain ordre,
00:06:03mais les chirurgiens s'étaient tellement habitués à cliquer qu'ils cliquaient
00:06:07si vite que le logiciel a commencé à buguer, et personne n'avait prévu que cela puisse arriver.
00:06:13C'est donc assez intéressant.
00:06:15Oui, vraiment, l'intersection entre les humains et l'automatisation est quelque chose auquel nous devons toujours prêter attention dans les produits que nous exploitons.
00:06:25Oui.
00:06:26Et j'ai aussi entendu dire que tu avais commencé
00:06:28le DevOps et le SRE à l'époque des bipeurs, où tu devais utiliser des pagers. C'est exact ?
00:06:35Oui, en fait, oui, la première fois que j'ai été d'astreinte, on m'a remis un
00:06:42pager physique. Et c'était... Oh, waouh ! C'était quelle année ?
00:06:46C'était en 2005.
00:06:48Oh, waouh ! D'accord. Donc mon premier travail dans la tech... oh, c'est génial.
00:06:55Je travaillais dans un garage, comme toute startup à succès le fait, à Plant City, en Floride.
00:07:02Un bon ami à moi...
00:07:04son père avait une activité secondaire : il gérait l'hébergement web, l'hébergement d'e-mails et un FAI par numérotation depuis son garage.
00:07:12Il s'appelle Curtis Fellaini — j'ai un respect infini pour lui — et il...
00:07:18Il m'a tout appris. Mais oui, on utilisait cet outil d'astreinte appelé What's Up Gold.
00:07:24Et tout ce qu'il faisait — je connais ce nom ! — et ce qu'il faisait, ce n'était pas des vérifications HTTP,
00:07:33c'était des pings ICMP vers les serveurs. Juste un ping de la vieille école, et s'il n'obtenait pas de réponse,
00:07:40il envoyait
00:07:42un message. Et j'avais un pager, j'ai porté un pager pendant un petit moment quand je travaillais là-bas.
00:07:48Immédiatement après, quand je travaillais dans mon alma mater pour le calcul haute performance (HPC), c'était Nagios
00:07:54et, tu sais, des SMS sur ton téléphone portable.
00:07:57Est-ce que c'était un choix délibéré, ou à cette époque, de nouvelles technologies comme les SMS étaient-elles déjà apparues, comme tu l'as dit ?
00:08:07Je veux dire, oui, à cette époque, il y avait simplement plus d'outils.
00:08:11Certes limités, mais il y avait plus d'outils disponibles pour surveiller
00:08:15l'infrastructure à l'époque. Et quand j'étais au département HPC de l'Université de South Florida,
00:08:22on gérait déjà des centaines de serveurs, parce que c'est du HPC,
00:08:27c'est-à-dire des racks de serveurs qui effectuent des tâches de calcul. On avait donc besoin
00:08:31un peu plus que
00:08:34d'un simple pager. Le contenu du message sur le pager importait aussi, car si tu recevais
00:08:40juste un message du genre « Oh, d'accord, je dois aller voir ce que c'est avec le bipeur »,
00:08:45avec Nagios, tu avais au moins un peu de contexte, comme quoi ce serveur
00:08:50est hors service ou que ce service associé à ce serveur est en panne. Donc même alors,
00:08:56à cette époque, tu avais une certaine sophistication pour pouvoir configurer,
00:09:01tu sais,
00:09:03ce que tu voulais surveiller par hôte ou par service.
00:09:06C'était vraiment bien avant les SLO, on ne pensait même pas à ça.
00:09:13On se demandait juste : « Est-ce que ce port est ouvert et est-ce qu'il me renvoie la réponse attendue ? »
00:09:17Oui, waouh, 2005, je crois que j'étais au collège à cette époque. Je ne pensais même pas à l'informatique
00:09:26à l'époque.
00:09:28Oui, ça ne se voit pas, mais je suis plus vieux que je n'en ai l'air. Oui, je m'en rends compte. Eh bien, tu te portes très bien. Merci beaucoup !
00:09:30Alors oui, en faisant un peu de recherches, il semble que tu aies travaillé chez Meta. Qu'est-ce que tu y faisais
00:09:37et c'était comment de travailler chez Meta ?
00:09:43Oh, mon Dieu ! J'étais ingénieur de production
00:09:45Oh la la. Euh, j'étais ingénieur de production
00:09:48et responsable de l'ingénierie de production, donc
00:09:52ce que ça veut dire en gros, c'est leur version du SRE, et j'ai travaillé sur deux projets. Le premier, pendant quelques mois,
00:10:00j'ai travaillé dans une équipe appelée Conveyor. Il y a d'ailleurs des articles publiés, je crois pour l'IEEE, sur
00:10:06Conveyor. Conveyor est probablement l'un des plus grands systèmes de CI/CD de la planète.
00:10:11Tous les artefacts de build générés pour les services backend chez Meta
00:10:18passent par Conveyor, avec un déploiement progressif de toutes les modifications sur des milliers et des milliers de services backend.
00:10:25C'est strictement interne à Meta ?
00:10:29En interne seulement, ouais.
00:10:31Mais oui, il y a un article de Boris Gubrick que vous devriez aller lire
00:10:37sur ce qu'ils ont construit, et c'est très, très intéressant.
00:10:39J'y ai donc passé quelques mois pendant qu'ils le mettaient à l'échelle
00:10:43et que je les aidais avec leurs alertes, parce qu'au début,
00:10:46c'est comme partout, on reçoit des centaines d'alertes par semaine et je me disais :
00:10:49« Attendez, faisons le ménage »
00:10:51et remettons leur observabilité à niveau pour qu'au moins ils sachent quand des pannes se produisaient. J'ai aussi
00:10:58mis en place
00:11:00comment dire, des procédures d'urgence pour couper des fonctionnalités clés grâce à leur outil de feature flagging,
00:11:06histoire de s'assurer qu'on pouvait récupérer rapidement suite à des incidents.
00:11:10J'ai fait ça pendant quelques mois, mais le plus clair de mon temps a été passé
00:11:13sur une autre équipe qui
00:11:16était en gros un Heroku interne. On a donc des services stateless très simples,
00:11:23et les équipes en sortent sans arrêt, il faut bien les exécuter quelque part, et cette
00:11:29équipe et ce service existaient pour simplifier ce processus, car par le passé, mettre en place un service était très difficile. J'ai donc été le premier
00:11:37ingénieur de production
00:11:40dans cette équipe, et c'était assez fou. Mais c'est ce que j'ai fait là-bas.
00:11:44C'était vraiment très amusant. Les gens avec qui je travaillais
00:11:48avaient des cerveaux cinq fois
00:11:51plus gros que le mien, vous savez. Les gens avec qui on travaille dans ce genre d'entreprise sont tout simplement
00:11:55hyper brillants et j'ai énormément appris là-bas. Je voulais dire, je crois qu'il y a une entreprise appelée Honeycomb et
00:12:02la personne qui l'a fondée, Charity Majors, était chez Meta ?
00:12:06Tu la connais ? Tu l'as rencontrée ?
00:12:09Euh, c'est très, très intéressant
00:12:12que tu demandes ça. Je l'ai rencontrée lors d'un événement Observability Days il y a un an et demi à Boston, je l'ai rencontrée en personne.
00:12:20Oui, elle a bien travaillé chez Meta,
00:12:22et l'inspiration pour Honeycomb vient d'un
00:12:26outil d'observabilité à l'échelle planétaire appelé Scuba.
00:12:30Voilà, donc j'ai utilisé Scuba et j'ai vraiment adoré, et je suis ravi qu'elle
00:12:37fonde une entreprise pour faire ça. On a discuté un peu sur LinkedIn de temps en temps ces derniers temps
00:12:44en raison de notre intérêt commun pour
00:12:47la façon dont le codage assisté par agent va influencer la fiabilité.
00:12:51Donc on a discuté de ce sujet de temps à autre.
00:12:54Mais oui, c'est quelqu'un de vraiment chouette et c'est un privilège de discuter avec elle de temps en temps.
00:12:59Oui, oui, alors en fait c'est une excellente transition pour ce qu'on voulait aussi te demander. Où est-ce que tu penses que l'IA
00:13:06va mener le SRE, le DevOps et toutes ces pratiques ?
00:13:13Oh la la, d'accord. Eh bien, superbe publicité, merci beaucoup. Je vais entrer directement dans le vif du sujet.
00:13:19Nous avons des ingénieurs logiciels qui ont reçu
00:13:24un outil formidable : le développement par agents. Tout le monde fait générer du code par magie à la volée, avec des outils comme Claude et compagnie.
00:13:35Ce que ça signifie, c'est qu'il va y avoir un volume de code décuplé
00:13:39qui va circuler dans notre
00:13:42chaîne de valeur, nos pipelines CI/CD, nos tests, nos revues, nos déploiements de code, notre gestion des incidents, nos procédures de gestion des changements... En gros,
00:13:50tout ce code va passer par le système que chacun d'entre nous a bâti pour son entreprise.
00:13:56Et cela signifie qu'on va soumettre à rude épreuve
00:13:58toutes ces capacités. Par exemple,
00:14:01il y a une relation
00:14:04linéaire
00:14:06entre le nombre de modifications que l'on peut apporter à un logiciel et le nombre de pages ou d'incidents reçus.
00:14:12C'est un fait établi.
00:14:14Donc,
00:14:15il est raisonnable de supposer que si l'on multiplie par 10 le flux de code à travers notre pipeline,
00:14:20on aura 10 fois plus d'alertes.
00:14:23Alors comment
00:14:26votre organisation va-t-elle réagir à cela ? C'est vraiment ça la question. Du côté SRE, je prévois
00:14:32qu'à l'avenir, nous, les gens des opérations, allons être très euh...
00:14:39très populaires, parce que nous serons là où se situe le goulet d'étranglement.
00:14:42Il ne s'agit plus seulement d'écrire du code et de le déployer. Il s'agit maintenant de savoir comment l'exploiter.
00:14:49Est-ce que ça marche ? Est-ce que ça répond aux attentes des clients ?
00:14:51Euh...
00:14:53et
00:14:55et donc je m'attends à ce que ce soit le changement majeur
00:14:58C'est un c'est un énorme défi car beaucoup de choses peuvent mal tourner pendant cette transition
00:15:04Vous pouvez, comme je l'ai mentionné, avoir beaucoup plus d'incidents. Comment apprenez-vous de vos échecs et
00:15:09Vous savez, continuez-vous à faire des post-mortems ? Construisez-vous un pipeline CI/CD qui fonctionne réellement, vous savez, et
00:15:15qui permet en gros de s'assurer que l'effort humain a toujours un impact maximal
00:15:20Le plus drôle, c'est qu'on se prépare à cet événement depuis des décennies. Sauf que, vous savez,
00:15:27on a tendance à y penser du point de vue de la tech où l'on compte 20 000 ingénieurs,
00:15:31mais
00:15:33désormais, de plus petites organisations peuvent produire 10 fois plus de code et le flux reste le même.
00:15:38Donc tous ces principes fondamentaux
00:15:40que ces grandes entreprises évoquent et dont elles parlent depuis dix ans maintenant,
00:15:47nous allons tous devoir les appliquer.
00:15:49Genre, tous les fondamentaux, il faut vraiment les mettre en pratique. Et donc voilà,
00:15:53il y a aussi la question de
00:15:56la manière dont les organisations – les structures de développement logiciel – se sont organisées autour de l'idée que le codage prend le plus clair du temps,
00:16:03que c'est la plus grande perte de temps.
00:16:05Il faut donc s'assurer que les ingénieurs codent le plus possible. Si c'est faux,
00:16:09nous devons nous réorganiser autour des activités qui prennent désormais le plus de temps.
00:16:15Il va donc y avoir un changement dans notre façon de gérer ces organisations, et enfin,
00:16:20et je pense que vous l'avez vu avec la tendance de l'SRE par l'IA,
00:16:23dont j'ai souvent parlé sur mon podcast, nous allons devoir introduire habilement
00:16:31cette technologie là où c'est approprié pour en tirer un grand profit dans nos opérations, n'est-ce pas ?
00:16:37Parce que, par exemple, il y a des entreprises, et je pense à incident.io, vous êtes bipé
00:16:44et avant même que vous ne sortiez du lit,
00:16:47vous savez, il y a déjà un flux de travail d'agent qui se dit : « Ok, quels changements ont été faits récemment dans le code ?
00:16:53Que disent vraiment les alertes ? Que disent réellement les métriques ? » et essaie de
00:16:59faire un premier diagnostic avant même que vous soyez sorti du lit et que vous ayez ouvert les yeux
00:17:04Il y a donc certains aspects de nos responsabilités opérationnelles qui peuvent
00:17:09bénéficier grandement de l'IA, mais il ne s'agit pas d'adopter tout en bloc.
00:17:12Il faut réfléchir aux vrais problèmes et au retour sur investissement.
00:17:16Mais bref, c'est ma thèse. Je fais d'ailleurs un webinaire dans quelques semaines sur ce sujet précis.
00:17:23C'est tellement intéressant parce que, le cas d'usage que vous avez mentionné juste avant,
00:17:29sortir du lit alors qu'on vous alerte déjà pour un problème,
00:17:32est-ce que cela a déjà été mis en pratique ?
00:17:36Car un problème potentiel que je vois, c'est que, disons qu'on a des niveaux de triage où le premier niveau,
00:17:43l'IA peut peut-être le résoudre seule. Mais pour le second, il faut un humain dans la boucle. Et parfois, ce que je
00:17:51– pour faire une comparaison avec le codage – parfois je vois Claude Code raisonner en se disant :
00:17:56« Je devrais faire ça » et puis pouf : « Attends une seconde,
00:17:59non,
00:17:59je devrais probablement tout effacer, recommencer et faire ça. »
00:18:02Et j'ai l'impression que la même chose pourrait se produire avec ces bots de gestion d'incidents qui se disent : « Oh, c'est facile à réparer,
00:18:10attends, je peux peut-être régler ça tout seul », ce genre de situation.
00:18:13Non, vous avez 100 % raison.
00:18:15Je crois que cette citation d'IBM datant des années 1970 circule beaucoup en ce moment : ne confiez jamais une décision de gestion à un ordinateur.
00:18:22Ce que je veux dire, c'est qu'il y a deux façons d'utiliser
00:18:27cette
00:18:29ia ou l'automatisation en général. Il y a deux philosophies de l'automatisation
00:18:32dont les gens ont parlé. La première est appelée le principe des restes, où l'on se dit : « D'accord, on va confier au logiciel
00:18:38– pas forcément de l'IA, ça peut juste être des outils – le soin de faire tout ça
00:18:43de manière autonome pour nous, sans qu'on ait à y penser.
00:18:46Et nous, les humains, héritons de ce qui reste, c'est-à-dire généralement les problèmes qu'il faut un doctorat pour résoudre. »
00:18:51Euh,
00:18:53déjà,
00:18:54ce n'est pas très maniable, car vous dépensez tout votre budget en docteurs,
00:18:57et vous faites trop confiance à un système qui tourne en autonomie, et s'il fait le mauvais choix, vous êtes dans le pétrin.
00:19:04La plus
00:19:07pratique est ce qu'on appelle le principe compensatoire : il s'agit de démultiplier l'effort humain,
00:19:15de permettre aux ordinateurs et à l'automatisation de faire ce qu'ils font bien, et de laisser aux humains ce que les humains font bien,
00:19:22c'est-à-dire
00:19:25que
00:19:26Nous comprenons le contexte de nos systèmes. Nous comprenons le problème que nous essayons de résoudre, nous comprenons, vous savez, l'expérience client.
00:19:33Il y a énormément de contexte dans notre cerveau qui rend les choses beaucoup...
00:19:38plus avantageux pour nous de l'utiliser plutôt que de laisser l'IA tout faire. Donc pour répondre à votre question plus directement,
00:19:44je pense que cette réorganisation par l'IA ne devrait vraiment pas
00:19:50modifier la production à moins de s'inscrire dans une démarche bien encadrée et bien définie.
00:19:58Je vais vous donner un exemple : les retours de code automatiques. Nous le faisons automatiquement sans IA si vous pensez à Kubernetes,
00:20:06n'est-ce pas ? Si vous avez un déploiement et que vous modifiez, vous savez, la version de votre nouvelle image de conteneur et que vos
00:20:13contrôles de disponibilité échouent. Devinez quoi ?
00:20:16Le changement ne sera pas déployé.
00:20:19Voilà. Ces mécanismes sont très simples, faciles à appréhender, et nous permettent d'effectuer des changements en toute sécurité.
00:20:26Vous savez, ce type de problèmes bien définis, je pense qu'on peut laisser l'automatisation s'en charger, et elle le fait déjà,
00:20:32mais confier
00:20:35à l'IA le soin de dire simplement “oui, nous devrions apporter cette modification à notre infrastructure” sans intervention humaine,
00:20:41je trouve cela irresponsable. Je pense que nous, les humains, pour en revenir aux contraintes,
00:20:46allons devoir consacrer notre temps à nous demander :
00:20:49est-ce vraiment la bonne décision à prendre ?
00:20:52Vous savez, valider ces approbations, faire de la revue de code et examiner le moindre changement d'infrastructure,
00:20:59ce sera là, je pense, que
00:21:00nous allons concentrer nos efforts.
00:21:03Et oui, nous voudrons automatiser cela dès que possible, mais cela exige de la discipline et un historique irréprochable en matière de sécurité.
00:21:09Oui, et une autre question qui découle de ce que vous disiez tout à l'heure concerne cette comparaison linéaire : plus vous avez de code,
00:21:19plus vous risquez d'avoir d'incidents. Vous travaillez comme consultant
00:21:22dans ce domaine. Avez-vous entendu dire que les entreprises font face à cette situation en ce moment, du fait
00:21:28qu'elles
00:21:30délèguent
00:21:31ou confient davantage de code à l'IA et subissent plus d'incidents en conséquence ?
00:21:36Absolument, tout à fait.
00:21:39Tout à fait, et j'ajouterais même que d'autres types de pannes commencent à apparaître en raison
00:21:47de
00:21:49ce changement. Un exemple très simple à comprendre et à analyser,
00:21:53c'est
00:21:54l'engorgement de vos pipelines CI/CD : le délai entre la création d'un livrable et son déploiement en production s'allonge de plus en plus
00:22:00parce qu'il y a tout simplement plus de modifications qui y transitent. Oui, les organisations commencent donc à
00:22:05ressentir ces difficultés dès à présent. Pour vous donner un exemple rapide, une étude de cas : j'ai
00:22:12un client pour lequel j'ai récemment réalisé un audit, car l'une de mes activités consiste à examiner
00:22:17la posture opérationnelle globale d'une entreprise, sa façon de livrer le code, de l'exécuter, et de lui conseiller la marche à suivre.
00:22:24L'une des équipes s'est dit : « Super, ce truc de Claude est génial, mettons-nous à pondre des fonctionnalités. »
00:22:31Et ils l'ont fait, mais
00:22:33ils n'ont pas modifié leur façon de publier, ils n'avaient pas de processus de revue de code solide
00:22:38et, par conséquent, le nombre d'incidents a immédiatement explosé. Au lieu
00:22:43de se concentrer sur le code et de livrer tout ce qu'ils pensaient pouvoir faire, ils se sont retrouvés submergés par les réclamations clients
00:22:49et les incidents.
00:22:51Donc oui, ce n'est pas théorique, ça se produit en ce moment même.
00:22:55Cette augmentation exponentielle du volume de modifications en production va
00:23:01mettre en lumière
00:23:03tous les maillons faibles de votre posture opérationnelle.
00:23:06Et lorsque l'on est en quelque sorte un
00:23:09médecin SRE qui a ce genre de client confronté à ce problème, que conseillez-vous de faire dans cette situation ?
00:23:16Comme vous venez de le mentionner,
00:23:18exactement. J'y ai fait allusion plus tôt : tous ces principes fondamentaux dont nous avons parlé
00:23:24au cours de la dernière ou des deux dernières décennies, nous devons nous y concentrer.
00:23:27Par exemple,
00:23:29les équipes ont besoin d'une stratégie de test valide.
00:23:35Elles doivent savoir que le code qu'elles s'apprêtent à envoyer en production est de haute qualité.
00:23:39Pour tout ce qu'elles ont appris par le passé, je suis un grand partisan des objectifs de niveau de service,
00:23:43je suis un grand partisan des SLO.
00:23:47Parce que cela nous permet de comprendre la santé de notre système de production du point de vue du client,
00:23:52ce qui
00:23:54constitue un élément clé du puzzle, car cela vous permet de réguler, sur la base de données, le volume de changements
00:23:59que vous effectuez en production en termes de demandes de fonctionnalités et autres. De cette façon,
00:24:03vous ne mettez pas en péril votre source de revenus actuelle
00:24:07tout en en cherchant de nouvelles.
00:24:10C'est la raison commerciale pour laquelle on veut des SLO. Une chose que j'ai remarquée avec les SLO dans la précédente entreprise où je travaillais,
00:24:16c'est qu'on se disait :
00:24:19chaque équipe doit respecter ses objectifs de SLO. Et pour certaines équipes, comme nous avancions très vite,
00:24:25nous n'atteignions pas ces objectifs.
00:24:28Beaucoup d'équipes avaient du retard,
00:24:30et la direction a tranché : peu importe, il est plus important de livrer des fonctionnalités que de respecter les objectifs de SLO.
00:24:36Certes.
00:24:37Et c'est probablement la raison principale pour laquelle les SLO n'ont pas été aussi efficaces que Google l'avait promis il y a dix ans.
00:24:44Car voici le problème — et j'en ai déjà parlé dans d'autres contextes — vous pouvez mettre en place un programme de SLO,
00:24:49vous pouvez demander à des ingénieurs de se réunir dans un coin pour identifier le parcours utilisateur,
00:24:55le quantifier, configurer de l'observabilité
00:24:57avec Prometheus ou OpenTelemetry, et obtenir de très jolis tableaux de bord.
00:25:01Mais si le chef de produit,
00:25:05si l'organisation produit ne veut pas jouer le jeu,
00:25:07si l'équipe de direction ne veut pas jouer le jeu,
00:25:09alors
00:25:12c'est une perte de temps.
00:25:14Vous vous retrouvez simplement avec des SRE et peut-être des ingénieurs qui travaillent dans leur coin en disant « attention, ça ne va pas », mais
00:25:19pendant ce temps,
00:25:21la direction veut continuer à livrer. Pour qu'un SLO fonctionne,
00:25:26il faut que ce soit un jeu collectif. Et lorsque j'évalue
00:25:32la posture SLO des organisations — ce que je fais beaucoup — je pose généralement cette question : si un budget d'erreur est épuisé,
00:25:38que fait le chef de produit ?
00:25:41Si le chef de produit répond : « D'accord, au prochain sprint, nous modifions le périmètre »,
00:25:46c'est bien,
00:25:48vous avez une maturité moyenne. S'il ne le fait pas,
00:25:50votre maturité est faible. J'ai d'ailleurs développé un modèle de maturité des SLO, de un à cinq (un étant immature, cinq étant l'optimisation), pour aider
00:25:58les entreprises à situer où elles en sont. Mais vous avez raison, de nombreuses organisations ne font pas
00:26:03de vrais SLO. Elles ont un tableau de bord, des métriques dessus, les ingénieurs sont payés pour ça,
00:26:08mais
00:26:10les décisions commerciales ne s'appuient pas sur les SLO.
00:26:12Cela sert juste à envoyer des alertes.
00:26:16Et donc, les types de clients qui font appel à vous, dans quelle
00:26:21situation se trouvent-ils lorsqu'ils
00:26:24ont besoin de votre aide ? Sont-ils dans une bonne, une mauvaise situation, ou entre les deux ?
00:26:28Cela dépend. J'interviens généralement auprès de mes clients à deux moments clés. Le premier point de bascule, c'est
00:26:37l'entreprise en phase de démarrage qui vient de lever des fonds, son équipe commerciale cartonne, l'adéquation produit-marché est là,
00:26:44mais elle manque d'expérience et n'a jamais géré d'infrastructure de niveau entreprise auparavant.
00:26:49Elle n'a jamais vendu à des clients grands comptes et commence à plier
00:26:53sous la pression de cette échelle accrue — c'est exactement ce que j'ai vécu au début de ma carrière.
00:26:59C'est un domaine que je connais très bien pour l'avoir vécu. C'est le premier point de bascule.
00:27:04Et c'est un moment passionnant, c'est plutôt un bon problème à avoir, même si cela peut être stressant pour les équipes sur place.
00:27:09Le deuxième point de bascule,
00:27:12c'est généralement lorsque vous êtes une plus grande structure et que vous devez standardiser
00:27:17vos modes opératoires entre plusieurs équipes.
00:27:21Peut-être avez-vous un programme SRE et devez-vous évaluer son efficacité, voir si les processus fonctionnent,
00:27:28si le modèle d'engagement est adapté, si les équipes d'ingénierie et le produit participent activement au processus.
00:27:34Les entreprises qui réalisent beaucoup d'acquisitions
00:27:37font généralement appel à moi parce qu'elles essaient de dompter cette bête sauvage : à chaque acquisition,
00:27:44c'est toute une nouvelle pile technologique qu'il faut intégrer. Il y a donc un niveau élevé de gouvernance à mettre en place
00:27:50pour s'assurer que tout le monde respecte les mêmes règles.
00:27:55Bien sûr.
00:27:57Et je pense qu'avec les petites entreprises, celles qui ont levé des fonds par exemple,
00:28:02l'utilisation de l'IA pour concevoir des fonctionnalités
00:28:06va aggraver le manque de structure, car les gens construisent et déploient des fonctionnalités avec l'IA
00:28:13sans se soucier des journaux, des métriques, des traces ni de rien de tout cela.
00:28:16Quels sont les problèmes les plus marquants que rencontrent ces jeunes entreprises et qui vous sautent aux yeux,
00:28:23alors qu'elles-mêmes ne les perçoivent pas comme tels ?
00:28:27Oui, j'y ai fait allusion dans une réponse précédente, mais je vais le formuler de manière globale.
00:28:34donc
00:28:36le problème flagrant que je constate, c'est une boucle de rétroaction brisée entre ce qui se passe en production
00:28:41et ce que vit le client, ainsi qu'en matière de priorisation des produits.
00:28:46Et je le constate depuis longtemps dans de nombreuses équipes. C'est probablement le problème le plus courant.
00:28:55Alors, lorsque je travaille comme consultant,
00:28:58l'une des choses auxquelles je pense en coulisses est : comment m'assurer que cette boucle de rétroaction est bien établie ?
00:29:03C'est incroyable
00:29:05de voir combien d'entreprises connaissent un incident,
00:29:08font fâcher leurs clients,
00:29:10reçoivent des tickets au support et se retrouvent submergées.
00:29:13Le support possède ce cadeau extraordinaire à offrir à l'organisation produit et ingénierie, qu'on appelle les retours. Ils savent
00:29:23ce qui met le client en colère, ce qui l'empêche de profiter du service et ce qui pourrait le pousser à partir.
00:29:30Et j'ai vu maintes et maintes fois
00:29:33que ces retours sont complètement ignorés ou relégués au second plan par rapport au travail sur les fonctionnalités,
00:29:41ce qui fait qu'au final,
00:29:44on fonce tête baissée sur les fonctionnalités alors même que le produit est en feu, et ça, pour moi,
00:29:51C'est quelque chose que je remarque immédiatement lorsque j'interroge et évalue des équipes
00:29:55Mais en général, quand on travaille au sein de l'entreprise, on ne le voit pas parce qu'on se dit : je suis ingénieur logiciel,
00:29:59je suis incité à livrer des fonctionnalités. J'ai livré 50 widgets le trimestre dernier, super, je vais avoir ma prime.
00:30:05Les chefs de produit pensent la même chose :
00:30:07oui, on a sorti ces projets, ce client signe avec nous grâce à ça. Pendant ce temps,
00:30:11les clients actuels sont furieux, ils ne sont pas contents de ce qui se passe.
00:30:16D'où une boucle de rétroaction brisée.
00:30:19Et est-ce dû à la culture de San Francisco ou simplement au fait
00:30:22que les gens veulent faire mieux que leurs concurrents ? Je ne sais pas, pourquoi à ton avis ?
00:30:28Je ne pense pas que ce soit propre à San Francisco. Je pense que c'est inhérent aux affaires en général, aux structures d'incitation comme
00:30:36les cultures d'entreprise, parce que
00:30:39quand
00:30:41on
00:30:42a différents départements,
00:30:44ce qui arrive naturellement lorsqu'une entreprise grandit et qu'il faut organiser le travail,
00:30:49les silos se mettent en place.
00:30:51J'ai les ingénieurs logiciels d'un côté, j'ai les chefs de produit de l'autre. Ils sont peut-être intégrés
00:30:55aux équipes d'ingénierie, mais ils ont leurs propres incitations. Et il y a le support, les équipes DevOps et SRE,
00:31:01qui ont leurs propres incitations, mais elles sont toutes séparées et en contradiction.
00:31:06Exact. Et
00:31:09généralement,
00:31:11à ce stade du jeu, personne ne s'est assis avec eux pour leur dire :
00:31:13comment modifier notre structure d'incitation pour que
00:31:18nous allions tous dans la même direction ? L'une des choses qu'a faites Meta
00:31:21et que j'ai beaucoup aimées, et qui selon moi fonctionne très bien,
00:31:25c'est que lorsqu'ils évaluaient les performances d'un ingénieur, du moins dans les équipes avec lesquelles je travaillais,
00:31:31ils ne regardaient pas seulement les fonctionnalités.
00:31:34Ils examinaient l'excellence opérationnelle et de production, ainsi que les incidents auxquels les ingénieurs avaient participé,
00:31:41le travail de fiabilité accompli, le travail d'évolutivité réalisé.
00:31:45Comment avaient-ils rendu le système plus fiable et plus exploitable ? Et cela comptait pour l'obtention de la prime
00:31:51et pour les promotions. C'était une part importante
00:31:54des critères.
00:31:57Donc,
00:31:58lorsqu'ils ont vraiment commencé à miser là-dessus, cela a changé les motivations des ingénieurs logiciels, et dans l'équipe où j'étais,
00:32:05où nous poussions vraiment cela
00:32:07avec les responsables de l'ingénierie avec lesquels je collaborais,
00:32:12ces ingénieurs ont mystérieusement commencé à venir me voir en me disant : hé, j'aimerais participer à des tâches de fiabilité avec toi.
00:32:18Est-ce que je peux reprendre ce processus de test de charge ?
00:32:20Bien sûr, absolument. Voilà les guides d'exécution, voilà quelques scripts, amusez-vous bien.
00:32:25C'est incroyable ce qui se passe quand les incitations changent.
00:32:29Donc,
00:32:31c'est une progression naturelle pour toute organisation. Quand on est une toute petite startup où tout le monde gère tout
00:32:38qu'on essaie de lever des fonds et de décrocher ces premiers clients pour les garder satisfaits,
00:32:43je pense que les incitations sont déjà alignées,
00:32:45sinon l'entreprise ne survivrait pas. Mais à mesure qu'on grandit et qu'intervient cette séparation des rôles,
00:32:51il devient de plus en plus difficile de maintenir une structure d'incitation alignée à l'échelle de l'entreprise.
00:32:55C'est donc là que les aspects sociotechniques entrent en jeu lorsqu'on parle de SRE et de DevOps.
00:33:00Très bien. Et tu as aussi mentionné qu'avec cette course effrénée vers l'IA,
00:33:06les gens auront de plus en plus besoin de profils comme le tien dans ce domaine, et d'un autre côté,
00:33:12on entend dire que le génie logiciel est en train de mourir, qu'il n'y a plus d'emplois, n'est-ce pas ?
00:33:17Alors, penses-tu que pour les développeurs juniors qui écoutent ce podcast,
00:33:23le SRE et le DevOps sont de bons domaines dans lesquels se lancer en ce moment précis ? Oui, et encore oui.
00:33:30Je vais nuancer, et je ne serai pas celui qui prétendra que le génie logiciel est mort.
00:33:36Je pense au contraire que les fondamentaux
00:33:38sont encore plus
00:33:41importants,
00:33:43comprendre les langages de programmation et leur fonctionnement, ainsi que les algorithmes, est encore plus crucial
00:33:50parce que
00:33:53comment sommes-nous censés relire le code généré par une IA ?
00:33:56Et comment concevoir des systèmes qui fonctionnent ? Si on se contente de dire à un modèle LLM : « Hé, conçois-moi ceci »,
00:34:04êtes-vous sûr que ça va marcher ? Disons les choses autrement : ouvrez un projet Claude Code
00:34:08et demandez-lui de concevoir un pont
00:34:11ou un gratte-ciel.
00:34:15Ensuite, je veux que vous preniez ce plan, que vous alliez le construire
00:34:18et que vous vous y asseyiez dedans. Serez-vous rassuré de le faire ?
00:34:22Serez-vous à l'aise pour rouler sur ce pont qu'il a conçu ?
00:34:25Tant que vous continuerez à secouer la tête, nous aurons besoin de ces ingénieurs sur place.
00:34:31Et pour ce qui est des spécialistes SRE et DevOps, oui, évidemment,
00:34:34il faut être plus nombreux, car c'est là que se situe le goulot d'étranglement. Si nous apportons autant de modifications au système,
00:34:39nous devons impérativement veiller à sa santé, comprendre l'impact de ces changements en production
00:34:43et disposer d'un pipeline CI/CD et d'une chaîne de valeur globale
00:34:51qui soit saine, surveillée et traitée comme un service de production. À mes yeux, toutes ces compétences vont devenir encore plus capitales.
00:34:58C'est un peu, pour prendre une image, comme en Formule 1 : vous avez une équipe aux stands
00:35:04qui connaît tout du véhicule, sait remplacer chaque pièce et donne au pilote la capacité de dominer la piste.
00:35:12Vous avez besoin de ces personnes
00:35:15parce qu'elles offrent aux chefs de produit et aux architectes l'environnement nécessaire
00:35:22pour itérer rapidement et déployer ces modifications sans subir de blocages.
00:35:27Donc, selon moi,
00:35:29c'est
00:35:30une excellente période pour être SRE. C'était différent il y a quelques années parce que tout le monde se faisait licencier,
00:35:35mais je pense que
00:35:37si vous vous focalisez vraiment sur les fondamentaux, si vous maîtrisez
00:35:39Linux et les systèmes, ainsi que les aspects sociotechniques, c'est-à-dire ce que signifie réellement être SRE,
00:35:46je pense que vous pouvez aller
00:35:49très loin
00:35:51dans cette carrière. Mais il faut tout de même tenir compte de l'avènement du développement agentique,
00:35:57on ne peut pas faire l'autruche.
00:35:59Tu as mentionné
00:36:02Le Projet Phoenix ? Oui, le livre.
00:36:05Quelles autres ressources trouves-tu précieuses pour quelqu'un qui souhaite approfondir ce sujet ?
00:36:12Oh la la, il y en a des tonnes. Laisse-moi te citer les ouvrages incontournables.
00:36:18Le DevOps Handbook est très bien. J'ai trouvé que lorsque ce livre est sorti,
00:36:21il offrait un excellent résumé de tout ce que j'avais appris avant sa parution. C'est une ressource
00:36:27très complète. Leading Change de John Kotter
00:36:30traite du leadership dans le cadre du changement transformationnel au sein des organisations.
00:36:34Il fournit un cadre de référence, et quand on est SRE dans une équipe ou qu'on essaie de mener une transformation vers la fiabilité,
00:36:41c'est un livre utile à connaître. Le livre Toyota Kata,
00:36:45qui explique comment Toyota pratique l'amélioration continue dans la fabrication de véhicules,
00:36:52est extrêmement utile. L'un des pionniers du système. Oui, je crois que j'en ai entendu parler. Le kaizen,
00:36:59c'était le concept de Toyota.
00:37:02Le miracle économique japonais est à l'origine de l'agilité
00:37:04et du DevOps, c'en était le précurseur. D'autres livres : The Practice of System and Network Administration,
00:37:07Et le DevOps, c'était le précurseur de tout ça, d'autres livres comme The Practice of System and Network Administration
00:37:13que j'ai mentionné, ont peut-être une nouvelle édition, très, très utile.
00:37:17Oui, les livres sur le SRE produits par Google sont bien, mais je vais nuancer.
00:37:22Ce sont des livres écrits par des gens qui travaillent pour des entreprises absolument gigantesques
00:37:27et qui ont un budget infini.
00:37:30Donc les pratiques et les méthodes qu'ils utilisent seront différentes de celles que vous appliquez avec
00:37:35votre startup de quatre personnes, mais je pense que
00:37:37rassembler tous ces éléments vous donnera une vue d'ensemble en tant qu'ingénieur,
00:37:44en tant
00:37:44qu'leader
00:37:46et en tant que stratège sur la façon de mener les initiatives DevOps et SRE.
00:37:49Donc je pense avoir une perspective unique parce que j'ai une vision globale. Je ne me contente pas de
00:37:55faire uniquement du Kubernetes et de le faire fonctionner. J'essaie de faire fonctionner les équipes,
00:37:59et ensuite nous identifions les problèmes techniques pour les résoudre.
00:38:03Et pour tous les auditeurs, nous mettrons les liens des livres mentionnés dans les notes de l'épisode.
00:38:09Euh, je voulais demander, pour en revenir à l'IA, je suis d'accord avec vous sur le fait qu'il faut apprendre les fondamentaux et que
00:38:16l'ingénierie logicielle ou le développement ne vont nulle part, mais il y a une tendance
00:38:21où je vois de plus en plus de gens pousser du code en production sans le relire,
00:38:26et je suis sûr que ce sont des gens sur Twitter ou X, ou simplement
00:38:30des gens qui se vantent et ce n'est pas vraiment vrai.
00:38:32Mais il y a quand même des leaders d'opinion, comme des dirigeants d'entreprises d'IA du type Dario, Musk, qui disent :
00:38:39l'année prochaine en 2027 ou autre,
00:38:41vous pourrez écrire du code et le déployer sans le regarder, ou vous pourrez écrire du code
00:38:47compilé sans même écrire le langage de programmation, le compilateur s'en chargeant, et que les langages seront donc morts. Qu'en pensez-vous ?
00:38:54Je doute fort que ces leaders d'opinion soient d'astreinte,
00:38:58parce que s'ils l'étaient, ils diraient quelque chose de complètement différent.
00:39:02Exactement.
00:39:04Ils ne sont pas, ils ne sont pas dans l'infrastructure. Ce ne sont pas eux qui sont dans l'équipe de sécurité informatique
00:39:08à pleurer
00:39:09à cause des vulnérabilités introduites, et ils ne gèrent pas ce qui se passe quand les clients sont furieux. Bien sûr,
00:39:13les LLM peuvent produire
00:39:16du code syntaxiquement correct et un minimum logique.
00:39:21Est-ce qu'ils écrivent genre 20 ou 30 % ?
00:39:23Peut-être.
00:39:25Peut-être.
00:39:29Mais même dans ce cas,
00:39:31vous aurez toujours besoin d'une surveillance et d'une observabilité adéquates,
00:39:37de tests en production, bon, si vous voulez des tests en production comme le prône Charity,
00:39:42il y a un certain
00:39:45investissement préalable à réaliser, et selon elle,
00:39:48ce sera l'observabilité, comprendre le comportement de votre logiciel. Mais même ainsi, si
00:39:54vous savez,
00:39:56j'étais un gouvernement et que j'avais besoin d'acheter un logiciel,
00:39:59il doit répondre à mes critères de sécurité.
00:40:03Si j'étais une entreprise médicale et que vous écriviez un logiciel littéralement responsable de maintenir des patients en vie,
00:40:09pensez-vous vraiment vouloir qu'un LLM génère cela sans relecture ? Ce serait inadmissible.
00:40:15Cela ramène à l'exemple du pont ou du gratte-ciel. Voulez-vous vraiment qu'un LLM conçoive un pont ou un gratte-ciel
00:40:21et l'expédie directement, qu'on coule le mortier et le béton armé, c'est parti ? Non.
00:40:27Non, absolument pas.
00:40:31Oui, cette analogie du pont et du gratte-ciel est une excellente façon de voir les choses, je n'y avais jamais pensé.
00:40:37Vous savez, si vous étiez un ingénieur
00:40:39parti de zéro, voudriez-vous marcher sur votre propre pont que vous venez de construire ?
00:40:43Oui, et voici ce à quoi nous devons penser : je mentionnais Curtis
00:40:49j'adore ce type au début de cet épisode.
00:40:52C'était un ingénieur diplômé (PE).
00:40:56Un ingénieur professionnel en génie électrique, ce qui signifie qu'il a fait des études,
00:41:02qu'il a passé l'examen professionnel, qu'il a fait un stage dans une entreprise pendant plusieurs années et qu'enfin, après avoir passé un examen difficile,
00:41:09alors et seulement alors, il a pu mener des projets d'ingénierie. Il y a un niveau élevé de discipline
00:41:18dans la façon
00:41:21dont vous faites les choses. Je veux dire, c'est la même chose pour les médecins.
00:41:23Vous apprenez la théorie, mais ensuite vous êtes sur le terrain pendant des années sous supervision avant de pouvoir réellement exercer la médecine.
00:41:30Et il y a une raison à cela, c'est parce que
00:41:33les décisions que nous prenons ont d'immenses répercussions sur la vie des êtres humains, sur l'environnement et
00:41:40Et et dans le monde, euh, et et le logiciel n'a pas tout à fait
00:41:44rattrapé son retard
00:41:47pour l'instant, et je ne dis pas forcément qu'il faut imiter ces modèles, mais
00:41:52nous devons au moins
00:41:54reconnaître les risques que nous introduisons, nous devons avoir la discipline, lorsque nous concevons des choses qui touchent à des vies humaines,
00:42:01d'avoir cette discipline. Nous devons penser aux risques, nous devons penser aux conséquences négatives,
00:42:05nous devons prendre nos responsabilités et je pense
00:42:08qu'il y a beaucoup d'organisations qui ne veulent pas l'entendre parce que cela freine leur capacité à progresser,
00:42:14mais
00:42:16pourquoi écrivons-nous du logiciel ? Nous résolvons des problèmes pour les gens, nous ne devrions pas en créer de nouveaux.
00:42:23Oui, et c'est très intéressant ce que tu disais à propos de ton ami - désolé, j'ai oublié son nom - l'ingénieur diplômé Curtis, parce que Curtis...
00:42:31Oui, parce qu'ici au Canada,
00:42:33il y a eu un débat sur le fait qu'ici, pour porter le titre d'ingénieur, il faut une certification professionnelle.
00:42:40Et puis il y a eu ce débat selon lequel les ingénieurs logiciels ne devraient pas avoir le titre d'ingénieur puisqu'ils n'ont pas obtenu cette certification.
00:42:48Oui.
00:42:51Oui, ça résonne, ça résonne.
00:42:53Oui, le niveau de discipline est tout simplement complètement différent entre notre industrie et la leur.
00:42:57Oui, exactement. Euh, je voulais aborder quelque chose que tu as écrit sur ton
00:43:03profil LinkedIn, tu as mentionné : de l'épuisement et des goulets d'étranglement à des équipes et des systèmes fiables et rapides.
00:43:12Alors, quelle est ton expérience avec l'épuisement professionnel ?
00:43:16Oh la la. J'ai beaucoup d'expérience en matière d'épuisement professionnel.
00:43:21Tu sais, en tant que responsable des opérations dans des organisations à croissance rapide,
00:43:26il y a
00:43:28clairement des gens qui ont des complexes de héros, des gens qui veulent faire leurs preuves, des gens qui ont
00:43:35ces petits mécanismes psychologiques où ils ont l'impression qu'ils doivent
00:43:39intervenir et tout prendre en charge. C'est une vulnérabilité, n'est-ce pas ? Le syndrome de l'imposteur,
00:43:45toutes ces tendances que nous avons tous en tant qu'êtres humains, le besoin de plaire, tout cela peut contribuer au burn-out où tu
00:43:52es tellement motivé à prouver aux autres que tu fais du bon travail que tu n'écoutes pas ton corps,
00:43:59tu n'écoutes pas
00:44:02tes émotions, ton état émotionnel. Tu ne fais pas preuve d'introspection. Tu ne t'accordes pas de temps ni d'espace pour te reposer.
00:44:08Ton rapport au repos est dysfonctionnel, genre, il y a eu une période où je pensais que le repos était une mauvaise chose,
00:44:14que l'oisiveté
00:44:16était du gaspillage, alors que tu sais, en
00:44:20cette saison de ma vie où je réfléchis beaucoup à tout ça, non, le repos
00:44:25te donne la capacité de soulever de lourdes charges plus tard.
00:44:29Tu sais, les gens qui font de la musculation, ils ne sont pas à la salle de sport tous les
00:44:35jours à travailler chaque groupe musculaire, ils se donnent du temps
00:44:40pour reconstruire les fibres de leurs muscles.
00:44:45Alors pourquoi est-ce qu'on
00:44:47se dit
00:44:49qu'on ne peut pas faire ça pour nos esprits ?
00:44:51Donc c'est ça le thème, mais je me rappelle
00:44:55qu'après avoir quitté Meta, j'étais un peu le patient zéro de la gigantesque vague de licenciements.
00:45:01J'ai donc été touché par les licenciements. C'était - désolé pour ça.
00:45:04Oh non, je veux dire, Moto n'existerait pas sans ça. Ok, c'est cool.
00:45:08Renaître de ses cendres comme un phénix, tu vois ? C'était un peu ma réponse à ça,
00:45:13ma réponse à cet événement. Mais cette période où je lance ma propre entreprise
00:45:18et où je prends du recul par rapport à l'industrie pour réfléchir à ma façon de travailler, m'a vraiment poussé à
00:45:23prendre conscience du burn-out que je traînais avec moi sans l'admettre, et euh,
00:45:32tu sais, je me rappelle qu'au début de ma carrière j'étais le sysadmin grincheux, et s'il y a des gens
00:45:38d'Acquia ou d'anciens d'Acquia qui écoutent ceci, vous savez de quoi je parle.
00:45:42J'étais vraiment grincheux,
00:45:44et genre, je suis très jovial aujourd'hui parce que j'ai fait un peu de travail sur moi-même, mais
00:45:49c'était du burn-out et je ne le reconnaissais pas.
00:45:51Je pensais juste que trop de gens venaient me voir pour me faire des demandes
00:45:56alors qu'ils devraient le faire eux-mêmes, genre, lisez la page man, tu vois ce que je veux dire ?
00:45:59J'ai eu affaire à beaucoup de burn-out, et je pense que mon entreprise et la façon dont je la dirige me donnent
00:46:04l'espace
00:46:07nécessaire
00:46:08pour affronter ces défis de front et aborder le travail d'une manière plus saine
00:46:13qui correspond mieux à la façon dont mon cerveau fonctionne, à ce que je veux dans ma vie, et qui garantit que
00:46:20Tu vois, je ne
00:46:23vis pas pour travailler. Je travaille
00:46:25pour vivre des expériences qui m'enrichissent, tu vois ce que je veux dire ?
00:46:28Qu'est-ce que tu en penses ? Je sais que j'ai un peu digressé.
00:46:31Je voulais dire que l'administrateur système
00:46:34grincheux, je vois tout à fait ce que c'est, pas pour moi personnellement, mais dans les entreprises où j'ai bossé, il y a toujours un gars qui
00:46:40sait comment configurer Kubernetes ou qui connaît tout sur AWS, et si tu veux un truc de sa part,
00:46:44il tire la tête, puis il le fait mais sans en avoir envie. Donc je peux comprendre ça,
00:46:49mais oui, je vois pourquoi ça arrive et d'où ça vient, tout simplement parce que ça se produit souvent et
00:46:56je peux comprendre cette frustration.
00:46:59Donc oui, je pense que c'est bien de faire une pause par rapport à ça et de travailler sur soi pour essayer autre chose,
00:47:05c'est sûr. Il y a une part de responsabilité personnelle, mais il faut aussi être très conscient de la culture
00:47:11des environnements dans lesquels on travaille, des équipes, des gens avec qui on interagit,
00:47:15et s'assurer qu'on choisit les endroits qui nous correspondent le mieux. Je sais que le marché du travail est encore un peu bizarre,
00:47:21et qu'il est peut-être difficile de faire
00:47:22ce genre de choix et de dire : “Je vais aller dans une autre structure.”
00:47:26Ça peut être très difficile, j'en suis conscient aussi, mais au moins être conscient
00:47:30de là où l'on est, écouter ses émotions, écouter son corps et agir en conséquence,
00:47:36je pense que c'est une pièce maîtresse du puzzle. Il y a
00:47:39un médecin, le docteur Maslach, qui a conçu l'inventaire du burnout.
00:47:44Elle l'avait initialement créé pour le personnel médical parce qu'elle venait de ce milieu,
00:47:49mais cet inventaire et ses recherches s'appliquent tout à fait au secteur de la tech.
00:47:56Et on peut même,
00:47:58tu vois, regarder certaines de ses conférences. Je crois qu'elle a fait,
00:48:01je crois qu'elle intervenait lors de l'événement DevOps annuel organisé par l'auteur
00:48:06de The Phoenix Project.
00:48:08Donc,
00:48:09oui, j'ai lu un peu de documentation sur l'aspect clinique du burnout en plus de l'avoir vécu personnellement.
00:48:15Oui, et je suis ravi que ce licenciement ait fini par donner quelque de positif pour toi, ça t'a mené
00:48:24à monter ta propre entreprise. Et je trouve ça tellement intéressant, d'après ce que je vois sur tes réseaux,
00:48:31Vous dirigez cette entreprise
00:48:33pratiquement sur la route, n'est-ce pas ? Vous
00:48:35déménagez tout le temps. Vous vivez un peu comme un nomade, c'est bien ça ? C'est tout à fait ça.
00:48:42Je vis de manière nomade, je suis littéralement en train de faire cet appel via Starlink au milieu du désert du Nevada en ce moment,
00:48:50euh, j'ai converti mon pick-up Tacoma...
00:48:54Je l'appelle Molly, j'ai transformé mon pick-up en un
00:48:59véritable poste de commandement mobile. Je me tiens
00:49:02debout dans la benne du camion,
00:49:04euh,
00:49:05et j'ai un espace de couchage confortable, 300 watts de panneaux solaires,
00:49:09un réfrigérateur, vous voyez, un système électrique que j'ai monté moi-même. J'ai donc fait de ce camion
00:49:16un micrologement et je travaille de partout, que ce soit sur mon terrain ici au Nevada ou dans
00:49:23le parking d'un cinéma AMC quelque part à Boston. Je travaille de n'importe où, ce qui est très amusant.
00:49:29Je fais ce genre de choses
00:49:31depuis deux ans et demi. J'ai fondé Shirtomoto il y a trois ans,
00:49:34et je vis en nomade depuis deux ans et demi, et c'est la meilleure expérience, la plus belle aventure de ma vie.
00:49:41Vous savez,
00:49:43alors que je travaillais dans les montagnes, un ours est monté dans mon camion une fois.
00:49:46Oh, waouh !
00:49:48Oui, c'était comment ?
00:49:51C'était un peu effrayant. À l'époque, j'étais dans une tente de toit,
00:49:54pas dans mon super aménagement de camping-car actuel. C'était un ours noir ou un grizzly ?
00:49:58Eh bien, je suis en vie, c'était donc un ours noir. D'accord, très bien.
00:50:02C'était le plus grand ours noir que j'aie jamais vu, il était gigantesque.
00:50:06Il cherchait des paniers de pique-nique ou quelque chose comme ça,
00:50:08mais
00:50:09il a grimpé dans la benne du camion où je dormais en hauteur, sur la galerie avec la tente de toit, et son poids a fait bouger le véhicule.
00:50:17J'ai dû attraper les clés dans ma poche, appuyer sur le bouton de l'alarme
00:50:21et faire retentir l'alarme, ce qui a fait fuir l'ours.
00:50:24Ouais, après ça, j'ai compris la nécessité de construire un abri fermé comme celui-ci. Au moins, l'ours ne peut pas me voir ni entrer.
00:50:30ou d'entrer, alors
00:50:33Tu as mentionné le Nevada et Boston, donc tu as fait un voyage à travers le pays avec ton camion chaque année. Oui, chaque année.
00:50:42Je prévois en fait de retourner dans le Nord-Est d'ici un mois. En ce moment, j'ai une remorque fermée de six pieds sur dix que j'aménage.
00:50:48Genre, après cet appel, je vais percer des trous et installer des fenêtres et des ventilateurs.
00:50:52Et installer un panneau solaire de mille watts, on fait tout le nécessaire et ça va être mon mobile...
00:50:58Mon bureau et poste de commandement mobile où je peux travailler par temps clément.
00:51:02C'est tellement cool. Et pour certains ingénieurs ou des gens qui s'intéressent aussi à ça...
00:51:08Quel est le coût pour construire un tel mobile-home comme tu l'as fait ?
00:51:13Je veux dire, la remorque fermée, c'est plutôt économique, tu peux en trouver une pour quatre à cinq mille, et après...
00:51:20Tout ce que tu dois faire peut faire monter le prix, mais il faut l'isoler,
00:51:24évidemment, il faut un peu de ventilation, un peu d'électricité.
00:51:27Il y a tout un univers de gens qui font ce genre de choses.
00:51:31Euh, je suis juste l'un des rares à avoir combiné la vie nomade et la tech pour que ça fonctionne.
00:51:36Mais le camion, tu sais, c'est un Tacoma avec une tente de toit personnalisée d'une entreprise appelée Go Fast.
00:51:41J'ai pris celui-ci d'occasion, mais euh...
00:51:44Oui, ça dépend vraiment de vos besoins. Je veux dire, je vois des gens s'en sortir très bien dans une Prius,
00:51:51tu sais, et je vois aussi des gens dans des installations plus sophistiquées, mais...
00:51:55Ouais, le coût de départ peut être bas si tu t'y connais un peu en voitures et que tu es prêt à...
00:52:01Tu sais, te retrousser les manches et bosser.
00:52:04Alors, qu'est-ce qui t'a inspiré à commencer cette aventure de...
00:52:07camper, voyager et...
00:52:10customiser ta voiture ?
00:52:11Ouais, euh, eh bien, je n'avais vécu que dans deux endroits avant...
00:52:14ce voyage, et je passais toute ma vie à travailler et à faire fondamentalement ce que les gens me disaient de faire.
00:52:21Ce qu'on attend d'un jeune homme, tu sais, tu vas à la fac, tu obtiens ton diplôme, tu trouves un bon boulot.
00:52:26Tu progresses. J'ai fait ça.
00:52:28Et...
00:52:29Et au bout de ce chemin corporatif, j'ai réalisé : mec, je ne suis pas aussi heureux...
00:52:34que je devrais l'être par rapport à tout ça. J'ai accompli des choses extraordinaires, mais je ne le ressens pas. Et depuis que j'ai monté ma propre entreprise, j'ai réalisé : est-ce que je veux vraiment payer un loyer aussi cher dans la région métropolitaine de Boston ?
00:52:41Si je ne restais pas à Boston, qu'est-ce que je ferais ?
00:52:44Et j'ai trouvé une vidéo YouTube de ce type qui a pris un camion U-Haul...
00:52:51Tu sais, un camion de déménagement.
00:52:53Et il l'a transformé en appartement sur roues, et je me suis dit :
00:52:55Hein ?
00:52:58C'est plutôt cool.
00:53:00Et j'ai commencé à plonger dans ce terrier de lapin YouTube et à découvrir qu'il y a toute une...
00:53:05tu sais, communauté de gens qui vivent comme ça, et j'ai juste...
00:53:08fait des recherches, regardé plein de vidéos sur YouTube, puis j'ai décidé de tout vendre.
00:53:13Je n'ai pas renouvelé le bail de cet appartement.
00:53:16Et j'ai conduit vers l'Ouest dans ma Civic, et quelques mois plus tard, j'ai eu Molly, et j'ai tout installé et...
00:53:22et j'ai commencé. Mais ouais, c'était la prise de conscience que j'avais pas mal...
00:53:28d'expérience de vie à rattraper.
00:53:31Euh, tu sais, j'ai passé trop de temps, ironiquement, sur un podcast tech. J'ai passé trop de temps...
00:53:37sur l'ordinateur et pas assez de temps dehors dans le monde, et j'ai réalisé que j'avais besoin de cette expérience pour m'équilibrer, parce que...
00:53:44je suis plus qu'un simple geek obsédé par le code. Je suis un être humain avec mon propre...
00:53:49mon propre style.
00:53:52J'ai de l'expérience, il faut que j'aille toucher de l'herbe.
00:53:55Je dois toucher de l'herbe, et j'ai touché bien plus que de l'herbe ici-bas : des rochers,
00:53:59tu sais, des montagnes, de l'eau, toutes sortes de choses. Il y a toutes sortes de choses à toucher par ici. Oui, 100%.
00:54:04Tu as donc mentionné ton incident avec l'ours, y a-t-il eu d'autres...
00:54:08aventures intéressantes pendant que tu étais sur la route ?
00:54:12Je veux dire, tellement, tellement ! J'ai fait le col Cinnamon dans le Colorado avec des amis, qui est un chemin tout-terrain, tu sais,
00:54:18un peu technique, un peu difficile. Je suis allé dans le Wyoming, je suis allé à Yellowstone, à Grand Teton.
00:54:24J'ai campé sur des terres publiques près de là où l'on peut voir les ours. Parfois, j'entends...
00:54:30euh, des ânes sauvages là où je suis. J'ai vu des chevaux sauvages il y a quelques jours.
00:54:34Tu peux, tu peux les entendre marcher et tu regardes par la fenêtre de la tente et les voilà. Il y a des chevaux.
00:54:39Euh...
00:54:41Mais ouais, j'ai sillonné le pays bon nombre de fois.
00:54:45Euh...
00:54:47Et euh, ouais, ça a été, ça a été chouette. J'ai une douce moitié qui est prête à...
00:54:51supporter ma folie et on vit des aventures ensemble.
00:54:54hum, et euh, ouais, c'est c'est c'est sympa. Je veux dire, ça pourrait faire un épisode entier sur tous les endroits fous où je suis allé
00:55:01Ah ouais
00:55:03Ça a l'air génial. Il y a probablement un épisode sur ton propre podcast, non ?
00:55:08À ce sujet, tu sais, il devrait y en avoir un parce que d'habitude je... enfin, parce que j'invite un invité et on parle de, tu sais...
00:55:15Du sujet, mais je devrais peut-être en faire un tout seul pour parler de ça.
00:55:20Oui, même tes points de vue et tes leçons sur le burn-out, je pense que ce serait un épisode...
00:55:25Très utile pour beaucoup d'ingénieurs, surtout de nos jours, parce que j'ai l'impression que...
00:55:29On nous a promis que l'IA allait...
00:55:33Nous rendre plus productifs et qu'on devrait travailler moins d'heures alors qu'en réalité, j'ai l'impression que c'est tout le contraire.
00:55:41Parfois, on fait simplement un burn-out à cause de la quantité de travail qu'on attend de nous avec ces nouveaux outils disponibles.
00:55:50Oui, mes points de vue là-dessus seraient probablement considérés comme très subversifs.
00:55:53Et je vais m'en tenir là, on a besoin, on a besoin, on a besoin de plus de travailleurs. Soyons honnêtes.
00:55:58C'est ce que nous sommes. Nous sommes des travailleurs. Nous avons besoin de conditions plus humaines.
00:56:03Totalement.
00:56:06Oui, d'accord.
00:56:08On aime toujours demander à nos invités : As-tu des avis tranchés sur le SRE, le DevOps ?
00:56:14L'IA, tout ce qui touche à la tech. Oui, oui. Très bien, un avis tranché, et je dis ça avec le plus grand...
00:56:22Respect, je ne veux pas faire de gatekeeping de la pratique du SRE.
00:56:26Mais je vais dire ceci : si vous avez un rôle SRE, si vous avez un intulé de poste...
00:56:29Intitulé SRE.
00:56:32Et qu'en ce moment vous êtes dans votre coin à écrire du YAML.
00:56:34Et à vous faire bipper.
00:56:37Je veux que vous vous demandiez vraiment si c'est bien un rôle SRE.
00:56:40Le SRE est une pratique où vous prenez un système peu fiable.
00:56:45Et vous le transformez en un système fiable.
00:56:47Et vous rendez les clients heureux grâce aux SLO.
00:56:50La gestion de la toiture, la planification de la capacité, bref, toutes ces responsabilités opérationnelles de plus haut niveau et l'utilisation du génie logiciel.
00:56:59C'est très, très important. C'est ça la pratique du SRE.
00:57:01Donc le YAML n'est pas un langage de programmation si c'est ce que vous faites la plupart du temps.
00:57:06Je vous encourage, vous savez, à vous aventurer en eaux profondes. C'est génial par ici.
00:57:11Il y a une super communauté, beaucoup de gens qui seront plus qu'heureux de vous enseigner, mais...
00:57:15Assurez-vous de trouver des rôles qui vous stimulent et vous font grandir.
00:57:18Le livre Le Projet Phoenix a popularisé le mot DevOps et depuis, il y a des gens qui sont ingénieurs DevOps et qui font quoi ?
00:57:26Tu as dit comme écrire du YAML et...
00:57:29Épeler Kubernetes et tout ça, et c'est un peu comme si le DevOps...
00:57:33Dont parlait le livre n'est pas quelqu'un qui fait ça. C'est plutôt ce que tu as expliqué, relier deux différents...
00:57:39C'était quoi le mot ? Pas des systèmes mais des disciplines ensemble ?
00:57:43Et je pense que c'est assez courant, comme je l'ai dit, dans le monde de voir « je suis ingénieur DevOps ».
00:57:48« J'apprends le DevOps » et c'est genre, ce n'est pas ça, c'est...
00:57:51Ce que tu as expliqué, c'est difficile maintenant de faire le pont parce que c'est tellement courant que les gens soient ingénieurs DevOps.
00:57:56Ce n'est pas perçu comme ce que tu as expliqué. Mais oui, c'est difficile de faire marche arrière maintenant, n'est-ce pas ?
00:58:02Oui, je veux dire, on parle de sémantique et de noms, donc je vais essayer de nuancer ce que je dis quand je parle de DevOps.
00:58:09Oui, en effet.
00:58:10Nous ne parlons pas d'un ensemble d'outils. Nous ne parlons pas d'une équipe spécifique, tu sais, titre, outil ou équipe, les gens parlent de ça.
00:58:15Tout le temps. Non, ce n'est pas ça, c'est la pratique de joindre...
00:58:19La technologie, les gens, le leadership, les processus afin de pouvoir livrer du logiciel au client d'une manière aussi rapide que possible.
00:58:27Productive et aussi bonne que possible pour l'entreprise, genre pour moi c'est ça le DevOps et le moyen d'y parvenir.
00:58:34C'est le verse.
00:58:35Ce n'est pas seulement Kubernetes, Kubernetes est un morceau du puzzle. Ce n'est pas juste, tu sais, la CI/CD.
00:58:40C'est un morceau du puzzle. Parfois, c'est aussi s'asseoir et écouter les gens. Parfois, il s'agit de construire une vision et une stratégie, parfois.
00:58:47Tu sais, il s'agit d'envoyer vos équipes en jour de repos après qu'elles ont été bipées une fois de trop à 3h du matin.
00:58:52Le DevOps concerne toute cette...
00:58:55Vision holistique plutôt que juste les outils. Les outils sont les outils sont sexy, je comprends, les gens veulent vendre les outils.
00:59:01Mais ce n'est qu'une facette de toute l'expérience. Oui, en parlant d'outils, est-ce que tu as des outils préférés que tu utilises ?
00:59:08Oh la la, d'accord. Euh, laisse-moi, laisse-moi y réfléchir. Oui, je vais, je vais, je vais en proposer un. Alors...
00:59:14Il y a...
00:59:15Il y a eu pas mal d'incidents sur GitHub récemment.
00:59:20Et on a un peu pris l'habitude de se dire : « Hé, j'aimerais que mes processus de build et mes pipelines de test soient... »
00:59:26Hébergés par nous-mêmes. Il y a un outil que vous pouvez exécuter à la place si vous voulez auto-héberger vos trucs.
00:59:32Qui s'appelle Concourse.
00:59:35Et j'aime bien Concourse. Ça vous permet de construire des pipelines très sophistiqués.
00:59:38Pour les tests, le build, la livraison ou quoi que ce soit d'autre en utilisant du YAML, chaque petite section s'exécute dans un conteneur.
00:59:47Mais vous l'auto-hébergez et la raison pour laquelle j'aime vraiment ça.
00:59:50C'est que la communauté open source...
00:59:53Genre la gouvernance est son propre modèle de gouvernance.
00:59:56Il n'appartient pas à une entreprise qui peut, tu sais, changer la licence et le transformer en SaaS.
01:00:01Ce qu'on a vu de nombreuses fois pour d'autres projets. Donc si vous commencez à vous frustrer de...
01:00:06Tu sais...
01:00:09Utiliser le service cloud du jour pour votre CI/CD, allez voir Concourse, utilisez-le, faites-le tourner on-prem.
01:00:16Tu sais, vous reculez peut-être de cinq ou dix ans en termes de philosophie, mais c'est peut-être plus stable. Qui sait ?
01:00:20Cool. Je n'en avais jamais entendu parler. Il va falloir que je regarde ça.
01:00:23Oui, moi aussi.
01:00:26Ouais, c'est du bon matos. Oh, il y a, il y a des entreprises qui l'utilisent vraiment.
01:00:29Euh, et ouais, les amis ne laissent pas leurs amis faire tourner Jenkins, genre c'est fini. Ne faites pas ça, ne faites pas ça.
01:00:35Donc tu dis que Jenkins est mort.
01:00:38Est-ce que j'ai dit ça ?
01:00:41Non, non, non, c'était juste pour le piège.
01:00:44Mais ce que je dis, c'est qu'il y a, il y a d'autres options.
01:00:47Et je ne pense pas que les gens veuillent encore écrire des scripts Groovy. Donc ouais.
01:00:51D'autres choses là-bas ont été une plaie pour moi aussi.
01:00:54Oui, quand je l'ai utilisé.
01:00:57Ouais.
01:00:59Très bien.
01:01:01Est-ce que tu veux promouvoir quelque chose, genre, tu as un podcast. Est-ce qu'il y a autre chose dont tu veux parler avant qu'on conclue ?
01:01:06Bien sûr, faisons ça. Je suis toujours reconnaissant pour ça. Oui.
01:01:09Je suis consultant dans mon entreprise chertomoto. C'est c-e-r-t-o-m-o-d-o.io. Je me spécialise dans l'évaluation...
01:01:18De la posture de fiabilité, DevOps et SRE des entreprises. Si vous vous faites bipper beaucoup.
01:01:22Si vous ne livrez pas souvent, si les clients sont en colère.
01:01:26Vous devriez vraiment caler un moment sur mon calendrier. J'anime aussi un podcast appelé Reliability Rebels.
01:01:31Où j'interviewe des gens qui parlent de...
01:01:33Comment le SRE n'est pas seulement les outils, mais aussi de défier le statu quo.
01:01:38En parlant du sociotechnique, et puis le 24...
01:01:41De février, je fais un webinaire sur...
01:01:45Le...
01:01:47Le tsunami de code de l'IA.
01:01:48Je crois que j'appelle ça le tsunami de code de l'IA. Euh, et je fais des webinaires mensuels pour parler de toutes sortes de sujets intéressants.
01:01:54Donc si ça vous intéresse, allez voir mon site web et vous pourrez tout apprendre sur ces trucs. Merci beaucoup pour l'opportunité de faire cette promo.
01:01:59Pas de soucis. Merci. Je suis partant pour...
01:02:03Pour parler de toutes ces désolé aventures et leçons apprises. Ça a été très amusant de t'avoir.
01:02:09Alors merci à tous d'avoir écouté cet épisode du podcast Better Stack.
01:02:13Abonnez-vous à notre émission où que vous obteniez vos podcasts, Apple, Spotify, YouTube, choisissez votre poison, mais pour l'instant.
01:02:20C'est un au revoir de ma part.
01:02:22C'est un au revoir de ma part.
01:02:25Et un au revoir de ma part.
01:02:33(musique joyeuse)