DevOps, le CALMS après la tempête

Il n’existe pas encore de référentiel de bonnes pratiques autour de DevOps. Il faudra donc se contenter d’une bonne dose de pragmatisme et des 5 piliers communément acceptés sous la dénomination C.A.L.M.S : Culture, Automatisation, Lean, Mesure et Solidarité.

S’il est un sujet qui a défrayé les chroniques web et qui soulève encore beaucoup de questions dans la plupart des équipes informatiques, c’est bien DevOps. Rappelons que DevOps a pour principal objectif de décloisonner les équipes de Développement (Dev) et d'Opérations (Ops) afin qu’elles puissent travailler de manière plus fluide et agile. Une agilité désormais indispensable pour accélérer la livraison de nouveaux services digitaux et améliorer la compétitivité des entreprises sur des marchés en mutation rapide, et sur lesquels nombre de nouveaux acteurs tels Uber ou Netflix se développement fortement.

Le concept d’agilité est essentiellement porté par les développeurs depuis le début des années 2000 avec les principes édictés dans le Manifeste pour le Développement Agile. Les bonnes pratiques de gestion des opérations informatiques ont quant à elles été formalisées dans des cadres méthodologiques tels qu’ITIL ou encore COBIT, et mises en œuvre par de nombreuses entreprises depuis le milieu des années 1990.

Aussi, après la tempête médiatique et face aux flots d’attentes que suscite DevOps, les directions informatiques doivent désormais s’attacher à évaluer les possibilités de mettre en place une approche agile, qui bien souvent est également poussée par les métiers. Pourtant, contrairement à ITIL ou COBIT, il n’existe pas encore de référentiel de bonnes pratiques sur lequel s’appuyer pour implémenter DevOps. Il faudra donc se contenter d’une bonne dose de pragmatisme et des 5 piliers communément acceptés sous la dénomination C.A.L.M.S : Culture, Automatisation, Lean, Mesure et Solidarité.

Culture – Y-a-t-il un pilote dans DevOps ?

Faut-il voir DevOps comme une simple extension de la sphère d’influence du Développement au détriment des équipes de Production ? Probablement non, comme pour toute évolution culturelle profonde, l’implémentation de DevOps nécessite un plan d’accompagnement du changement visant à casser l’organisation en silos, héritée du cycle en V, autour de développement, test, qualité et production. C’est une démarche qui requiert sensibilisation et pédagogie pour espérer une adoption réussie, et des outils de serious gaming sont de plus en plus employés. A noter également que selon le cabinet IDC, 80% des entreprises revendiquent l’impulsion de la direction générale comme facteur clé pour assurer le succès du projet

Automatisation – DevOps & OpsDev

L’automatisation est une des clés de la réussite pour DevOps, une étude d’IDC indique d’ailleurs qu’en 2015, parmi les entreprises ayant lancé une initiative DevOps, 48% se sont équipées de solutions d’automatisation.

Pour autant on ne peut pas se borner à considérer DevOps comme une simple chaîne automatisée allant du Développement vers les Opérations. Se contenter de produire des changements à une cadence plus élevée ne fait que déplacer et faire prospérer un goulet d’étranglement qui s’installe durablement au niveau de la production, sans produire de valeur ajoutée. En pratique, dans une approche DevOps réussie, le Développement se positionne en tant que consommateur d’infrastructures clé en main. Les Opérations s’installent alors dans une démarche OpsDev, et fournissent des infrastructures à la demande pour toutes les phases d’intégration continue depuis la compilation jusqu’à la qualification, en passant par les tests unitaires.

Si DevOps constitue un changement radical dans la manière dont le Développement travaille, OpsDev révolutionne également les pratiques des Opérations.  Cela passe par des infrastructures « déclaratives » plus agiles, décrites et construites à partir d’un code source, une automatisation encore plus sophistiquée et la possibilité de fournir des services d’infrastructure en accès-libre pour les développeurs.

