Arrivé à la fin des années 2000, le DevOps est l’un de ces termes qui ont explosé dans le marché de l’IT Web. Depuis, il semble avoir convaincu les entreprises, au point où une majorité en font ou pensent à en faire¹. Dès lors, vu la foule d’offres d’emplois DevOps et l’explosion des salaires², nous autres techniciens y pensons forcément : Comment prendre le train du changement ? Autrement dit, comment devenir DevOps ? Nous allons voir ça.

Étape 1 : vous ne pouvez pas.

Certes, c’est du troll, mais laissez-moi vous expliquer pourquoi. Et pour cela, commençons par le commencement : les modèles d’organisation du travail.

L’organisation d’une entreprise

Plus, c’est mieux

L’informatique est une science jeune. Bien que l’écriture de logiciels remonte à bien plus longtemps que ça, on a du mal à s’imaginer qu’en 2004 seule 30% de la population française avait un accès à Internet³.

Software is eating the world.
~ Marc Andreessen

Avec l’informatisation grandissante, les applications sont devenues plus complexes et interconnectées, les équipes plus grosses et les enjeux plus forts. Il est alors apparu logique de découper les équipes techniques : d’un côté ceux qui s’occupaient de l’application, de l’autre ceux faisant l’administration du système socle. Ce découpage est attendu, c’est un réflexe hérité de l’industrie : on spécialise pour augmenter la productivité locale. C’est une logique de quantité.

Par chance ça tombait bien, ces deux populations avaient déjà deux états d’esprits bien distincts. Ces deux populations créées, l’entreprise leur a fourni des objectifs différents :

• les Dev devront faire évoluer le logiciel,
• les Ops devront stabiliser le socle.

Mais dans le même temps, après des décennies d’expérience terrain, les techniciens ont commencé à porter un regard critique sur les fonctionnements historiques. Dès les années 1990, des expériences sur l’organisation furent menées et se sont révélées efficaces au regard des spécificités du domaine de l’informatique. C’est suite à ces constats que le manifeste Agile naît en 2001.

Le Dev… quoi ?

L’Agile ne traite que du logiciel, laissant sur le côté l’administration système et les Ops. Le problème, c’est que les objectifs que l’on a vu à l’instant ne sont pas seulement différents, ils sont contraires. Ainsi, même si l’entreprise avance plus efficacement grâce à une méthode Agile, elle n’exploite pas son plein potentiel puisqu’une partie de l’entreprise a pour objectif de faire exactement l’inverse !

Pour défaire cette situation, Debois et Shafer définissent la terminologie « Infrastructure Agile » en 2008 afin d’appliquer les méthodes Agiles de bout en bout – de l’applicatif à l’infrastructure –, et ainsi remutualiser les objectifs opérationnels. Une formalisation plus tard, le terme DevOps représente toujours cette volonté.

Depuis, on associe 4 principes fondateurs au DevOps regroupés sous l’acronyme CAMS (CAMP en français) :

• Culture : le changement de paradigme et les principes servent l’organisation, les interactions et le business. C’est les personnes qui doivent s’approprier ce changement ; les outils ne font que soutenir l’objectif ;
• Automatisation : renforcer les pratiques consiste à les formaliser et les automatiser pour les répéter aussi fréquemment que requis par le business (ex : les tests, la configuration ou le déploiement) ;
• Mesure : les métriques, alertes et supervisions sont configurables par l’équipe qui les utilise (quelle qu’elle soit). Cela implique une qualité pour le système : son observabilité ;
• Partage / Sharing : casser le silo technico-business en offrant aux équipes tierces le résultat des pratiques techniques pour leur usage autonome.

Ces principes sont mis en pratique par les méthodes suivantes :

• Itérations courtes impliquant toutes les parties prenantes,
• Livraison continue de la production de valeur,
• Décalage « à gauche » des procédures de vérifications dans la CI/CD/CD,
• Maximisation de la ressemblance des environnements (ou parité),
• Monitoring en continu des environnements d’exploitation,
• Application des pratiques Agile du dev jusqu’à l’infra.

