Transcription

• Speaker #0

  Le stockage objet, c'est le type de stockage. Et S3, c'est une implémentation de ce type de stockage. La génération de ces fichiers-là aussi, des fois il y a des gens encore qui remplissent des Excel à la main, alors qu'on pourrait automatiser le remplissage de ces fichiers-là. Et il y a beaucoup plus d'entreprises qu'on ne le pense qui sont dans le cas où il n'y a pas encore de test et il n'y a même pas un prémice de philosophie DevOps qui est insupplé chez les développeurs.

• Speaker #1

  Bonjour et bienvenue dans un nouvel épisode l'humain à coeur du digital aujourd'hui on va parler DevOps c'est un sujet qu'on entend de plus en plus dans les médias dans les tendances technologiques IT cloud cyber, mais qu'est-ce qui se cache derrière ce terme-là ? Et donc, pour aller plus loin dans la conversation et les échanges, je vous demande d'accueillir Louis. Salut Louis !

• Speaker #0

  Salut Julie !

• Speaker #1

  Ouais, on imagine que les gens, ils vont applaudir derrière. leur écran, leur smartphone, quand ils vont nous voir. Ouh, la star, Louis ! Et donc, Louis, moi, j'ai plein, plein de questions sur la partie DevOps. Donc, la première, assez simple, quand on parle DevOps, de quoi on parle ?

• Speaker #0

  Alors, ce qu'il faut savoir, c'est que le DevOps, c'est aujourd'hui une culture, c'est une philosophie. Ce n'est pas forcément un métier. Et ça, dans l'imaginaire collectif, c'est un peu dur à appréhender. En fait, à la base du métier, ce sont des administrateurs système réseau. en fait, je dirais classique, auquel on a insufflé la philosophie de DevOps. C'est ça la grosse différence. C'est très associé à la méthode E-Till Agile. La philosophie de DevOps, elle s'inscrit dans ce schéma-là, finalement.

• Speaker #1

  Ok.

• Speaker #0

  Voilà.

• Speaker #1

  Alors, c'est quoi ?

• Speaker #0

  Alors, c'est toute une série de méthodes de travail, d'outils qu'on met à disposition, qu'on crée pour des équipes, principalement des équipes de développement, pour les aider à livrer, on appelle ça livrer, des releases d'applications plus vite, de manière autonome. automatisé, sécurisé et surtout scalable et répétable. C'est ça les grands mots du DevOps.

• Speaker #1

  Mais c'est, ok tu dis que c'est une philosophie, mais c'est une philosophie qui se situe entre quoi et quoi ?

• Speaker #0

  Principalement entre les personnes qui vont s'occuper de l'infrastructure sur laquelle va vivre les applications des développeurs et forcément du coup les équipes de développement.

• Speaker #1

  Ok, donc les développeurs logiciels, web, app. Absolument,

• Speaker #0

  c'est ça.

• Speaker #1

  Tu l'as un peu dit, mais qu'est-ce que ça change ? de ce qu'on faisait il y a 10 ans, même 5 ans on va dire, et même ce qui se fait encore des fois dans certains milieux. Qu'est-ce que ça change réellement ?

• Speaker #0

  Alors il faut prendre un peu de recul dans l'histoire du développement et se dire qu'il y a une époque, révolue ou pas, en fonction des équipes, des clients, ça dépend beaucoup, dans lesquelles les développeurs avaient la mainmise totale sur le déploiement de leur application. Il n'y avait pas forcément de tests qui était fait sur le code il n'y avait pas forcément de suivi qui était fait sur les modifications apportées au code, c'est à dire qu'un développeur avait une idée pour ajouter une fonctionnalité, il allait dans le code direct en production sur la machine, il écrivait sa modif et bim c'était parti. Il n'y a pas de test, il n'y a pas de test de ce qu'on appelle les tests de non régression, c'est à dire que quand un développeur pense développer une nouvelle fonctionnalité, il y a moyen qu'il en casse une autre, donc c'est une régression. Et il n'y avait pas forcément tous les aspects de cyber sécurité auquel on est confronté aujourd'hui, il n'y avait en gros pas de contrôle. résumé à pas de contrôle on laissait les clés de l'infrastructure aux équipes de développement dont ce n'était pas le métier leur métier c'est de développer donc il a fallu trouver le bon équilibre entre laisser de l'autonomie aux développeurs sans leur laisser les clés entières de l'infrastructure on

• Speaker #1

  peut dire que avant c'était le développeur qui donnait le périmètre les conditions et tout ça pour que l'ingé de l'infra fasse La virtualisation,

• Speaker #0

  le serveur et tout ça. Oui, c'est un peu l'idée. C'était dans un schéma sans DevOps, sans tout ça, on créait un espace pour le développeur pour qu'il puisse poser son application et il était autonome. Et l'administrateur système qui soutenait... s'occupaient de l'infrastructure et ne regardaient pas du tout ce qui se passait dessus. Vraiment, c'était, tu es responsable de ton application, de sa sécurité, c'est toi qui te débrouilles, il n'y avait pas tout ça. Et forcément, avec les temps qui courent et les changes... au niveau des infrastructures, on demandait de plus en plus aux développeurs d'être administrateurs système. Donc du coup ça leur prend aussi une part de leur temps de travail parce qu'il faut qu'ils s'occupent de tous ces aspects là, ils passent moins de temps à développer donc forcément ça paie un peu moins à la direction. Donc il fallait trouver justement un nouveau métier, une nouvelle méthode de travail qui les rendait plus performants tout en activant toutes les étapes dont on vient de parler.

• Speaker #1

  Et là vous êtes apparus.

• Speaker #0

  Et là on est apparus.

• Speaker #1

  Génial. Justement, tu parlais d'étapes. Est-ce que tu peux tous nous les définir ? C'est quoi travailler en mode DevOps ? Est-ce qu'on peut dire DevOps by design ? Comme on dit cybersécurité by design, c'est-à-dire au début du projet, on prend en compte la cybersécurité. Est-ce que là, c'est la même chose ?

