Alors, le DevOps, c'est un échec, puisqu'on vient de le dire, c'est la fête du slip, c'est le bullshit marketing.
Donc du coup, le DevOps, c'est un échec.
Et donc pourquoi est-ce que le DevOps, c'est un échec ?
C'est justement la promesse d'un post-linked in, d'Isham, Haït, Baslam.
J'espère que je prononce bien ton nom, Isham, si c'est pas le cas tu peux me taper sur les doigts.
Alors, Isham, il est directeur de la transformation et de la stratégie IT à Capgemini.
J'étais assez surpris d'ailleurs par son post vu d'où il vient.
Mais justement, comme quoi, il y a plein de choses.
Alors, ce post-là, ça va être l'occasion pour moi justement de revenir en plus de l'article précédent sur ce qui est essentiel dans le DevOps
et de lancer la discussion entre nous.
Donc, ce que je vais faire, c'est qu'en intro, je vais me permettre de lire le post-Isham qui est assez court.
Et moi, je t'encourage, si tu nous écoutes, à aller y répondre, à aller donner ton avis sur ce post-là.
Parce qu'il est vraiment bien.
Alors, l'adoption du modèle DevOps représente une promesse de transformation profonde pour les directions des systèmes d'information,
les fameuses DSI, avec l'objectif d'accélérer le déploiement de solutions, d'améliorer la collaboration entre les équipes de développement et d'opération
et, ultimement, de créer de la valeur plus rapidement pour l'entreprise.
Pourtant, malgré des investissements conséquents et des ambitions élevées,
de nombreuses organisations se retrouvent face à un constat d'échec dans l'implémentation effective d'un modèle DevOps opérationnel.
Cette chronique explore les raisons derrière ces échecs et met en lumière les défis sous-chassants aux transformations manquées.
Premier motif d'échec, la lourdeur organisationnelle.
C'est un frein majeur.
Une des principales difficultés rencontrées par les DSI dans la mise en oeuvre du DevOps,
c'est la lourdeur inhérente à certaines organisations.
On parle là de très grosses entreprises.
Ces structures hiérarchiques rigides, les processus décisionnels longs et complexes,
des silos fonctionnels qui constituent des obstacles significatifs à l'agilité,
à la collaboration que requiert l'approche DevOps.
Cette rigidité organisationnelle, elle freine l'innovation, la rapidité et d'adoption,
qui est essentielle à la réussite de la transformation.
Donc si tu as déjà une lourdeur organisationnelle, là ce n'est pas qu'il le rajoute,
il y a déjà un truc à travailler avant même de passer au DevOps.
Ou alors c'est peut-être le moment de faire quelque chose.
Des partenaires qui jouent pas le jeu.
L'écosystème d'une entreprise, c'est composé de fournisseurs, de partenaires et de prestataires
qui jouent un rôle crucial dans la mise en oeuvre du DevOps.
Parfois tu as des partenaires extérieurs qui ne s'alignent pas sur les principes et pratiques
du DevOps ou qui résistent au changement.
Ils peuvent ralentir voire compromettre la transformation.
Le manque de coopération et d'engagement de la part des partenaires
peut créer des discontinuités dans les workflows augmentant la friction
et réduisant l'efficacité des initiatives du DevOps.
Des investissements mal orientés.
Investir dans la transformation des DevOps est essentiel,
mais parfois l'allocation des moyens est inefficace.
Ces investissements peuvent mener à l'échec.
Parfois les DSI se concentrent exclusivement sur les outils et technologies
au détriment des aspects humains, culturels, qui sont pourtant au coeur du DevOps.
Sans un investissement adéquat à la formation,
le développement des compétences et la gestion du changement,
les outils seuls ne peuvent pas instaurer de changements profonds
nécessaires à une culture DevOps authentique.
C'est ce que je constate régulièrement.
Si c'est trop orienté vers les outils, la culture ne va pas évoluer.
On a des petites améliorations, mais qui ne sont pas à la hauteur des promesses.
Et évidemment la sous-estimation de la culture et du changement comportementale.
Le passage au DevOps est en tout une transformation culturelle
qui demande des changements de comportement significatifs
de la part de tous les acteurs et de toutes les personnes qui sont impliquées.
Cette dimension est souvent sous-estimée par les DSI
qui peuvent privilégier encore une fois les aspects techniques au changement culturel.
L'adoption de nouvelles manières travaillées,
la communication ouverte, la collaboration transversale,
les prises de responsabilité collective ou le partage des responsabilités
sont des aspects culturels qui sont essentiels
et qui nécessitent du temps et de la persévérance pour s'implanter.
Alors justement, on en parlait déjà dans Actu DevOps en février 2022.
Sur un autre article qui disait que la Suisse était déçue par le DevOps
et on tirait grosso modo les mêmes conclusions extrêmement proches de ce poste.
Donc je te mets le lien de la vidéo de l'époque en commentaire
où il y a un petit i qui va s'afficher sur Youtube.
Moi ce poste-là, il fait écho à plein de choses que je vois et que j'entends.
Et donc du coup je vais me tourner vers vous
puisque c'est la continuité parfaite de l'article que nous a partagé René.
C'est quoi votre avis sur ces constats d'échecs en entreprise ?
Est-ce que vous avez vous même vu des constats d'échecs de ce type-là
ou est-ce que vous en avez entendu parler de votre entourage ?
Est-ce que Nida, tu veux bien commencer ?
Je vais continuer sur le côté fait du slip.
Le côté l'order organisé nationnel, c'est le titre et l'exemple parfait
du château de cartes qu'est mis en place dans les entreprises quand on parle de DevOps.
C'est une organisation plus personne qui fait quoi.
C'est du silottage dans le fonctionnement
et on arrive à des situations où on fait plus de mal que de bien.
C'est contre-productif.
On doit travailler en bonne intelligence.
Je pense que DevOps c'est limite.
J'ai envie de bannir le mot et de dire travailler en bonne intelligence.
Je pense que c'est un mot qui est de l'informatique à l'heure actuelle.
On a un tel niveau d'abstraction technique
qu'on arrive à un niveau d'abstraction organisationnel.
On a perdu le sens commun sur le côté pyramidal et silottage.
Je pense que vous allez agir.
Je pense que je suis assez d'accord avec l'article.
Je pense que c'est très vrai dans les grandes entreprises.
Tous les problèmes organisationnels, disons-le plus radicalement,
c'est aussi des problèmes politiques.
C'est-à-dire que bouger les organisations,
ça fait des changements de chef qui sont là, qui n'ont pas envie.
C'est ça qui est difficile à faire évoluer.
C'est des choses que j'ai vues.
Heureusement, je pense qu'il y a des entreprises qui arrivent à s'en sortir
ou qui arrivent à fonctionner en mode DevOps.
Pour les très gros, je pense que c'est assez difficile de ce côté-là.
Après, les partenaires qui ne jouent pas le jeu,
j'en ai eu une bonne illustration avec un client
qui travaillait avec des fournisseurs qui n'étaient pas dans le DevOps.
Il était, malgré toute la bonne volonté de vouloir faire une transition
peut-être à l'héber du DevOps.
Son fournisseur ne voulait absolument pas travailler comme ça.
Il était engagé pendant encore plusieurs années avec lui.
Il n'était pas dans le contrat.
Il avait un échec plus ou moins de facto
parce qu'il liait entre guillemets pour un contrat.
C'est des choses que j'ai vues.
Effectivement, je suis assez d'accord avec ça.
Les investissements ou la partie un petit peu allée sur les outils,
ça rejoint un petit peu.
C'est quand même la partie facile de mettre en place des outils.
Ça aussi, c'est du vécu.
On pense que faire du DevOps, c'est mettre en place des outils.
Au final, ça ne m'éduire pas forcément.
Effectivement, ça peut rendre les choses parfois plus complexes
si les gens ne sont pas habitués à ces outils-là,
si ils n'ont pas été formés.
Je pense que le point clé, c'est le dernier.
Il faut...
Qu'est-ce qu'on cherche à faire avec le DevOps ?
Qu'est-ce qu'on cherche à améliorer ?
Parce que pour emmener les gens, pour avancer dans ce verse-mod là,
il faut donner l'objectif
et il faut déjà l'avoir compris soi-même,
parce qu'il n'est des fois pas toujours le cas.
Et moi, pour moi, c'est ça le point clé.
Il faut arriver à...
Forcément, les gens, si tu leur dis,
on va te changer ton boulot, on nous n'est encore plus,
mais ils ne savent pas trop pourquoi.
À la base, il y a ces peu de gens qui vont dire,
ouais, super, ça ne passe pas bien.
Et du coup, créer un peu cet envie d'y aller,
je pense que c'est difficile,
à partir surtout sur des boîtes qui sont vraiment plus ou moins grosses.
Enfin, du moins grosses, on va dire ça comme ça.
Je vais donner un petit peu mon avis de...
Donc oui, je suis assez en phase avec ce qui est dit.
Après, il y a quand même des gens qui arrivent et qui ont des succès, heureusement.
Sinon, ça serait dommage.
Nico, si tu veux prendre la suite.
Oui, il va falloir que je garde les idées claires
et que je réussisse à garder mon calme,
parce que c'est bien le sujet qui m'énerve bien.
Déjà, on va reparler du...
C'est quoi, DevOps ? C'était bien une philosophie.
Et dans la philosophie, il y a quoi ?
Il y a donc l'acronyme CAMS,
culture, automatisation, mesure et partage.
Pourquoi ?
C'est pour avoir une culture de l'entreprise,
une culture du produit, une culture de la prod et ainsi de suite.
Bon, l'automatisation, on ne va pas revenir là.
C'est pour aller plus vite et que tout marche bien.
La mesure, c'est quoi ?
C'est qu'on va mettre des maitris sur qu'est-ce qui est important pour l'entreprise.
Donc, ça va rentrer dans les KPI des équipes.
Et c'est quelque chose qui est partagé.
La responsabilité de ces KPI sont partagées au niveau de l'entreprise.
Donc, que ce soit les développeurs, les évopérations,
mais on pourrait aussi mettre ça dans les mains du PO,
qui va être responsable de faire en sorte qu'il y ait la priorité
sur un maintien de bonne performance et pas de toujours pousser des nouvelles fonctionnalités,
de bien corriger les bugs pour que les utilisateurs soient contents et ainsi de suite.
Et avec un truc qui pour moi est aussi important que tout le reste,
c'est le partage et le partage de tout ce qu'on a vu au-dessus,
le partage de la responsabilité, le partage de la culture,
le partage des maitris qui a ainsi de suite.
Et le partage dans l'entreprise, c'est on partage aussi ce qu'on apprend
sur les incidents, sur des bugs, sur des machins,
et on partage tout au niveau de l'entreprise.
Bon, bref, et finalement pourquoi ça marche pas dans certaines voies ?
Je vais juste préciser, c'est à oublier le L, qui est l'achronyme de Linn,
qui est les petits pas, ça veut dire qu'on avance petit à petit aussi,
c'est un des piliers importants que je voulais rappeler.
Après il y a plein d'autres piliers, mais je prenais le cams de base.
Je parlais pas du cams ça.
Non, je parlais du cams, qui est l'achronyme qu'on a entendu au tout début de DevOps,
mais effectivement le Linn c'est super important,
parce que c'est ce qui va vous permettre à la fois d'être feignant
et à la fois de réduire vos coûts, puisque vous allez faire que ce qui est strictement nécessaire.
Alors ça c'est pareil, si vous connaissez pas le Linn Management,
intéresser vous à ce sujet là, c'est un truc super intéressant.
Alors ça permet de dégresser certaines boîtes qui sont mal financièrement,
mais si vous adaptez ça à votre vie de tous les jours,
vous allez énormément progresser sur plein de sujets
et vous allez arrêter de vous éparpiller sur des sujets qu'il ne nécessite pas.
Mais bon, justement c'est parpiller sur des sujets qu'il ne nécessite pas.
Moi ce que je constate aussi dans beaucoup de grosses boîtes
et je ne veux pas donner de nom pour fâcher personne,
et je pense que c'est comme ça, dans plein de grosses boîtes,
a priori sur tout français, parce que c'est un peu culturel chez nous.
On a plein de chefs de projet.
Pour aller déployer 4 serveurs, on va avoir un Ops, un Dev et 5 chefs de projet.
Et on va avoir des réunions en permanence.
Et finalement, les deux quirames, ils sont tout le temps en réunion.
On leur demande pourquoi ils n'avancent pas, parce qu'ils sont en réunion.
Et finalement après on s'étonne que DevOps, ça marche pas.
Ouais, alors déjà arrêter de recruter des DevOps,
recruter des gens qui sont dans le métier.
Après vous les appelez DevOps, si vous voulez, c'est plus facile à recruter.
Ok, pas de problème.
Par contre, mettez en place vraiment une organisation DevOps.
Arrêtez de tout siloter dans la boîte,
arrêtez de mettre des barrières avec des outils de ticketing à la conne
qui font chier tout le monde et perdent du temps.
Je vous avais dit que j'étais énervé.
Bref, regardez vraiment, revenez au fondamentaux de DevOps.
Et les deux articles qu'on a eu sont vraiment intéressants et importants
pour prendre conscience de ce problème-là.
Et essayez de regarder si vous pouvez pas appliquer ça chez vous.
Moi, les dernières boîtes où j'ai bossé,
c'est des choses qu'on a mis en place.
Et finalement, c'est assez naturel quand on travaille comme ça au quotidien.
Parce que finalement, quand l'application est par terre,
c'est celui qui est le plus pénalisé, c'est le client.
Et la boîte est là pour fournir un service au client.
Et ce qu'on veut, c'est rétablir le service le plus rapidement possible
et de faire en sorte que ça ne se reproduise pas.
Et ça, c'est du travail d'équipe.
On a bien compris que tu en avais gros sur la patate.
Du coup, je vais prendre la suite.
Et d'ailleurs, pour finir là-dessus, ça me fait penser,
quand on parlait tout à l'heure, le dernier article,
ça m'a fait penser un petit peu au télétravail,
où tout le monde a dit pendant des années,
non mais le télétravail, c'est pas possible chez nous, machin, etc.
Et puis, quand on a été obligé de télétravailler,
parce qu'on a été confiné, on s'est rendu compte que ça ne marchait pas si mal que ça.
Et toutes les boîtes où ça n'a pas marché,
et tous ceux qui ont dit que non mais le télétravail, ça ne marche pas chez nous,
c'est parce qu'en fait, ils étaient mal organisés déjà à la base.
Et le fait d'être en télétravail,
ça a mis le doigt sur tous les points qui n'allaient pas dans la boîte.
Et puis voilà.
En fait, là, c'est pareil.
On fait du DevOps, parce qu'on a vu dans 01net Mag, machin, que c'était à la mode.
Gartner a dit qu'il fallait faire du DevOps, donc on va faire du DevOps.
Mais on ne cherche pas ce que c'est réellement que le DevOps
dans la substantifique moelle et comment l'implémenter.
Et du coup, on se met à faire n'importe quoi, n'importe comment.
Puis après, on dit que c'est pourri et que ça ne résout pas les problèmes.
Pourtant, j'ai mis un Jenkins, donc on est DevOps, mais ça ne marche pas.
Voilà. Je te laisse la parole.
C'est peut-être Jenkins le problème dans ce cas-là.
Mais je ne vais pas te rouler.
Par contre, ce que je vais pouvoir dire, c'est que je vais rebrew dire sur plein de choses.
Je ne vais pas réagir sur le DevOps et la fête du Slip,
même si je ne pense pas moins, c'est devenu tellement un mot marketing
qu'on a oublié ce que ça voulait dire.
Et moi, je n'ai jamais oublié.
Alors, c'est pour ça que je me sens un peu en décalage par rapport à plein de gens.
Mais pour moi, s'il DevOps est un échec, je reste persuadé
que c'est l'implémentation, le problème et pas le DevOps.
C'est l'implémentation qui en effet, dans certaines boîtes,
le problème et pas le DevOps en lui-même.
Puisque en plus, le DevOps, il y a plein de manières de le faire.
Mais il y a quand même des concepts à prendre en compte.
L'idée, elle disait, je ne sais plus quel terme a été utilisé, mais le bon sens,
c'est la coopération, c'est la mémérasation continue,
c'est plein de trucs qui font que c'est là pour marcher.
Et il y a plein de personnes aussi qui dévoilent DevOps en disant,
ok, mais le DevOps, je l'ai fait court, mais c'est la banquette intellectuelle culturelle.
Pas tant que ça, en fait.
Ce n'est pas technique versus culture, c'est culture et technologie.
Puisque la culture est là pour fluidifier la coopération entre les équipes
et puis te mettre dans un état d'esprit qui fait que ça va bien marcher avec tes collègues.
Et la technologie est là parce qu'en changeant certaines technologies vieillissantes
par des technologies un peu plus nouvelles,
qui sont celles qu'on utilise dans le DevOps de manière importante,
les deux ensemble font que ça va marcher.
Bien sûr, si tu fais que l'un et pas l'autre,
tu auras des résultats moindres.
C'est pour ça que les entreprises qui ne font que la partie tech,
elles ont des résultats, mais pas à hauteur de ce qu'ils voient.
Parce que c'est pas parce que tu mets l'intégration continue,
tu mets des pipeline GitLab CI ou GitObaction, je ne sais quoi.
Mais si tu continues à avoir des gestions de TK et TSM,
peut-être que ça n'a pas bien marché.
Bref.
J'aimais bien aussi, je ne sais pas si c'est renait, c'est toi qui a dit ça,
mais avoir une vision.
Moi, ce que je fais quand j'initie mes mentorats,
parce que je fais du mentorat DevOps d'équipe et de personne,
ce que je fais avec les personnes ou les équipes,
c'est définir un objectif.
Il a un peu flou, moi j'ai tendance à dire,
c'est le phare dans la nuit, c'est là vers quoi on va aller,
puisque nous on est une embarcation qui va naviguer
et on va vers le phare,
même si on ne sait pas si on va arriver exactement au phare
ou à la plage, à la cric d'à côté.
Donc, si vous lancez dans une transformation de DevOps,
si vous êtes une grande entreprise,
il faut avoir une vision et surtout,
il faut que la vision soit partagée.
Et donc, faites-vous accompagner.
Ça, c'est un autre des enseignements aussi,
mais on en a parlé là,
il y a de fortes chances,
si vous êtes une grosse boîte qui n'avait jamais fait de DevOps,
que vous n'y arrivez pas seul.
Vous aurez beau lire tous les articles,
vous aurez beau faire tout ce que vous voulez,
vous y arriveriez pas seul.
Donc, faites-vous accompagner par des consultants,
des consultantes, des menteurs, je ne sais quoi.
Non, on peut vous aider,
mais il y a plein de gens qui peuvent vous aider
à former vos équipes,
à les accompagner dans ce chemin,
parce que c'est un chemin qui est souvent long.
Et en effet, les petites boîtes,
elles passent plus facilement des DevOps,
parce que c'est plus facile, elles sont plus agiles déjà de base.
Et elles ont tendance à avoir la coopération
et la collaboration dans leur ADN,
parce que quand on est une boîte de 5
ou une boîte de 10,
c'est plus facile de coopérer,
parce qu'on n'a pas le choix, en fait.
Quand on est une boîte de 500, c'est déjà plus complexe.
Donc, ça s'apprend.
La culture de la coopération, ça s'apprend.
Je suis assez bien placé pour le savoir,
je suis dans une coopérative,
et ce n'est pas iné.
On apprend, et nous, notre coopérative,
on apprend à coopérer ensemble,
même si on n'a pas tous les mêmes métiers,
on a quand même des choses qu'on fait ensemble.
Donc, ça se travaille.
Ce n'est pas juste valir 3 articles,
va écouter 3 podcasts de Christophe,
et puis ça y est, tu seras DevOps.
Non, ça ne marche pas.
Donc, faites-vous accompagner,
c'est mon mot de la fin,
trouver des gens en qui vous avez confiance
pour vous aider dans ce chemin,
parce que c'est vraiment un chemin long,
une transformation DevOps,
d'autant plus si vous êtes une grosse entreprise,
ça peut prendre plusieurs années.
Je ne sais pas si vous voulez réagir à ça,
mais oui, vas-y, Nicolas.
Je croyais que pour devenir DevOps,
il suffisait de changer l'intitulé de son CV.
C'était un troll, bien sûr.
Sinon, je pense que le titre de l'article
était inspiré de la présentation
de Nicolas Ruff,
pourquoi la sécurité est un échec.
Donc, ça a pas mal tourné,
et je pense que ça vient de là.
Nicolas Ruff, c'est un des podcasteurs
de nos confrères, de nos limites sécus
que je vous incite à aller écouter,
parce que c'est aussi très intéressant.
Cool. Alors, ce n'était pas un article,
c'est un post-unicudine.
Mais allez-y.
En effet, c'est toujours bon
d'aller écouter ça. Si tu as le lien
que tu peux nous le fournir, on pourra le mettre
en plus dans les notes de l'épisode.
Est-ce qu'on ne passerait pas à la suite ?
Parce que vous avez encore des choses à dire
sur les échecs du DevOps.
Je pense qu'on a assez parlé des échecs du DevOps, non ?
Allez.
Bon, avant de passer
à la section des outils, mon petit appel à l'action,
si tu veux, justement,
te forger un état d'esprit DevOps, parce que
ce n'est pas inné. Tu peux
acheter ma formation, j'en ai fait une,
spécifique là-dessus.
DevOps Mindset, donc cette formation
te permettra justement de rentrer
dans le mouvement et d'acquérir les bases
de cette culture. Tu verras, on parcourra
ensemble tout ce qui fait
de pourquoi on a eu besoin du DevOps
et tout ce que fond le DevOps,
selon moi évidemment, aujourd'hui.
Même si tu n'y connais rien, tu peux prendre
la formation, tu apprendras ça.
Tu verras, il y a le
lien en description.
Et si tu veux aller plus loin, j'en parlais
tout à l'heure, si tu es une entreprise et que tu veux te faire
accompagner, soit tu veux accompagner
des personnes ou si tu vas accompagner des équipes,
j'ai un mentorat DevOps, justement,
où j'accompagne les équipes
à mettre en place le DevOps dans leur
projet.
Et c'est grâce à ça qu'ils y
arrivent parfois.
Tu vas voir sur le site
des compagnons du DevOps, tu as tout.
Ces compagnons, tu verras DevOps.fr
Je le rappelle, t'as accès à
tous les formations du mentorat, etc.
Et puis évidemment le super forum.
Merci d'avoir regardé
la vidéo de la suite.
Je vous invite à vous abonner
pour ne pas vous abonner