Émission Libre à vous ! du 4 octobre 2022

Titre : Émission Libre à vous ! du 4 octobre 2022

Intervenant·e·s : à la régie

Lieu : Radio Cause Commune

Date : 4 octobre 2022

Durée : 1 h 30 min

Podcast PROVISOIRE

Page des références de l'émission

Licence de la transcription : Verbatim

Illustration : Déjà prévue

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Transcription = Marie-Odile

Voix off : Libre à vous !, l’émission pour comprendre et agir avec l’April, l’association de promotion et de défense du logiciel libre.

DevOps (abolir les barrières entre les équipes de développement et les équipes d’administration système) avec Xavier Talon (co-fondateur et directeur technique de la société ORNESS, Président de DitRit, association loi 1901 d’intérêt général, qui traite de la transformation numérique) et Romain Soufflet = Eve

Frédéric Couchet :

Nous allons passer au sujet suivant. Nous allons poursuivre par notre sujet principal, qui va porter sur l'approche devops. C'est-à-dire, en tout cassé ma compréhension, abolir les barrières entre les équipes de développement et les équipes d'administration. Système. Nos invités du jour. Xavier talon, co-fondateur et directeur technique de la société ornex, président de dix huit, association loi mille neuf cent un d'intérêt général qui traite de la transformation numérique. Et romain soufflait, et c'est re indépendant, et c'est revlon dire site web et outils engineer. Mais comme on nomme mon anglais pourri, je vais vous le faire en français aussi: ingénieur de fiabilité de site. Il nous expliquera évidemment tout à l'heure. Ce que signifie essaie. Donc, bonjour xavier, bonjour, bonjour romain, bonjour. Alors n'hésitez pas à participer à notre conversation zéro neuf, soixante, douze, cinquante et un, cinquante cinq, quarante six, ou sur le salon dédié à l'émission sur le site cause commune, point faible, bouton de chat de salon libre à vous. On va commencer par une petite question classique que vous allez maîtriser, une présentation personnelle rapide. On va commencer par romain soufflet. Oui, d'accord. Donc, moi, rapidement, donc, je suis ingénieur développeur à la base, donc sur du python, puis j'ai progressivement passer donc sur les questions plutôt devops. C'est opérationnel, donc, c'est là que je suis arrivé à être indépendant et c'est re. Donc, c'est re qui va traiter de la stabilité des sites. En production et de l'aide aux développeurs, dans dans ce cas drh-là, et on va en parler quand même pendant pas mal de temps. Évidemment. Oui, moi je suis. Effectivement, j'ai participé à la création de la société hornet. Ça fait déjà vingt-deux ans et, au départ, effectivement, j'étais sur des problématiques toujours très techniques, ont travaillé pour des grands comptes où on avait des problématiques. D'ingénierie assez classique. On a fait pas mal de choses et, dès le départ, on était assez motivés. On a été des gros défenseurs. On a essayé de de poser des aspects du logiciel libre chez nos clients. Et puis on a assisté à pas mal de révolution, petit à petit, avec l'arrivée de nouvelles technologies, notamment le clos de toutes sortes de choses, et puis le devops est. Et avec ça, on a rencontré des nouvelles problématiques et un nouveau champ d'action qui nous a vraiment permis de voir qu'il y avait vraiment des améliorations à faire et des crocs difficultés qu'était à abolir et avec lesquels on pouvait. Avancer et créer beaucoup de valeur d'où. Un gros tournant dans la société. C'est devenu un de nos axes principaux. Hé. On verra un petit peu. On va en reparler, mais ça a été aussi l'occasion de créer l'association en détruite. Qui travaille sur ces problématiques. Là est une association loi mille neuf cent un et qui essaye de faire de traiter ces problématiques, notamment par l'incubation de logiciels libres. Alors on a, bien évidemment, Tout à l'heure, notamment en fin d'émission, sera partie de nitrites. On va commencer par une question. Un peu simple. Je précise que d'ailleurs, c'est xavier talon- et qui m'a est plutôt carole abbado, a cofondé, cofondatrice dorne. Est-ce qu'il y a quelque temps m'a proposé de traiter ce sujet de deux devops? Première réaction, ça a été la développe sur une émission grand public. Il va falloir lancer un défi. En même temps, on aime bien les défis. Elle a pris les pieds, on s'est dit, on va inviter les gens qui vont savoir en parler. Donc, si je parle aux gens de dévote, les deux termes qu'ils emploient, qu'ils entendent c'est d'eve et hop, alors d'eve. On voit bien que ça fait partie. Ça fait référence au développement obs, opérations opérationnelles. Peut-être qu'on va commencer par là pour préciser ces deux termes. Peut-être le premier mieux connu, mais en tout cas le rappeler est le deuxième terme avant d'entrer dans les détails. Qui veut romain soufflet? Ii va très bien, on va commencer par là. Donc, effectivement, développeurs, on arrive très bien à comprendre ce que c'est. C'est devenu plus facile à comprendre pour un peu tout le monde maintenant, puisque on a des développeurs qui sont plus nombreux que il y a trente ans et encore plus nombreux qu'il y a cinquante ans. Donc maintenant, on a une assez bonne compréhension globalement de ce que c'est par nature les développeurs. Ils se concentrent à changer les applications. Donc leur métier, c'est vraiment d'ajouter des fonctionnalités. D'ajouter des corrections de bug, de de faire en sorte que les applications évoluent pour que les utilisateurs puissent avoir de nouvelles fonctionnalités. Et les opérationnels, donc, sont ceux qui vont s'occuper des serveurs physiques pour que le, pour que l'application soit disponible pour leurs utilisateurs. Et les opérationnels ont, par définition, eux, leur objectif, c'est que Ce soit stable et que l'utilisateur qui a besoin de l'application à deux heures du matin puisse s'en servir. Et donc, en fait, par nature, le développeur, lui, il est axé sur le changement, l'opérationnel sur le bas. Une fois que ça marche, on joue plus trop y toucher. Donc, ils sont par nature amenés à être en conflit, et c'est là que la culture des obstinés. On est une même entreprise, on a un même objectif: servir nos utilisateurs. Faut qu'on travaille ensemble, et c'est comme ça que je définirais donc ce terme, avec ces deux métiers principaux: développeurs et opérationnels. Xavier, ce que tu veux compléter sur une partie de définition. Oui, ce n'est pas une partie, c'est. C'est pas si facile que ça, puisque il y a une chose qu'il faut savoir, c'est qu'il n'y a pas réellement de définition figée, normative de ce qu'est devoxx, la même manière qu'il n'y a pas non plus De manifeste comme un manifeste agile, et c'est. Le mieux pour définir, c'est de considérer que c'est une approche. C'est une approche qui vise à améliorer la performance, qui vise effectivement à abolir un petit peu les silos, toutes les difficultés, toutes les frictions qui peuvent se passer, notamment entre les œuvres, on l'a vu, les ops. Mais pas que, puisque pour faire tourner. Un logiciel, on a besoin de développeurs, on a besoin des gens qui vont faire les opérations, qu'on a besoin de gens qui vont faire la sécurité, les gens qui vont gérer aussi les budgets. On va, et donc on a fait le, l'acronyme devops, mais en fait, on a aussi le dvd, c'est comme de l'inox, etc. Et c'est vraiment ce principe d'essayer finalement de mettre de l'agilité. De fluidifier un petit peu les principes, de fer que on va être beaucoup plus efficient dans la construction des logiciels et surtout, de pouvoir aller beaucoup plus vite à un résultat donné. Alors, beaucoup plus vite, on va essayer de donner beaucoup plus de de capacité à voir les volumes. Eussions et allé dans le bon sens et de corriger les évolutions au fur et à mesure où elles vont venir. Donc, c'est tous ces objectifs qui visent vraiment à l'efficience, qui sont traitées par le développe, par cette approche. Hé. Après, on a différents moyens d'y accéder. On va y revenir, mais j'ai joué. Question j'ai. J'ai une question, une précis de questions. On va commencer par la première, qui a parlé du de l'agilité. Peut-être que les, les gens qui font du sport ont une vision de l'agilité, mais c'est quoi l'agilité dans le domaine de l'ingénierie informatique? Est-ce que tu peux présenter ça rapidement? L'agilité, ça va consister à essayer de. De mieux exploiter. Les ressources, les capacités de l'ensemble des personnes de mieux lisser les communications entre les personnes et, surtout, à essayer de De faire une amélioration continue. Beaucoup plus visible et qui permettra d'être beaucoup plus en accord avec le besoin. Typiquement, quand on faisait un logiciel, on va dire à l'ancienne, il y a quelques, il y a quelques années. On pouvait avoir entre le moment où on écrit le code et le moment où il va être en production. Il y a beaucoup, de beaucoup d'activités qui sont à réaliser. La mise en place des serveurs, leur installation, enfin, toutes les toutes, les toutes, au tous les différents en activité, comme la sécurité, etc. Qui sont nécessaires pour que le logiciel puisse tourner. Et il pouvait se passer. Facilement six mois, un an, parfois plus, entre le moment où on voulait concevoir un logiciel et le moment où le logiciel allait tourner. Dans ce temps-là, on a un tunnel. Ce qui va se passer finalement. Il va falloir attendre tout ce temps pour pouvoir avoir un résultat et sans doute s'apercevoir que ce n'était pas tout à fait ce qu'on visait. Quand on va arriver sur des approches d'agilité. On va essayer de faire. Plus petit. Plus vite. Et de manière cyclique. Et donc, on va essayer de se dire: fixons nous non pas directement la cible qu'on peut atteindre, mais une première étape où on vous voir aller rapidement et voir un premier résultat, premiers résultats, et pour permettre de corriger le tir et faire une deuxième petite étape qui sera bouclée, sera améliorée par rapport. Un feu hier à cette première itération et on va aller comme ça, petit à petit, jusqu'au bout. Alors on ne va pas forcément plus vite sur le tout, par contre. Très rapidement, on voit les déviances et on peut corriger, et on peut améliorer, et ça apporte énormément de qualité, énormément de stabilité et aussi une adéquation entre les besoins réels de la une de l'équipe cliente et ce que développe l'équipe de développement, plutôt que de les livrer bouddhique x moi, quelque chose qui ne correspond pas aux besoins. Là, c'est l'itération continue. J'aimerais juste préciser qu'on a consacré une émission sur l'agilité, c'est une mission cinquante neuf. Donc, si vous écoutez le début de l'émission, c'est libre à vous. Pour un slash, cinquante neuf. Merci pour la prison sur l'agilité. Maintenant, ma deuxième question, mais pour tous les deux, tu as parlé de d'approches. Devops, c'est dire, c'est ce que j'ai utilisé dans le, dans le, dans le titre de l'émission, mais on voit, on voit des veuves sur sur des tv. Aujourd'hui, c'est très à la mode. Donc, devops, c'est un métier en tant que tel, que c'est un nouveau métier en tant que tel, ou est-ce que c'est une approche qui est mise en œuvre par des gens dont c'est Un métier qui existe déjà, que son développeur ou développeuse soit dans l'administration système. Est-ce que c'est un métier ou une approche? Alors on a soufflé que moi, c'est un sujet qui me tient à cœur, c'est que, en tant qu'indépendant, quand je mets des votes sur mon cv, c'est ce que j'ai fait d'ailleurs, en fait, je ne m'en cache pas. C'est que j'ai besoin de d'éclaircir avec le client. Que le client entend par développe. En fait, le souci de cette approche, développe donc cette culture. Devops, c'est que c'est tellement large, ça regroupe tellement de métiers différents que c'est à peu près impossible de dire: je suis. Développe, c'est de maîtriser l'ensemble des sujets. Comme le disait xavier, c'est, ça prend parfois de la finance. Deux, le coût des serveurs, le coût des applications qu'on utilise. Parfois, ça va être de la sécurité informatique. Parfois, on va parler donc des backup, des solutions de stockage, qui sont plus donc de la base, de la qualité des sauvegardes exactement, et c'est impossible pour un seul, une seule personne, de maîtriser tous ces aspects là. Donc, au final, dire Je suis des vôtres. C'est quand même assez difficile, parce que ça regroupe vraiment beaucoup trop de choses. C'est pour ça que moi, donc, dans ma présentation, je dis, comme c'est re, que c'est un interne qui est un peu à la mode dans le milieu dans lequel nous évoluons. Qui est donc ingénieur de fiabilité de site en français, mais c'est au final une implémentation de cette culture dit loppsi. C'est un poste qui va être je m'occupe de la stabilité de la production afin de m'assurer qu'elle est toujours en place, que on a des bonnes informations sur comment elle tourne. Elle tourne bien, à ce qu'elle tourne de manière optimale ou de manière un petit peu dégradée. Voilà, mon métier va être vraiment sur cet aspect. Maintien en condition opérationnelle. Mais dire devops est un métier. C'est beaucoup trop difficile. Ça, c'est trop large pour qu'un seul, une seule personne puisse le maintenir. Juste avant que xavier qu'on complète sur essert. Euh, donc donc, ingénierie de la fiabilité ici. J'étais me renseigner un petit peu avant. Quand il voit que sur la page wikipédia, il y a une, une citation de de benne trailer, qui est fondateur, donc la team. L'équipe de google et qui dit: et re, et ce qui se passe quand un ingénieur ou une ingénieuse vous l'ingénieur logiciel, est chargé de ce qu'on appelle des opérations. C'est ça, en fait. Oui, c'est ça, c'est-à-dire qu'en fait, tout ce qui va être automatisables, va être automatisé. On va voir donc le déploiement non pas comme une tâche d'administrateur système qui va devoir le faire à la main, mais comme un projet informatique apparent. Entière. Donc, les applications, ce sont les développeurs qui les écrivent et moi, de mon point de vue, les développeurs, ce sont mes clients, c'est-à-dire que je dois leur fournir des outils et une infrastructure pour que leurs applications viennent s'interfacer avec la mienne et se mettent en production. Je vais dire un peu tout seul, en peu de. Manière magique qui va faire que tout fonctionne sera monitorer correctement, avec des bonnes métriques, avec de quoi donner au management, on va dire- les informations sur qu'est-ce qui est en ligne, qu'est ce qui tourne bien, de quelle manière. C'est vraiment un projet de développement. Le développement de l'infrastructure. Les outils, on en parlera tout à l'heure dans une deuxième partie. On poursuivre là-dessus, donc toujours sur ma question. En fait donc, ce coup-ci, Xavier talon. Donc, c'est un métier, c'est une approche. Et tu disais en introduction que ornait, maintenant c'est, s'est positionné sur cette affiche, pas cet affichage sur cette pratique du devops. Donc par rapport à ça, c'est un métier, c'est une approche, comment ça se passe en fait. Le. L'objectif de devoxx, c'est de réussir par, comme on le disait, d'aller vite sur des sur des fonctionnalités bien définies, délimitées, pour faire des cycles courts, mais pour le coup, sur, c'est ça, ou le développe. En fait, c'est un peu une extension de l'agilité qu'on est habitué à voir plutôt au niveau des développeurs. C'est l'idée de le faire sur l'ensemble des métiers qui sont nécessaires pour supporter l'application. Donc, ça veut dire qu'il va falloir faire des petites équipes où on va avoir toutes les compétences. Développement. Opération. Sécurité. Toutes les technologies qui vont être derrière. La qualité. Le testing, etc. Et donc, on voit tout de suite la complexité qui se pose, c'est qu'il faut que l'équipe maîtrise tous ces aspects. Donc, par l'automatisation, les outils, on facilite les choses, mais comment est-ce qu'on va le réaliser? et donc, on a besoin, et on voit apparaître des nouveaux métiers, on voit apparaître aussi des personnes. Fin des Des projets où on s'imagine qu'on va avoir le profil devops qui est capable de gérer tous ces aspects. Une utopie, c'est pas réalisable. Le mouton à cinq pattes, il y en a assez peu. Mais par contre, on voit qu'on va d'une manière ou d'une autre de voir dans les équipes introduire toutes ces compétences. Et du coup, il va aussi falloir lisser un petit pot pour faciliter le processus, pouvoir voir globalement comment est-ce qu'on met en place de la qualité. Et on a des nouveaux métiers, comme le ferreux, dont le rôle est D'assurer la qualité un petit peu transversal de tout ça. Donc, il y a pas de métier devops, il y a un ensemble de métiers et aussi un ensemble de nouveaux métiers, et on a besoin de réussir à mettre en musique toutes ces compétences au sein de petites cellules qui vont être capables d'aller très, très vite pour pouvoir fournir, au rythme de deux semaines à deux mois, des realise. Petite des dix, mais les versions de l'ue, l'avenir du système, réalisent des nouvelles versions de deux, d'une solution, d'une application qui va permettre d'actes de cranter systématiquement de plus en plus de qualité et de stabilité dans les produits argent. Alors, j'ai une question: par rapport à ce que tu décris historiquement, il y a hum, hum. Plutôt souvent un antagonisme entre les équipes de développement, les équipes de maintenance ou de d'administration système, parce qu'en fait les les objectifs sont pas les mêmes. L'administration système, cette équipe, elle veut que ça fonctionne, qui est qui et pas de bug qu'on puisse effectivement. Bourreau que ça fonctionne. La musique de dvd, souvent ils veulent livrer le plus vite possible, etc. Donc est-ce que l'un des enjeux ou est-ce que l'une des, justement, l'un des défis de développe, c'est de réunir ces personnes qui ont a priori des antagonismes de fonctionnement historique dans une même équipe pour, finalement, que les deux travaillent en cohérence avec, au final, finalement rendre un système opérationnel pour le plus important que la partie cliente. Forum romain. Vous avez comme vous voulez. Bien sûr, c'est tout. L'objectif est l'idée, effectivement, c'est de d'enlever les barrières qu'on va avoir effectivement de population, quand l'objectif contraire, le jeu, les gens qui vont développer veulent introduire de nouvelles fonctionnalités. Toute nouvelle fonctionnalité implique des changements, donc un risque sur la stabilité du système et les obs, pour eux, leur objectif primaire. Si Prennent que celui-là, c'est d'assurer la stabilité du système et d'empêcher qu'il y ait quoi que ce soit qui viennent. L'impact du coup. On voit tout de suite cette friction. Maintenant, l'idée du devops, une des idées principales, c'est tout simple, c'est de remettre l'humain au centre, de prendre les différentes populations et qu'elles discutent directement autour d'une table. Donc l'humain et la communication, exactement, et fait le point principal quand on met juste des personnes. Ensemble. Avec une qui va lire votre chien. Moi, j'ai besoin de faire telle fonctionnalité. Comment est-ce qu'on va mettre ça au niveau technique? Et que l'autre en face voit l'objectif, on va pouvoir immédiatement interagir. On va résoudre les problèmes en quelques minutes là où, de manière classique, dans un mode d'organisation comme vous pouvez l'avoir il y a quelques années, et bien, ça ferait passer par des équipes qui vont communiquer via des mails, qui vont faire des réunions. Qui vont à avoir des comptes-rendus des niveaux de décisions à prendre, etc. Et la même problématique pouvait prendre des mois. Simplement remarqué. Oui, oui, en fait, c'est tout à fait ça. Maintenant, effectivement, en pratique, on a cette difficulté. C'était que Dans certaines grosses entreprises, on a par exemple un pôle sécurité qui n'est pas du tout. Conviés, on va dire dans les processus de développement et qui se retrouvent à la fin du développement à dire pourquoi on ne nous a pas appelés. Donc, effectivement, il y a cette culture développe, qui a du mal à s'implanter dans des structures qui ont été organisées il y a pas mal de temps. C'est pour ça qu'on parle plus de culture et de philosophie développe, c'est-à-dire qu'en fait, il y a une vraie transition à effectuer de beaucoup d'entreprises qui ont des modèles où l'humain est réellement au centre. Là, Application non plus n'est pas réellement au centre. Typiquement, cette équipe sécurité est souvent vu comme un ennemi du développement. C'est malheureux, mais c'est que, bah, on les prend un peu pour des empêcheurs de tourner en rond. C'est dire que leur travail, c'est la sécurité, c'est de s'assurer que ça fonctionne bien à la fin. Mais comme on leur parle beaucoup trop tard, ça ne fonctionne pas bien et ça crée des divergences énormes dans les entreprises. Donc, là, c'est pour ça aussi, on parle de transition des veuves. C'est vraiment beaucoup de ses romans. Une question organisationnelle et je sais que moi, pour moi personnellement, c'est très difficile d'agir là-dessus, que comme je suis indépendant, je suis tout seul par nature. Donc, arriver tout seul dans une grosse restructure et dire: vous organisez mal en terme de structure parce que on a besoin de se parler tous ensemble, parfois, c'est quand même un discours qui a du mal à passer et c'est là qui fait que notre métier est quand même assez difficile. Il y a une grosse composante organisationnelle: restructuration des équipes et communication inter équipes. Faire entrer en jeu par douze questions. Je viens de parler de grosses structures. Tout à l'heure, xavier talon, dans son introduction, a parlé de petites équipes. Est-ce que cette approche, culture, philosophie, devops? S'applique à tout type de projet et quelle est la différence entre appliquer des veuves dans une équipe de développement et d'aide opérationnelles qui toute petite, nette par nature, donc une petite structure, et qu'elle elle dit le défi de le faire dans une grosse structure, comme vient de le citer? Romain, donc une grande banque ou une grande collectivité que c'est? je suppose que les défis ne sont pas les mêmes et il est la mise en œuvre n'est pas la même, xavier talent. C'est, c'est des problématiques qui sont de deux niveaux différents et c'est ce qu'on va appeler la mise à l'échelle. Et donc, vous avez des méthodologies qui permettent, qui commence à expliquer comment est-ce qu'on peut faire de l'agilité scrum, par exemple. Des méthodes qui sont quand même, c'est une des méthodes qui, c'est une méthode qui permet de faire sa formule d'agilité et, effectivement, déjà, on sapé Soit que la problématique de faire des petites équipes avec toutes les compétences pour un petit projet n'est pas simple. Mais alors quand il s'agit de traiter un parc global ou des applications qui sont ce qu'on appelle des monolithes et des crocs aux applications énorme avec énormément de fonctionnalités, etc. Ça devient beaucoup plus compliqué. Et là, du coup, si on veut, L'agilité le développe son lui-même. En termes d'équipe, ça n'a pas marché si on a des centaines de personnes. Or, on a forcément des niveaux, des parcs applicatifs et des applications. Même unique qui demande? Deux, deux, deux, deux, d'organiser un très grand nombre de personnes. Et donc, du coup, comment est-ce qu'on va faire? et donc, il faut réussir à décomposer les problématiques pour que différentes petites équipes puissent traiter chacune un bout, sauf que, du coup, faut assurer la cohérence. Donc, il va falloir trouver un cadre méthodologique pour réaliser ça et ça devrait. C'est compliqué. On a des méthodologies qui arrivent, qui sont mises en place, qui sont vraiment des méthodologies pour le coup assez complexes, typiquement self, qui est une une méthodologie de monter à l'échelle pour créer de nouveaux cef, en anglais. Tout à fait. Et qui a justement pour objectif de démontrer ou de d'organiser une un système d'information pour qu'on puisse traiter à l'échelle selon la méthodologie. Agile devops. Des parcs beaucoup plus importants. Mais c'est. C'est là aussi assez compliqué. Ce n'est pas la seule méthodologie, et c'est des méthodologies qui, du coup, devraient se prêter un petit peu à toutes les caractéristiques de chaque système d'information spécifique. On a un ensemble de technologies qui peuvent être extrêmement différents. Des organisations de de de compte, qui peuvent être complexes à gérer, fait des vrais chantiers de transformation. Ils sont vraiment importants et qui sont difficiles à mettre en oeuvre. Typiquement, il faut considérer qu'il faut une bonne dizaine d'années pour transformer l'organisation. D'un grand compte pour aller de fin de deuil d'une organisation classique. Qui peut y t-il qu'on pourrait les avoir avant? et ça pourquoi? puisque toutes ces nouvelles méthodologies et ses approches agiles sont très différentes, sont très clivante par rapport aux organisations qu'on avait avant. On avait tendance, effectivement à structure. Silo t on a une culture d'entreprise qui est: Construite et qui s'est consolidée pendant trente ans, quarante ans sur ces modèles, qui visait justement à découper, à siffloter, a stratifié et organisé par communication, par des outils de communication de passage entre les équipes. Et, en fait, il s'agit de déstructurer tout ça et de remettre une organisation, effectivement, qui est Complètement à l'opposé et c'est d'une complexité énorme. Le problème n'est pas technique, c'est-à-dire que le développe sa mise en place. On sait comment faire, on sait trouver les cibles, mais il y a rien de plus difficile que modifier les usages, la manière dont les gens travaillent. L'organisation. Faire du devops. C'est aussi un nouveau type de métier, des nouvelles manières de gérer du personnel. Donc, c'est aussi une remise en cause des haches des budgets, c'est une transformation très globale du système d'information à leurs questions. On va s'adresser plutôt. Bien compris une problématique de grands comptes autres. Je suppose qu'il faut un engagement très fort de la direction générale. Et c'est quoi la première approche que vous avez pour les convaincre de se dire: on va se lancer dans un chantier de dix ans pour refont toute l'organisation. C'est quoi? c'est le fait de produire des logiciels de meilleure qualité? est-ce que c'est le plaisir des équipes qui vont travailler, parce que, justement, ils vont travailler différemment, donc avec plus de plaisir? c'est quoi? Votre première approche pour, pour essayer de convaincre déjà de se lancer dans cette étude: migration vers une approche devops. Romain, et puis xavier. Après, on a l'inverse comme vous voulez. En fait, moi, j'ai, dans mon expérience, Dans mon expérience, c'est que les entreprises m'appellent parce qu'ils ont déjà mis en place ou disaient: ils ont la volonté de se mettre en place. Cette transition développe en fait. C'est-à-dire que, de mon point de vue, la transition et surtout Basé sur la technique. En fait, c'est que, techniquement, les applications ont énormément évolué ces dix dernières années, avec surtout l'arrivée des d'éclats ou de l'éclat de public, donc l'informatique en nuage, en français. C'est donc une nouvelle manière, on va dire, de gérer sa production. Ce sont des produits qui coûtent cher, qui ont besoin de nouvelles compétences pour être utilisés et donc, à partir de là, l'amisom production est plus simple. Mais c'est surtout des problématiques, je vais dire, de marcher, en fait, qui donc incite les Reprise à vouloir déployer plus vite, plus rapidement et plus souvent des nouvelles fonctionnalités, d'être plus agiles d'en bas, comme l'agilité d'un sportif, de pouvoir bouger plus facilement et plus rapidement pour réagir aux utilisateurs, aux usages. Et c'est cet usage, on va dire d'utilisateur final, qui pousse les entreprises à se remettre en question et à faire cette transition de deux. Mon expérience, ce n'est pas des prestataires comme moi qui viennent d'accord pour pousser cette transition, c'est le client me demande: nous voulons transition vers un modèle des vols, vers un modèle plus agile, plus rapide, et c'est à partir de là que les problèmes commencent, parce que ils sont clairement pas structurés de cette manière-là pour la plupart des grosses entreprises. Et, effectivement, c'est beaucoup plus facile pour des petites équipes d'être agile et d'être développe, parce que en étant une petite équipe, on se parle beaucoup plus facilement. Les problèmes viennent justement avec cette mise à l'échelle des grosses entreprises. On est cinq mille, c'est quand même difficile de connaître tout le monde. Deux, et de partager et de communiquer. Je suppose la problématique est la même pour ernest et je suppose peut-être- mais tu vas me confirmer ou infirmer, xavier- que vous avez peut-être une démarche un peu plus proactive vers vos clients actuels ou vers de nouveaux clients pour leurs- entre guillemets- leur vendre l'intérêt d'une démarche devops. Alors on a, comme le disait romain, on n'a pas vraiment besoin de le défendre aujourd'hui. C'est une évidence de dire que les clients, depuis un certain nombre d'années. Se retrouve effectivement avec, quelque part, une organisation, un existant qui est lourd, qui est difficile, et ils vont se retrouver souvent en concurrence avec des sociétés qui se mettent immédiatement en partant de rien, dans un mode d'organisation beaucoup plus facilement agile. Puisqu'ils partent de rien, ils ont Toutes tout, tout ça adapté. Et, en fait, ils ont pas le choix. Ils se retrouvent de facto face à des concurrents qui, quant à eux, il leur faudra six mois, un an, sinon plus, pour sortir un nouveau produit, le même produit, avec le même niveau de conception. La fintech, qui est à côté, par rapport à une banque, par exemple, va peut-être pouvoir, diront que c'est une entreprise doit financer ça. Oui, voilà, mais, garçons, sur un mode un petit peu, société nouvelle génération qui, immédiatement, va arriver sur le marché et pouvoir s'organiser, eux, sans avoir l'historique, sans avoir à gérer leur existence. Donc, à partir de ce moment-là, pour eux, c'est vital. Donc, de toute façon, la plupart de nos clients, Ces grands comptes sont ne n'ont pas vraiment le choix. Il faut pouvoir adapter les mêmes. Un outil, les mêmes démarches, les mêmes capacités, qu'on la concurrence. Après. Quand je disais tout à l'heure: il faut une dizaine d'années. Pour, pour se transformer, pour arriver à maturité. Bien évidemment, on peut commencer à faire des choses, à transformer, par étapes. D'information. Voilà, en mettant les choses maintenant. Ce simplement, et en plus, les évolutions technologiques et tous les nouveaux outils dont on dispose permettent de faire beaucoup de choses après, pour réussir à transformer une organisation. A tous ces niveaux dont on parlait aussi bien à la finance. La gestion, l'organisation, la gouvernance. Évidemment, ça prend beaucoup plus de temps, mais- et la plupart des grands comptes français ont commencé leur transformation vers ces objectifs là il y a déjà cinq, sinon plus il y a quelques années- souvent des chats depuis sept, huit ans. D'accord, on va faire une pause musicale et après la pause musicale, on va avoir un peu plus en pratique, comme on commence. Ça se met en place dans des organisations. En attendant, nous allons écouter un instant par cheap et odyssée us. On se retrouve dans environ deux minutes. Belle journée à l'écoute de cause commune, la voix des possibles.

Nous venons d'écouter un instant- par type et odyssée disponible sous licence libre. Retrouvez toutes les musiques diffusées au cours des émissions sur cause commune. Point f m est sûr, libre à vous. Point org library- libre à vous. Libra l'émission de l'april sur les libertés informatiques, chaque mardi, de quinze h trente à dix sept heures sur radio cause commune, puis en podcast.

Deuxième partie = Eve

Frédéric Couchet :

Chronique « Le libre et la sobriété énergétique » de Vincent Calame, bénévole à l’April = Marie-Odile

Frédéric Couchet : Nous allons poursuivre

Vincent Calame  :

[Virgule musicale]

Quoi de Libre ? Actualités et annonces concernant l'April et le monde du Libre = Marie-Odile

Frédéric Couchet :