Bon alors si t'écoutes ce podcast, t'as déjà une petite idée de ce qu'elle dévops.
Mais on voit de plus en plus de mots connexes poppés sur la toile.
Comme devdataops, finops, devsecops, noops, mlops ou encore mielpops.
Bref, on n'est pas sortis de l'auberge avec tout ça.
Bienvenue sur Radio Dévops, la balade aux diffusions des compagnons du dévops.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue à toi chers compagnons, dans Radio Dévops,
t'en émission de vulgarisation Dev & Cloud.
Et comme tu le sais, on essaie d'être didactique et de vulgariser un peu notre vision du dévops.
Mais avant de commencer, comme tu le sais, on est sur YouTube et dans un podcast.
Alors, c'est le scempinternelle.appel à t'abonner si tu n'es pas déjà abonné au podcast ou à la chaîne YouTube.
Et active la cloche, tu seras notifié quand on sortira une vidéo.
Tu peux aussi partager le podcast, l'envoyer à tes collègues,
l'envoyer sur les réseaux sociaux, sur LinkedIn, sur Mars avec Iginuti, on en a déjà parlé.
Alors, aujourd'hui, on va être sur un format un peu plus libre,
un peu table ronde autour des sujets whatever-ups.
Alors tu as compris, on va parler de tous ces termes qui commencent à faire parler d'eux.
Et on va essayer de les définir et de te donner notre avis dessus.
Et tu verras, on n'est pas tous d'accord.
On va essayer de ne pas sortir les gants de boxe et de rester courtois entre nous.
Pour en discuter et combattre avec moi, ce soir, j'ai R1.
Bonsoir, R1.
Bonsoir.
J'ai aussi Damir.
Bonsoir, Damir.
Je ne suis pas du tout d'accord.
Non, bonsoir.
Je suis un peu en avance.
A peu à l'en avance.
Et enfin, René, bonsoir, René.
Bonsoir.
Alors, on va commencer par les petites définitions.
Du coup, bon, est-ce qu'on définit le DevOps ?
C'est bien de définir le DevOps parce qu'il y a plein de gens qui arrivent sur la chaîne et qui ne connaissent pas forcément.
Il faudrait un jour d'ailleurs qu'on fasse un épisode de podcast sur le DevOps, pure et dur.
Qui veut bien tenter de définir le DevOps ?
Moi, je dis c'est au maître de la chaîne de définir le DevOps quand même.
Alors DevOps, pour moi, c'est avant tout une philosophie, un mouvement qui vise en fait
à rapprocher les équipes qui font du développement des équipes qui font de l'exploitation,
l'Ops, vous voyez, ou la production aussi, on appelle ça.
Et du coup, en fait, le but c'est les faire communiquer, d'améliorer en continuant nos pratiques.
Et puis le tout, évidemment, c'est pour le bien de l'entreprise.
Alors je vois que les notes de l'émission ne rèdent pas de troller toute seule.
C'est pour ça que je suis perturbé.
Qu'est-ce que vous en pensez de cette définition ?
Oui, c'est ça et on rajoutera peut-être que c'est le pont et le langage commun
qui est la méthodologie qui permet d'avoir un pont et un langage commun
entre les équipes plus Ops, du coup, et les équipes plus Dev.
Et je dirais que c'est aussi la mise en commun des objectifs.
Du coup, avant d'avoir des objectifs qui s'est scopés par métier,
du coup, on mesurait un peu, chacun en son coin, ses objectifs,
et on s'arrangait pour les atteindre.
Et d'où la fameuse caricature du ball Ops, il ne veut pas que ça change
parce que lui, sa métrique, sa stabilité et chaque mise en prod,
c'est un risque de détruire cette métrique.
Aujourd'hui, on en est passé sur des métriques, entre guillemets, de l'air DevOps,
qui vont être le nombre de déploiements qui sont effectifs,
le fonctionnement, après beaucoup de travail aussi sur la résilience,
qui est de manière un peu différente, un peu plus moderne.
Mais derrière ça, il y a une vraie restructuration des objectifs d'équipe.
D'ailleurs, j'en profite, je vais faire un peu mon autopromo,
mais si tu veux en savoir plus sur le DevOps,
c'est de forger un état d'esprit DevOps, tu peux aller regarder.
J'ai fait une formation qui s'appelle DevOps Mindset,
qui permet de rentrer dans le DevOps,
d'avoir une bonne vision de ce que c'est comme mouvement.
On a aussi le FinOps qui veut bien nous faire une petite définition du FinOps.
Je peux tenter.
Le FinOps, en fait, ça vient pour un peu troller AWS.
On va prendre l'exemple d'AWS, c'est quand vous êtes une grande entreprise,
c'est très vite le bordel pour comprendre votre facture.
Et il y a toujours la blague, d'ailleurs,
une société qui s'est créée pour la compréhension des factures AWS,
pour comprendre comment ou partez l'argent, parce qu'il part très vite.
Au final, c'est petit à petit, c'est devenu un métier,
parce que quand vous êtes une grande entreprise, vous avez plusieurs out-contes, etc.
Il faut pouvoir gérer cette facturation.
Et quand je digérais la facturation,
ça implique pas mal de choses qui se sont groupées dans un rôle, slash un métier.
C'est souvent un rôle qui a assumé par quelqu'un qui est dans les parties-là.
Ça a déjà d'identifier ce qui coûte de l'argent,
identifier aussi potentiellement pour la sous-facturation.
C'est-à-dire si vous avez des comptes, dans le cas où vous avez plusieurs BU,
et vous devez sous-facturer derrière,
vous devez être capable de sous-facturer,
c'est avec des tags et des choses comme ça, et de l'analyse de ce type-là.
Et aussi tout simplement,
au-delà de l'identification,
centraliser les différentes off-clouds,
centraliser les coûts pour avoir une vision claire.
Globalement, c'est d'apporter la vision des coûts dans le cloud à la société
et permettre derrière de jouer avec tout ça.
Peut-être que j'ai tort, mais pour moi, il y a aussi la notion
de rentrer un petit peu dans une démarche d'optimisation
et aussi de faire des intérations pour essayer d'une démarche d'amélioration continue
et de progresser un peu comme on le fait dans le DevOps.
Merci.
On va passer au truc que je ne connaissais pas avant ce soir,
avant qu'on lance l'émission plutôt.
Le DevOps, et je vois que Damir a une belle définition à nous donner.
Globalement, c'est pour discuter la donnée.
Le DevOps, c'est très dur à définir qu'on n'est pas habitué.
Globalement, comme on sait, la data est un cycle,
il y a une importance qui est plus vitale pour le business.
Le DevOps, c'est de garder cette vision d'attache, d'exploitation, etc.
dans le cycle DevOps et de coût de impliquer les parties prenantes de la data
dans ce cycle-là pour qu'elle puisse intégrer, potentiellement explorer de nouvelles data,
pouvoir en tirer de nouvelles informations,
à préférer la business intelligence dessus, etc.
Globalement, ça va être vraiment de travailler avec les équipes d'attache
pour qu'elle puisse profiter de cette mise en déploiement continué, etc.
Par exemple, si jamais demain on déploie une nouvelle feature
et que derrière on peut récolter des données sur quelque chose
et qu'elles se rendent compte avec le temps que la personne utilise mal,
ou que ce n'est pas clair, c'est aussi qu'ils puissent faire un feedback dessus,
réutiliser la data, l'adapter, etc.
Donc, c'est vraiment des impliqués là-dedans
pour qu'elle puisse avoir une interaction directe,
et pas que ça passe par des remontées de hiérarchie, etc.
qui prennent beaucoup trop de temps, mais qui, des fois,
font louper des trucs tout simplement au niveau de la data.
Je ne sais pas si c'est très clair, je ne vois pas simple.
Moi, ce que j'en avais compris, quand j'avais vu une présentation
un peu sur le sujet, c'est aussi un peu pareil,
c'est appliquer souvent la data, il faut la raffiner,
et donc la nettoyer, la rendre exploitable.
Et en fait, c'est appliquer des techniques qu'on a aujourd'hui dans le DevOps,
notamment la CI avec les pipeline et les étapes, les jobs,
les différentes jobs qui vont construire notre livrable.
L'idée, c'est aussi un peu d'appliquer,
enfin, ce que j'en avais compris, c'est que c'était d'appliquer
un peu ces mêmes techniques sur la donnée,
donc justement, rentrer dans un pipeline qui va la nettoyer, etc.
et la préparer, et de manière à ce qu'elle devienne exploitable.
Oui, c'est vrai que ça, je n'en ai pas parlé,
parce que j'ai peur qu'on parte plus sur les outils
que la logique, que le DevOps, c'est plus de la communication générale.
Mais souvent, quand on va parler d'airflow,
tout ça, ça va être pour optimiser des pipelines de la data,
et arriver à récupérer justement des données,
et être traitées automatiquement.
C'est pour donner l'exemple d'airflow.
Non, en parlant d'automation,
on va parler de MLOps qui veut nous en parler justement.
MLOps qui veut dire machine learning,
j'ai compris ça après, parce que pour moi, j'imaginais autre chose.
J'imaginais mailing least, ops.
Ben, je peux peut-être...
Moi, ce que j'en avais compris, c'est un peu comme pour la dataOps.
En fait, c'est sauf appliqué au...
enfin, pareil, utilisation des bonnes pratiques,
manière iterative, etc., qu'on a dans le DevOps,
mais au niveau du machine learning.
Donc, à pro-faire progresser les modèles de manière iterative.
Voilà, c'est...
un peu les techniques qu'on a, mais appliqué au machine learning.
Alors, comme je ne suis pas...
je ne connais pas forcément très bien ce domaine,
ça ne m'a pas forcément hyper parlé, mais c'est ce que j'en ai retenu.
C'est bizarre, c'est pas du tout l'idée que je m'en faisais.
Moi, j'imaginais que c'était le machine learning appliqué à l'ops,
c'est-à-dire on utilise le machine learning pour faire des...
pour gérer l'infrastructure, en fait.
Alors, après, je peux me tromper, mais je ne crois pas.
Je crois que c'est vraiment...
pour moi, c'est beaucoup lié aussi à la dataOps, justement,
préparer ces données et gérer ces modèles en continue,
en jante des pipeline et en améliorant les choses de manière iterative.
Mais je peux me tromper.
Mais j'avais la même image, le cœur.
Ouais, pour le coup, j'avais aussi un peu la même image.
C'est vrai que le problème, en fait, globalement,
le problème d'adonner du machine learning en général,
c'est qu'avec le DevOps, potentiellement,
les données à étant sa plus changées qui étaient récoltées
ou à être impactées par les changements.
Donc l'idée, moi, c'était plus de profiter de ça
pour ne pas quitter trop de delta et pas que ça casse,
entre guillemets, du machine learning ou autre.
Alors, du coup, après, on a le noops.
Le noops, c'est...
On a plus d'exploitation.
C'est tout, en fait, l'automatisation et la virtualisation
qui gère l'infrastructure.
Il n'y a plus aucune équipe interne qui s'en occupe.
Souvent, ça passe par la plateforme as a service, du pass,
parce que sinon, je ne vois pas trop comment on peut se passer d'ops.
Et c'est corollaire, en fait, du coup,
à l'automatisation dont on parlait avec le MLOps, peut-être.
Après, si c'est serveur là, s'il y a plus de besoin d'ops, de toute façon.
C'est pas comme ça ?
Oui, serveur là, je pense que c'est une suite logique, en effet.
On a après, mon préféré, le dev secops.
Qui veut nous définir le dev secops ?
Je peux me lancer.
Pour moi, c'est la prise en compte de la sécurité
dans le devops.
Donc intégrer des notions de sécurité au niveau des pipelines, par exemple.
Et aussi, je pense, en termes d'organisation,
penser la sécurité et avoir des intervenants
qui connaissent le sujet au plus tôt dans le projet.
C'est comme ça que je le comprends.
Au final, tu as plutôt bien résumé.
Je fais gaffe à l'exemple des pipeline et des choses comme ça,
parce que souvent, on tend à réduire ça.
Pour moi, le vrai truc du dev secops, c'est vraiment de dire aux équipes de sécurité.
On venait aussi un peu dans les équipes, dans les ateliers qui a, etc.
Pour voir ce qu'on fait.
Potentiellement relever des trucs,
potentiellement donner un coup de main et dire à ça,
on pourrait faire autrement un niveau secu.
Toutes ces choses-là qui ne sont pas forcément faites par défaut.
Souvent, quand on se retrouve dans des équipes produits, des features teams,
ou des choses comme ça, par défaut,
il y a du dev, du chef de projet et du coup de l'ops.
Un ou deux ops.
La sécurité est rarement présente totalement.
Donc il faut arriver à l'intégrer au plus proche de ces équipes,
pour garder un lien.
Je pense que c'est un peu commun avec tous ces termes-là.
C'est l'idée de mettre de l'huile entre les équipes
et d'appliquer la bonne communication entre les différentes équipes.
Le devops est connective people, c'est Nokia.
Je vous propose qu'on avance sur les définitions
et qu'après, on dise qu'on en pense un petit peu.
On va parler du GitOps.
J'avais justement d'ailleurs fait un épisode de podcast
en solo numéro 4 qui s'attitue là, c'est quoi le GitOps ?
J'encourage notre auditeur à l'aider à l'écouter.
Mais là, nous, on va faire une petite définition pour ce podcast aussi.
Je vais m'y recoller, je vais dire ce que j'en ai compris.
Pour moi, c'est un petit peu différent des autres termes.
Le GitOps, c'est plutôt...
Pour le coup, il me semble, c'est plutôt de la technique.
C'est de mettre la source de vérité de notre infrastructure
dont on gère dans Git.
Et donc aussi plutôt que de pousser les référentiels,
plutôt venir les chercher en fait.
Donc être en mode plutôt pool que push.
Et d'avoir un truc un peu plus événementiel
et éviter que l'infrastructure par exemple se mette à dériver
dans sa configuration.
Moi, ce que j'en comprends, je ne sais pas vous ce que vous avez...
Moi, je rajouterai que contrairement aux autres définitions qu'on a données
qui sont quand même liées d'une façon ou d'une autre
à des métiers qu'on arrive à resituer à quelque chose près.
Pour moi, le GitOps...
Je ne crois pas avoir vu une annonce parlant de...
On recherche un GitOps.
Pour moi, c'est plus une méthode.
Comme le disait René avec de la technique derrière.
Et avec ce côté de...
Si ça n'existe pas dans ce repo Git,
si ce n'est pas comité dans ce repo Git, c'est que ça n'existe pas.
Et pour moi, ce qu'on entend derrière GitOps,
c'est un peu tout ce qu'on vient de dire là.
Et ce n'est pas lié à un métier.
C'est-à-dire que quelque part, je dis n'importe quoi,
mais le vendeur de tomates, il pourrait faire du GitOps si il voulait.
Alors que les DevSecOps, ou même DevOps,
même si on est tous d'accord pour dire que c'est un mouvement
et pas un métier, etc.
N'empêche qu'on sait l'associer à un métier derrière de l'opérationnel.
Or que GitOps, vraiment, je ne vois que ça
par le prisme de la méthode et de la technique comme évoqué.
Moi, je vois le GitOps comme un outil et une bonne pratique
qui est à disposition pour nous.
Mais en fait, le GitOps, René nous a dit que c'est plutôt en mode pool.
Mais en fait, il peut s'utiliser en mode push et pool
en fonction de ce qu'on veut faire.
C'est vrai que les deux, en tout cas, dans la bonne pratique,
peuvent exister en fonction de ce qu'on veut.
En effet, on utilise plutôt du push que du pool.
Je suis assez mode pool, moi, que mode push,
surtout quand on fait du Kubernetes, mais on ne va pas rentrer dans les détails.
Du coup, on pourrait parler de tout un tas d'autres trucs.
En tout cas, moi, je n'en ai pas trouvé d'autres.
Mais on peut se poser la question de, finalement,
pourquoi tous ces termes sont apparus et pourquoi on en entend
de plus en plus parler depuis ces dernières années.
Est-ce que vous avez une piste justement là-dessus ?
Moi, j'en ai une petite.
Il y a deux choses pour moi.
La première chose, c'est les faits de mode.
On ne va pas se le cacher.
Les boîtes essaient de faire le buzz,
de faire monter les offres d'emploi, de ressortir un peu de tout ça.
Donc souvent, dès qu'il y a un mot comme ça qui apparaît quelque part,
les réutilisent à bonne mauvaise éssion.
Et du coup, après, ça fait du boule de neige.
Je n'aurais de sépar d'autres, etc.
Ce qui fait qu'on entend plus ou moins parler,
même quand ce n'est pas adapté.
Après, je pense que beaucoup de choses,
c'est déjà plus ou moins inclus dans le DevOps.
C'est pour moi le DevOps.
Je le vois vraiment comme une table
où tout vous a retrouvé toutes les parties prenantes,
comme un repas, faite venir toutes les parties prenantes.
Si jamais demain, vous allez à une entreprise
qui fait d'adaptables,
évidemment, la place à la table
et elle va rapporter un élément sympa et logique.
Après, d'un autre côté, je suis assez ouvert
et je me dis aussi que je comprends,
dans certaines entreprises, dans certains cadres,
qu'on puisse vouloir mettre l'emphase en changeant de termes.
Et au final, ça ne me dérange pas
et plus j'y pense personnellement, plus la sujet volume,
même sur la notion de,
est-ce que le métier de DevOps existe ?
Au final, je commence à me dire
si demain, une entreprise dans son organisation,
ça correspond à une réalité qui a une logique
et que ça l'aide dans son fonctionnement,
Why Not ?
tant que c'est clair pour elle
et qu'elle ne va pas dire à tout le monde
c'est un métier qui fait ça pour tout le monde.
C'est son implementation.
On a tous dans les entreprises connu des choses
qui étaient un peu spécifiques entreprise.
Donc là-dessus, je pense que c'est ça.
C'est juste pour mettre de l'emphase
et ce n'est pas forcément une problématique en soi.
Là, je ne suis pas sûr que
laisser trompier dans la porte
et la laisser ouverte comme ça,
ce soit une bonne idée
sur le terme du post-DevOps.
Mais bon, on en discutera justement après.
De mon point de vue,
il y a un truc,
j'ai l'impression qu'on a envie
en effet de mettre des étiquettes
parce que ce qu'on ne peut pas étiqueter
c'est un peu dur à conceptualiser.
Donc j'imagine que ça vient un petit peu de là.
Et puis parce que c'est un peu de la question
parce qu'il y a plein de nouveaux métiers qui apparaissent
puisque la numérisation
va aller en sacs élérants
et du coup, j'imagine qu'on met du hop
à tout va.
Et d'ailleurs, je me pose la question
en même temps que je parle.
Est-ce que les Devs aussi ont des
Dev à tout va ? Je ne sais pas.
C'est une question.
Sur Fullstack.
Je vais laisser rebondir quelqu'un d'autre.
Oui, sur Fullstack.
Backend,
Frontend Dev,
Fullstack Dev.
No Code, etc.
Oui, No Code Dev.
C'est vrai qu'il y a
une grosse part, un peu de marketing
là-dedans,
comme Damir l'a dit.
Après,
comme tu le disais,
catégoriser les choses, est-ce que ça aide
les gens à mieux comprendre
ce que c'est ?
Peut-être.
Je rejoins ce qui a été dit.
Je vois ça un peu comme
il y a
10 ans,
tu cherchais
quand tu cherchais du TAF,
tu cherchais un Génieur System,
ou je ne sais pas quoi. Aujourd'hui, tu tapes plutôt
des Vops. J'imagine que c'est un peu la même chose
pour
les autres TAF
qu'on a cité précédemment.
Je vois ça plus
comme l'évolution, parce que c'est
rentré dans le langage commun
et que les gens recitue peut-être plus
facilement, plutôt que
un métier qui a vraiment
évolué.
Je ne sais pas si tu as la même expérience que moi
là-dessus, je ne suis pas
le plus expérimenté.
Mais moi, j'ai toujours connu
les entreprises qui personnalisaient
les noms de postes pour mettre un truc
un peu sympa, un truc qui correspondait
potentiellement plus à ce qu'ils faisaient.
Et j'ai eu le droit à plein de choses
et au final, souvent c'était du métier d'adminsis
avec des petites orientations derrière.
Mais j'ai eu des trucs custom. C'est pour ça
que moi en général, tu cherches
plus au final,
je dis beaucoup de fois au final, tu cherches plus
par compétences, par domaine d'expertise, etc.
Et le titre du job,
ça fait des années que je ne m'y fit plus.
Là, je crois que je suis marqué comme développeur
dans mon job actuel.
Pourquoi pas ?
Mais ce qui compte, c'est la fiche de poste
et les missions, les technologies.
Je pense que ça a plus trop m'offi à ça.
Si l'entreprise pourrait, c'est plus significatif
de mettre A ou B, tant mieux.
Moi, je ne sais pas.
Je ne sais pas si vous allez même ressentir.
Oui, mais justement,
je pense que c'est pour ça que c'est
rentré un... enfin, qu'aujourd'hui,
tu vas voir des annonces de type
DevOps, de type DevSecOps, etc.
parce que justement,
c'est le lien avec
ce que opérationnellement
est attendu
et rentré un peu
dans le truc commun.
Et oui,
je suis d'accord.
Ce n'est pas parce qu'il y a marqué ça
que tu...
Il faut bien entendu
lire l'annonce avec vraiment le détail
des technos,
de ce qui est fait opérationnellement, etc.
Mais ce que je veux dire,
c'est que la mine de rien,
le...
quand tu cherches du travail,
ce titre, en fait, il va te ramener du monde
parce qu'ils savent qu'en cherchant ça,
il y a...
c'est connoté avec un spectre
d'activité et...
Je suis d'accord. Ce que je voulais juste dire,
c'est que ce n'était pas nouveau et moi, pour donner un exemple,
avant de retrouver le DevOps sur la mode,
j'ai eu du...
ingénieur technique en web opérationnel
ou des trucs comme ça, qui au final n'avaient pas
d'avoir en plus de sens que de dire, bah, t'es 6 à demi
ou un g6, quoi.
Ouais, d'ailleurs,
j'ai travaillé pour un...
il y a... avant, enfin, il y a
quelques temps pour une boîte où je suis
rentré, j'étais plus ingénieur
système ou quand même un truc comme ça,
puis un jour, on m'a tapé sur le pôle, on m'a dit
pour tout un tas de
raisons, on va taper
DevOps maintenant, est-ce que tu pourrais nous signer
cet avenant ? Oui.
Mais bon, bah, ça n'avait rien changé de ce que je faisais.
C'est... c'est parce que
ils avaient dû recruter quelqu'un qui
sous ce profil-là et du coup
pour faciliter aussi
en termes érages, on m'avait demandé
de... de signer l'avenant, quoi.
C'est bizarre, après, je sais que
les titres... il y a des titres
reconnus, qui correspondent
à une liste de compétences, en tout cas
en France,
puisqu'on a parlé de l'ingénieur
système DevOps dans une des trouvailles du Vondredi
et il y a des titres qui n'existent
nulle part ailleurs,
notamment le fameux
DevOps, ingénieur
DevOps, dont on a parlé il y a plus de 2 ans
et demi maintenant, c'était notre 1er épisodes de podcast
et à l'époque on était tous tombés d'accord
sur cet ingénieur DevOps, en fait
si on regarde la plupart des annonces du marché
on ne saurait pas ça... on ne saurait pas ce qu'il fait
en fait, et je pense qu'aujourd'hui
on saurait encore moins.
Ce qui... ce qui moi
me perturbe avec tout ça, c'est que
du coup, ces étiquettes
elles sont utilisées par des gens qui ne comprennent pas forcément
le mouvement
ou même ce qu'il y a derrière et que
du coup, on en arrive
à un truc où finalement
la plupart des gens, pensent que c'est des buzzwords
peut-être à juste titre
au final, et du coup
même les gens qui s'intéressent
à ça, n'arrivent plus à définir les choses
typiquement
les gens qui embauchent des DevOps
tu leur demandes, il fait quoi, votre DevOps
un coup il est développeur, un coup il est
hops, un coup il gère
la pipeline, un coup
il est gestionnaire de livraison
en fait, et au final il fait plein de choses
du coup, je suis un
peu perplexe vis-à-vis de tous ces termes
si ils ne sont pas clairement définis
et communément admis par la profession
j'ai un peu le cul entre deux
je suis d'accord
d'un côté, je suis d'accord qu'il n'y a pas de définition commune
je pense qu'il n'y en aura jamais
parce que le DevOps
surtout l'agilité de ça, c'est aussi s'adapter
en fonction de ses besoins
et on n'a pas tous les mêmes besoins, les entreprises
n'ont pas tous les mêmes besoins, et le métier c'est
toujours un peu différent
et quand on fait même un même métier dans plusieurs entreprises
souvent le scope bouge un peu, le fonctionnement
bouge un peu, donc ça ne me paraît pas
déconnant que tout le monde n'est pas la même définition
ça ne fait pas forcément quelque chose pour moi
d'éliminatoire
moi je ne pense pas
donc c'est vrai que pour le coup
j'ai le temps, ça ne peut pas être dérangé
par le fait que demain une entreprise
dise je cherche un DevSecOps
du moment où
si je fais l'entretien quelque chose
et que je conseille de façon à nos auditeurs
c'est que si jamais vous voyez des offres avec des thèmes comme ça
moi je vous conseille de faire ça, c'est de leur dire
j'ai vu l'offre, pour moi ça ne veut pas forcément dire grand chose
pourquoi vous avez usé
ce mot entre guillemets
qu'est ce qu'il y a derrière, qu'est ce qu'il y a d'ailleurs
et je pense que certaines entreprises
c'est du buzzword, elles vont vous dire
ça marchait mieux dans les recherches
et vous avez aussi certaines entreprises
qui pour le coup je pense vont vous dire
non parce que là en fait on a vraiment fait une structure
autour de telles modèles etc
et ça peut amener des choses intéressantes
c'est vraiment à calibrer en fonction de l'entreprise
du contexte et de comment adapter
mais c'est pas éliminatoire pour moi de part
de définition commune parce qu'on serait
sûrement pas tous d'accord soit définition
d'un bon ops ou
d'un bon dévoure
d'un bon dévoure
du coup avant qu'on arrive
à la section où on va dire
ce qu'on en pense, est ce que vous pensez
que l'on va avoir de nouveaux termes
qui vont arriver dans les années à venir
c'est sûr, avec différents
en fait
ça donne quand même le sentiment
que dès que tu deviens
fin dès qu'il y a des spécialisations
possible sur des domaines un peu précibes
et que ça devient
besoin de retrouver un peu les méthodologies
qui sont propres
au DevOps
si ça peut coller
tu peux générer
un terme comme on les a
cités au début
moi ça me choquera pas
de voir de nouveaux trucs
arriver en tout cas
moi je vais déposer
Quantum
pour le
pour le quantique
ah mais n'oublie pas de déposer ça
sous forme de NFT dans un super jeu
des 7 familles de DevOps
à collectionner bien sûr
j'ai le magie j'y pense
mais alors vous n'êtes Quantum
ou QOops
ah j'aime mieux Quantum
ça me rappelle quoi de Quantum
c'est ce que tu auras la référence
mais pas tout le monde noir
ouais et j'ai la référence
si vous ne connaissez pas vous pouvez aller voir
du coup on va pouvoir sortir les gondes box
et parler de ce qu'on en pense
et de se dire
franchement les choses peut-être non
allez c'est qui qui commence
et sur quel sujet
je vais me permettre de prendre la parole
comme j'ai mis la première note là dessus
après on se tape là dessus
moi ce que je trouve de commun
à tous ces métiers
on va dire
en jeu mé métier entre guillemets
c'est le côté
le fait
d'appliquer les méthodologies
des DevOps avec
le fameux 8
de test
de deploy
observé etc
et ça m'éloy et tout
mais avec ce côté
il faut que
tout soit reproductible
comité
c'est pour ça que le GitOps qu'on évoquait un peu plus tôt
pour moi c'est clairement
dans ce sens-là
et du coup
qu'il y a un côté déterministe
aussi et automatisé
c'est à dire qu'il y a cette notion
de ne pas faire rien à la main
tout ce qu'on fait
on le fait via
des automates
des pipelines de ce qu'on veut
et tout ce qu'on fait
on le fait à partir d'une source de vérité
qui peut être
un repo
un repo Git
et j'ai l'impression que
que les métiers qu'on a évoqués
et que le côté opérationnel
de ces métiers là c'est de produire
du contenu pour répondre
à leur spécialité via
via ce que je viens de dire
donc le côté reproductible, comité
déterminé et automatisé
voilà j'ai lancé le premier pavé
fait de ce que vous voulez
je sais pas si c'est un pavé en fait
parce que... alors après
dans tous ces termes là
il y a des posts qui sont clairement identifiés
moi j'identifie clairement
ce que c'est un fin Ops
je vois bien
son but
et en effet je ne sais peut-être pas le recul
mais je ne vois pas ce que ça pouvait être
avant l'arrivée du cloud
alors évidemment Damir pourra me dire
oui mais tu sais dans les data centers
on faisait déjà ça
je sais pas comment s'appeler ce métier là
mais c'est peut-être le gestionnaire des achats
je sais pas et je sais pas si le fin Ops
a justement
une fibre technique aussi
moi je le vois comme ça
parce qu'on me dit Ops
je me dis il a quand même un aspect technique
il connaît le cloud
il sait que et peut-être qu'il va chercher
à optimiser
avec l'architecte en disant bah voilà
peut-être qu'on pourrait faire chante de choses
non mais vas-y vas-y je te laisse
pardon excuse-moi Damir
je te laisse la parole
alors je très rapidement
moi j'ai envie de dire oui
pourquoi pas avoir ce côté technique
alors peut-être c'est pas lui qui va modifier
le terraform en fonction des optimes
qui l'aura vu
mais par contre son analyse
de la facture AWS
peut-être qu'au début
il fait des trucs à la main
mais j'espère surtout dans les grosses entreprises
où là c'est peut-être très pénible
à faire et très complexe à suivre
j'espère qu'il y a des outils
qui permettent de dire
bah tiens
je dis n'importe quoi
mais ah bah tiens derrière ce lot de balanthiers
on a mis quatre machines alors qu'en vrai
avec deux ça serait largement
suffisant ou des trucs comme ça
et ce genre d'analyse
j'espère que c'est
quelque chose qui
peut être automatisé via
du scripting
etc
enfin c'est un peu comme ça que
je voyais le truc
ouais bah globalement c'est un peu comme j'ai dit
d'ailleurs bah ça dépend des entreprises
dans les petites entreprises souvent
c'est plus un rôle que porte quelqu'un dans l'équipe
ou porte même toute l'équipe en fait qui fait
le terraform et qui se plaissent un peu de temps
pour optimiser potentiellement
voir comment
je sais pas migrer sur du spot par exemple
les GlusterCube pour gagner un peu d'argent
et j'ai vu aussi des grandes entreprises
où c'était structuré où t'avais vraiment une personne
donc son rôle était Phenops
pour le coup c'est pas de l'opérationnel
au sens où on entendrait souvent
c'est plus de l'opérationnel au sens où la personne
comprend un peu les paradigmes et les concepts
globaux et aussi surtout
l'organisation du cloud
si je prends l'exemple et je prends cet exemple là parce que
dans le compte-fois je suis désolé mais dans un gros zorgas
c'est ce truc qui est complet
si on prend un WS il faut quand même avoir des bonnes notions
pour comprendre comment ça s'enclenche, une organisation
les différents accounts, commandes à gérer la facturation
des différents services, comprendre
ce que ça implique, tout ces choses là
en fait il faut que les personnels comprennent donc
un objet est un peu technique même si c'est pas de la technique
opérationnelle en réalité c'est plus de la technique de logique
ou un peu de la technique de certif, on va pas se mentir
et d'ailleurs ça en fait
ce qu'il va faire c'est définir des plans de tagging etc
pour récupérer ça dans des métriques
et dans des dashboards
d'exploitation, il y en a dans un AWS
il y en a des indépendants, je suis sûr qu'il y en a qui s'amuse
à faire ça sur l'excel et du csv pour bien souffrir
mais là c'est des questions de moyens
c'est pas le problème
mais d'ailleurs on va faire du reporting là dessus
et si jamais en général il y a des pistes d'évolution
par exemple si on voit qu'un cluster cube coûte très cher
et c'est un cluster de staging
ces personnes là elles ont peut-être potentiellement des pistes
par exemple dire bah on va passer sur du instant spot
on va l'éteindre à tel moment
mais en général elles vont aller voir les ops
ou elles vont aller voir des architectes et tout
et dire je vois que ça ça coûte cher
est-ce qu'on aurait des pistes pour l'améliorer
ils vont trahir ensemble
pour le coup là
oui c'est exactement comme ça que je le voyais en effet
comme quelqu'un qui comprend le cloud
mais c'est pas lui qui va faire le travail
sauf en effet
plus l'équipe est petite évidemment
plus les gens ils font
tous les métiers quoi c'est évident
plus l'entreprise est le monde
je parle d'entreprise qui payait des millions par an
en terme de cloud
ouais j'ai rarement vu des entreprises comme ça
moi le dev data ops
il m'interpelle aussi
j'aimerais bien qu'on y revienne dessus
est-ce que c'est un métier pour vous
est-ce que c'est
ou est-ce que c'est quel que... enfin j'ai
je vous avoue que
je reste perplexe là devant en fait
ou est-ce qu'on a pris le mot data et qu'on l'a collé entre
des dev ops parce qu'on s'est dit c'est le dev ops
adapté à la data je sais pas
moi je vais attendre ça dire c'est plutôt
plutôt des mouvements et pas forcément des métiers
et après
le terme va définir
les pratiques qui vont être
qui vont avoir lieu et un petit peu la technologie
et sur quel domaine ça va s'appliquer
enfin moi tous ces termes là je les vois comme ça
et du coup
je pense que l'intérêt c'est
c'est que ça fait
une caractérisation
un peu grosse maille
quand même voilà de
qu'est-ce que le poste va être
peut-être
ou qu'est-ce qu'on va attendre
quand on va aller sur
un poste intitulé
dans lequel on aura ces mots-là
moi je vais
rajouter à ce que
René vient de dire c'est que
effectivement
si je suis d'accord avec ce côté
c'est plus de la méthode
ou etc. appliquer
donc au domaine de la data etc.
ou en vrai
ça a toujours existé
des personnes qui étaient là pour raffiner
les données
qui étaient là pour les exporter
dans le bon format
ou dans les bonnes bases de données
ou les exporter vers des partenaires extérieurs
ou je sais pas quoi
et j'imagine
le taf de Dev Data Ops
comme quelqu'un qui
applique les méthodologies
avec
On Commit
comment dire
on automatise tout ça
le pipeline d'automatisation
de transformation de la données
de mon hotel
en fait tout ça c'est comité
et donc du coup
avec ce côté
je sais reproduire
exactement mon état
et puis j'ai les outils pour
observer que ma transformation
je gagne du temps
de dessus
au fur et à mesure
et donc j'y ter pour gagner du temps
et pour améliorer mon process
c'est un peu comme ça que je vois le métier
mais tu vois j'ai pas l'impression que c'est hyper nouveau
en tant que tel
c'est juste la méthode
qui est
ce qui vient du monde de Dev Ops
ça a l'air de pas mal marcher entre Ops et Dev
on doit pouvoir faire la même chose
excusez-moi
les métiers qui faisaient de la data
c'est pas les métiers du Dev
non
moi je
enfin après
j'imagine bien sûr encore une fois ça dépend
des contextes etc mais tu vois
les deux dernières boîtes que j'ai faites
les personnes qui manipulent vraiment
de la data c'était pas
des Dev en tant que tel
c'était des gens qui maîtrisaient
des outils alors je pense à des outils
comme ça
qui s'est manipulé
enfin qui permet de te faire un hotel
de la mort
et tu vois
c'est des gens qui savaient
faire de l'algorithmie
ou des choses comme ça du traitement
de données voire même du traitement de données
à très grande échelle mais
c'est des gens
qui sont sur un domaine
technique très spécifique donc tu vois
enfin en tout cas
peut-être que j'ai mal compris la question
mais si le côté
est-ce qu'on a besoin de Dev pour faire ce genre
de métier ?
je vais préciser parce que pendant un long moment
moi chez Casino je m'occupais
de l'exploitation et de l'installation
de tout un tas de flux ETL donc c'est un truc
que je connais bien et en fait
les flux ETL on utilisait informatica
nous étaient livrés par les développeurs ETL
on les appelait les développeurs ETL
c'est des équipes de développement
spécialisés dans l'ETL
ou dans la gestion de la donnée
et du coup
moi je m'interroge parce que pour moi
c'est des développeurs particuliers
au même titre que les Devfront, les Devback
on a les développeurs qui développent des outils
liés à la donnée on a aussi
les Ops qui sont
affectés à des outils liés à la donnée
je pense notamment au DBA
et à la database administrateur
et je me pose la question de est-ce que finalement
c'est pas et des Dev d'un côté
et des Ops de l'autre qui sont en effet dans les métiers
de la donnée et que finalement
ce Dev d'un côté c'est ni plus ni moins que du DevOps
parce que c'est des métiers
que ce soit des Dev sur des Ops
je dois m'en dire là dessus rapidement
je sais pas trop trop tant
je suis d'accord sur le fait que de façon
tout ça globalement, à part FinOps qui est à part
reste quand même
des bonnes pratiques ou de l'extension de DevOps
après pour rebondir là dessus
je reste un peu sur
ma vision qui est escalée
et je vais donner
des exemples
typiquement pour le dev data Ops
ou le DevOps
peu importe comment on l'appelle
j'ai envie de dire
effectivement de l'un côté c'est des Dev
qui ont une spécialité
en général ça n'a pas le titre de developer
c'est plus des data engineer
ou des choses comme ça
donc ces personnes là
elles travaillent d'autres contraintes
elles travaillent une autre échelle sur d'autres problématiques
l'optimisation n'est pas la même
les langages, la manière de faire n'est pas la même
les réflexes ne sont pas forcément les mêmes
donc pour moi c'est vraiment une spécialité
et en fait de l'autre côté
c'est pareil en fait on ne gère pas les mêmes stacks
là où tu as peut-être l'habitude
de gérer un cluster cube quand tu as un Ops
applicatif on va dire ça comme ça
là tu vas plus gérer comme j'ai du cluster
du coup du air flow
et des choses comme ça
donc pour moi et moi
typiquement je finirais là dessus
deux fois des missions qu'on aurait pu appeler
data Ops ou ce qu'on veut
ce qui était vraiment ce qui changeait par rapport
au reste ou au métier en fait
classique d'Ops en environnement
d'Avox c'était la stack techno et la manière
de faire et d'échelle pour le faire
et pour moi quand on utilise ce mot là c'est plus
pour préciser cette contrainte là et dire ce contexte
il est particulier parce qu'on gère de la data
c'est pas les mêmes outils c'est pas les mêmes services
et les choses comme ça que réellement
derrière entre guillemets
un truc révolutionnaire
c'est plus pour préciser ce contexte en fait ça
une simplification
de ça
puis peut-être aussi le livrable
livrable est pas le
même dans la data Ops
l'idée c'est de
le livrable c'est
comment dire exploiter ces données là
et trouver ce qui fait du sens avec ces données là
je sais pas voilà
moi je rajouterai je viens de faire
pendant qu'on discutait un truc
très très con j'ai cherché
des annonces là dessus
et j'ai regardé
donc le détail des profils recherchés
là je vois donc c'est vraiment
un poste data Ops
le bâgin de rechercher
c'est ingénieur soit commercial avec
force forte appétence
pardon pour la data
connaissance en SQL
personne analytique
tu comprends la valeur ajoutée qui apporte
le data au business
et tu es bon communicant
donc
ce que je veux dire c'est que du coup là
on est quand même très loin
d'une annonce type dev
et on peut
je pense pas que
personne qui postule là va avoir
un test technique
on va
pointer la dessus
d'algorithmie
et
alors
sur un échantillon de 3 annonces
ça va vraiment prendre avec des pincettes
mais sur les 3 annonces on retrouve
un peu ce même pattern
il n'y a qu'une annonce
où j'ai vu
une techno
mis vraiment en avant
là c'est celle que j'ai sous les yeux
il y a quand même marqué à la fin
savoir développer
des scripts pour de l'automatisation
entre parenthèses pitons avec des tâches
synchrones serait un plus
un plus
voilà je voulais apporter
ce prisme
à la discussion
moi ce qui m'embête avec ça
en fait et on va le retrouver dans le dev cccops
je suis encore plus
vm avec le dev cccops
c'est que finalement
on va créer
on va créer des séparations
là où il n'y en a pas vraiment
là où justement la philosophie
elle est partagée dans toutes les parties
prenantes de l'entreprise
pour moi profondément
pour moi le devops ça doit s'étendre
même au non tech
la compta
la direction, la rh
devrait faire du devops et donc
en effet il faudra peut-être le renommer mais
l'idée c'est de faire de l'amélioration continue
de l'automatisation
de la communication
et donc
ce qui me gêne en fait avec ça
c'est qu'on va créer
des nouveaux termes
des nouvelles cases
et donc il dit
nouveau termes, nouveau casse, nouveau silos
et finalement est-ce qu'on va pas re-siloter
quelque chose qu'on essaie de dessiloter
et c'est encore plus vrai
pour moi avec le dev cccops
et peut-être qu'on pourrait parler au dev cccops
parce que
le métier de la sécurité c'est quelque chose
que je vois plus que les métiers de la data
et moi il y a un vrai problème
pour moi
dès que j'entends parler de dev cccops
déjà ça se entend un truc c'est que
les équipes qui font de l'ops
enfin que les équipes secues
ne font pas partie des ops
pour moi
c'est des gens qui font
de la production aussi
comme les admin 6, les dba, les gens du réseau
du stockage etc etc
et pour moi ça renforce le silo comme je l'ai dit
et j'ai peur finalement
qu'en utilisant le terme
dev cccops
ça renforce l'idée de ceux que je connais
que la sécurité
il reste dans leur tour d'ivoire
et qu'ils appliquent les méthodes de DevOps
sur leur truc mais depuis leur tour d'ivoire
et qu'ils se mélangent pas
c'est ça qui est vraiment mon gros problème
ça c'est pas
comment dire
un constat
de quand t'as des entreprises
qui grossissent de plus en plus
il y a aussi des spécialisations
qui deviennent de plus en plus pointues
et en fait c'est peut-être juste pour caractériser ça
c'est à dire que je crois pas
qu'il est forcément
ce côté silo comme tu le dis
il n'y a rien qui implique
forcément que les gens
sont pas censés travailler ensemble
et avec ce côté tour d'ivoire que tu viens de décrire
c'est
justement
normalement si tu respectes
un petit peu tous les préceptes
de la méthodologie
c'est censé
être des choses sur lesquelles
les gens se retrouvent
parce que justement ils vont être
contributeurs les uns des autres
ils vont être clients de ce que produit l'un et l'autre
mais tu vois moi je vois plus ça
comme il y a des gens qui sont plus spécialisés
là dessus
et voilà comme t'as des gens
qui sont spécialisés
en piton et d'autres en js
bah ça veut pas dire
tu vois je sais pas
peut-être que je suis
un peu naïf là dessus
je comprends ce que tu veux dire
mais je vois pas pourquoi ça serait
forcément incompatible
non mais on est profondément d'accord
c'est juste que
pour moi le DevOps c'est pas un métier
donc à partir du moment où c'est pas un métier
c'est en effet un mouvement que tu partages dans l'entreprise
et donc les gens de la sécurité
sont partis prenant de ce mouvement là
et devraient être au même titre que les
développeurs backend frontaine de les adminsis etc
participer au mouvement
et pour moi on n'a pas besoin d'un nouveau terme
pour rajouter quelque chose
vas-y Roder je te laisse rebondir
non ce que j'allais dire c'est ce que je trouve assez rigolo
c'est que moi je comprends plutôt la mer c'est-à-dire
que du fait qu'on est en train de dire
on va faire que la sécurité
qui est justement assez
dans sa tour d'ivoire
viennent
dans ces pratiques là
pour moi c'est justement on va essayer de casser le silo
après peut-être que
est-ce que
il fallait un nouveau terme ça je suis pas sûr
parce que ça devrait être quelque chose globalement
je suis assez d'accord avec toi implicit
c'est-à-dire que dans le mouvement
DevOps il y a déjà ça
après on a un nouveau terme pour peut-être
rappeler aux gens de la sécurité
que ça serait bien qu'ils travaillent avec les autres
merci Roder
tu vas dans mon sens
dans ce sens là où justement
je m'attends un jour à arriver
voir le terme de FQA SecOps
et je ne sais quoi
mais en effet pour moi les gens de la sécurité
ils sont désagré comme les autres
je lui dis
je suis un peu l'élément perturbateur
c'est vrai que
je suis d'accord dans l'idée que
le DevOps encore une fois ça basse et englobe tout le monde
etc c'est magique
mais il y a aussi un côté réel
où on sait très bien et surtout dans la première année
du DevOps
il n'y a pas de tout le monde qui d'un coup s'est dit
oui travaillons tous ensemble
pour aller dans la même direction
dans la joie et la bonne humeur
ça ne s'est pas passé comme ça
et on sait très bien et historiquement
il y a un historique là-dessus
au début moi j'ai des souvenirs des équipes de sécurité
qui étaient ultra-optes de DevOps pourquoi
notamment parce que eux aient des paradigmes
de gestion notamment de certification
qui sont différentes
où ils avaient des cycles, des cycles beaucoup plus longs
des certifications il faut être sûr
des versions qui tournent etc
et eux quand le DevOps il est arrivé globalement
ils ont vu un boulet qui détruisait tout leur métier
et dans beaucoup d'équipes
je ne dis pas que c'est partout encore une fois
il y a toujours des exceptions etc
mais dans beaucoup d'entreprises notamment des grandes
du coup ça crée une frustration
et la sécurité qui était déjà un peu dans sa tour d'ivoire
parce que dans la sécurité il y a des obs
des gens qui sont plus obs mais il y a aussi beaucoup de gens
qui font de la
de la validation etc
de la certif etc qui sont plus papier
tous ces gens là sont un peu retrouvés isolés
parce que ils étaient un peu en opposition là-dessus
et le DevOps au début ça allait un peu vite
ça allait dans tous les sens
et ils n'ont pas forcément été écoutés dans les entreprises
parce qu'elles voulaient mettre des freins
ils n'ont pas arrivé dans beaucoup d'entreprises
à se trouver le rythme et la manière très ensemble
ils ont retrouvé isolés et là pour moi
l'idée du DevOps souvent
ça va être du coup de
dire bah venez
revenez dans la boucle
on va trouver des moyens de faire ça ensemble
et c'est pour ça aussi que tout à l'heure j'étais un peu chiant
sur le fait de
le DevOps c'est pas
je prends l'histoire de Piper
je t'ai décoré avec toi René c'est juste
désolé de prendre cet exemple mais celui qui revient le plus souvent
c'est souvent je disais on est DevOps
parce qu'on a activé le test
le Dast ou Stas
donc les tests d'analyse statique ou dynamique
sur GitLab donc du coup
non c'est pas ça
le DevOps c'est de faire revenir
ces équipes qui étaient un peu opposées aux trucs et tout
et de voir comment ensemble on peut résoudre ces problématiques
après encore une fois je refais juste un petit parallèle
de une phrase
il y a aussi des cas où le DevOps ça désigne vraiment
une position où la personne va gérer
comme je disais pour le Datalog c'est un exemple
là j'ai pas connu ce métier là mais j'ai connu de gens
qui avaient ce rôle là de dire bah on est par exemple
sur AWS et moi mon rôle c'est
entre guillemets DevOps dans le sens où
c'est d'intégrer de la sécurité de manière automatisée
flexible
avec tous les paradigmes
Git etc donc du coup bien fait
on a un phrase code
dans le cloud et du coup c'était un vrai rôle qui faisait le pont entre tout ça
voilà ça c'était pour la petite
chose qui peut aussi encore trouver une entreprise
mais pour le reste
pour moi je suis
c'est pas forcément déconant mais encore une fois
dans l'idée on est tous d'accord sur le fait que non
DevOps ça inclut tout le monde mais la réalité
il y a une historique et un passif là dessus pour moi
justement
je vais apporter
mon deuxième point et tu me fais une transition
parfaite le dev secops
me gêne pour une deuxième
deuxième chose c'est que ça sous-entente la sécurité
et pas inclut dans le DevOps
alors même que c'est par design
un mouvement qui prône l'amélioration continue
et de ce fait là
sous-entente qu'en fait on a besoin du dev secops
pour amener la sécurité dans les applications
ou les infrastructures
pour moi c'est un vrai problème parce que ça veut dire
que avant on le faisait pas
ce qui est pas vrai, si c'est fondamentalement pas vrai
on le faisait
alors peut-être qu'en effet on le faisait mal
ou peut-être qu'il y a des gens qui le faisaient pas
mais pour moi c'est pas
enfin je veux dire
c'est
c'est
c'est comme si en fait
on avait découvert que la sécurité
existait et qu'elle devait être inclue
dans le DevOps avec ce terme là
et moi ça me choque
parce que pour moi c'est quelque chose qui est là
depuis le début
et en effet il y a des entreprises qui le font pas
mais
et c'est à nous
de faire ça, je vais rebordir sur un deuxième truc
tu dis c'était magique
ne laissons pas croire aux gens que le DevOps c'est magique
et que c'est facile, non
ça demande du travail
c'est un long chemin pour faire passer
l'entreprise au DevOps parce que ça demande
de la communication et de la coopération
entre les équipes et ça c'est pas inné
c'est très compliqué et c'est très long
surtout quand on part
d'entreprises où il y a des silos qui sont très
claires et très posés
moi j'ai quitté, il y a longtemps je travaillais
longtemps dans une entreprise où il y avait
des silos même entre DevOps
il y avait des silos entre
les gestionnaires d'applications
entre les gens qui s'occupaient du système
les gens qui s'occupaient du réseau
il y avait des silos même entre DevOps
donc on va s'attaquer
à faire casser ces silos et c'est long, c'est pas magique
et c'est pour ça que
moi je suis embêté avec ce terme-là parce que
ils sous-entend plein de choses
qui en fait sont inclus dans le DevOps
et l'existence même de ce mot-là
fait que
quand tu vas parler du DevOps
les gens vont te dire oui mais attends
le DevOps c'est bien gentil mais on va faire du
DevSecOps, on va faire de la sécurité
alors qu'en fait non, c'est déjà dans le DevOps
et c'est
c'est aussi
ce qui a induit par ce terme-là
je réponds juste que du coup
tu relevais des points de vue
encore une fois je pense que sur le fond on est d'accord
mais dans la logique
déjà il faut voir que la sécurité
c'est pas que des opérationnels et je dirais même plus
un RSS6 n'est pas un métier technique
ça j'avais interviewé
un RSS6 dans un autre podcast qui a expliqué ça
RSS6 n'est pas un métier technique
c'est un métier de gestion
c'est un métier de gestion de risque et des choses comme ça
et eux tous ces paradigmes et tout qu'ils ont
c'est des paradigmes qui au début
encore une fois
effectivement dans les petites entreprises etc
ça n'a pas posé de problème, les secuis ont dit
vous travaillez comme ça on va trouver une solution
mais dans beaucoup de grosses boîtes ça a créé des problèmes pourquoi
parce que quand tu mettais en prod
un projet, il fallait que tu fasses une fiche de mise en prod
avec ton PV
de mise en prod
avec les versions impactées etc
que tu le fasses vaider par la secule
la secule faisait après une période de pen test
une fois qu'elle a la vaider c'était ok
et en fait ce cycle là tu ne pouvais plus retrouver le DevOps
donc dans beaucoup de cas
et encore une fois c'est pas tous les cas
mais dans beaucoup de cas notamment de grandes entreprises
et c'est des cas que j'ai connus
la sécurité c'était naturellement mis un peu à l'écart
parce que elle était perdue on est passé au cloud
avec des paradigmes de sécurité qui sont différents
des paradigmes de gestion
de certification, de gestion de risque etc
c'est pareil ils ont du tout recommencé à zéro
et du coup
ils se retrouvaient un peu en merdé
et d'un autre côté ceux qui voulaient un peu passer
moderne et accéléré
les équipes de DevOps
ah un terme je ne vais pas lui dire
mais les équipes de DevOps qui voulaient avancer
ils n'ont pas pris le temps de voir avec la secule
la secule elle était un peu perdue entre les deux
et pour moi ça peut désigner juste ça
après oui des entreprises ils seront mal de termes
mais les entreprises utilisent déjà mal
le terme DevOps en fait
le terme de base est déjà fucked up
je suis désolé mais quand je vois le nombre d'entreprises qui me disent DevOps
on m'a déjà dit on entreteint dans une grande entreprise
pour un poste
vous êtes combien de pourcent DevOps, combien de pourcent Hops
c'est déjà fucked up
je pense que le terme de base
il est mort et il fout de la confusion dans des boîtes
ce terme là ne foutra pas plus la merde
non non
non mais on le défend
mais ce que je veux dire c'est que ce terme là
ne pose pas plus de problèmes ça
tant que l'entreprise utilise pour une vraie raison
si l'entreprise utilise elle dit parce que putain c'est cool
on a fait plus 12 candidatures sur LinkedIn
oui c'est de la merde
si par contre derrière elle me dit parce que nous
on a une équipe entre avec la sécurité pour faire des policiers
que ce soit d'Optail Cloud etc
tout en gardant une flexibilité
je dis why not, il y a un truc qui se défend
je suis très chiant je sais
non non mais R1 renait
des choses à ajouter
ou on vous a séché
tous les deux
ouais après voilà
moi je suis
enfin
voilà ça me ch...
enfin je suis pas choqué par le terme
voilà après
après je suis pas sûr qu'il était nécessaire
mais voilà ça me choque pas non plus
si ça permet
à la sécurité
de progresser
et aux gens de mieux comprendre
ce que c'est
ben pourquoi pas en fait
je suis un peu là dessus en fait
je suis un peu sur ce stade fait
ouais mais alors
je suis d'accord
parce que je pense que la sécurité
comme tous les métiers
a besoin de progresser
nous les premiers mais
déjà il y a une grande partie des entreprises françaises
et européennes qui sont même pas passées au DevOps
ou alors qui n'ont pas encore entendu parler du DevOps
là on amène le DevOps
le fait est en effet
que les équipes de sécurité
et je pense que même avant le DevOps
étaient un petit peu dans leur tour de l'hiver
en tout cas j'en ai connu beaucoup qui l'étaient
c'est aussi à nous
de les accompagner et de leur dire
mais non en fait on fait partie du même bateau
et on va aller ensemble
faire les choses
et là où je vais
enfoncer Clou
c'est un guide qui m'a profondément agacé
je l'ai pas lu entier tellement
tellement dès le départ
c'est...
enfin voilà c'est
du Magaity, stratégie d'ESI 2021
qui parle du DevSecOps
et en fait je l'ai appelé
dans les notes de l'émission la stratégie du Pipo
parce que ça commence déjà
par quel problème
essayer de résoudre le DevSecOps
c'est intégrer la sécurité dans les pratiques des DevOps
je n'ai pas parlé donc je vais pas mettre en dessus mais
c'est aussi ce genre de choses qui m'embêtent
c'est quand on communique
et surtout quand c'est des grandes
des grands magazines
le Magaity c'est plus grand que nous
ça m'embête en fait
ça m'embête et je trouve que
ça va dans la mauvaise voie
alors déjà que le DevOps est dans la mauvaise voie
et je trouve que vraiment
je pense que je vais faire
un épisode de podcast solo
je vais l'attituler le DevSecOps
c'est du bullshit
mais bon ça c'est...
mais je comprends ton avis Damir
c'est juste que moi je refuse
parce que je ne comprends pas c'est que
tu as le même problème avec le DevOps
c'est des choses, c'était des bonnes pratiques
travailler en collaboration avec les DevOps, la muration continue
c'est des trucs que j'ai déjà connu avant le DevOps
du moins un sympa naturel quand il y avait
une alarme qui sonnait
et quand le DevOps disait ouais bah la paix est m'implementée
il faudrait plutôt check ça ou check ça
de me dire ah ouais bah plutôt que la mute
ou la secca je vais aller corriger le truc
je vais le redocumenter etc
tout ça on va pas seulement tirer le DevOps
encore une fois c'est juste un regroupement
c'était pour faire beau on a pris toutes les bonnes pratiques
qui existaient on a fait un beau regroupement
on a appelé ça le DevOps parce que ça allait bien
et parce que d'ailleurs on a pu claquer des paradis
mais des choses comme ça un truc cohérent
mais ça reste de la bonne pratique
et ça on n'empêche pas le mot d'être mal utilisé
l'idée pour moi c'est vraiment d'intéresser
tous ces mots là pour moi ils peuvent dire 3 choses
et là je conclure un peu sur ma vision de choses
moi quand on parle de DevSecOps, de DataOps
ça ça peut dire 3 choses
c'est du bullshit et on veut vendre un truc disruptif tout ça
on s'en fout
donc ça on le voit très vite quand on s'en parlait
avec les parties prenantes
2ème cas ça représente une réalité technique
et une stack technique chez eux comme je dis avec le DataOps
comme je dis avec le DevSecOps
où tu vas travailler sur une stack avec vraiment
des idées très particulières, sécurité sur AWS etc
donc des scopes très réduits
et ensuite il y a le cas en fait
effectivement où c'est juste pour mettre l'enface
sur quelque chose et dire
là on dit DevSecOps parce que
l'équipe sec elle était un peu à côté
on a changé le mot parce que chez nous
c'était important pour eux, c'était important
pour qu'ils se sentent intégrés
et tant mieux, si derrière ça les aide à utiliser
les bonnes pratiques, moi je m'en fous
ils peuvent l'appeler comme ils veulent, ils peuvent même me dire
que le DevSecOps c'est un métier qui est dérivé du métier de DevOps
en réalité c'est pas grave
tant qu'elles ont compris la logique derrière qu'elle applique
au final c'est la bonne chose
si demain ils veulent s'appeler DevOps
si demain ils veulent s'appeler
je sais pas, moi la bande de canards on ne sait rien
je sais pas grave
pour moi l'important c'est qu'ils comprennent la philosophie
derrière les bonnes pratiques
et l'idée de s'améliorer et de faire les choses bien
je suis trop relou par les puits
moi je vois que c'est pareil
ce qui gênait Christophe
mais en vrai je pense que c'est juste
un blocage parce que tu es très
accroché
à ce mouvement
et à l'image
qui doit véhiculer
et j'ai l'impression que tu vois ça comme
tu vois ce genre d'intitulé de postes
je mets encore des guillemets
autour de ça
comme si
justement c'était des sujets qui ne intéressaient pas
les gens issus
de la méthodologie DevOps
alors que
comme le dit Damien
je pense que
en fait au final
ce qui compte c'est que
les équipes qui sont autour de ces sujets
produisent, font, etc
et le comment
je pense qu'on est tous d'accord
pour dire que la méthode
on est à peu près d'accord
sur à quoi elle doit correspondre
et sur ce qui est produit
effectivement
suivant les équipes
suivant les scopes et tout
ça peut être des choses plus orientées
infras, plus orientées cq
ou whatever pipeline ce qu'on veut
mais en vrai
ça après c'est propre aux entreprises
et puis
je suis d'accord on s'en fiche un petit peu
à partir du moment que
que ça parle aux gens
qui sont dans l'entreprise et tout
c'est ok
et nous
je pense que notre
notre rapport là-dedans
en tant que défenseur
pardon
de ce mouvement
c'est de s'assurer que si
les gens
qui sont derrière ces métiers
estiment qu'ils
appliquent les méthodes des bosses
si on voit que c'est pas le cas
on remet et on essaye
de remettre dans le droit chemin notre niveau
et puis voilà quoi mais tu vois c'est
enfin je sais pas
peut-être encore une fois très naïf
mais c'est un peu comme ça que je le vois
après je suis extrêmement attaché
aux mots et aux portées des mots aussi
c'est mon
c'est mon côté très politisé aussi
c'est que chaque mot a une portée
et chaque mot veut dire quelque chose
et déf secops autant
en tant que métier
déjà je comprends pas mais
aussi en tant que mouvement parce que
ça prône aussi un mouvement déf secops
qui je trouve
bon je l'ai déjà dit
mais je trouve n'est pas nécessaire parce que
tout est déjà inclus dans le DevOps
et moi je vous renvoie
à cet article la stratégie du PIPO
allez le lire vraiment vous allez voir
vous avez tombé des nus dans ce qui est dit dedans
et du coup
quand on communique comme ça
et qu'on présente le déf secops comme ça
forcément
t'as des réactions comme la mienne
t'es évident
je fais juste deux questions
première question c'est d'accord pour toi
et pour moi honnêtement le déf secops ça va pas vous en dire
en chose non plus
mais est-ce que tu serais prêt à accepter
si demain je suis une entreprise
je te dis moi je le déf secops
ça veut vraiment dire quelque chose c'est pas du bullshit
c'est vraiment toi par exemple ce que je te disais
c'est le pilier qui va retransmettre la sécurité en or
on va dire moderne flexible
et surtout qui vont pas bloquer les autres
qui vont pas être grains de sable dans ta route DevOps
genre est-ce que t'es prêt à l'écouter
et deuxième chose c'est je pense que le magazine que tu cites
et ces stratégies heighten
c'est vraiment un truc de direction
c'est un truc de gestion
ça ne reste pas vraiment à des textes
qui s'adressent à des CTO, à des gens comme ça
et qui à un certain niveau sont plus textes
en juste des gens qui doivent donner
des visions à long terme etc
pour aussi l'actionnariat, pour attirer des choses etc
et dessiner des stratégies d'art
et en fait on s'en fout de la direction générale
ce qui compte c'est des actions concrètes qui vont découler
et ça c'est un peu comme les biens
qu'on lance dans les petits jeux
les biens qu'on met ça rebondi etc
quand il lance en fait un mot
une stratégie comme ça
le DSI, le CTO ou whatever non il a
la biens en fait elle va rebondir
chaque étage en fait
les personnes de plus en plus techniques
vont l'affiner, vont l'affiner par l'affaire intérêts
au bon truc qui va donner une action qui est concrète
et vraiment bonne
moi aussi je suis CTO, alors certes je suis CTO
d'une mini boîte mais je suis CTO aussi
et moi ça me choque de lire ce genre de trucs
mais après
si une boîte est prêt à définir le DevOps
je suis prêt à l'écouter
mais je pense qu'à la fin je dirais
mais oui mais ce que vous me dites c'est du DevOps
en fait c'est juste du DevOps
appliqué à... mais pour moi
parce que encore une fois pour moi le DevOps
il transcende les équipes IT
et il va plus loin
et peut-être qu'il faudrait trouver un autre nom
mais cette idée d'amélioration continue etc
ça transcende et ça doit regrouper
toute l'entreprise
mais de toute façon ça fait plusieurs années
que moi je le prône
et que je le prône à mes clients
que si ça marche dans nos équipes IT
ça doit marcher dans toute votre entreprise
c'est mon côté co-opérateur
en le SES qui parle
vas-y René
non non c'est juste que t'as besoin
d'avoir
une dévision très précise
et je pense que... enfin je parlais pour moi
je pense pour Damir aussi
voilà
nous on peut accepter qu'elle soit plus floue
et que ce soit moins strict
entre guillemets
je dirais pas flouille je pense que ça a un bon sens
c'est comme Scrum
je sais pas si vous vous rappelez mais Scrum
il y a beaucoup d'entreprises qui vont essayer de l'adapter vraiment
prendre le truc en mode non mais on veut prendre le Scrum
le plus clean possible
on veut du Scrum 100% pur et tout
tel point qu'on a écrit que j'ai rien
d'île de drogue mais ça c'est une autre histoire
mais au final là où ça marchait mieux Scrum
c'est quand tu l'adaptes à ton entreprise c'est
ça au final ça ne nous va pas en Scrum
ça il faut l'adapter ça ne nous va pas
ça va faire autrement et c'est là que ça marche
et de DevOps au final je considère comme ça Sylv DevOps
c'est un ensemble de règles
brutes avec des définitions ultra sévères
et dès qu'on y déroge un petit peu ça va pas
on perd toute cette flexibilité
tout qui est censé apporter et cette efficacité
donc je trouve ça un peu dommage
après là dessus oui on est clairement pas
sur le même avis mais
voilà c'était juste pour te défendre un peu
ce point désolérone
je voulais juste rajouter que je trouve que
effectivement je ne vais pas penser à ce parallèle
avec Scrum mais je trouve
assez juste parce que effectivement
tu as
tu as eu un moment cette
espèce de mouvance où tout le monde disait
oui je fais du Scrum by the book
etc mais en vrai
moi j'ai jamais vu
la même implémentation
pareil de la méthode
et tout
dans toutes les boîtes
que j'ai fait et pourtant
ils disaient fièrement on fait du Scrum
machin avec les rituels
effectivement il y avait des rituels qui avaient les mêmes noms
mais on faisait pas les mêmes choses
enfin j'exagère mais c'est
c'est un peu ça
et finalement
non mais je trouve que c'est un bon parallèle
parce que je rejoins
d'avenir et renais là dessus
c'est que
tant que ça parle
aux gens dans la boîte etc
et pourquoi pas
parce que finalement on peut aller plus loin
si
si finalement tu mets pas mal la pétance
sur l'amélioration continue
pourquoi tu continues d'appeler ça dévops
par exemple
je fais
la méthode Christophe
Frugit
et c'est la méthode Luration Continue
et d'autres trucs
en vrai tu vas en parler
et puis après on va dire bah en fait c'est
un peu ce que c'est censé apporter les trucs dévops
et tu vois c'est
alors si je peux me permettre
Scrum c'est vraiment très défini
c'est écrit et tout
le dévops c'est un ensemble de préceptes
dont on n'est même pas tous d'accord
dans le mouvement
puisque comme on a pu le remarquer
il n'y a pas de manifeste dévops
contrairement au manifeste agile
ou au manifeste Software Crafts Pachips
il y a plusieurs manifeste dévops
j'en parle dans ma formation
mais il n'y a pas
une philosophie pure et dure
et c'est assez
peu défini
finalement le dévops il y a des bonnes pratiques
il y a des outils
et moi j'ai tendance à dire souvent
chaque entreprise elle doit trouver
son dévops elle doit trouver sa voix
et c'est aussi
pour ça que la comparaison
avec le Scrum je trouve qu'elle est un peu bancale
parce que le Scrum c'est hyper rigide et défini
mais dans ce cas pourquoi tu veux
absolument le définir de manière stricte
je ne parlais pas tant de la définition
de devops maintenant
parce qu'il y en a plein
mais justement ce que je veux dire par là
c'est pourquoi on veut absolument
déclarer une définition comme étant pure
standardisez le truc à un point
où on ne veut pas déroger à quelque chose
plutôt que se dire le Scrum
le devops c'est un ensemble de bonnes pratiques
on ne veut justement pas que ça devienne comme
le Scrum ou autre et que ça soit un truc
ultra défini où les gens en fait
se sentent obligés de rentrer dans une case
aux forceps et au final déchoué
pourquoi on voudrait arriver vers là ?
c'était plutôt ça dans le sens que je voulais prendre le comparatif
et pas dans le sens c'est la même chose
c'était plus dans
cette objection
de vision du truc
je ne peux pas te répondre
parce que ce n'est absolument pas ce que j'ai dit
je dis que
le devcops
n'a pas besoin de définir
parce qu'il sous-entend des choses
qui sont déjà inclus dans le devops
je ne dis pas que le devops
il doit forcément être définie clairement
je dis juste qu'en fait
ce que j'ai lu qui définit le devcops
comme le fait que
dans le devops il n'y a pas la sécurité qu'on doit faire entrer
la sécurité de la vente pour moi
si tu l'as lu quelque part et que tu prends pour compte
c'est que
ce que tu as lu c'est le manifeste de devcops
qui contient un truc et pour moi
c'est chacun sa vision
non
non non non
non je lutte contre
des idées
en tant que vulgarisateur de contenu
de devops je lutte contre cette idée
qui est de dire
que dans le devops il n'y a pas de sécurité
que les équipes de sécurité ne sont pas
des équipes de devops comme les autres
je comprend
mais je ne vois pas en quoi
c'est une position
en quoi ça a invoilli le devcops comme étant potentiellement
une autre accentuation
ou une autre manière technique
de voir les choses ou un autre scope
pour moi ça n'a pas de truc au contraire
c'est ça que je ne comprends pas
moi aussi je te dis
donc c'est pour ça que je ne vais pas me raconter le...
ça sert à rien
oui je pense qu'on ne tombera pas d'accord
dessus
non pas ce soir
est-ce que
on parle d'autre chose
ou est-ce qu'on va vers la clôture de l'émission
allons vers la clôture
sinon on va faire un truc
petit peu de problème
oui en plus je vois que ça fait déjà 1h10 qu'on tourne
du coup tu l'as compris
c'est un sujet chaud
chez l'auditeur et si tu veux continuer à discuter
de tout ça
si tu es plutôt devcops
plutôt devops
et bien viens en discuter
sur le forum des compagnons parce que je suis sûr
que le sujet associé à ce podcast
là fera
ce sera très long parce que à mon avis
dans la communauté on va pas mal en discuter
donc tu peux t'inscrire, le lien est en description
et je vais laisser
à vous le mot de la fin
et cette fois je vais commencer par
R1
quel est ton mot de la fin
j'ai rien sous les
les mains par contre
je vais juste dire que comme convenu
on a beaucoup parlé sur le sujet
et on...
suivez nous sur twitter
parce que le débat avait commencé déjà sur twitter
il y a quelques threads là dessus
non mais encore une fois
ces...
ces sujets sont pas toujours évidents
à appréhender
j'ai l'impression qu'on a discuté plutôt bien dessus
et qu'on a apporté quelques éléments
en tout cas de réflexion
pas de réponse mais de réflexion
et j'espère que ça aura convenu
à tout le monde et voilà
tout à fait je mets le lien
du thread twitter que j'ai initié
justement dans les notes de l'émission
on a réussi à pas
mettre de 100 partout c'est quand même génial
et bien renez
à toi le mot de la fin
je vais m'empresser d'aller
déposer le quantum up comme j'ai dit
avec le NFT
comme ça je comprendrai aussi ce que c'est
les NFT
et voilà après on a
pas obligé d'être toujours d'accord sur tous les sujets
et c'est pas pour autant qu'on
on doit pas s'entendre
et bien ce sera mon mot de la fin
exact
ah magnifique
et d'amir c'est toi qui lui dis
du coup on a un mot de la fin
pour troll mais dans la vraie vie
j'ai envie de dire
on n'est pas tous d'accord sur les termes
je pense qu'on est d'accord sur le fond et les pratiques
donc ça c'est déjà une je pense le plus important
et au final qu'on ne soit pas d'accord
si on doit appeler ça un unicorn, un tricetratops
ou un devops
au final j'ai envie de dire on s'en fout
ce qui compte c'est de faire les choses et de les faire bien
et c'est aussi là pour ça aussi qu'on fait
cette émission pour vous aider à faire les choses bien
et au final la forme
c'est une autre histoire