Appartenir au DevOps, c’est tout ça. C’est revendiquer que le modèle productiviste n’est pas adapté, qu’on le sait depuis les années 2000, et qu’on participe au mouvement permettant de créer de la bonne valeur aux bons endroits.

Alors quel est le problème ?

Il y a dans le domaine de l’informatique une effervescence qu’on ne retrouve nulle part ailleurs. « Le logiciel dévore le monde », mais pas que. L’informatique dans sa totalité dévore le monde ; ce n’est pas pour rien qu’il résiste au chômage.

Dans cet écosystème fourmillant, être le premier revêt un intérêt stratégique⁴ pour rester dans la course. Il faut montrer qu’on est à la page. Comme le dit S. Godin « L’expression “Maison créée en 1906” avait son importance. Maintenant c’est apparemment un handicap. ». Le problème survient quand cette démarche se fait pour de mauvaises raisons ou sans comprendre correctement le sujet.

Dans le cas du DevOps, le terme est aujourd’hui utilisé à tort et à travers⁵ par :

• des entreprises qui n’ont aucune intention de remettre en question le modèle historique mais qui veulent se refaire une crédibilité à moindres frais ;
• des entreprises qui ont entendu parler du DevOps et veulent l’appliquer sans trop savoir si c’est bien pour elles ;
• des recruteurs qui veulent garantir leur part de marché et acceptent les demandes des entreprises soit par incompréhension, soit par cynisme.

Que cherchent ces entreprises ? Celui qui va pouvoir leur faire atteindre cette nouvelle terra incognita, persuadées qu’elle est technique : UN DevOps. Et malheureusement, cette demande trouve un écho auprès d’une autre population qui utilise ce terme, et cette dernière est plus insidieuse : les techniciens mercenaires, guidés par ce qui rend le mieux sur le CV. Au final, le message initial est brouillé et ce marché complet et stable est piégé dans sa mécompréhension.

Mais le pire n’est pas là. Chercher UN DevOps (ou construire une équipe DevOps en dehors des précédentes), c’est dire « eux sont dédiés au DevOps pour qu’on ait pas à s’en occuper ». Il n’y a alors plus 2 équipes avec des objectifs différents, mais 3. Cool les choses ont empiré !

D’une façon ou d’une autre, l’entreprise n’aura aucun bénéfice de ce nouveau fonctionnement et tout le monde sera perdant.

Changer la donne

Actuellement, le DevOps a perdu de son sens, noyauté par tous ces mésusages. Pour autant, le secteur n’en est encore qu’à ses débuts et le mot est le reflet d’une meilleure compréhension de ses particularités ; l’abandonner reviendrait à retourner au modèle industriel historique et oublier ce qu’on a appris ces 50 dernières années. Une correction de trajectoire est nécessaire et peut se faire sur plusieurs axes.

Entreprise : une trousse à outils, mais pour quoi faire ?

On ne peut que constater à quel point le DevOps n’est abordé qu’à travers ses outils, tant dans les roadmaps⁶ que dans les annonces de jobs ici et là. C’est un tort, car les curieux en viennent à penser qu’il ne s’agit que d’outillage, et tout le monde finit persuadé que Tartempion est « DevOps » parce qu’il utilise ces outils.

Non, connaître Docker, Kubernetes, Ansible, Terraform et Jenkins ne fera de personne un DevOps, uniquement un technicien spécialisé. Parce qu’en réalité, tout ça est très secondaire. Appliquer l’outillage DevOps dans toutes situations revient à choisir une solution avant de connaître la nature du problème.

De part mon statut, j’ai l’habitude des interlocuteurs qui tâtonnent sur leur situation et n’utilisent pas les bons mots. C’est même une part importante des échanges. C’est très bien comme ça, après tout : « l’industrialisation est une étape compliquée ». Au cours des échanges, j’aide à extraire ces quelques questions :