• Speaker #0

  C'est un peu la même chose. Ça ne se dit pas trop DevOps by design. En tout cas, moi, je ne l'ai pas beaucoup entendu. Mais en fait, dans ce qu'on applique vraiment en pratique, c'est ça. C'est du DevOps by Design. piliers, des étapes qu'on a alors quand je dis on, c'est pas nous, c'est la communauté on va dire des étapes qui ont été définies pour expliquer par quelles portes on doit passer pour être compliant au niveau DevOps. Il y a une phase de planification forcément qu'est-ce qu'on va faire sur l'application en cours, qu'est-ce qu'on a prévu de changer il y a forcément la phase de code qui va être la prise par le développeur et à part ces deux phases qui sont prises à 99% par les développeurs tout le reste c'est aux équipes qui font le DevOps de s'en occuper. Et là, on parle de test sur le code. Vérifier, alors c'est des tests qui sont très répétitifs. S'assurer qu'une fonctionnalité basique de l'application, peu importe les itérations qu'on fait dans le code, elle est toujours valable. Les fameux tests de non-régression, on vérifie que tout va bien et qu'on n'a rien cassé. On rajoute, ça c'est une nouveauté. Alors, nouveauté dans le monde de l'informatique, c'est très relatif. On va dire que ça a apparu il n'y a pas très longtemps, c'est qu'on se met en focus sur ce qu'on appelle les tests. test end-to-end. Je ne sais pas si tu sais ce que c'est.

• Speaker #1

  Pas du tout, mais j'ai hâte de savoir.

• Speaker #0

  C'est une étape qu'on a volée aux équipes d'assurance qualité, qui permet de s'assurer qu'un parcours utilisateur sur l'application se déroule bien de A à Z. Par exemple, on va simuler, si on parle d'une application web, on va simuler un utilisateur qui va se connecter sur un portail, qui va naviguer dans des dossiers, qui va cliquer sur des liens, et on attend un retour de ce test-là. Alors, tout se passe en ligne du coup. de commandes de manière automatisée. Et à la fin, on a juste un résultat qui nous dit OK, test, je ne sais pas, 120 sur 120 passe. Et on passe à l'étape d'après. L'étape d'après, c'est là où on commence la partie infrastructure. On va packager l'application dans ce qu'on appelle un conteneur, dont on va parler après. Et ce conteneur-là, on va aussi lui faire subir des choses. On va aller le poser à un endroit pour qu'il soit stocké, versionné, forcément. On aura différentes versions de l'application, donc on les garde toutes avec une rétention qu'on définit à l'avance. Et super. Ce package containerisé, c'est là qu'on va aller s'amuser à le déployer. Et quand on parle de déploiement, là, on force ce qui n'existait pas dans les schémas anciens. On va définir différents environnements. C'est-à-dire qu'on ne va pas tout de suite aller pousser l'application en production. Ça, c'est hors de question. On ne va pas, t'imagines, si tu as 100 000 clients qui utilisent l'application, bim, tu as une release qui tombe, il y a tout qui change. Enfin non, c'est impossible de faire ça. Donc, on va d'abord l'envoyer sur un environnement, par exemple, de développement. L'environnement de développement, ça va permettre aux développeurs qui viennent de faire sa modification de la voir en temps réel, de pouvoir vérifier si, malgré les tests qui ont été faits avant, quand il y a un humain qui est derrière, ça fonctionne bien.

• Speaker #1

  Est-ce qu'on pourrait rappeler un bac à sable ou pas ?

• Speaker #0

  Oui, absolument. Alors, l'environnement de dev, il a plusieurs noms. On l'appelle bac à sable, sandbox en anglais, dev, recette, tout ce qui n'est pas en fait les environnements suivants qui sont la pré-prod et la prod. L'environnement de pré-production, c'est un environnement qu'on souhaite être au plus proche de la production. On va monter le même stockage, on va prendre des données qu'on va anonymiser avant, mais qui seront un ensemble de données qui est au plus proche de la production. Alors que dans un environnement de développement, on ne va pas avoir de données du tout, par exemple.

• Speaker #1

  Sur l'environnement de pré-prod, c'est là où potentiellement les product owners, les chefs produits, ceux qui ont réfléchi l'application avec les développeurs, peuvent tester.

• Speaker #0

  La partie assurance qualité dont je parlais avant, c'est la casquette de tous ces gens-là, justement. vérifier, tu connais aussi le sujet de toute façon, tu y as été confronté, donc c'est faire tester à ceux qui n'ont pas le nez dedans, donc pas les développeurs, pas les Ops, comme on les appelle, c'est le nouveau nom des administrateurs système, on les appelle les Ops, faire tester tout ça. Et quand c'est validé, là on a encore deux choix pour la mise en production, c'est soit on a une décision qui dit, ok, on a tout validé avec des équipes, il y a un comité qui est passé, fond. valide la mise en production etc etc on y va tout de suite en prod ou alors on fait ce qu'on appelle un ab test ça tu connais aussi la bête est voilà et ben on fait de la bête est côté des bobs aussi père on a les outils qui nous permettent en fait de déployer une environnement de production bis je dirais à côté et les outils d'infrastructures qui permettent quand un utilisateur d'arriver sur l'application il va être redirigé soit sur l'un soit sur l'autre de manière transparente là on le voit notamment sur nos applications réseaux sociaux

• Speaker #1

  Quand ils sortent des nouvelles fonctionnalités et qu'on dit à quelqu'un, à nos collègues, « Ah tiens, t'as vu, ils ont sorti ça ? » et que le collègue dit... Tout à fait. Pas du tout, moi je n'ai pas du tout... C'est exactement ça. C'est ce que nous on est capable de faire aussi sur la partie DevOps.

• Speaker #0

  Et tu vois, quand tu as cette nouvelle fonctionnalité qui apparaît sur ton réseau social, tu n'as pas eu de notification qui t'a dit il faut vous connecter à tel endroit maintenant, c'est totalement transparent pour l'utilisateur. Et donc avec ces fameux A-B tests, on est capable aussi de récolter de la donnée sur des tests qui sont dans l'application pour dire là le parcours utilisateur, il n'a l'air pas dingue, peut-être qu'on va revenir à la version d'avant. Donc du coup on fait ce qu'on appelle un rollback. qui fait aussi partie du pipeline DevOps, le rollback permet de revenir à la version qu'on avait en production avant. Alors, c'est un schéma qui est applicable, même si tu n'as pas de DevOps. Le rollback peut s'apparenter à une restauration de sauvegarde. Ça marche. Mais là, le fait de rentrer dans cette philosophie, ça fait que le rollback est pris en compte pendant tout le pipeline et du coup, on a les leviers pour l'activer rapidement. Par exemple, tu vois que tu as un gros problème, que tout le monde, malgré tous les tests que tu as faits, les gens qui ont vérifié... Et en fait, en production, tu commences à recevoir des appels de tous tes clients parce qu'il n'y a rien qui va. Tu cliques sur un bouton, tu passes à la version d'avant et hop, on peut se reposer et réfléchir à la suite.