Lean – Le rasoir d’Ockham

La philosophie du Lean trouve ses sources dans les méthodes de production de Toyota, où la recherche de la performance se fait grâce à l’élimination des gaspillages appelés « muda » en Japonais. Les types de gaspillage sont au nombre de 7 : surproduction, attentes, transport, étapes inutiles, stocks, mouvements inutiles, corrections/retouches. Ils peuvent être appliqués à bon nombre d’activités industrielles, et résonnent désormais fortement aux oreilles des professionnels l’informatique avec le Lean IT.

Que l’on ne s’y trompe pas, DevOps n’est pas un processus ou un ensemble de processus additionnels que l’on va venir greffer à des cahiers de procédures existants. Il s’agit bien d’une remise en cause totale de l’organisation et des modes d’interaction en place, visant à fluidifier et optimiser, en éradiquant les gaspillages de la chaîne de livraison des applications. En un sens, adopter DevOps c’est aussi faire place nette et preuve de rationalisme, ce que finalement la philosophie Occidentale à également bien décrit avec le principe du rasoir d’Ockham.

Mesure – Amélioration Continue

Selon un principe bien connu attribué à Lord Kelvin, il est impossible d’améliorer un processus pour lequel on ne dispose pas de mesures fiables quant à son fonctionnement. Et concernant DevOps, c’est bien d’amélioration continue ou de « Kaisen » dont il est question. Directement issu de l’approche Lean, le « Kaizen » contraction des mots Chinois « kai » et « zen » (changement et meilleur) vise à résoudre les problèmes directement sur le terrain sans investissement ni gros moyens. Encore faut-il disposer d’un référentiel d’indicateurs de performance adéquats et partagés notamment avec les métiers. En effet, l’établissement d’une communication transparente vis-à-vis des métiers est un facteur de succès qui a été reconnu, toujours selon le cabinet IDC, par plus de 40% des entreprises en phase opérationnelle.

Un indicateur tel que le  TRS (Taux de Rendement Synthétique), très utilisé dans le milieu industriel, peut constituer un excellent KPI puisqu’il fournit une vision synthétique et sévère de la performance en un chiffre unique.

Solidarité – « C’est pas moi, c’est nous »

Avec la solidarité c’est encore la culture qui est en avant, ou plutôt le changement de culture autour d’un conflit d’intérêt séculaire datant des origines de l’informatique. Les équipes Opérations ont en effet pour objectif de garantir la stabilité des systèmes, avec comme principal moyen le contrôle strict et la limitation des changements. A l’inverse, les équipes Développement ont pour mission d’apporter les changements nécessaires le plus vite possible, au risque d’impacter la stabilité.

L’antagonisme de ces objectifs et la séparation stricte des tâches peut rapidement aboutir à ce que les anglo-saxons nomment le « finger-pointing », c’est-à-dire des intervenants qui se rejettent la faute au lieu de s’aider mutuellement pour corriger un problème. Avec DevOps, un changement de paradigme est nécessaire, il consiste à abandonner les objectifs spécifiques à chaque équipe et à matérialiser un but commun. Dans un contexte d’accélération des cadences et donc de multiplication des risques d’erreur, la paix entres les équipes est à ce prix.

Se mettre au CALMS

Comme l’a assez clairement exprimé Patrick Debois, à l’origine du mouvement DevOps, l’essentiel des écueils liés à l’adoption de DevOps n’est pas d’ordre technique mais d’ordre humain. Il est avant tout nécessaire de faire renaître une véritable confiance, souvent perdue, entre les différents intervenants de la chaîne de livraison applicative. Faute de cadre méthodologique défini, les piliers du CALMS offrent néanmoins un éclairage pertinent pour avancer, reste à chacun de définir sa propre feuille de route pour des pratiques plus agiles. Mais finalement si l’on considère DevOps comme un outil de différenciation, n’est-il pas raisonnable d’en faire sa propre affaire ?