• Quel est le besoin de l’entreprise à ce jour ?
• Quels sont les objectifs stratégiques à mettre pour évaluer la satisfaction de ce besoin ?
• Quels sont les objectifs opérationnels à décrire pour satisfaire la stratégie ?

Ces questions ont une réelle vertu : elles aident à percevoir où le besoin d’action réside. On croit trop souvent (à tort!) qu’on pourra tout résoudre par la technique, mais c’est faux ; l’organisation et la communication ont aussi leur part⁷.

Armé de ces questions, on évite les effets de modes autour des mots. Parce qu’après tout, on se fiche du mot, ce qui compte c’est le besoin de l’entreprise.

Ce que nous appelons rose, sous un autre nom, sentirait aussi bon.
~ W. Shakespeare

Trouvez vos objectifs et vous trouverez les outils, les organisations et les personnes qui vont avec.

Technicien : je ne suis pas DevOps

Soyons transparents, la part de mes confrères techniciens qui s’étiquette DevOps a une part de responsabilité dans le dévoiement du mot. Assurément, ça place le profil en haut de la liste des candidats, mais à quel prix ? Se prétendre DevOps, c’est laisser à penser que l’on va porter sur nos épaules tout l’effort de changement de culture dans le business, l’infra ou encore le développement, et ceci sans que l’entreprise n’ait à faire quoi que ce soit. Voire ne le souhaite même pas⁸. Comme tout échange où l’on ne parle pas la même langue, ça peut être frustrant, dérangeant voire carrément dangereux.

Se dire DevOps revient aussi à perpétuer le mythe du technicien omnipotent et omniscient. Ce mythe-là est tenace car l’entreprise a un intérêt direct à ce qu’il existe et côté technicien il fait un bien fou à l’ego. Imaginer qu’on puisse avoir un dev expert en front, back, infra et désormais automatisation est vraiment pratique pour l’entreprise ! Dans la réalité, bien peu d’entre nous en sont vraiment capables, et l’entreprise réduit même sa capacité à paralléliser ses tâches.

Dans les deux cas, l’entreprise s’attend à un résultat que vous ne pourrez lui donner.

Alors, comment se nommer pour que le message passe ? Parce que le sujet adressé par le DevOps n’est pas que technique, Ingénieur DevOps n’est pas un bon intitulé. À mon sens il y a trois options :

• soit vous êtes promoteur de la méthode DevOps et vous pourriez vous présenter comme Pilote DevOps, Chef de projet DevOps ou Coach DevOps ;
• soit vous êtes en charge de l’outillage et ce serait Ingénieur automatisation ou Ingénieur plateforme ;
• soit vous appliquez le DevOps dans votre métier et votre titre ne devrait pas changer.

Pourquoi cette dernière option ? Parce qu’après tout, DevOps est une sous-branche de l’Agile et aucun nom de poste ne change quand l’équipe applique Agile plutôt que le cycle en V, uniquement des nouveaux métiers qui se greffent.

L’organisation productiviste pousse l’entreprise à diviser le travail en tâches simples, atomiques et répétables pour produire plus vite. Mais un système d’information ne fonctionne pas comme ça et les techniciens ne sont pas des ouvriers. En informatique, la seule constante c’est que tout est inconstant. Le DevOps cherche à s’approprier cette inconstance, au bénéfice de la production de valeur. Pour cela, il va jusqu’à redéfinir l’organisation. Personne n’est DevOps ; c’est l’entreprise tout entière qui devient DevOps.

Sources :

• https://blogs.cisco.com/learning/the-rise-and-rise-of-devops-adoption
• https://www.riverbed.com/riverbed-wp-content/uploads/2023/03/ema-devops-and-continuous-delivery-tooling-launchpad-for-digital-enterprise-fr.pdf
• https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report?hl=en
• https://www.niceideas.ch/roller2/badtrash/entry/devops-explained