• Speaker #1

  Oui, et ça, c'est la philosophie DevOps. Et ça,

• Speaker #0

  c'est la philosophie DevOps.

• Speaker #1

  J'ai une question sur ce que tu disais tout à l'heure. Il y a un truc qui me titille un peu. Il y a des fois, et on peut y être confronté en tant qu'utilisateur d'une application, tout d'un coup, on se connecte ou alors il y a plein de gens qui se connectent sur un site web ou une application parce que... il y a eu une énorme pub télé, parce qu'il y a eu un énorme influenceur qui a fait quelque chose. On se connecte et là, il n'y a plus rien.

• Speaker #0

  Absolument.

• Speaker #1

  Normalement, si on a une philosophie de DevOps, ça ne devrait pas arriver ?

• Speaker #0

  Ça ne devrait pas arriver. Est-ce que tu peux un peu nous expliquer pourquoi,

• Speaker #1

  à un moment donné, c'est l'écran noir sur les utilisateurs, les consommateurs ?

• Speaker #0

  Pour bien comprendre comment on pallie ce problème, il faut revenir sur cette fameuse notion de conteneur. La notion de conteneur, c'est... Quand on déploie une application sans cette fameuse containerisation, une application ne fonctionne pas nativement toute seule. Elle a besoin de dépendance. Des dépendances, on appelle ça de temps en temps des librairies système qui permettent par exemple de faciliter la connexion à un actif directorique. Le développeur ne va pas s'amuser à refaire cette intelligence par lui-même, il va se baser sur le travail existant de quelqu'un et il va l'intégrer dans son application. Ça devient une dépendance. En fonction de là où on va déployer l'application qu'on vient de créer avec ses dépendances, tu vas peut-être te retrouver sur une infrastructure qui va tout de suite avoir les dépendances et une autre infrastructure qui ne l'aura pas. Du coup, il y a un moment où ton application va marcher et un moment où elle ne va pas marcher du tout. Pour pallier ce problème, la conteneurisation, ça veut dire qu'on va prendre notre code source applicatif et on va prendre aussi toutes ses dépendances avec et on va les mettre dans une boîte. Et cette boîte-là, du coup, elle devient complètement autonome. Elle ne repose que sur un logiciel qui permet d'exécuter ce qui est à l'intérieur de ce conteneur-là. Et ce logiciel, il est uniforme, il peut s'installer à peu près partout. À partir du moment où le logiciel, dont vous avez forcément entendu parler, s'appelle Docker. Alors, Docker en est un parmi beaucoup, mais c'est le plus connu en tout cas sur le grand public. À partir du moment où tu as une infrastructure qui possède Docker, tu es capable de faire tourner ton conteneur partout. De manière uniforme, de manière totalement agnostique de l'infrastructure qui est en dessous. et de manière répétable, du coup. C'est ça qui est hyper intéressant. Étant donné que l'application est embarquée avec toutes ses dépendances, tu es capable de multiplier les instances de ton application à côté d'elle-même pour justement, par exemple, absorber de la charge. Donc en fait, les outils DevOps qu'on a aujourd'hui, ils vont aller poser des sondes autour de l'application, notamment sur le trafic qui va arriver dessus, et à partir d'un certain seuil de trafic, va décider tout seul de créer une copie de l'application. Pour absorber la charge, absorber le pic, et quand le pic redescend, supprimer les copies pour n'en avoir plus qu'une ou deux ou trois, ça dépend de ce que tu te fixes en seuil bas, et limiter du coup aussi les coûts d'infrastructure. Parce que tu pourrais te dire, je suis un site e-commerce qui fait beaucoup de ventes, je ne prends pas de risque, et sur les 365 jours de l'année, je mets beaucoup de copies de mon application, mais à la fin la facture elle est...

• Speaker #1

  Alors qu'il faut mieux le faire peut-être au moment de Noël ou à un autre moment.

• Speaker #0

  Et donc ce principe-là a un nom, ça s'appelle la scalabilité horizontale. J'ai dit bien horizontale parce qu'on a aussi la scalabilité verticale.

• Speaker #1

  Mais on va y revenir après. Aujourd'hui, avant qu'on passe à tous ces termes techniques, parce que là tu nous fais un peu du teasing sur plein de termes techniques, pourquoi aujourd'hui on ne peut plus se passer de DevOps ?

• Speaker #0

  Alors aujourd'hui... On ne peut plus se passer de DevOps, ou en tout cas c'est difficile de faire autrement, parce qu'on a des enjeux, notamment au niveau de la sécurité des données, de la cybersécurité au global d'une application, où on ne peut plus se permettre de poser une application. ou de faire des modifications de code dans une application sans contrôle, sans test, sans vérification, parce qu'on s'expose tout de suite à des schémas de fuite de données, de failles de sécurité qui sont exploitées. Avec l'arrivée de l'IA, ça peut aller très très vite aussi. Donc c'est presque vital d'avoir cette philosophie DevOps. Ça ne veut pas dire qu'il faut avoir une équipe qui est dédiée à ça, mais il faut au moins sensibiliser les développeurs s'il y a une équipe de développement et une équipe infra. les sensibiliser à cette philosophie de DevOps by Design et même aujourd'hui en 2026 de Security by Design. Vraiment, on fait très attention à ça. C'est difficile de passer à côté aujourd'hui, clairement.

• Speaker #1

  Et il y a eu un avènement du DevOps. Je vais avoir une question là-dessus, c'est comment tu as atterri sur le DevOps, parce que je pense que ça intéressera beaucoup de monde. Mais il y a eu un avènement du DevOps parce qu'il y a aussi de plus en plus d'applications qui sont en mode SaaS.

• Speaker #0

  Oui.

• Speaker #1

  application sur ton smartphone, etc. Et ça, je pense que ça a changé la donne.

