Hey, bienvenue à toi cher compagnon ! Tu as entendu ? Ouais, on a une nouvelle intro !
Ça swing n'est-ce pas ? Bon, c'est un tronc, on l'a doit à Baptiste, Baptiste il m'a
contacté et il a bien voulu faire une nouvelle intro pour Radio DevOps et il
est en train de faire la route trop donc on verra plus tard la route trop. Bon, je
suis content de te retrouver pour ce nouvel épisode et aujourd'hui, ça va être un
épisode un peu plus intime pour moi parce que je vais te confier pourquoi
est-ce que le DevOps me tient autant à coeur et pourquoi je fais autant de
choses autour de ce mouvement là ? En fait, ça tient vraiment à mon histoire
personnelle et ce que j'ai vécu dans ma vie professionnelle donc ça va être un
peu l'instant story time du Radio DevOps donc du coup, prends un petit
café, un petit thé, installe tout et puis on va discuter tous les deux et
puis si ce que je dis dans cet épisode te parle, eh bien, viens en discuter au
sein de la communauté. Mais tout d'abord, si tu me connais pas, moi c'est
Christophe et je suis consultant indépendant au sein du collectif Lidra et on
aide nos clients à déployer leurs applications rapidement et sans couper
leur service. On les aide aussi à faire des transitions des DevOps. Je crée aussi
du contenu puisque j'anime ce podcast et je fais des vidéos sur YouTube autour de
l'huit laps. On va se projeter en arrière, on était dans les années 2000-2006.
En 2006, j'ai commencé à travailler pour une SS2I. Donc maintenant, ça s'appelle les ESN.
Elles ont changé de nom pour faire oublier ce qu'elles étaient mais bon,
elles n'en reste pas moins des marchands de viande mais c'est pas grave. L'idée,
en fait, c'est que j'ai commencé en 2006 dans une SS2I et puis j'ai
envoyé à un grand groupe de grandes distributions à Saint-Etienne et j'ai commencé à travailler
pour un service qui s'appelle la gestion des applications. C'était pour monoprix chez Casino.
Je gère l'infrastructure informatique de monoprix hors développement.
J'ai passé sept ans. C'est long dans une carrière,
surtout dans une carrière d'OPS. Mon travail en gros consistait à mettre en place les
applications sur les serveurs, les déployés et s'assurer que tout fonctionne bien. C'est
ce qu'on appelle le MCO, maintenant, son condition opérationnelle. Pourquoi je te raconte tout ça?
En fait, c'est parce que le gros de mon quotidien, c'était de déployer des applications.
Donc il faut savoir que déployer des applications dans des grands groupes comme ça,
c'est prendre les livrables que les développeurs te fournissent, les installer sur les machines que
les administrateurs systèmes te fournissent ou que tu demandes aux administrateurs systèmes et
s'assurer après que tout fonctionne bien. Autant de dire que t'as pas vraiment la main sur les
machines, même si tu es compétent en une X-Linux, tu ne vas pas vraiment pouvoir trifouiller.
Donc ça veut dire que tu es forcément dépendant des autres services, les administrateurs systèmes,
les services de stockage, les services qui gèrent les bases de données parce qu'il y a des DBA,
les services qui gèrent les middleware puisque on l'utilisait Tomcat à l'époque,
puis c'est pas nous qui les installions, c'était un autre service. Donc à chaque fois qu'il fallait
faire du tuning sur les applications pour améliorer leur performance parce qu'évidemment,
c'est nous qu'on appelait dès qu'il y avait des problèmes de performance. Nous on centralisait
un peu tout ça. Un ternacle point d'entrée et on dispatchait au service, surtout qu'en plus,
on était le seul service vraiment en rapport avec Monoprix qui n'était pas synthétienne mais à
Paris. Donc du coup, on encore donnait tout ça. Et donc ce qu'il faut savoir c'est que dans ces
grands groupes, et je pense que c'est encore le cas pour beaucoup, il y a beaucoup de friction entre
les services et vraiment des guerres. Il faut savoir que dès que tu demandes quelque chose à un autre
service, surtout s'il y a un problème de performance ou autre, ils vont se sentir un peu
pris en défaut. Et donc ça va commencer à discuter mais pourquoi ? Pourquoi tu veux faire ça ? Pourquoi
si ? Pourquoi ça ? Attends, on va regarder et puis ça prend des plombes. Ça prend des plombes à
faire évoluer les choses. Ça prend des plombes vraiment à ne serait-ce que comment ça se passe
l'installation d'une application dans ces entreprises-là. Moi je m'occupais d'un hotel,
l'Hôtel Informatica et j'avais créé un programme de déploiement qui en une seule ligne de commande
prenait le livrable que nous donnaient les études, les développeurs et l'installait dans Informatica.
Le tout en l'une ligne de commande alors qu'avant il fallait faire plein de trucs. Ok. Donc ce qui
veut dire qu'en fait j'étais capable de livrer, enfin tout le monde en fait dans le service,
c'était capable de livrer une nouvelle livraison au hotel en moins de deux minutes. Ouais, tu te
connectes sur le serveur, tu tapes la ligne de commande et pouf c'est livré. Mais sauf qu'en
fait le plus long dans la livraison c'était la lourdeur administrative. On utilisait un outil de
suivi ITSM, donc ITSM c'est pour la gestion des services informatiques, c'est très utilisé dans les
boîtes qui font du utile. En gros dès que tu demandes un truc à un autre service, tu dois faire
une demande, tu te connectes sur le boutique, tu fais la demande, tu remplis 15 champs, 20 champs,
30 champs, je sais même plus combien il y avait de champs à remplir. Les développeurs ont demandé
un bordel au lieu de livraison Excel où il fallait qu'ils mettent les infos, le nom du livrable,
qu'est-ce que ça touchait comme base etc. Pour eux j'imagine même pas la lourdeur que ça devait
être. Et puis pour nous à chaque fois on recevait les livraisons et il y avait une demande associée.
Le plus long c'était de qualifier la demande, l'ouvrir, télécharger le bordel au lieu de livraison,
prendre le nom du livrable, vérifier que le livrable était bien sur le serveur de livraison
et puis livrer. Et une fois qu'on avait livré on vérifiait que tout se passe bien et là on
renvoyait soit la demande aux développeurs s'il y avait un problème, soit on la clôturait.
Donc autant dire que quand tu fais ça toute la journée, ne serait-ce que même deux après-midi
ou deux matinées par semaine, t'en as vite marre, tu trouves ça ennuyeux. Et donc forcément moi je
m'en nuiais sérieusement. Parce qu'une fois que j'avais automatisé les déploiements,
une fois que j'avais automatisé la livraison des war, une fois que j'avais automatisé,
on échangeait aussi plein de fichiers entre plein de serveurs, tout ça. Et bien un bout d'un
moment tu commences un peu à tourner les pouces et tu te poses des questions parce que bon cette
ambiance là elle est quand même pesante parce qu'entre les services c'est lourd. C'est lourd,
vraiment les réunions c'était lourd, les déploiements c'était lourd parce que comme je crois que je
l'ai abordé dans un épisode, mais tu passes deux réunions de deux heures avec 15 ou 20 personnes
pour expliquer comment tu vas livrer. C'est pesant à l'époque, je commençais juste à découvrir
Geat et si j'avais connu Geat à l'époque, sérieux, les développeurs ils ont un Geat push,
hop une intégration continue, elle génère le package, elle déploie automatiquement sur notre
environnement de développement, notre environnement de pré-production et puis voilà, rouler jeunesse,
on parle plus d'outils TSM etc. Non c'est tout automatisé et du coup on a le temps de faire
autre chose. Mais bon c'était pas le cas et je suis pas sûr que ce soit encore le cas chez beaucoup
d'entreprises. Alors là on est en 2011-2012 et je me pose des questions quand même sur mon avenir
et sur ce que je fais ici parce que c'est quand même... et moi j'avais envie de beaucoup d'autres
choses, j'avais envie de plus d'automatisation, plus de liberté dans mes choix d'outils, plus de
robustes tests évidemment dans la livraison des outils, je voulais avoir plus de robustes tests
et plus de robustes tests dans les applications et puis surtout une sérénité de travail plus
importante parce qu'à chaque fois qu'il y avait un problème ça tombait sur nous, c'était compliqué,
il fallait qu'on aille voir, j'imagine notre service gérer une cinquantaine de serveurs,
il n'y avait même pas de centralisation des logs. Dès qu'il y avait un problème, il fallait se
connecter sur les logs, il fallait trouver la bonne log et puis il fallait regarder, il fallait faire
des croisements entre les logs. Enfin bon, bref. Du coup à ce moment là en flanant sur le net,
j'ai découvert qu'en fait j'étais pas seul dans ce cas là, j'étais pas seul à se poser
ce genre de questions et qu'il y avait un mouvement même qui avait émergé à un mouvement dont
j'avais jamais entendu parler mais bon forcément je ne m'intéressais pas vraiment à ce qu'il se
faisait en dehors de ma mission et ce mouvement c'était le mouvement DevOps et donc là ça a fait
tilt dans ma tête, j'ai fait... Ouais il faut que j'aille par là, il faut que j'aille par là et puis
j'en ai parlé à mes managers puis comprenez pas, comprenez pas ce que je voulais faire,
bref bon bah. J'ai fini par quitter la boîte au bout d'un moment et puis à me mettre à mon compte
pour justement explorer ça, le mouvement DevOps. Là on est en 2015 et je me lance en tant que frilance,
en tant qu'administrateur système frilance qui applique le mouvement DevOps. Bon à l'époque
je me présentais comme tout le monde au début, j'ai fait les erreurs de dire que j'étais DevOps
et tout, j'en suis vite revenu, enfin vite, quelques années après quand j'ai commencé à vraiment
comprendre un peu la philosophie du mouvement. Au début on cherche surtout à automatiser son travail,
à améliorer ses outils et puis après une fois qu'on a fait ça on s'interroge quand même sur nos
pratiques et nos méthodes et là vraiment c'est la philosophie qui rentre en compte. Et avec le recul
je m'aperçois qu'en fait tout ça a été bénéfique parce que non seulement en effet j'ai pu obtenir
ce que je voulais c'est à dire plus d'automatisation dans mon travail, plus de liberté, plus de robustesse
et vraiment la sérénité elle est là, le mouvement il est là et puis surtout je m'aperçois qu'en
fait quand une entreprise elle fait une transition des DevOps, quand vraiment tout le monde se met
dans le mouvement, quand ils prennent un bras le corps en fait toutes ces bonnes pratiques,
toutes ces méthodes, cet état d'esprit, quand ils sont dans l'amélioration continue, et bien il y a
de la sérénité au travail et les membres des équipes finalement travaillent ensemble. Et c'est plus
en fait l'objectif du service qui va être important mais c'est l'entreprise et tout le monde a
en tête cette entreprise et le bien de cette entreprise et tout le monde va travailler ensemble
pour améliorer les outils d'entreprise et surtout performer, faire que l'entreprise se porte encore
mieux et soit plus efficace. Et ça je trouve que le côté humain dans le mouvement des DevOps est
le plus important, enfin pour moi c'est vraiment le point fort de ce mouvement là, c'est le mouvement
humain, la coopération entre les gens et ça on en parle assez peu, c'est pas vraiment ce qui
intéresse les directeurs, les managers, eux ce qui voit c'est oui on va livrer plus rapidement,
oui on va livrer des applications plus robustes, oui notre système d'information il va être plus
robuste plus souple, il va s'autoréparer, oui tout ça c'est cool mais les hommes, les femmes qui
créent ces logiciels qui installent et qui maintiennent le système d'information, ils soufflent,
ils respirent, ils travaillent ensemble, ils aiment ce qu'ils font, ils retrouvent du sens à leur
travail et ça pour moi c'est vraiment le point le plus important de ce mouvement là, c'est comment
est-ce que les équipes vont se retrouver, comment elles vont retravailler ensemble et en travaillant
ensemble elles vont apporter beaucoup de choses à l'entreprise et ce n'est pas uniquement des
indicateurs comptables ou techniques qu'on doit mettre en place quand on fait une transition des
Vops pour moi et là je vais parler en tant consultant, pour moi on doit aussi mettre en place des
indicateurs de bien-être au travail, de coordination, de coopération et de productivité et tous ces
indicateurs vont nous montrer qu'en fait les gens sont bien mieux dans une entreprise où on a
passé au mouvement des Vops que dans une entreprise on l'a pas fait et ça je voulais le partager avec
toi parce que c'est pour ça que ça me tient autant à coeur, c'est pour ça que le dévops pour moi a
pris une telle importance dans ma vie ces dernières années, c'est parce que je pense que ben on n'est
pas fait pour faire des guerres entre les services, on est fait pour travailler ensemble et parce que
l'entreprise c'est elle qui est importante au final parce que on travaille pour une entreprise,
on a rejoint une entreprise, on a rejoint un esprit d'entreprise et pourquoi est-ce qu'on l'oublie en
fait, pourquoi est-ce qu'on n'est pas tous les jours en train de penser mais c'est quoi le but de
notre entreprise et qu'est-ce qu'on va faire pour elle parce que si on fait des choses pour elle,
elle elle fait des choses pour nous. Donc voilà c'était un petit épisode un peu plus personnel que
d'habitude et j'espère que ça t'a plu, j'espère que du coup tu le partagera autour de toi, que tu
partageras cette vision que que la vision du bien-être des femmes et des hommes qui font
les services informatiques sont peut-être plus importants qu'en fait le nombre de livraisons
qu'on fait par jour ou l'automatisation, le niveau d'automatisation ou mettre en place
Kubernetes ou ce genre de choses. Alors c'est super important mais ça l'est peut-être moins. Voilà
dis-moi ce que t'en penses en commentaire ou alors ben rejoint la communauté des compagnons pour en
vidéo DevOps. La balle de diffusion des compagnons du DevOps est produite par l'Hydra. Si l'épisode
t'a plu, note le plus la note sera élevée et plus il sera mis en avant dans les applications.
Tu peux aussi le partager cela nous aidera à le diffuser et à rendre le mouvement beaucoup
plus visible. Si tu es envie de discuter du mouvement, le plus simple c'est que tu rejoins
de la communauté des compagnons du DevOps. Le lien est en description. À bientôt !