L’engouement des DSI pour l’approche DevOps est régulièrement mesuré, et salué, par des études et des sondages auprès des entreprises. Pour l’auteur, consultant en optimisation de fonctionnement des DSI, c’est une bonne nouvelle, pour au moins trois raisons : d’abord, les entreprises qui ont mis en œuvre DevOps ont constaté une réelle amélioration de la productivité, de la qualité et de la réactivité de la DSI.
Ensuite, « ce succès ne doit rien au hasard, les pratiques de DevOps n’ont rien de magique, c’est une autre façon très cohérente de faire de l’informatique d’entreprise. » Enfin, « ces pratiques si efficaces reposent sur un système qui a déjà fait ses preuves, si le nom est récent, les bases sont anciennes. »
Pour autant, il n’existe pas de définition unique de DevOps, chaque expert, chaque précurseur de la méthode ou cabinet d’analystes a la sienne. Pour Alain Sacquet, une définition de DevOps se réfère à quatre composantes : une communauté de personnes, un objectif (maîtriser la construction, la maintenance évolutive et l’exploitation du SI qui doivent pouvoir être modifiées rapidement sans faillir), une perspective (la démarche Lean pour améliorer la performance, la qualité, les délais, les coûts et la productivité) et un ensemble de moyens (qualité des relations entre les personnes, partage d’une même culture, qualité des outils et des infrastructures…).
Mettre en œuvre DevOps, comment évoluer vers une DSI agile, par Alain Sacquet, Dunod, 2016, 222 pages.
La légitimité de DevOps tient aux travers dans le fonctionnement des DSI, en particulier le mur érigé entre les métiers et les développeurs et les silos créés entre les équipes des études et celles de la production. « La mauvaise collaboration entre les deux équipes s’explique par les différences entre les objectifs assignés aux uns et aux autres : le souhait de changer le fonctionnement des applications pour les développeurs s’oppose au désir des exploitants de faire fonctionner un système stable », souligne Alain Sacquet.
Avec DevOps, précise l’auteur, « des sessions de travail collaboratif sont substituées à la rédaction et à la lecture des cahiers des charges exhaustifs. » Pour que cela fonctionne, il faut plusieurs ingrédients : une culture collaborative (différente de la culture d’entreprise), des méthodes, des outils, des indicateurs de mesure, des équipes intégrées multicompétentes et autonomes, une architecture agile et des plateformes solides.
L’approche DevOps est intimement liée aux démarches Lean, qu’il s’agisse de Lean Thinking, du Lean Software Development ou du Lean Manufacturing, qui reposent sur les mêmes principes : une maîtrise du flux des demandes de travail qui influe sur la productivité d’une organisation et la qualité de sa production. « L’intérêt de la diminution de la taille des lots de fabrication est particulièrement souligné, car elle fonde les pratiques DevOps de mise en production en continu », ajoute l’auteur.
Reste à mettre en œuvre la démarche DevOps. Hélas, reconnaît l’auteur, « l’écart est considérable entre la logique de fonctionnement des DSI traditionnelles et le modèle DevOps. » Pour Alain Sacquet, les points de friction s’observent dans plusieurs domaines : la spécialisation des équipes (la séparation entre études et production des DSI traditionnelles s’oppose à une spécialisation par couches et par applications de DevOps), la différence dans les modes d’organisation (taylorisé vs auto-organisé), dans la gestion des ressources humaines (proximité avec les métiers, qualité, valorisation du métier d’informaticien…), dans le modèle de productivité (taylorisation et workflows d’un côté, intégration des compétences de l’autre) et les différences de profils : « La culture DevOps valorise les ingénieurs et l’excellence technique », assure l’auteur.
Pour ce dernier, les DSI n’ont pas d’autre choix que de se transformer : « Les DSI sont soumises à une double action : les métiers poussent les études à plus de réactivité et de qualité pendant que l’exigence de disponibilité des infrastructures et les offres cloud tirent les productions aux pieds du SI. Les DSI risquent ainsi d’être renversés par le grand mouvement de balayage extérieur. »
C’est, bien sûr, possible d’opérer une transformation culturelle, organisationnelle et managériale des DSI vers une démarche intégrant DevOps et l’auteur suggère de nombreuses pistes pour y parvenir. Il propose un cadre de référence pour DevOps et la DSI agile. Il suggère ainsi, pour atteindre cet objectif, d’agir dans plusieurs domaines : appliquer DevOps partout où cela est possible, identifier les contraintes d’architecture, revoir la stratégie d’externalisation (surtout au niveau contractuel pour lever les freins à l’évolution agile des applications) et construire un « mix informatique autour d’une ingénierie Lean et agile et une gouvernance », en lien avec les métiers et la direction générale. Pour l’auteur, la philosophie de cette démarche n’est plus « la mise en œuvre de DevOps, mais la question de la DSI agile grâce à DevOps. »