• Speaker #0

  Il faut prendre un exemple qui parlera peut-être un peu plus à tout le monde. C'est, et tu l'as cité, c'est une application sur ton smartphone. Peu importe ce qu'elle fait. Disons une calculatrice, toute bête. Ton développeur, il va créer sa première calculatrice avec son code sur son ordinateur. Il va faire des simulations, par exemple d'iPhone, sur son ordi pour vérifier que son application marche bien. et au moment où il va... avoir besoin d'un vrai iPhone pour voir comment ça se comporte sur un vrai téléphone. Là déjà, si on fait l'analogie, l'environnement de développement, c'est son PC et la pré-prod, c'est son vrai téléphone. Déjà, on est dedans. Ensuite, le développeur tout seul, alors qu'il ait une équipe DevOps ou pas, mais imaginons qu'il soit déjà sensibilisé à la philosophie DevOps qui n'est pas forcément une équipe infra, ça peut être un auto-entrepreneur par exemple, il va commencer à faire ses tests. Alors ça, il n'y a rien de compliqué dans la mise en place. Mais surtout... Il va vouloir pousser son application sur les stores pour que les gens la téléchargent. Voilà, logique. Donc toi tu reçois l'application, tu la testes, tu dis que tu es en attente d'une mise à jour parce que je ne sais pas, il te manque la fonction diviser sur ta calculatrice. C'est un peu bête, mais bon, dans le développeur, dans son focus, peut-être qu'il a oublié. Ça peut arriver. Et donc du coup, tu vas contacter le développeur pour lui dire « Écoute, il manque la fonction division dans ton application. Est-ce que tu peux la rajouter dans ta prochaine mise à jour ? » Il va te dire « Ok, je travaille dessus. » Sans philosophie DevOps, ce « je travaille dessus » peut durer de une semaine à six mois en fonction de comment le développeur y travaille. Et là, il y a autant de façons de travailler qu'il y a de développeurs dans le monde. Donc tu ne sais jamais, tu es juste en attente. Avec une philosophie DevOps, tu peux avoir, je ne dirais pas un estimatif, mais te dire qu'avec tous les outils qui seront à la disposition du développeur, il va itérer tellement rapidement et de manière tellement automatique que lui, tout ce qu'il aura à faire finalement, c'est ouvrir son code source. rajouter sa fonction division, enregistrer et après ça part dans le tunnel et deux heures après, ta mise à jour elle arrive sur ton app store, tu as juste à l'installer et c'est terminé. Donc on a aussi une dynamique de je déploie plus vite, j'ai un time to market qui est vachement réduit. Alors ça c'est encore, tu le disais tout à l'heure aux personnes type Product Owner de définir un peu le cycle de release qu'ils veulent pour leur application. Il y en a qui itèrent jusqu'à 15 releases par jour, ça arrive. D'autres qui bloquent des cycles en disant qu'on fait des mises en production que le jeudi entre 16h et 17h, par exemple. Mais en tout cas, on voit avec l'avènement du DevOps que le time to market est réduit parce que les développeurs peuvent produire plus vite, plus sereinement et de manière plus sécurisée.

• Speaker #1

  Et ça, ça vient aussi un peu de la méthode agile.

• Speaker #0

  Un peu, beaucoup même. Parce que du coup, la méthode agile, la base de résolution des problèmes de la méthode agile, c'est les user stories. Et les user stories, ça parle beaucoup aux développeurs. J'ai un utilisateur qui n'arrive pas à faire ça. Tu donnes ça à un développeur, il te fait ta feature qui débloque le problème initial. Après, ça part dans le pipeline et du coup, le ticket agile, il est passé d'une colonne à l'autre en deux secondes.

• Speaker #1

  Donc, on ne peut pas parler aujourd'hui de DevOps sans parler de containerisation. Est-ce que tu peux nous en dire un petit peu plus sur la containerisation et comment au quotidien ça se schématise ?

• Speaker #0

  Alors, la containerisation, c'est devenu un standard aujourd'hui. C'est une méthode qui permet d'empacter. une application, ses dépendances et son environnement d'exécution qu'on appelle vulgairement un système d'exploitation, dans une boîte qui est un format standardisé qu'on va pouvoir déployer à peu près où on veut sur n'importe quelle infra à condition que l'infra soit prête pour accueillir ses conteneurs. Et là, l'intégralité des acteurs du cloud permet aujourd'hui d'accueillir des conteneurs sans avoir à réfléchir, sans que le développeur ait besoin de se poser la question Deux, je vais prendre une machine virtuelle qui fait tant de CPU, tant de RAM, tant de stockage. Non, non, il a juste à envoyer son conteneur. Le conteneur est mis en production du côté de l'acteur du cloud avec des paramètres, on en parlait tout à l'heure de scalabilité, de certificat SSL pour protéger l'application, on va lui demander sur quel nom de domaine. Tout ça, ça dépend de comment fonctionne le cloud qui est derrière, mais en tout cas, le schéma est le même, on vient déposer un conteneur. Donc le développeur maîtrise la technologie de containerisation, il sait comment ça fonctionne, il comprend comment il doit construire. Là, la philosophie DevOps peut venir intervenir en insufflant les bonnes pratiques de containerisation pour le développeur. Parce que le but, c'est que, étant donné qu'on se retrouve avec une enveloppe dont l'application à l'intérieur ne va représenter qu'une fraction de tout ce qui est embarqué par le conteneur, on essaye de faire des économies de poids et donc de ne pas embarquer dans ce conteneur-là des choses qui ne vont servir à rien pour l'exécution de l'application. Donc nous aussi, on a un rôle auprès du développeur pour lui dire, là, tu as peut-être tenté d'embarquer quelque chose qui ne va pas servir. Du coup, on te conseille de le supprimer. Tu n'as besoin fonctionnellement que de ça, ça et ça. Et ton application, elle pourra fonctionner.

• Speaker #1

  Est-ce que ça aide aussi le côté un peu numérique responsable ?

• Speaker #0

  Forcément. Forcément, parce que l'aspect… Là,

• Speaker #1

  on dirait que j'ai posé une question qui était sur le papier. Alors, pas du tout. Ce n'est pas du tout naturel.

• Speaker #0

  Prêt ou dépourvu. Ça fait partie, c'est un des axes d'études du numérique responsable, qui est de limiter l'impact environnemental. Alors, on parle souvent de l'impact environnemental du matériel, mais ça peut aussi prendre en compte les services et les applications. Le fait de réduire la taille d'une application containerisée, ça fait qu'elle va consommer moins d'espace. Plus égal. Voilà, exactement sur l'infrastructure sur laquelle on va la déployer. Et quand on va scaler cette application dans le futur, on va consommer moins de ressources de manière exponentielle, ce qui a forcément un impact sur ce côté-là. Donc oui, c'est une petite goutte sur le travail que représente tout le numérique responsable, mais par contre, ça a un impact.

• Speaker #1

  Et en quoi la containerisation facilite l'intégration continue ou le développement continu d'une application ?

