Ludovic Pio fait grosso modo le même métier que moi.
Il est architecte collode et aide les entreprises dans leur transformation des Vops.
Mais il partage aussi beaucoup en conférence.
Vous trouverez Pléthor de conférence de lui sur Youtube.
Je vous mets un petit lien en description,
vous verrez, il y a plein de conférences que vous pourrez aller voir.
On va parler tous les deux de l'administrateur système des Vops,
entre autres, donc restez bien jusqu'à la fin.
Bienvenue sur Radio des Vops, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes,
abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour à toi chers compagnons,
et bienvenue dans ce nouvel épisode d'En apparté,
l'émission où je m'entretiens avec un invité.
Avant de commencer,
je te rappelle que j'ai créé une communauté en ligne francophone dédiée au DevOps,
et justement, l'invité du jour fait partie des compagnons du DevOps.
Tu peux nous rejoindre pour discuter avec nous,
c'est le premier lien en description pour t'inscrire.
Bonjour Ludovic.
Salut !
Bienvenue dans le podcast.
Est-ce que tu peux justement te présenter en quelques mots
pour les auditeurs et d'électrices qui ne te connaîtraient pas,
nous dire ce que tu fais un petit peu dans la vie ?
Ouais d'abord, merci beaucoup de m'inviter.
En fait, assez bizarrement, c'est mon premier podcast.
Alors que j'écoute des podcasts depuis super longtemps,
c'est mon premier court podcast, donc je suis très honoré déjà,
et puis je suis très touché de faire ce premier podcast.
J'ai envie d'en faire depuis des années.
Alors qui je suis ?
Je suis Ludovic Pio, et en fait, on va passer assez vite, je pense, à la suite,
parce que je pense que dans la suite, je vais vous raconter un petit peu mon histoire.
Rapidement, en fait, moi à la base, je suis biologiste marin,
donc je m'occupe des orcs et des dauphins essentiellement,
et à mon donné, en fait, l'Internet est arrivé en France,
et donc j'ai sauté dans cette activité-là,
parce que les orcs et les dauphins, finalement, en région pasienne, il y en avait assez peu.
Donc il y avait des débouchés professionnels assez limités.
Et puis comme l'informatique était quand même une grande passion pour moi,
et que finalement, je suis né avec l'informatique,
Apple a été créé à l'époque où j'ai appris à lire,
l'Internet était arrivé grosso modo quand j'ai eu mon bac,
enfin voilà quoi, l'histoire de l'informatique est connexe à ma propre histoire,
et donc en fait, assez naturellement, j'ai versé dans l'informatique
quand j'avais une vingtaine d'années, et donc je fais du DevOps depuis très longtemps.
Du coup, on a grosso modo le même âge peut-être alors.
J'ai 47 ans.
Tout petit peu plus avec moi, mais pas beaucoup.
En fait, t'es tombé dans l'informatique un peu plus tard que moi,
du coup, moi je tombais vraiment quand j'étais ado en fait.
Ah mais attends, moi mon premier machine, ça s'appelait Videopac.
Il y avait un autre nom qui était Odyssey2,
sur lequel on codait en assembleur.
J'ai fait une partie il y a quelques jours avec ma fille.
C'est vraiment les trucs avec les gros pixels,
mais vraiment c'est avant les 8 bits,
avant les ordinateurs 8 bits qu'on a connus, c'était du 8 bits bien sûr,
mais c'est avant les ordinateurs 8 bits qu'on a connus.
C'était un truc à cartouches,
et franchement j'ai eu ça, je devais avoir 6-7 ans.
Ah oui, quand même.
D'ailleurs, si je me trompe pas, il y a un Macintosh derrière toi.
Alors derrière moi, il y a un Macintosh Plus,
et en fait il y a 42 machines derrière,
dont un Macintosh Plus et un X qui vient du cerne,
si vous ne vous plaisez pas.
C'est décollé, bon peut-être qu'à jour je verrai ça.
Ecoute, merci.
Je vais te poser les questions rituelles que je pose à tous mes invités.
La première c'est, et c'est la plus importante selon moi,
c'est quelle est ta définition du DevOps ?
Alors pour moi le DevOps, c'est d'abord un objectif,
et c'est une démarche.
En fait cet objectif, on le recherche à travers une démarche.
L'objectif quelque part, c'est revenir à du pragmatisme,
revenir à de la réalité.
Et c'est surtout, enfin pour le dire concrètement,
c'est aligner l'ensemble des acteurs
et des compétences du système d'information
sur la seule chose qu'il va et qui est la qualité du produit
restitué à l'utilisateur.
Et ça pour moi c'est l'objectif principal du DevOps.
Et pour y arriver, il y a une démarche,
et cette démarche, elle consiste,
on pourrait la régimer en une ligne,
c'est arrêter avec des processus shadow.
Pour le dire de façon un petit peu plus corporate friendly,
ça veut dire,
engager l'ensemble des acteurs sur la chaîne de production de valeur.
Donc déjà, il y a une question d'engagement,
vraiment avoir un alignement de ces acteurs
sur la chaîne de production de valeur,
leur rappeler quelque part en fait avoir
une démarche d'animation de cette équipe,
enfin de ces acteurs,
sur le fait qu'ils se sont engagés à fournir un produit de qualité.
Et ça doit passer par un certain nombre de facilitants.
Ces facilitants, c'est d'abord une collaboration libre et sans contrainte.
Et je vais revenir dessus quand on va parler d'automatisation,
parce que évidemment l'automatisation est un des lecteurs,
mais pour moi le premier truc, c'est la collaboration libre et sans contrainte.
Et le souci de l'amélioration continue,
ça c'est vraiment dans l'état d'esprit.
Dans les facilitants,
il y a aussi la question du partage d'information en temps réel,
et donc c'est-à-dire, on fait pas un email,
on attend deux jours pour avoir l'info,
en fait c'est l'info,
quand quelqu'un l'a gêné,
cette info est immédiatement restituée à l'ensemble des acteurs de la chaîne de valeur.
Donc un partage de l'information est bien entendu le partage de responsabilité
qui va avec ce partage d'information.
Ça c'est souvent évité,
ou c'est souvent mis sous le tapis,
ou c'est souvent retardé dans l'arrivée,
lorsqu'on fait une transfo.
Et puis c'est évidemment le partage d'outils et de méthodes communes.
On n'a pas l'outil de collaboration de l'équipe A
et l'outil de collaboration de l'équipe B,
et ces deux outils n'ont rien à voir l'un avec l'autre,
parce qu'on collabore beaucoup moins bien avec chacun son outil quand même.
Et puis c'est l'automatisation.
Mais pour moi l'automatisation,
très souvent quand on aborde l'automatisation en DevOps,
on oublie un truc, c'est que l'automatisation,
c'est une première rôle,
c'est d'étendre au maximum l'autonomie des différents acteurs
en dehors de leur propre champ de compétences.
C'est-à-dire que l'automatisation, elle est là
pour remplacer l'expert
à qui on aurait demandé de faire quelque chose.
Et donc en fait, l'automatisation,
on peut l'utiliser en self-service.
Pour moi l'automatisation, elle n'est intéressante
que si elle est consommée en self-service.
Voilà.
Et pour moi, le DevOps, c'est ça.
C'est-à-dire cet aliment de l'ensemble des équipes
autour de ce terrain de jeu commun.
Ça crée des finitions.
J'espère que c'est pas ça que tu sers à t'écrire,
parce que c'est un peu long du coup.
Alors c'est un peu long, mais finalement ça tient assez bien.
Mais j'ai pas l'habitude d'être très court.
Non mais la phrase que tu as dit au début,
en plus, se rapproche assez bien de la mienne.
Et du coup, le DevOps, tu l'as rencontré comment,
à quel moment dans ta vie, et surtout,
qu'est-ce que ça a changé dans ta vie en fait ?
Parce que moi je sais que ça a eu un gros impact dans ma vie
quand je me suis rendu compte de ce mouvement-là.
Alors je vais avoir une réponse longue et en deux temps.
Parce que le DevOps, je l'ai rencontré en deux étapes.
Enfin, je l'ai rencontré en deux temps.
Le truc, c'est que moi, comme je vous l'ai dit,
je suis un autodidacte pur en informatique.
C'est-à-dire que je crois que j'ai eu 4 heures de Pascal
dans ton cursus étudiant, universitaire, etc.
Et c'est en tout et pour tout ce que l'intégralité
de mon cursus informatique dans le lors de mes études.
Donc je suis un pur autodidacte et donc ma carrière,
ça a commencé par du poste de travail.
Donc elle est branchée des câbles,
ce genre de trucs, des souris, etc.
C'est sur du Macintosh d'ailleurs.
Ensuite, j'ai fait de l'exploitation.
Donc vraiment, le pupitreur qui vient sur son GECOS
qui n'a même pas d'écran en fait, c'est le clavier.
Et puis c'est une restitution,
après-caractère, sur une imprimante maficière.
J'ai fait aussi l'exploitation
sur des espèces de gros photocopieurs
à base de Sun Solaris.
Et puis de fil en aiguille, en fait,
j'ai fait un petit peu de devres.
Alors d'abord du devre de gestion.
Puis ensuite, j'ai fait du devre d'outils système.
En particulier, j'ai fait un espèce d'outil déploiement
père à père avant qu'on ait des histoires
de Pierre Toupir un peu standardisé.
Et puis j'ai fait de l'admine,
à peu près de l'admine de tout ce qui existe.
C'est-à-dire de l'admine aussi bien Exchange,
Windows, Linux, Solaris, IX, base de données,
Oracle, PostgreSQL, SQL Server,
enfin la totale, SideS.
Et puis, en fait, à partir de 2003,
avec ces différentes casquettes, finalement,
j'ai été un espèce d'acteur un petit peu particulier,
un espèce de moutour, un sang de pâtes.
Et donc, en fait, les projets sur lesquels je suis passé,
j'étais un petit peu cet espèce de nœud intermédiaire
qui savait parler au développeur,
qui comprenait leurs exigences, leurs enjeux, etc.
mais qui comprenait aussi les enjeux de la production,
puisque j'avais fait du 24-7,
j'avais fait de l'exploitation au sens strict du terme,
suivre un ordonnanceur de prod et sur un autre truc,
être réveillé la nuit.
Et donc, en fait, j'étais un petit peu à la croisée
de tous les chemins, ce qui fait que quand il y avait,
à l'époque, je bossais chez Accenture,
et quand il y avait un blème entre le plateau projet accentuuriens
et l'ensemble des acteurs du client,
c'est moi qui en envoyais parce que, globalement,
je savais parler à l'ensemble des gens,
et j'avais finalement le relationnel et la compréhension,
j'allais dire l'empathie,
mais c'est pas une question d'empathie,
c'est une question de culture, en fait.
J'avais cette compréhension de quelle était la réalité
de mon interlocuteur, et donc, à partir de là,
je savais ce qui lui posait problème.
Très souvent, quand on a un interlocuteur,
il ne s'est pas oralisé,
il ne s'est pas verbalisé ce qui lui pose problème.
C'est crainte, et la plupart du temps,
en fait, il faut aller le débuter cet élément-là.
Et pour le débuter, quelque part, il faut comprendre sa réalité.
Et donc, moi, comme j'avais fait des années de vie ma vie auparavant,
j'ai commencé ma carrière en 1998,
et j'ai commencé cette espèce de rôle d'intermédiaire,
de médiateur en 2003-2004.
Et donc, en fait, pendant cinq ans,
j'avais eu suffisamment d'expériences térins
dans les différents postes
pour avoir fait suffisamment de vie ma vie,
pour comprendre ces acteurs-là.
Et donc, ça a été ma première approche du DevOps,
puisque globalement, c'était ça, en fait.
C'était rapprocher les devs, les obs, les admins,
les exploitants, les architectes, etc.
Les chefs de projet.
Donc, c'était déjà un petit peu du DevOps avant l'heure.
Et en particulier, à cette époque-là,
j'ai commencé à faire de l'infrascode.
Sur des server-lams en Windows,
alors, il y avait un outil qui s'appelait Alt-Tri-SRDP,
évidemment, on soit bien clair.
Je savais pas que c'était du DevOps,
parce que le mot n'existait pas.
Mais déjà, à cette époque-là,
j'ai commencé à faire de l'infrascode,
donc sur des server-lames HP,
avec un outil de déploiement, donc,
Headless, qui s'appelait Alt-Tri-SRDP,
qui détectait les événements du type
« je râque une lame, je sors une lame,
ma lame est déjà installée,
ma lame n'est pas installée, selon du truc ».
Et donc, derrière, on pouvait trigger
tout un tas d'orchestrations,
d'automatisations, etc.
Ce qui fait que je me suis amusé
comme un petit fou à faire de l'infrascode.
En voilà, dès cette époque-là,
c'était en 2003.
Donc ça, c'est ma première rencontre
avec le DevOps.
Mais quelque part, j'étais Monsieur Jourdin,
j'étais quelqu'un qui faisait, sans savoir,
et...
Et surtout, je me sentais bien seul,
parce qu'évidemment, je rentrais
dans aucune case, et surtout, je bossais
à l'époque pour Accenture,
qui avait une vision très utileienne,
des rôles et compétences
des acteurs sur un projet informatique.
Et donc, je me sentais vraiment
hyper seul.
Donc, ça m'amène à la deuxième partie
de la réponse, qui est,
j'ai rencontré le DevOps au moment où ça a émergé.
C'est-à-dire, en fait,
moi, j'ai eu une formation
avec Martin Fowler.
Donc, je suis un pur Martin Fowler
disciple.
Et donc,
c'était en
l'entour de 2010, où vraiment,
là, pour le coup, j'ai rencontré vraiment
le terme de DevOps.
Et nous, surtout,
j'ai fait partie
d'une tribu à l'époque, j'étais chez Octo,
d'une tribu qui était la tribu des DevOps.
Et là, pour le coup, qu'est-ce que ça a changé ?
Déjà, ça a changé que j'avais l'impression
d'avoir des perres, j'avais l'impression
de faire partie d'une communauté
qui existait. Et puis, surtout,
j'avais l'impression
que mon travail était valorisé.
C'est-à-dire que jusque-là, j'étais un espèce
de, comment dire, un espèce de couteau
suisse, le mec qui vient fixer, mais un type
un petit peu, comment dire,
le type un peu débrouillard, quoi, l'espèce
de MacGyver du projet informatique.
Et puis, d'un seul coup, en fait,
je me suis rendu compte que c'était
un poste, que c'était un rôle,
que c'était une activité
qui était pleinement reconnue, qui avait
sa propre communauté, sa propre culture,
son propre étage aussi,
et son propre salaire aussi. Parce que là,
pour le coup, j'étais plus rémunéré comme
un espèce de six admins mal gaulé,
mais j'étais un
DevOps sans strictes d'uternes.
Donc, ce que ça a changé, c'est que
enfin, j'ai pu
savoir qui, enfin,
dans les chaussures de qui, je marchais
avec quoi, quelque part.
Donc, voilà ce que ça a porté.
Et encore une fois, bah voilà,
donc en fait, je fais du DevOps, souvent
quand je fais une conférence, je me présente
en disant que je fais du DevOps depuis 2003,
le terme a été inventé en 2007,
ce qui fait que je suis un DevOps vieux,
et voilà, c'est un peu ça que
j'ai ressenti quand je
rencontrais le DevOps,
c'est que
ce côté,
ce côté, quand on dit
ce côté vraiment,
il y a
une réalité, il y a un univers
dont je fais partie
qui, voilà, auquel
je fais allégeance, et qui est
mon univers. Voilà, c'est ça,
le truc que ça a changé dans ma vie.
Je sais qu'on n'a pas la même vision
sur le poste et le métier, on ne va pas
troller dans ce podcast-là, par contre
Bah je pense qu'on l'abordera un peu plus tard
quand on va parler de la nuit, si ça...
On va parler de ça. Et du coup,
tout ce que tu as dit, ça m'a amené une question
supplémentaire dont t'es pas au courant.
Est-ce que tu penses, finalement,
parce que tous les deux ont fait du
conseil aussi en transition DevOps, est-ce que tu penses
qu'on peut dignement conseiller les entreprises
à faire une transition DevOps,
si on n'a pas justement fait tout les
métiers du cycle de vie, d'une application,
parce que comme, comme toi,
moi j'étais développeur, puis exploitant,
j'ai fait aussi la prod,
puis Admin 6, et du coup,
est-ce qu'on peut vraiment les conseiller
si on n'a pas fait tous ces métiers-là, et si
on n'essaie pas rendu compte de
tous les tenants et aboutissants de ces métiers-là ?
En fait, quand je fais une presse
de la culture à son DevOps, c'est une super question.
En fait, merci, franchement,
c'est une super question.
Quand je fais une présentation
de la culture à son DevOps,
très souvent j'ai un slide qui dit
le DevOps, en fait, c'est pas une destination,
c'est un chemin. Et je pense que là-dessus
on se rejoint, Christophe, c'est-à-dire
que la démarche, finalement, est...
Évidemment, il ne faut pas perdre de vue l'objectif,
mais l'objectif, on sait que la plupart du temps,
on ne l'atteint jamais à 100%,
en particulier quand on embarque
une entreprise, un gros packbo
dans une transfert DevOps, c'est quand même assez rare
de se dire, enfin, c'est assez rare
de quitter ce chantier de
transformation. Quand le packbo
ça y est, il s'est transformé en zodiac,
quoi. Le packbo
se transforme jamais en zodiac,
et donc, en fait,
jamais on aura un modèle
DevOps comme on le sait le voir
dans des startups, par exemple,
dans des équipes très agile
et très orientées
modèle DevOps agile, quoi, on va dire.
Donc, on sait que
les entreprises, les grosses entreprises,
vont jamais transitionner à 100%.
Mais en moins,
donc, pour moi,
la question, c'est vraiment la question du chemin.
Et pour donc répondre à ta question,
qui était, je vous le rappelle,
chers leaders,
est-ce qu'on peut légitimement
accompagner dans une transfert DevOps
sans avoir la légitimité d'avoir fait
tous ces posts ? Je pense qu'en fait,
comme dans toutes les choses, enfin, comme dans
tous les facilitateurs,
comme dans tous les enneyebleurs
d'une transfert DevOps,
connaître
cette réalité
par soi-même, c'est
évidemment un plus énorme, quoi.
Moi, je me souviens d'une époque
où, quand je faisais de l'exploitation,
j'avais une chaîne de batch quotidienne
qui tournait en 36 heures.
Je vous le refais, une chaîne de batch
qui tournait tous les jours
et qui tournait en 36 heures.
Autrement dit, en fait, on avait 12 heures
de recouvrement entre la chaîne de la veille et la chaîne du jour.
Donc, autant vous dire que quand il y avait
une couille, c'était vraiment, vraiment un problème.
Et donc, je me souviens que
toutes les nues, quand je me levais
pour aller aux toilettes ou ce genre de trucs, enfin, quand je me réveillais la nuit, voilà,
pour...
Essentiellement pour aller aux toilettes, parce que la nuit, voilà, on se réveille pas pour grand-chose d'autres.
J'avais
un PC qui était allumé sur le chemin
entre mon lit et les toilettes.
Et je regardais la chaîne pour voir la chaîne de production
pour voir s'il n'y avait pas une couille
en dehors de
des pagers, etc. Mais, en plus,
des pagers, j'avais un œil
proactif sur cette chaîne. Donc,
je sais ce que c'est que ce stress-là, en fait.
Je sais ce que c'est que ce stress-là,
mais on n'est pas forcément, enfin,
pour moi, en fait, un des sujets
principaux dans le DevOps,
c'est d'abord, d'être en empathie
avec son interlocuteur.
Qu'on soit le dev, qu'on soit l'ops, qu'on soit
un rôle DevOps intermédiaire,
qu'on soit
un agiliste peu importe, en fait,
son rôle et son activité au sein
d'entreprise, l'important dans la culture
DevOps, c'est avant tout
de se mettre dans les pompes de son interlocuteur,
de comprendre sa réalité, de comprendre
ses exigences, de comprendre
éventuellement ses craintes sous-jacentes
et inexprimées.
Et pour ça, en fait, évidemment,
c'est plus facile.
En tout cas, pour moi, qui ne suis pas, qui sont un peu sociopathes
sur les bords, c'est plus facile
d'avoir vécu ces vies-là.
Mais par contre, il y a des gens qui sont
d'un naturel empathique, par à la base,
et qui savent faire ça sans avoir besoin,
enfin, qui savent détecter les signaux faibles.
Moi, je ne sais détecter les signaux
faibles que parce que je les ai vécues,
et donc, en fait, je sais
les redétecter
par comparaison de paterne,
quelque part.
Donc, je pense que c'est un facilitateur,
mais je suis absolument convaincu,
et d'ailleurs, je le vois
d'expérience quand j'ai des acteurs
autour de moi. Il y a des gens,
en particulier, par exemple, en ce moment,
je travaille avec une jeune femme, et là,
cette empathie naturelle,
qui fait que, elle, c'est
une pure DevOps.
Donc voilà, ton poil se hérisse, je le vois bien,
que ton poil s'est hérisse, Christophe.
Bon, elle est en train
de travailler sur une toulchaine de CICD,
et donc, elle est la DevOps
de la bande.
La DevOps, c'est une génère de la bande,
et elle a cette empathie naturelle
pour ses interlocuteurs, que ce sont
des interlocuteurs de prod, des interlocuteurs de devre.
Donc voilà, pour répondre
de façon courte à ta question,
je pense que c'est
un facilitateur non négligeable.
Par contre, très clairement,
c'est pas
indispensable.
Il faut quand même avoir une petite
expérience, mine de rien.
Je veux dire, tu sors pas d'école d'ingénieur,
et tu fais pas ça tout de suite, quoi.
Non ?
Non, parce qu'en fait, il faut avoir
suffisamment éprouvé la réalité du terrain.
Ça, pour le coup,
là, je suis d'accord avec toi, il y a une réalité du terrain,
tu peux l'avoir vécu en tant que devre,
avec des ops en face,
et donc avoir codu la douleur
ou de l'incompréhension de l'équipe d'en face,
ou de ta propre incompréhension
des exigences de l'équipe d'en face.
Donc ça, effectivement, il faut avoir un petit peu
de bouteilles pour
prétendre à mener ces transformations.
De toute façon, il y a aussi la réalité
du terrain et du marché. C'est-à-dire que
on va pas te prendre pour mener une transfert de DevOps
d'une grosse entreprise, parce que la plupart du temps,
les transferts de DevOps, ça se fait pas
avec des équipes qui tiennent dans un garage.
Donc on va pas te prendre
pour mener ces transformations si t'as pas un peu
de bouteilles et si t'as pas aligné quelques galons
et si t'as pas quelques trophées à présenter.
Oui, c'est vrai
que tu fais pas de transfert de DevOps dans les start-ups
ou les petites équipes, parce qu'elles trouvent très vite
leur chemin.
Après, les PME, pourquoi pas ?
C'est peut-être plus facile.
J'essaie de viser les PME, justement,
les PME du Numeriki.
Oui, tout à fait, t'as raison.
Je pense qu'elles sont plus faciles
à faire évoluer que les gros mastodontes,
parce que je sais que tous les deux
ont eu des clients en commun.
J'ai d'autres gros clients.
C'est très compliqué.
On en parlera, je pense, une autre fois.
J'ai une autre question pour toi, parce que
notre auditeur, il adore les petites histoires,
il adore le point story time.
Et du coup, est-ce que tu peux nous raconter
un truc, un problème qui t'est
arrivé dans ta carrière et que tu as
pu justement améliorer avec le DevOps,
le principe du DevOps ?
Et surtout, est-ce qui est intéressant pour nous,
puisque c'est un petit retour d'expérience,
comment vous avez fait pour régler ce problème-là ?
Chers auditeurs, sache-le,
ces émissions sont préparées.
Et donc, en fait,
j'avais les questions auparavant.
Quand tu m'as posé cette question,
j'y ai réfléchi.
C'est assez compliqué pour moi, parce que quelque part,
j'ai fait quasiment toute ma carrière en faisant du DevOps.
Donc, si tu veux,
j'ai du mal à comparer le avant après.
Quand je faisais pas de DevOps, c'est quand j'ai fait du DevOps.
Par contre, je me souviens, en fait, quelque part,
je me souviens d'un truc que je considère moi,
personnellement, comme mon plus grand succès, quelque part.
Je travaillais pour la poste.
Il y a prescription, maintenant,
c'était en 2012-13,
je crois, un truc comme ça.
Et je travaillais pour la poste qui, à l'époque,
n'était ni Agil, ni DevOps, enfin, voilà,
c'était vraiment la boîte à la papa.
Et je travaillais pour la lettre recommandée, numérique.
Donc, en fait, la version digitalisée,
numérisée
de la lettre recommandée.
Alors, on est bien d'accord, normalement,
la question du digital,
on est bien d'accord, moi aussi, ça me fait rire.
Mais après, voilà, il y a une réalité, on va dire,
du métier, du business,
de notre écosystème professionnel,
qui fait que quand on parle de digitalisation,
c'est, voilà,
cette transcription numérique
d'une activité qui, autrefois, ne l'était pas.
Bref.
Donc, je travaille sur la lettre recommandée, numérique,
et mon premier job,
en fait, où j'arrive en tant qu'architecte solution
sur cette mission-là.
Et mon job, en fait, c'est de faire un intérim d'été
pour remplacer
l'architecte solution qui s'est barré un mois en vacances.
Et grosso modo, le job,
c'est, ils doivent passer d'une V3
à une V4, je crois, un ou un truc comme ça.
Donc, juste,
upgrade applicatif.
Ok, donc je fais les documents
d'architecture, je fais un truc, et puis, j'accompagne
le projet dans cette migration.
Enfin, dans cette immigration, dans cet upgrade.
Excuse-moi, c'était un upgrade, juste un upgrade
applicatif. On est bien d'accord, je te le dis.
Et donc,
le passage de V3 avec A,
sans dentir,
ça a pris 3 jours,
donc 3 fois 8 heures,
avec interruption de service. Donc, ça se coupe
un vendredi soir, ça se ralume un lundi matin.
Et pendant ces 3 jours, donc,
8 heures non stop, t'as un mec qui fait du clic bouton,
clic bouton, clic bouton,
je connais le prénom de ce garçon, il s'appelait Christophe.
Et il a fait du clic bouton
pendant 3 fois 8 heures.
Donc, 24 heures, il a
bossé à faire du clic bouton pour faire
l'upgrade de cette putain d'appli
V3 vers V4.
Et donc, moi, j'ai regardé ça
évidemment pendant les 3 jours, bon, je me suis
un petit peu fêché,
et deux, un petit peu arraché les choses,
je me suis dit, c'est pas possible, quoi.
Et donc, en fait,
il se trouve, alors, je vous la fais un peu
courte, bien que vous avez vu, j'aime
bien délaier, mais je vous la fais un peu courte
et je reste sur cette mission
et
des mois passent.
Et en fait, on prépare
la next version, donc la version 5.
Et là, pour le coup, je reste
architecte de solution de la V4 jusqu'à
la V5.
Et donc, en fait, pendant tout ce temps,
on a tout revu.
En fait, on a revu les équipes.
Donc, en fait, on a diminué par 3 la taille
des équipes. On a revu
les socles sur lesquelles on tournait, donc on tournait
sur du WebSphere, du WebSphere NQ, du WebSphere
Application Server. Il y avait de l'oracle
derrière. On est passé
sur du RabbitMQ, du Tom4.
Alors, attention, on était
sur du WebSphere Application Server,
mais les développeurs qui étaient
en centre de service Nierchor
dans un bled
de région parisienne, eux, ils travaillaient pas
sur du WebSphere Application Server parce qu'ils avaient pas
laissé une salle. Donc, ils bossaient sur du
Gboss, bien évidemment. Et donc, il y avait
plein de blèmes de migration de Gboss,
l'air WebSphere. Enfin, bref, que
on a vu, des conneries comme ça, vraiment, tous les antipaternes
qu'on peut rencontrer traditionnellement
quand on arrive sur un chantier
on va dire pas vraiment DevOps friendly.
Et donc, on a tout refait du
sol au plafond et
au final, quand on a migré
donc avec la migration technique, que ça impliquait
de migrer de V45, puisqu'on avait changé
complètement toute l'architecture technique,
on avait refondu une partie
de l'applicatif, on avait évidemment étendu
les fonctionnalités, etc. Et quand on a
fait la migration vers V5,
la migration vers V5, ça a demandé 10
minutes, une ligne de commande passée
et sans interruption de service.
Et là, j'ai dit, ok,
mon job est fait.
J'ai fait ce qu'il y avait à faire.
Et évidemment, qu'est-ce qu'on a fait ?
On a fait du blue green.
On a fait évidemment une vraie architecture
autour de l'open source, qui fait que plus
de problèmes de licence, ce qui fait que les devs
ils devaient, ils devaient, sur les bonnes
architectures techniques,
des environnements beaucoup plus volatiles,
beaucoup plus agiles, pilotés évidemment
en Ascode, enfin bref, la totale
de ce qu'on peut faire, enfin, on va
dire le Devos by the book, quoi, quelque part.
Et c'était
un plaisir. Et j'ai revu, donc ça c'était
en 2013, je crois, et j'ai revu
lors d'une conférence
le patron de la prod, alors
là je vous ai parlé des aspects architecturaux,
techniques, etc. Mais ce qu'on a
fait aussi, c'est évidemment que les devs
et les mecs de prods, alors
les mecs de prods et cadigeons, les devs
les séparatisiennes, donc évidemment
on les a fait se rencontrer, on les a fait
bouffer ensemble, lors des mecs
moi j'amenerais carrément le petit prix de bière
vous savez les petits frits de bière, grand comme ça
grand comme ça, qu'on trouve
dans les supermarchés de façon
à ce qu'on puisse picoller un petit
peu, avoir une mep un peu festival,
quoi. Et bref
et donc en fait, et on a resserré
considérablement ces deux équipes
de façon à ce que voilà l'ops
restait un ops, les devs sont restés
des devs, mais très clairement, ils bossaient ensemble sur l'infrascode, ils bossaient ensemble
sur les déploiements, sur les déploiements en prod, mais aussi sur les déploiements en
environnement à mou, et puis quand il y avait un jeton, on était tous sur le pont, etc.
Et donc en fait, on est repartis de là, on était super heureux de bosser ensemble,
et surtout on était fiers de ce qu'on avait fait. Donc c'est vraiment pour moi un truc
sur lequel mettre en place du DevOps, d'une part ça a été une réussite, et d'autre part ça a
été un plaisir en fait. Et alors mon côté entrepreneur, il se pose la question, est-ce
que le retour sur investissement y était, et est-ce qu'ils ont profité justement pour
raccourcir les délais entre les mises en prod et les faire plus souvent du coup ? Oui,
alors oui d'ailleurs excusez moi, je n'ai pas fini un truc. Je reviens ta question,
je n'ai pas fini un truc, c'est que donc j'ai revu le patron de la prod quelques années plus tard,
genre 5-6 ans plus tard en conférence à Marseille, et il disait bah ton truc,
il tourne toujours comme une horloge, et on continue à bosser sur ces perchis de
textures, etc. Donc ça c'était vraiment un grand, enfin c'est-à-dire que en fait tous les
préceptes, tous les paternes DevOps qu'on avait mis en place, ils se les étaient non seulement
appropriés, mais en fait ils continuaient à les étendre, etc. Donc c'était un espèce de
proto-de-Devops à la poste, et c'est quelque chose sur lequel c'est fait, enfin c'est fait la
culture DevOps de cette entreprise, et vous savez aujourd'hui que, enfin aujourd'hui la poste
discute beaucoup, enfin communique beaucoup sur ces réussites DevOps, et je suis content
d'y être un petit peu pour quelque chose. Concernant ta question, les déplorants plus
souvent, oui bien sûr, bien entendu, puisque je crois que le passage de V3 avec 4, ça avait pris 6
mois, le passage de V4 avec 5, très clairement ça a pris je pense aussi 6 mois, mais par contre,
alors en termes de mise en production, donc là-dessus on n'a rien gagné, mais par contre il
y avait la migration technique, toute la réorgue, des équipes, etc. Donc en fait on était sur un
projet qui avait une ampleur complètement différente, là où de la V3 à la V4 c'était juste on
remplace un Java par un autre Java. Donc la durée était la même, par contre évidemment les
idées sur les environnements de tests, elles ont été infiniment plus nombreuses. Là pour le coup
j'ai pas de maitris que clair, mais elles ont été évidemment très nombreuses puisque ben voilà,
on a largement intérêt sur ces réarchitectures, ces refontes, les évolutions de, les évolutions
fonctionnelles, etc. En termes de Héroï, je vais être complètement transparent avec vous.
Moi je vais bosser donc en tout et pour tout, de V3 à V5 et quelques, j'ai bossé 30 mois pour
ce projet, le coût de ma prestation à l'époque je bossais chez Octo, le coût de ma prestation
ça a été 900 000 euros pour 30 mois. D'accord, on a fait un gain de 3 millions d'euros sur les
licences web sphère et web sphère MQ qu'on a bazardée et sans compter évidemment, alors là
pour le coup ça peut pas vraiment se calculer parce qu'il y avait énormément d'équipes
internes sans refacturation interne, mais on est passé, on va, je vais dire, une quarantaine d'acteurs
sur le projet à une équipe qui était resserrée à une douzaine d'acteurs et donc on faisait le même
job à 12 que auparavant on le faisait à 40 avec toutes les réunions etc. que ça coûtait. Donc en
fait on a gagné en termes d'agilité, on n'a pas forcément gagné énormément en termes de
vélocité et de toute façon il restait quand même tout la sphère métier. Encore une fois le projet
n'était pas agile, donc en fait la descente des expressions de besoin métier vers les
développeurs, elle se faisait encore en cyclanvé, tout ça se faisait en cyclanvé, donc on a fait du
DevOps sur du cyclanvé quand même, il faut voir un peu, mais donc on n'a pas forcément gagné en
vélocité strict sur le projet en termes de time to market, par contre très clairement en termes de
vélocité opérationnelle, là pour le coup on a gagné énormément. C'est marrant alors tu dis ça,
tu fais bien parce que quand j'arrive dans une boîte qui veut passer au DevOps, je leur montre
déjà si elle a fait une transition agile et moi je refuse de mettre les pieds typiquement sur
une boîte qui n'a jamais fait de transition agile parce que je ne veux pas gérer le cyclanvé
et le DevOps. Toi tu mets peut-être parce que tu as plus de gens avec toi, moi je suis un indépendant
tout seul maintenant et du coup je n'ai pas vraiment envie de mettre les doigts là-dedans.
Ça a été compliqué culturellement, en fait tu sais quoi, c'est marrant parce que je me souviens
très précisément du moment où j'ai réussi à tout déverrouiller, c'est à dire que dans un cyclanvé,
le vrai problème du cyclanvé c'est que la responsabilité est ciblée contractuellement
par le passage d'une équipe à l'autre à travers des tickets. Quand on me fait le mal digérer,
c'est comme ça que ça se passe, il y a une équipe, elle fait des tickets à une deuxième équipe et
donc en fait ce ticket m'intérialise le moment où on passe la responsabilité à l'équipe d'après.
Quand on commence à raccourcir tout ça et à faire travailler les gens beaucoup plus en
collaboration, qu'ils touchent au même code etc. à ces questions de tickets etc.
même si elles existent encore pour des questions de traçabilité, de la communication et de
conservation de l'historique quelque part. Et puis parce que c'est intéressant d'avoir une
toudou, simplement, ne serait-ce que pour soi personnellement, moi j'aime bien bosser avec du
gyrain ou du trélo ou ce genre de trucs ou du github issue etc. parce que au moins le matin
quand j'ai un peu la tête dans le cul, tout de suite ça me recadre dans ce que je vais à faire.
Mais en tout cas, bref, le rassi est très carrément matérialisé, les outils viennent
matérialiser ce carcan un peu itil, cyclanvé etc. Et je me souviens très bien le moment où j'ai
réussi à dévéroiller tout ça, c'est que j'étais avec le patron de la prod, j'étais avec le team
lead de la dev, le team lead était plutôt favorable à faire du dev ops, évidemment comme
souvent les devs, le patron de prod beaucoup moins comme souvent les patron de prod et un moment donné
en fait, donc on discute un petit peu de la nouvelle orgade de comment bosser ensemble et
tout et puis le mec vraiment il est hyper réticent et puis un moment donné je lui dis
qu'est-ce qui te fait peur en fait et il me dit bah ouais mais je ne veux pas claraître son solidité
et je lui dis ah mais c'est ça en fait ton problème, ton problème c'est le rassi et bah
écoute, tu sais quoi on va le refaire, la refaire la matrice rassi et en fait on va me mettre partout.
Justement avant que tu continues parce qu'on s'adresse aussi à des no-fit est-ce que tu peux
expliquer ce que c'est le rassi moi je sais mais pour nos auditeurs. Oui alors le rassi c'est une façon
c'est un modèle qui permet d'établir qui est responsable de quoi dans un plan d'action. Donc
en fait quand on a un plan par exemple de déploiement on va dire telle personne elle est soit responsable,
soit partie prenante, soit contributrice, soit informé c'est à dire mise au courant d'eux parce
que ça peut être intéressant pour elle d'être informé donc typiquement quand on déploie je
sais pas moi une base de données avec un applicatif au-dessus très clairement quand l'applicatif va être
déployé une des personnes qu'on va informer c'est le DBA mais par contre il ne va pas être dans
l'action d'upgrader cette application. Par contre au niveau de l'upgrade du modèle de base de données
par exemple je vous fais ça façon manuelle à l'ancien arrondis bien d'accord. Par contre donc
dans la mise à jour de la base de données l'administrateur va être acteur donc dans le RASI donc
il va être acteur mais par contre quelqu'un qui va être mis en contribution par exemple ça va être
le développeur parce que par exemple dans son application il doit changer la chaîne de config
de connexion à la base de données parce qu'on a changé de base de données par exemple. Donc voilà
c'est une façon de modéliser comme ça dans un document qui est acteur qui est contributeur qui
est responsable qui est acteur qui est contributeur et qui est informé des différentes actions.
Il y a une fin ça vient évidemment de l'anglais donc le R et le A s'inverse entre l'anglais et le
français mais globalement on s'y retrouve. Je vous mets un lien en description vous irez voir ce
que c'est le RASI. Et donc en fait de mon point de vue souvent quand on parle de DevOps malheureusement
dans les entreprises on parle d'abord d'automatisation et après on parle de culture et très souvent la
question du RASI passe un peu sous le tapis hors en réalité de mon point de vue ma sensibilité
personnelle sur les choses c'est que le RASI c'est un petit peu la pierre de rosette du DevOps
c'est à dire que si on arrive à péter le RASI le DevOps se sait gagner parce qu'en fait
globalement se retrouver sur des techno c'est pas très compliqué enfin après il y a toujours des
biais culturels des biais personnels je choisis tel techno ah ouais mais non je préfère celle-ci
mais globalement ça ce sont des guerres d'individus mais ce sont pas des guerres de
système par contre si on n'arrive pas à péter le RASI ça reste un sujet de transformation du
système et là pour le coup en fait si on n'arrive pas à faire ça ça va être un échec globalement
ça va être ça va être pas peut-être pas un échec mais en tout cas un succès largement incomplet
quoi c'est pour ça que c'est important de le péter et donc c'est j'ai répondu à ta question
oui ouais et donc avec ton directeur là et donc en fait ouais avec mon directeur voilà pour
reprendre mon histoire donc à m'en donner donc il a je lui demande de quoi il a peur grosso modo
ce qui me dit c'est qu'il n'a pas envie de se faire taper sur les doigts et qu'il soit pris pour
responsable de cette espèce de prototype de ces espèces de monstres d'hydr à plusieurs
têtes là qu'on est en train de monter ce qui s'appelle le DevOps et je dis mais écoute c'est pas
un problème moi je suis consultant donc je prends la responsabilité d'être le fusible donc en fait
on va le changer la racine je suis architecte solution donc quelque part c'est un peu à moi de
le faire donc on va le changer ce racine et je vais me mettre partout en tant que responsable et
donc à partir de là globalement s'il ya une faute qui arrive c'est vers moi qu'on va se retourner
et à partir du moment où on a changé alors évidemment là pour le coup c'est passé mais je
sais même pas comment c'est passé tellement c'était énorme mais en fait on a réussi à me faire ça et
à partir de ce moment là en fait la collaboration elle était hyper hyper tranquille quoi tout le monde
était nettendu du slip parce que globalement en fait cette question de la responsabilité noire sur
blanc elle avait été levé quoi après évidemment ça n'a l'air pas toutes les difficultés au quotidien
mais c'était un point enfin à partir du moment où ça s'est devenu officiel ça n'a plus été un
sujet et ben merci pour cette histoire et on va pouvoir lancer notre discussion sur justement
le poste d'administrateur système comme tu le sais récemment il ya le poste d'administrateur
système dévox qui a été créé c'est c'est paru au journal officiel et justement j'en ai parlé
dans une de mes vidéos et je crois que toi et moi on n'a pas le même avis là dessus déjà est-ce
que tu peux me dire ce que tu penses de ce poste et après je vais je vais rappeler mon avis un petit
peu là dessus bah déjà je pense que c'est bien enfin je pense que c'est bien un monde alors je
connaissais pas les je suis pas un grand spécialiste de l'administre enfin des aspects administratifs et
des aspects on va dire officiels ça est compris que bon à la fois par mon parcours et par mon
métadestrie en fait je suis quelqu'un d'assez enfin qui qui qui finit out of the box quoi je
suis quelqu'un d'assez peu on dirait rigoureux et rigide donc je ne sais pas comment c'était
auparavant mais en tout cas la première chose que j'ai je pense que c'est j'ai pris connaissance
de cette information donc de la publication de ce poste au journal officiel je pense que je l'ai
appris à travers un p-tweet et donc en fait quand je l'ai vu la première chose que ça m'a évoqué
c'est que je me suis amusé parce que je suis dit à mon avis christophe là ça doit le chauffer ça
c'est le premier truc que je me suis dit le deuxième truc que je me suis dit c'est mais quand
même c'est bien un moment donné que le terme dévox entre au journal officiel ça c'est le premier
truc que je me suis dit et après je suis allé lire un petit peu et globalement en fait ce que j'ai
lu est le nœud de ce dont on va débattre là tout de suite c'est à dire est-ce qu'il y a un écart entre
ce que notre business appelle le dévox enfin notre business c'est à dire les entreprises françaises
donc ils sont plutôt des grosses entreprises plutôt du k40 plutôt des entreprises institutionnelles un
peu à la papa appelle le dévox et de ce que nous on appelle le dévox et effectivement globalement
en fait là où tu dis on est pas d'accord je pense que fondamentalement on est d'accord on a la même
sensibilité mais pas sûr qu'on ne soit pas d'accord parce que je pense en fait je pense qu'on
est d'accord mais je pense que il y a un écart effectuel il y a un écart factuel si tu veux entre
notre sensibilité et notre culture dévox est ce que le commun des mortels enfin ce que les dsi
lise dans le 0 1 m quoi en fait ouais et c'est ça le truc alors je sais pas si t'as vu ma vidéo
juste en sur le sujet ouais je l'ai vu donc tu as vu avec tu tu alors je vais rappeler pour ceux
qui l'ont pas vu donc j'ai fait une travail du vendredi donc vous pouvez aller l'avoir il y a la
fiche d'information qui s'affiche si vous êtes sur youtube pour moi en fait alors c'est un titre
c'est pas un poste c'est vrai c'est un titre donc ça veut dire c'est un titre officiel donc c'est un
diplôme pour le coup donc on passe un diplôme mais après dérive des métiers donc déjà c'est pas
un métier d'ingénieur dévox parce que le titre c'est bien administrateur système sur lequel pour
moi on a accolé un adjectif qui est dévox et pour moi c'est la bonne manière de qualifier les titres
c'est de prendre un vrai titre qui existait et du coller l'adjectif pour dire bah voilà on va
faire ce métier là ce titre là on va lui accoler la méthodologie le mouvement dévox moi c'est la
bonne chose après dans le titre il y a des petits trucs qui me dérangaient mais là où
tu avais réagi sur twitter il y a aussi le truc c'est l'absence de culture sur le titre c'est vrai
que la culture elle n'est pas mentionnée même si en filigrame quand on lit complètement le titre
il y a les aspects collaboration et autres mais le terme culture il n'y est pas ouais en fait je vais
dire dans le titre administrateur système dévox finalement ce qui me choque le plus c'est système
parce que en vrai aujourd'hui et surtout quand on commence à faire du cloud enfin parce que dans
le intitulé du poste de l'administrateur système dévox il y a quand même tout un sujet cloud
infrascode et en fait quand on parle d'infrascode c'est grosso modo déploiement et provisioning
ascode donc c'est pas nécessaire nécessairement nécessairement que de l'infrastructure mais ça
peut être aussi des services et en particulier des services manager etc et donc en fait la
question de l'administrateur système là pour le coup me pose problème finalement ce que décrit
ce poste globalement pour moi c'est ce qu'on appelle sre entre nous c'est à dire quelqu'un qui a une
responsabilité de run et qui fait et qui a dans son dans ses activités à la fois de run et à la fois
de build puisque il a quand même des activités de build très clairement identifiés qui a recours
au bon pratique et aux technologies qu'on appelle traditionnellement devoves dans les
industries dans notre industrie à it et donc en fait ce qui me choque le plus finalement quelque part
c'est quelque part c'est plus le côté administrateur système qui pour moi en fait est un peu
qui va chouant en fait pour moi ce qui me pose problème dans ce dans cette dans la façon
on s'est accolé c'est que pour moi l'administrateur système ne recouvre pas nécessairement la
réalité du run c'est à dire qu'en fait très enfin moi dans mon expérience personnelle les
administrateurs de système sont quand même des gens qui sont en n3 voire en n4 en termes de
réactivité sur incident ou quand on parle d'un sre ou d'un administrateur système de vote c'est
quand même quelqu'un qui est assez immédiatement confronté à l'incident parce que globalement
il a une vision beaucoup moins silotté et beaucoup moins quand dire technologie centrique que que
ne peut ne peut l'être l'administrateur système ou dévastation c'est à dire que l'administrateur
système on l'appelle globalement quand on sait que c'est l'hyperviseur qui est d'arbre on l'appelle
assez peu avant il est pas réveillé parce que l'applicatif est d'arbre alors que un sre ou un
admin devops on va dire ou un devops de run va être beaucoup plus en première ligne en termes de
en termes de de prise de prise en compte d'un incident va être beaucoup plus en première ligne
il va être beaucoup plus dans une démarche dans une démarche à large spectre donc le côté
administrateur en fait dans administrateur système parce que sinon tu vas faire un long vlog alors
qu'on est là pour discuter moi dans dans ma carrière j'ai une longue période où j'étais
exploitant donc gestionnaire d'application on peut aussi dire ça alors comment on appellait ça
je faisais de la proche j'installe les applications sur des systèmes unix et linux et et je n'irai
pas le système mais j'avais besoin de plein de connaissances de systèmes et du coup mon métier
finalement sera proche et de l'administrateur système sont en mettre je vous les systèmes et autres
par contre j'utilisais le système et je le faisais du déploiement etc et pour moi et en plus n'oublions
pas ce titre c'est un titre bac plus trois c'est pas un titre d'ingénieur je suis assez d'accord avec
toi sur le côté cloud pour moi il n'a rien à faire là il d'ailleurs il devrait même pas être là et on
devrait se focaliser sur l'administration système les connaissances du système et le provisioning et
la configuration la gestion de la configuration mais tu vois par exemple tu faisais je te rejoins
c'est à dire que toi le poste que tu avais c'était un poste de ren applicatif en fait d'ops
applicateur exactement et donc pourquoi système tu devais avoir aussi des compétences réseaux tu
devais avoir aussi des compétences db mais moi éventuellement des compétences messagerie moi
quand même parce que vraiment on avait vraiment des compétences systèmes très fortes moins de
compétences réseaux d'ailleurs je suis très mauvais en réseau là dessus j'avais aussi des compétences
db mais en même temps aujourd'hui on demande à l'administrateur système d'installer les bases
de données et d'installer enfin on demande un peu tout à l'administrateur système ou à l'ingénieur
système là c'est un autre problème pour moi mais c'est parce que j'ai aussi travaillé dans beaucoup
des startups donc des petites équipes quand j'ai travaillé chez casino en effet il y avait
des gens pour tout donc c'était assez c'est à moi je bosse là ça fait trois quatre ans que je
bosse en secteur bancaire finance santé mutuelle ce genre de trucs assurance très clairement tu vois
les dba et les ingénieux des ingéraisaux et les admins de système c'est trois populations différentes
qui ont vraiment des réalités assez ouais mais là ce que tu décris pour moi c'est l'administrateur
système à la papa alors que pour moi ce titre c'est le nouvel administrateur système qui rendent
dans le mouvement des vops il connaît son système linux il sait l'utiliser il sait installer des
choses et il sait surtout configurer et faire de la gestion de configuration je suis d'accord avec
quoi mais est ce que ça veut dire que c'est pas ce mec là qui va faire de l'installé kfk par exemple
et évidemment que c'est lui qui va faire l'installé kfk oui donc en fait il n'est pas
administrateur système en fait en même temps il n'y a pas d'autre tu sais on part de loin c'est
ça parce qu'il n'y a pas d'administrateur kfk encore que kfk c'est un middleware mais c'est
quand même les administrateurs système qui font middleware parce qu'il y a les connaissances
techniques et le métier que tu fais derrière tu vois c'est ça que je veux dire c'est qu'il y a le titre
et le métier en fait pour moi je comprends je comprends ce qu'il veut mettre derrière ça de mon
point de vue c'est mal enfin les mots qui sont employés sont pas les bons parce que globalement si
on se tourne un petit peu vers la culture on va dire des vops un peu plus anglo saxone on va
dire en tout cas un peu plus sensible à notre à notre communauté ça se rapproche d'un sre et
un sre c'est quoi c'est un acteur technique qui a un pied dans le run et qui a un pied dans le
guide c'est ça et c'est un acteur technique qui n'est pas un développeur c'est surtout ça la
différence c'est à dire c'est à dire que lui en fait il n'est pas là pour développer le fonctionnel
il n'est pas là pour développer le métier il est là pour pour développer je veux dire les
fonctions en rapport avec les exigences du métier donc il est là essentiellement pour les la
stack technique mais pour moi administrateur et système sont alors administrateur système selon
les réalités du terrain ça peut être du run comme ça peut être du build mais de façon assez
exclusive or là c'est plutôt un rôle qui englobe les deux et c'est plutôt bien que ça englobe les
deux et à la fois le côté système moi je suis pas je suis pas super fan après je comprends ce
qu'ils veulent mettre derrière et pourquoi pas appeler ça administrateur système en fait voilà on
discute évidemment et ça fait ça fait de l'écoute pour nos auditeurs enfin je veux dire ça
ça entretient notre discours auprès des auditeurs mais en réalité en fait moi je suis c'est un peu
ça l'essentiel de notre débat en fait c'est que moi quelque part que ça s'appelle administrateur
système ou sre ou ops ou web ops ou whatever ops en fait je m'en fous ce qui est important c'est
qu'on soit aligné sur ce que ça veut dire et surtout sur la réalité que ça recouvre au quotidien
et c'est ça qui de mon point de vue est le plus important alors justement je vais te poser une
question est-ce que tu donnes des cours ouais moi ouais bien sûr tu as pu remarquer parce que moi
aussi j'en donne tu as pu remarquer quand même que pour inclure le DevOps dans les cours c'est pas
facile notamment à ces niveaux là parce qu'il y a des programmes et on peut pas forcément sortir
des programmes et donc moi quand je propose mes cours des vops sensibilisation des vops en bts ils
disent ah bah non c'est pas dans le programme et donc moi je vois le fait de ce titre arriver une
bonne chose parce que dans les programmes on va pouvoir mettre ce genre de choses on va pouvoir
mettre la culture va pouvoir mettre l'automatisation on va pouvoir mettre les autres trucs et je
pense c'est une bonne première marche elle n'est pas parfaite surtout quand on voit comment elle
est rédigée mais voilà quoi après on va pouvoir aller de plus en plus vers la mise en place des
de tout un tas de titres des vops partout enfin de tout un tas de titres qui vont dans le mouvement
des vops et pouvoir sensibiliser tout un tas de population ouais tout à fait j'aimerais bien
qu'on ait des titres développeur des vops tu vois typiquement ben mais en fait tu vois en ce moment
je suis j'ai un client excusez-moi il y a une petite mouche en ce moment je suis ses inclinants et
ils ont voulu lors de ma mission de transferts de vops donc je suis arrivé pour faire le cadrage
de cette transfert et donc il y a certains de mes interlocuteurs qui sont du 6 level on
m'a demandé de ne pas parler de devops mais de dev ccops alors moi en mon foire intérieur je
me suis bah ouais et défine up et donc la partie film on s'en occupe pas et la partie data on
s'en occupe pas et la partie ml on s'en occupe pas et en fait et pourquoi rajouter secs je veux dire
a priori un autre c'est ça fait déjà partie de ses attributions de base enfin je veux dire
à l'administrateur système c'est quand même une de ses valeurs ajoutées de savoir sécuriser et
durcir son système c'est d'ailleurs c'est d'ailleurs un des grands sujets qui présentent tellement de
contraintes et de frictions que les devs ils commencent à taper sur l'obs fin globalement en fait
c'est bien parce que il y a des sujets contraignants comme la sécurité qui a un sujet à la base un
peu compréhens perçu comme compréhens par les équipes de dev que le devops a été inventé c'est
bien pour lisser ses frictions pour huiler ses frictions donc en fait rajouter secs dans le
terme pour moi c'est enfin quelque part je trouve ça grotesque mais en même temps enfin franchement
dans mon foire intérieur je dis mais devos en fait le sec il est déjà dans votre ce mec on est
parfaitement d'accord là dessus faut que je fasse un épisode de podcast là dessus mais mais en
fait une fois que une fois que voilà une fois que mon poil s'est rissé intérieurement et que mon
petit coeur c'est un petit peu meurtré intérieurement je me dis mais pourquoi pas en fait en fait
l'important c'est finalement pas le terme ce qu'il faut c'est qu'on soit aligné dessus et à la limite
qu'on enfonce le clou une deuxième fois en rajoutant sec mais pourquoi pas quoi après je trouve ça
grotesque parce que à la fin on finit avec un truc qui s'appelle dev sec fin ml data ops
mais pourquoi pas en fait t'as oublié le no au milieu alors non le no on va on pourra en parler
si tu veux un moment donné et de fois du coup parce que il y a un truc qui m'embête un petit peu
avec ça et puis on passera la dernière question je pense après c'est finalement les gens tu leur
vas se renseigner ils vont pas tomber finalement sur les articles ou les conférences des vops et
risque de passer sur tout un pan qui est pour moi fondateur du mouvement quand même oui mais à
contrario alors je suis d'accord avec toi je suis complètement d'accord avec toi mais à
contrario si tu colles juste des vops c'est vrai que tu vas tomber sur énormément de
sujets d'enjeux de déploiement et beaucoup moins sur des sujets de d'analyse statique de sécurité
sur des images de coeur par exemple ce genre de truc alors depuis l'arrivée des conteneurs c'est
quand même beaucoup moins vrai c'est à dire que en fait la partie sécurité comme le
conteneur est un paquet j'en vais dire très standard qui a permis justement de quand
dire de faciliter l'intégration d'analyse statique de sécurité dans la chaîne ci et
etc ça c'est rentré beaucoup plus dans les meurs qu'auparavant mais enfin moi je vous
souviens du moment où vous êtes de l'infrascode sur du cloud public avant les conteneurs et où la
sécurité c'était un enjeu qui était assez peu traité même dans les conférences des vops tu vois
alors c'était c'était traité enfin on l'avait dans notre scope radar et on faisait on faisait au mieux
pour l'intégrer mais disons que c'était quelque chose qui n'était pas qui n'était pas aussi qui
n'avait pas le même poids que le développement que le déploiement par exemple dans les dans
les conférences on pouvait trouver comme littérature dans la communauté donc quelque part si tu veux
c'est vrai que le dévops quand tu en parles et quand tu et quand tu te penches sur le compte le
compte qui existe sur internet par exemple c'est quand même très orienté déploiement et monitorie
je dis si on devait pondérer en fait les différents éléments du dévops enfin les
différentes activités qu'on peut trouver dans le dévops si on devait les pondérer par rapport à
littérature qu'on peut trouver ou à la surface de la culture à son qu'on peut avoir par rapport
à la communauté c'est clair que ce qui vient d'abord c'est l'automatisation ce qui vient ensuite
c'est le déploiement ce qui vient ensuite c'est le monitorie et ce qui vient ensuite c'est la
sécu et si tu veux ça arrive effectivement avec ces poids là et donc quelque part remettre le sec
dans le terme bah quelque part ouais ça servait en fond le clou et ça fait remonter un petit peu
de sec pourquoi pas c'est bon tu m'as remonté comme un coucou je pense que je vais enregistrer
mon épisode de podcast sur le dev c'est comme je te le ferai écouter en tu verras tu verras
mon point de vue là dessus je vais je vais charcre mais pourquoi tu dis que tu en as un
an je veux dire parce que on est déjà à 55 minutes et qu'il va falloir arrêter ce podcast
si tu veux on en discutera plus tard et bah écoute ça va être ma dernière question
est-ce que tu as un livre un article ou même une conférence à conseiller à notre auditeur
alors moi je te fin
non pas vraiment ce que je vais faire plutôt c'est vous conseiller des podcasts parce que les
podcasts c'est la vie yabon mangeaisant j'aime beaucoup ce format pour plusieurs raisons d'abord
parce que la plupart du temps ce sont vraiment des comment dire des passionnés qui font ça parce
que c'est c'est pas encore dans les gros vecteurs de monétisation etc donc c'est souvent c'est
souvent du podcast amateur et c'est fait par des passionnés et souvent ces passionnés sont
extrêmement bons et donc bah dans les podcasts que je peux vous conseiller il y en a quand même
quelques uns il y a bien il y a le quain évidemment il y a celui aussi de wiskale qui est fait par l'ami
tomah il y a l'excellent post cas de claveur cloud alors là pour le coup c'est pas dévops mais c'est
une boîte et des acteurs qui sont assez quand dire clivants mais ce que j'aime beaucoup c'est qu'ils
ont énormément une approche d'ingénieur et là pour le coup en fait ça nous remet un petit peu
dans la réalité en fait moi qui suis consultant tout comme toi d'ailleurs parfois on a un peu
l'impression de faire des claquettes et là pour le coup en fait eux ils ont une approche d'ingénieur
chez un éditeur et là pour le coup en fait j'aime beaucoup cette approche je veux dire ils ont des
épisodes sur les évolutions kernels qui sont absolument fabuleux et c'est vraiment une grosse
une grosse acculturation pour moi et puis il y en a un dernier que j'aime bien c'est électro monki
alors là pour le coup je connais le l'éditeur mais uniquement de réputation et je trouve que
il a un podcast qui est de grande qualité aussi un dernier podcast pour la route et là c'est
un sous podcast du podcast tech café où on parle énormément d'intelligence artificielle
d'informatique quantique et de cartes graphiques et de processeurs et là pour le coup c'est pareil
en fait on est vraiment dans le cybissium pur de dur et c'est très sympa c'est très sympa écouter
voilà et bien écoute merci je connaissais les trois premiers podcasts pour le coup nos auditeurs
connaissent tomas puisque c'est damir sur radio dévap et je ne connaissais pas chronique des
composants alors que j'écoute tech café c'est quand même fou bah je vais aller écouter ça mais
faut écouter un guillaume pojaspala alors je sais pas si t'as lu son bouquin sur les machines de jeu
nous en parle à chaque fin de podcast bah je l'ai lu ce bouquin où ils expliquent un petit peu
les enjeux des consoles 8 bits et comment elles étaient programmées et qu'elles étaient les
contraintes techniques et tout c'est complètement ouf ici enfin vraiment ça c'est enfin moi j'aime
beaucoup ce podcast et son autre faut que j'aille écouter ça parce que j'ai commencé avec les
consoles 8 bits enfin pas vraiment mais je vraiment pris la passion du jeu vidéo à ce moment là
bon elle m'a quitté depuis mais mais quand j'étais à dos c'était ça et ben écoute merci je vais
mettre tous les liens en description je vais mettre aussi de lien de ton link d'in sauf si tu
veux pas tu peux mettre mon link c'est parce qu'il y a plus d'interressants écoute je vais être
lié que tu veux en tout cas dans l'épisode et je vais tu parlais justement des podcasts et du fait
amateur je vais en profiter pour rappeler vous pouvez soutenir ce podcast en faisant un petit don si
vous vous sentez l'âme charitable ou si vous a plu sur libéra paix le lien est aussi en description
et je vais te laisser le mot de la fin avant la clôture la prochaine fois surtout c'est donc
ce n'est pas un mot de la fin en fait c'est un mot pour la prochaine fois non bah écoutez j'espère
que ça vous a plu et on a prévu d'enregistrer d'autres épisodes donc si vous avez apprécié celui
là abonnez vous et vous aurez les autres merci d'avoir écouté radio dévobs n'oublie pas de
nos télépisode plus la note sera élevée et plus sera mis en avant dans les applications tu peux
aussi le partager ça nous aidera à le diffuser et à rendre le mouvement plus visible si tu as
envie de discuter du mouvement alors rejoins nous dans la communauté des compagnons du dévobs à bientôt
la balade aux diffusions des compagnons du dévobs est produit par l'hydra