Pourquoi le DevOps ne prend-il pas dans mon entreprise ?

Le DevOps c’est fantastique. Automatisation, intégrations, tests et livraisons continus, stabilité des applications, sécurité accrue, délais accélérés de mise sur le marché, la démarche séduit les ingénieurs certes, mais également les cadres des services voisins.  Jusqu’à la direction qui n’y voit que des avantages sur le résultat global. C’est en tout cas ce qu'affirment beaucoup d'entreprises. Et les autres ? Le DevOps ne s’adresserait-il qu’aux licornes, startups et pure players ? Certainement pas, si l’on prend garde à ne pas répéter les erreurs courantes qu’induit en général une organisation silotée traditionnelle d’entreprise.

Source de l'illustration : nemesis-studio.com

DevOps, l’affaire de tous

Parce que le DevOps est un mouvement apparu au sein de l’ingénierie informatique, il est rare que les autres directions disputent à la direction des systèmes d’information la paternité de sa mise en œuvre. C’est donc la DSI qui lira les articles consacrés à la démarche, elle qui portera son attention sur les prérequis, les bénéfices à en attendre, les écueils à éviter. Elle enfin qui fera le point sur les besoins et les raisons d’unifier les équipes de développement et d’administration pour le succès de ses futurs produits.

C’est donc très accessoirement qu’une direction générale se penchera sur la question, y voyant quasiment le pré carré de la DSI, teinté sans doute de l’impression, somme toute compréhensible, de n’y comprendre que bien peu de choses. En conséquence de quoi, la DSI se retrouve seule à la tête d’une démarche pourtant éminemment structurante, considérablement « transformante », exigeante et demandeuse de pédagogie, de temps et de sponsoring.

On l’aura compris : sans direction générale sur le pont, le DevOps ne se déploiera qu’à la marge et c’est bien dommage. Dommageable à quel point ? Au point d’impacter à terme le recrutement, le rythme de mise sur le marché, l’innovation, la capacité de pivot d’une entreprise du XXIe siècle.

Peut-on isoler le DevOps ?

Parce qu’ils restent perçus comme la figure de proue du DevOps, les entreprises ont une fâcheuse tendance à se précipiter sur les outils couramment utilisés dans les processus DevOps.

La conteneurisation par exemple promet d’importants gains de temps et la suppression d’un grand nombre de points de friction. Formidable sur le papier, un outil comme Docker exige aussi beaucoup de forces vives et une nouvelle organisation pour produire tous ses effets. Il est pourtant courant de rencontrer dans l’entreprise le cas d’un développeur solitaire, chargé d’explorer le logiciel, quand la tâche n’est pas confiée à un stagiaire. C’est dire à quel point tout le sens de la démarche DevOps et son esprit de collaboration et d’itération en équipe sont oubliés ou relégués au rang de quantité négligeable.

DevOps prend sa source dans la collaboration, l’échange et le partage de l’information, des objectifs, des contraintes et difficultés et des succès. Si DevOps unifie le développement et les opérations par le biais de solutions technologiques et de process, il tend d’abord et surtout à souder les équipes. Malheureusement, point de formule magique là-dedans, point de baguette de sorcier. Seuls un sponsoring fort et une bonne organisation fourniront le terreau indispensable aux équipes pour s’unir dans la démarche.  

Partager les succès, mais aussi les responsabilités

Combien sont-elles ces entreprises à vouloir casser les silos ? C’est presque un marronnier de l’IT ou la bonne résolution de début d’année qu’on ne parvient pas à tenir. La vérité est qu’une démarche DevOps implique l’acceptation par tous de suspendre des processus jusqu’ici bien installés et de leur substituer un fonctionnement collaboratif aussi familier par le terme qu’absent dans les faits.

Une collaboration efficace et réussie suppose que des équipes que tout oppose (réactivité pour les uns, stabilité du système pour les autres - entre autres choses - ) travaillent à partir de nouveaux objectifs communs, de concert du début à la fin d’un projet, avec des outils partagés, dans un dialogue permanent qui n'est pas réservé qu'aux ingénieurs, mais fait participer les utilisateurs finaux également.

Elle suppose en outre d’établir un environnement de travail qui met en confiance les collaborateurs, de façon à ce que les responsabilités soient assumées collectivement dans une culture de correction et d’amélioration continue.

Derrière tous ces mots s’en dissimule un qui chapeaute le tout : l’humain. Complexe, changeant, intégré dans une structure faite de codes et de règles, l’être humain présente toutes les caractéristiques pour s’opposer au changement. Quand, de son côté, le DevOps demande un saut dans l’inconnu.

La confiance dans la méthode

Que l’on saute d’un pont à l’élastique ou que l’on accepte d’adopter de nouvelles façons de travailler, tout est une question de confiance. Si les avantages techniques de DevOps (moins d’erreurs commises, une plus grande célérité, une stabilité accrue), et ses avantages économiques (des solutions professionnelles sécurisées disponibles plus rapidement pour les équipes, des fonctionnalités nouvelles en direction des clients) sont compris de tous, ils ne créent pas à eux seuls la dynamique de changement dans les équipes.

Attention à la communication interne, elle est souvent insuffisante. Elle ne remplace pas le dialogue avec les équipes, lequel ne prendra forme que si le sentiment d’être impliqué dans la nouvelle stratégie est vraiment ressenti. Alors l’investissement, l’engagement et avec eux, les questions pertinentes et les propositions constructives viendront.

Attention également à la culture de l’expert, largement répandue dans les directions techniques. Aussi valorisante soit-elle, elle ne contribue pas au partage de l’information et de la connaissance. Elle renforce au contraire une compétition sous-jacente qui s’aligne mal avec la culture DevOps, qui tendrait plus volontiers à l’acceptation de la critique des pairs.

C’est alors toute la difficulté du travail en équipe vs l’évolution professionnelle individuelle qui apparaît. Travailler de façon à simplifier le travail des autres, par exemple, n’est que rarement pris en compte au moment de l’appréciation des compétences et des progrès. Or pour que la culture DevOps imprègne une structure, il faut aussi très certainement faire évoluer les critères d’évaluation professionnelle.

Un sponsoring continu pour un déploiement continu de la culture DevOps

Mettre les moyens, financiers et humains, sur la table est indispensable pour accompagner les équipes vers la culture DevOps. Mais il appartient à la direction générale d’assumer ce nouveau positionnement et de le sponsoriser avec vigueur aux côtés de la DSI et des autres directions, grandes bénéficiaires indirectes du DevOps.

Sponsoriser ne signifie pas imposer. Les outils DevOps, qu’ils portent sur la gestion du code source, les tests d’intégration continue et de déploiement continu, les conteneurs, les solutions de stockage, l’automatisation sont légion. Leur sélection doit être le fruit d’une concertation avec ceux et celles qui en auront l’usage, si l’on souhaite réellement leur adoption.

C’est une question de bon sens. Les nouvelles générations d’ingénieurs sont biberonnées au DevOps. Combien de temps encore la fracture sur les méthodes restera-t-elle insensible au sein de l’entreprise, mais également avec les partenaires et les prestataires tiers ? Sans compter qu’aujourd’hui déjà, de nombreux informaticiens plaident pour une plus grande latitude de moyens.

La culture DevOps est une part importante de la transformation numérique de l’entreprise. Dans peu de temps, les nouveaux recrutements (ou la difficulté à recruter) illustreront la réussite ou l’échec de cette transformation.

Martin Hervieu, Chief Innovation Officer