• Speaker #0

  Ce que je le disais tout à l'heure, c'est un standard. Il n'y a pas 36 manières de faire des containers. Il y a un standard. Alors, tout à l'heure, je parlais de Docker qui est... un environnement d'exécution de conteneurs. Il y en a d'autres, il y a conteneur D par exemple, qui en est un second, mais si tu veux, le format qui est utilisé par ces conteneurs, c'est un standard en lui-même qui s'appelle Spoiler OCI, pour Open Container Interface.

• Speaker #1

  Ah oui, on est partout.

• Speaker #0

  Incroyable. Et donc ce standard-là, il est utilisé par tous les programmes qui font tourner des conteneurs et qui dit standard, dit schéma de répétabilité. qui est absolument déployé partout. Il n'y a pas de conteneurisation sans respect de ce standard OCI.

• Speaker #1

  Ok. Et c'est un modèle open source ? Comment ça fonctionne ?

• Speaker #0

  C'est un modèle qui est évidemment open source. C'est un modèle qui a été porté... par des acteurs historiques de ce qu'on appelle l'informatique cloud native, toute la philosophie de containerisation. Alors, c'est un peu, c'est pas forcément, c'est très lié au DevOps, évidemment, mais c'est deux, je dirais, deux verticales qui sont quand même séparées. quand on parle de cloud native, on parle de toutes les technologies qui gravitent autour de la containerisation et de la scalabilité des applications dans le cloud. Donc évidemment, la communauté sous-jacente, elle est pour le partage, donc la majorité, si ce n'est pas toutes, tous ces outils qui sont utilisés dans le cloud native sont open source, y compris les briques fondamentales type le standard OCI.

• Speaker #1

  Ok, donc si on revient, cloud native, Dans le clone natif, il y a conténérisation. il y a DevOps, forcément, puisque quand on parle de cloud natif, on parle de développer une application qui, quoi qu'il en soit, sera dans le cloud et de penser son application en mode, elle va être en SaaS.

• Speaker #0

  Exactement. C'est exactement le but. Alors, il y a évidemment, tu t'en doutes, des petites divergences à droite, à gauche, selon les use cases, mais en tout cas, le schéma reste toujours le même. Respecter ce pipeline DevOps dont on a parlé tout à l'heure, déployer l'application quelque part, et effectivement, tu le soulignes, Je vais même rebondir. rebondir là-dessus. Quand on parle d'applications en SaaS, il y a quelque chose auquel on ne pense pas forcément, mais c'est souvent des applications web. On parle d'applications qui sont accessibles par Internet, soit par un site web, soit par une application de smartphone qui, en fait, elle-même, va se connecter derrière un site web. Donc, c'est souvent de la technologie du web.

• Speaker #1

  Ok. On a parlé de containerisation, on va parler de stockage S3. Si je dis stockage objet, je parle de la même chose ?

• Speaker #0

  Oui.

• Speaker #1

  Ça c'est poli, mais ça veut dire que ce n'est pas tout à fait la même chose. On peut préciser. Tu nous expliqueras les deux. Est-ce que tu peux nous dire, stockage S3, stockage objet, qu'est-ce que ça veut dire et quel est le lien avec la philosophie DevOps ?

• Speaker #0

  Alors, le stockage objet, c'est le type de stockage. Et S3... c'est une implémentation de ce type de stockage.

• Speaker #1

  Waouh ! Voilà.

• Speaker #0

  En gros, le stockage objet vient en opposition au stockage qu'on a tous connu et qu'on connaît tous aujourd'hui, qui est le stockage par bloc, qui est ce que ton ordinateur utilise. Un système de fichiers dans un disque dur dans lequel tu peux naviguer par dossier, qui est utilisé par les applications de ton PC, mais qui a une adhérence très forte avec le matériel sur lequel il tourne. Exemple tout bête, tu enlèves le disque dur de ton ordi, t'as plus d'ordi. Voilà, je veux dire, je peux pas faire plus simple. Le stockage objet, c'est un stockage qui a été pensé pour ce fameux monde du cloud natif, où là, on n'est plus dans une philosophie d'adhérence au matériel d'infrastructure sur lequel on va déployer l'application. Si on était dans ce schéma-là, ni le développeur ni les admin systems qui sont derrière vont aller se poser la question de mon application a besoin de stockage. Il faut que je pense à l'avance, à me dire attention l'infra sur laquelle j'arrive, elle a tel type de disque dur, elle a tel type de point de montage. Non, non, ce n'est absolument pas une question à se poser. Il faut que l'application puisse utiliser un stockage qui est un standard aussi et qui soit disponible. Disponible partout. Et aujourd'hui, qui dit disponible partout, dit sur Internet. Donc, technologie web. On y revient toujours. Donc, le stockage objet, c'est une série, en fait, de couches d'abstraction sur du stockage physique classique, des disques durs, mais qui vont permettre... à un développeur, un administrateur, un personnel technique, de pouvoir interagir avec du stockage, donc créer des fichiers, les modifier, les déplacer, les renommer, leur mettre des attributs, les protéger, tout ce qu'on fait sur un système de fichiers classique, mais au travers d'une interface web, au travers d'une API, pour le coup.

• Speaker #1

  En quoi cette partie stockage S3, c'est ça, stockage S3, je relis bien mes notes, parce que vu que c'est technique, je ne voudrais pas avoir des commentaires en me disant attention, ce n'est pas les bons termes techniques. En quoi elle facilite le travail de la philosophie d'Elobs ?

• Speaker #0

  Alors, pour une raison toute simple, c'est que le stockage objet est donc S3, si on rebondit sur S3, S3 c'est l'implémentation de ce stockage-là. C'est un standard d'API pour utiliser ce stockage objet. C'est écrit par... Amazon et Amazon a rendu la conception de cette API open source ce qui a permis en fait à des éditeurs de solutions de stockage de proposer leur implémentation de cette API au standard S3. C'est génial parce que ça veut dire que qui voulait utiliser du stockage objet était obligé d'aller chez Amazon parce que c'était eux qui proposaient ce standard-là et qui était le meilleur. Mais du coup, le fait de l'avoir rendu ouvert a permis de pouvoir l'installer chez soi, de pouvoir avoir des implémentations chez des acteurs privés du cloud. Souverains. Souverains, exactement, et d'avoir un standard qui permet que la même API qu'on utilisait chez Amazon. pour exploiter ce stockage, on va la retrouver chez un autre acteur 100% compatible. Et là, on en revient à cette couche. Alors, je parlais du standard OCI, qui était le standard de containerisation. Le standard S3, du coup, est le standard de stockage. Ce qui fait qu'encore une fois, peu importe l'endroit où on va aller déployer notre application, à partir du moment où ce fameux stockage S3, qui, je le rappelle, est sur Internet, donc c'est un lien HTTPS pour accéder à un fichier, à partir du moment où ce point-là, il est disponible pour l'application, Du coup, son stockage est disponible. Donc, on devient aussi agnostique de là où on va stocker les données. Et ça, c'est génial.

• Speaker #1

  Excellent. Si on se met côté entreprise, si une entreprise a une application, a développé son propre RP via un partenaire ou pas, si elle a développé son site web, son portail client, etc. et qu'elle se dit, je pense qu'il faut que je sois dans une philosophie DevOps parce que je me rends compte que j'ai des problèmes de cybersécurité, de performance, de test, de pré-prod, de bac à sable, etc. Par quoi elle doit commencer ?

• Speaker #0

  Alors souvent, elle va commencer par identifier un use case qui est répétable, c'est-à-dire une action qui est faite dans la journée 2, 3, 4 fois manuellement. Et quand on se rend compte en fait que cette action manuelle, elle a la possibilité d'être automatisée en jouant sur, alors ça peut être le déploiement d'une application, ça peut être le téléchargement ou l'upload de fichiers type CRM. CSV avec des données dedans. La génération de ces fichiers-là aussi, des fois il y a des gens encore qui remplissent des Excel à la main alors qu'on pourrait automatiser le remplissage de ces fichiers-là. Quand il y a un use case de ce type-là qui est identifié chez le client, c'est là qu'on peut commencer à enclencher la philosophie d'Azure. DevOps. Étudier la chose pour se dire la première étape, c'est comment on va automatiser cette tâche répétitive qui est redondante. Et là, je ne parle même pas de code applicatif. Ça peut vraiment être de la saisie de données. Juste, on est capable d'aller insuffler cette philosophie d'automatisation dans des tâches qui sont souvent rébarbatives. Mais en tout cas souvent... très répétitives et qui peuvent être ennuyantes du coup.

• Speaker #1

  Et justement pour toi, quelle est l'erreur la plus fréquente quand on se lance dans le DevOps ?

• Speaker #0

  Alors l'erreur elle vient...

• Speaker #1

  Tu souris.

• Speaker #0

  Ouais je souris parce que forcément quand bien même on est sur une communauté qui est largement open source et ouverte, il y a des acteurs qui veulent faire du business dessus donc ils vont développer beaucoup d'outils alors en SaaS souvent mais qui eux-mêmes suivent la philosophie DevOps on boucle la boucle toujours au final mais qui vont aller vendre BOUM des abonnements, vendre des prestations, miroir, tout est joli, on va venir chez vous, on va absolument tout automatiser, ça va être génial. Alors, c'est vrai que c'est génial parce que du coup, tu te dis, toutes mes saisies de données, toutes mes releases de codes applicatifs, tout ça, ça va être automatisé en un coup de cuillère à peau, mais derrière, l'entreprise, elle va quand même perdre le contrôle sur ce qui se passe. Ça va être confié finalement à un prestataire. Le prestataire, il va, alors c'est son rôle évidemment d'aider le client là-dedans. Donc pour moi, c'est mon point de vue personnel, c'est une erreur dans le sens où un... on perd un peu la maîtrise sur les processus qui sont mis en place chez le client. C'est-à-dire que lui, il avait l'habitude de faire comme ça, et il va avoir souscrit un abonnement à un logiciel tiers qui va lui, je ne vais pas dire lui mettre le bazar, mais qui va plutôt tout remettre d'équerre de manière automatique, mais sans forcément voir ce qui se passe en dessous. Alors, la finalité, elle est là, elle existe, et elle sera probablement très bonne. Mais par contre, le jour où il faudra défaire ce qui a été fait, parce qu'il y a eu un changement de système. un changement de technologie, là, il va y avoir de la friction.

• Speaker #1

  Donc, toi, tu es plutôt sur une philosophie, je pense, qui ressemble pas mal à la philosophie des hubs, sur du copilotage, de la procréation. Exactement. On prend le temps.

• Speaker #0

  On prend le temps, on y va étape par étape. On adresse d'abord des petits projets qui sont très identifiables par toutes les équipes. Et après, on s'attaque, on gravit la montagne petit à petit.

• Speaker #1

  La stratégie des petits pas. Nous, on adore parler de ça chez ECI. la stratégie des petits... petit pas, on y va, il faut y aller, mais petit à petit, pour que ça soit une réussite.

• Speaker #0

  Et surtout, tu as vu le nombre d'étapes qu'il y a dedans, tu ne peux pas arriver en une semaine et espérer tout implémenter tout de suite. On peut mettre les étapes les unes après les autres. Ne serait-ce que s'adresser à une équipe de développement qui n'a jamais fait de test, et leur mettre un pipeline de test, c'est déjà un grand pas en avant pour eux, parce que ça leur permettra d'avoir tout de suite un retour sur leur code en leur disant attention, ce que tu as fait là, ça ne marche pas. Et il y a beaucoup plus d'entreprises qu'on ne le pense qui sont dans le cas où il n'y a pas encore de test et il n'y a même pas un prémice de philosophie DevOps qui est insufflé chez les développeurs. Donc c'est pour ça vraiment petit à petit, on y va.

• Speaker #1

  Et concrètement dans ton métier au quotidien ? avec ton équipe. Tu nous l'as expliqué, faire des tests, ce n'est pas cliquer là, cliquer là, etc. Vous faites des tests automatisés. Vous êtes dans la création des modèles de tests. Après, ça part comme tel un script.

• Speaker #0

  Tu peux nous expliquer ça ? C'est... Alors, il y a une étape humaine qui est forcément nécessaire, parce que le code ne peut pas deviner tout seul ce qu'il doit faire finalement comme test. Alors aujourd'hui, avec l'IA, on peut faire des miracles. Mais évidemment, avant, il y avait une... Il y a toujours une dynamique dans laquelle l'OBS, le fameux OBS dont je parlais tout à l'heure, il doit avoir une appétence quand même pour le code applicatif. Parce que, pour implémenter des tests, alors que ce soit des bêtes tests de formatage de code, des tests un peu plus poussés, type les tests de non-régression, ou les fameux tests end-to-end, ces trois catégories. Si on doit rédiger ces fameux tests, il faut avoir à la fois connaissance métier de l'application qu'on est en train de traiter et à la fois connaissance un peu, à minima, du code sur lequel on est en train de travailler. Donc, c'est pour ça qu'on parle de DevOps, développeur opérationnel. Il y a une patte côté développement et il y a une patte côté admin system avec le côté Ops.

• Speaker #1

  Oui, c'est vraiment un 360.

• Speaker #0

  Oui, oui.

• Speaker #1

  Et même tu dis côté développeur, côté admin system, même côté fonctionnel, c'est ce que tu disais, métier. Oui. Prendre aussi l'application parce que si tu ne comprends pas l'application, les tests que tu vas produire, ils sont peut-être standards. Ok, tu as des tests standards. Oui, c'est ça, exactement. Mais tu vas aussi avoir des tests qui sont extrêmement liés à l'application. Oui, tout à fait. Est-ce que l'utilisateur va en faire ?

• Speaker #0

  C'est un côté qui est un très bon exemple. Je prends une application qu'on connaît bien chez Océan, Odoo. Par exemple, sur une équipe d'administration système, s'occuper d'ODU, ça va être s'occuper que l'infrastructure fonctionne et s'occuper que l'application ODU fonctionne de manière système. C'est-à-dire, on va vérifier que le service tourne et qu'il est OK. Et éventuellement, si on veut pousser un tout petit peu plus loin, on va mettre une sonde qui va vérifier que la page d'accueil de l'application ODU, elle répond. Mais on s'arrête là. On ne rentre pas dans l'application. Et là, ça peut devenir un point de friction. Parce que du coup, le développeur qui est de l'autre côté, qui va faire des choses sur Odoo, lui va se concentrer sur ce qu'il fait sur Odoo. Et tout ce qui se passe entre la page de login et son code à lui, dans ce schéma-là, il n'y a personne qui le vérifie. Donc ça peut être complètement cassé. Je veux dire, tu peux avoir ta page de login qui est là, sur laquelle tu peux taper ton login, ton mot de passe, mais par contre, quand tu appuies sur Entrée, derrière, il n'y a plus rien. Ça, ça arrive super souvent, vraiment super souvent. Donc, la philosophie DevOps dans cette optique-là, c'est d'aller un peu plus loin. On ne parle pas d'aller vraiment décortiquer chaque fonction d'ODU une par une, mais vraiment de faire des tests fonctionnels qui permettent de s'assurer que quand le développeur vient de livrer une nouvelle version de son code pour ODU, on n'a pas cassé le reste d'ODU. Donc, on va simuler une connexion sur ODU. On va aller ouvrir la comptabilité dans ODU, vérifier que ça s'affiche bien. Vraiment, c'est du test de surface. On vérifie juste que ça marche. Et le fait de connaître comment fonctionne Odoo, forcément, ça aide à rédiger les tests. Et ça, ça peut s'appliquer à peu près à n'importe quelle application à condition qu'on ait de la documentation qui permette de savoir comment fonctionne l'application. Et à partir de là, on est capable d'imaginer toutes sortes de tests différents. Je te dis que là, le paradigme dit qu'on va rester en surface pour vérifier que tout va bien. Après, il y a des équipes qui vont très très loin dans les tests. qui peuvent prendre jusqu'à une journée entière parce qu'on va tester vraiment chaque bouton de l'application pour être sûr qu'il y ait tout qui marche. Encore une fois, ça vient du pilotage qui est au-dessus, les product owners, savoir ce qu'ils veulent, mais on peut tout faire. Théoriquement, le champ des possibles est infini. On peut vraiment faire tous les types de tests.

• Speaker #1

  Tu peux créer des scripts de tests sur plein de choses.

• Speaker #0

  Un exemple qui est plutôt tiré de ces équipes d'assurance qualité, c'est quand tu fais une application en client final qui est intégralement web, un site e-commerce, un site de prestation, le simple fait de tester que ton application s'affiche n'est pas suffisant tu vas vouloir faire des tests sur différents navigateurs tu vas prendre Google Chrome d'un côté Firefox, Edge et en fait tu vas faire exactement les mêmes tests mais avec différents navigateurs et ça si ton application elle est lourde et que tu fais beaucoup de tests ça peut durer un temps donc ça dépend à quel niveau on met ce curseur de test justement mais théoriquement tout est faisable si je résume avant qu'on passe à la conclusion

• Speaker #1

  Normalement, quand on a une philosophie de DevOps, on ne devrait plus entendre « ça, ce n'est pas moi, c'est le développeur, ça, ce n'est pas moi, c'est l'admin système Ofra » .

• Speaker #0

  Absolument, parce que chaque étape est traçable, du coup, forcément. Il y a quelque chose qu'on n'a pas évoqué qui sort un peu du DevOps, mais qui vient quand même en base, c'est que la première chose qu'on va faire, c'est qu'on va mettre un outil de versionning de code. Donc, on va voir en fait qui a fait quelle modification. Donc déjà, ça, ça permet… Alors, le but, ce n'est pas de blâmer, mais c'est surtout de se retourner… vers la personne en disant, là, je vois que c'est toi qui as travaillé là-dessus, il faudra peut-être corriger ce truc-là, tu as l'air de mieux connaître que moi. Surtout ça. Et surtout, on est dans une philosophie dans laquelle on va intégrer en plus des tests. Alors les tests, c'est des choses qu'on met... permet à la construction de l'application. Mais une fois que l'application est en production, il faut quand même continuer à la surveiller. Et donc, du coup, dans cette philosophie, on va intégrer énormément de sondes applicatives qui vont pouvoir remonter elles-mêmes, déjà de l'historisation sur le comportement de l'application, les temps de réponse, est-ce que ça communique bien avec une base de données, par exemple, et des indicateurs, ça marche, ça ne marche pas, dans l'application.

• Speaker #1

  Oui, et puis aussi, vu qu'on est tous dépendants... des grands acteurs du marché et de leur mise à jour et forcément à un moment donné tu as créé des dépendances que tu disais tout à l'heure dans ta partie comptabilisation, de tester régulièrement ça permet aussi que quand on va pas le citer mais voilà l'entreprise mondiale qui fait beaucoup de mise à jour et sur lesquelles 90% des entreprises sont fait une mise à jour ça évite si tu as fait des tests et des scripts pour faire en sorte que ton application elle plante comme si elle était...

• Speaker #0

  C'est ça et à ça même deux choses différentes. La première, c'est que le fait d'avoir conteneurisé ton application. tu as verrouillé ces dépendances. Donc déjà, même si ton éditeur fait une mise à jour de ta dépendance, elle ne sera pas embarquée dans ton application parce que toi, tu as dit, moi, cette version-là dedans est point barre. Donc, tu es sûr que ça fonctionne avec. Oui,

• Speaker #1

  en fait, ce que tu as bloqué, c'est la version.

• Speaker #0

  Exactement. Et si ton éditeur fait une mise à jour, toute ta série de tests qui se passent avant va te permettre de voir si ton code fonctionne toujours avec la version mise à jour. Donc du coup, tu résous deux problèmes en un.

• Speaker #1

  Super intéressant. Si tu devais résumer avant qu'on passe, parce que j'en ai fait du teasing.

• Speaker #0

  de comment on atterrit dans le DevOps parce que moi ça m'intéresse si on devait résumer DevOps en une idée forte c'est une philosophie c'est une méthode de travail ce n'est surtout pas une stack technique Parce que le DevOps, ce n'est pas une série d'outils définis, ça peut être plein d'outils différents qui existent sur le marché, ou même des scripts, des bêtes scripts, qui permettent d'activer cette philosophie, et ce n'est pas un métier. C'est vraiment une méthode de travail. On s'entoure évidemment d'outils, mais c'est des idées, et c'est surtout très... très... comment je pourrais dire ça ? C'est très malléable en fonction du contexte dans lequel on veut appliquer cette philosophie. On ne va pas faire du DevOps de la même manière chez un client A et un client B. L'idée de base reste la même, avec les piliers qu'on a cités. Par contre, l'appliquer...

• Speaker #1

  de ces piliers là elle va différer tout à fait en fonction du contexte dans lequel on sera justement ben voilà la question de ce podcast et comment tu as atterri dans le devops à quel moment on se dit ça je vais faire du devops j'ai vraiment dit je vais être un g cyber j'ai un frère j'ai claude développeurs Qu'est-ce qui s'est passé dans ta vie ? Raconte-nous parce que je pense que tout le monde... Déjà t'as quel âge ?

• Speaker #0

  Alors moi j'ai 33 ans. Je suis 93. Ouais. Et j'ai été formé au CNRS pendant 4 ans où le DevOps n'existait pas du tout à l'époque. je faisais plutôt ce qui s'apparente aujourd'hui à de l'informatique interne là-bas. Et en sortie d'alternance, je fais mon alternance là-bas, quand je cherchais du travail à Paris, j'ai été recruté chez Mythique, site de rencontre. Alors Mythique, il faut savoir qu'à l'époque, c'est une plateforme européenne qui est opérée par les équipes en France, mais qui adresse du coup tous les sites de rencontre européens sur une seule et même plateforme qui était située en France. En fonction de là où tu te connectais, si tu te connectais en France, tu avais Mythique. .fr, si tu te connectais depuis les Pays-Bas, tu arrivais sur les mêmes serveurs, mais par contre, ça affichait devant toi la version néerlandaise, par exemple, de Mythique. Et quand j'ai découvert ça, je me suis dit, mais attends, c'est pas des petits humains derrière qui font en sorte que chaque personne arrive, il y a forcément quelque chose derrière. Et quand j'ai vu, en fait, l'infrastructure dont disposait Mythique, donc c'était des centaines de serveurs web qui avaient tous le même code, à la virgule près. Je me suis dit, de la même manière, c'est... pas un humain qui va s'amuser à chaque mise à jour à pousser sur chaque serveur unitaire le nouveau code, il y a forcément quelque chose qui existe pour déployer en masse, et c'est à ce moment-là que je suis tombé dedans, quand j'ai découvert que tu peux avoir des infrastructures qui étaient gargantuesques à partir du moment où tu as un standard que tu as défini avant pour tester, déployer, monitorer l'ensemble, du coup tu peux avoir une toute petite infra ou quelque chose d'énorme, ça se traite exactement de la même manière. Ça m'a passionné, je suis resté là-dedans. Après, j'ai déménagé à Strasbourg. Je suis arrivé chez OCI. Et du coup, voilà.

• Speaker #1

  Super. Donc, Amitik, tu as fait tomber amoureux du DevOps, on peut le dire.

• Speaker #0

  On peut le dire, oui.

• Speaker #1

  Je vais faire le teasing sur un autre podcast qu'on va faire ensemble. Comment va évoluer le DevOps dans les années, les mois, les années à venir ? Tout va tellement vite dans l'IT et dans le digital.

• Speaker #0

  Alors, c'est excellent teasing. Ça va beaucoup tourner autour de l'IA, c'est sûr et certain. Tout à l'heure, je citais pendant notre discussion que l'Ops devait avoir une appétence pour la partie de développement. Avec l'IA, ça va devenir de moins en moins vrai parce que l'IA deviendra la partie du cerveau de l'Ops qui s'occupera de voir comment le code fonctionne. Ça va permettre d'insuffler encore plus de puissance, si je peux dire ça comme ça, aux équipes qui font du DevOps. Parce que du coup, elles vont pouvoir adresser tout un tas de contextes différents, alors qu'aujourd'hui, tu as des DevOps qui sont plutôt spécialisés dans un, deux, trois langages de programmation de prédilection. Demain, avec l'IA, il n'y aura plus du tout cette barrière-là. On gardera cette philosophie de « je dois faire mes étapes DevOps » . Par contre, comment le code a été écrit à la base, on mettra une IA dessus qui nous conseillera en nous disant « là, le développeur a tenté de faire ça, il faudrait peut-être rajouter un test » . qui parle de cette fonction et on n'aura plus besoin de savoir comment le code se comporte parce qu'on aura une IA dessus.

• Speaker #1

  N'en dis pas plus.

• Speaker #0

  J'en dis pas plus.

• Speaker #1

  Il faut que les personnes regardent le futur podcast sur l'IA et le DevOps. Merci Louis, c'était passionnant le DevOps. Je pense que j'ai appris plein de choses, ça c'est sûr. J'espère que les personnes qui nous écoutent ont appris également beaucoup de choses mais je n'ai aucun doute là-dessus. Merci beaucoup. Et moi, il ne me reste plus qu'à vous dire au revoir et à bientôt pour un nouvel épisode de l'Humain à cœur du digital. Salut ! A bientôt !

• Speaker #2

  Vous avez apprécié ce moment ? Alors laissez-nous un commentaire, un avis ou partagez cet épisode autour de vous. Et nous, on se dit à très bientôt pour un nouvel épisode de l'Humain à cœur du digital.