Le mur de la confusion
Introduction
En retraçant l’historique du DevOps, on comprend pourquoi il est devenu un élément indispensable de l’agilité. Cette pratique dépasse largement le cadre technique et constitue bien un aboutissement dans la transformation agile des organisations.
Il est clair que le contexte a largement contribué à faire évoluer les pratiques : difficultés rencontrées dans l’application du cycle en V ; nécessité de tirer le flux de valeur en fonction de la demande et du besoin réel ; importance de l’expérimentation dans le processus d’innovation. Si le DevOps apporte des réponses à ces besoins, c’est aussi parce que les organisations en place ont du mal à y répondre en appliquant les anciennes méthodes. Il est donc tout aussi important de comprendre ce que le DevOps doit améliorer les organisations en analysant les points de douleur qu’elles rencontrent.
Genèse d’un projet applicatif traditionnel
1. Un super projet
Pour illustrer les problèmes rencontrés dans les départements informatiques, nous prendrons l’exemple d’une entreprise représentative de nombreux grands groupes qui forment les piliers de l’économie. Cotradis (le nom est fictif) est une grande entreprise spécialiste dans la vente de détail, et qui dispose de nombreux magasins sur tout le territoire. Encore récemment, cette entreprise concentrait son activité sur des ventes physiques, en magasins. Mais désormais, à l’heure du digital, une grande partie du chiffre d’affaires passe par des commandes sur Internet, en retrait ou en livraison.
Depuis sa naissance, c’est-à-dire depuis quelques décennies, la DSI de Cotradis fournit des services de support informatique qu’elle répartit en deux catégories de métiers :
-
l’amont pour les besoins du siège et des activités de soutien au business,
-
l’aval pour les activités de ventes, c’est-à-dire pour les besoins des magasins.
Transversalement à ces catégories, l’entreprise adresse des domaines traditionnels de son business :
-
le domaine de la logistique,
-
le domaine du marketing,
-
le domaine des achats,
-
le domaine du paiement,
-
etc.
Chacun de ces domaines décline ses besoins différemment en fonction de l’aval et de l’amont. Pour faire simple, l’aval et l’amont représentent des utilisateurs et des besoins différents dans chacun des domaines.
De son côté, pour rendre les services informatiques nécessaires à ces domaines, la DSI emploie entre 500 et 1 000 personnes, et fixe plus ou moins son modèle de fonctionnement sur le découpage par domaine métier de l’entreprise.
Pour autant...
Une dette technique insurmontable et un produit fragilisé
Les conséquences de cette mise en production chaotique seront durablement néfastes pour toute la vie de l’application. Celle-ci naît avec une dette technique qui est déjà quasiment insurmontable. Une action de remédiation impliquerait un re-engineering sur de nombreux éléments :
-
la documentation,
-
la mise en conformité des environnements,
-
la clarification de la stratégie de sécurité,
-
l’automatisation des tests de l’application,
-
la construction des scripts d’automatisation et la mise en place d’un outil ad hoc,
-
la mise en place d’un outil d’observabilité,
-
la mise en place de la haute disponibilité et la construction d’un deuxième environnement de production sur un autre site.
Cela représente un coût de remédiation important qui aura du mal à trouver son budget. Dans la plupart des projets, une fois la première mise en production achevée, il devient très compliqué de financer des actions d’apurement de dette technique, simplement parce qu’elles n’apportent pas de valeur métier immédiate. Il faut alors démontrer que la remédiation apporte une vraie valeur business, soit en conditionnant le développement de nouvelles fonctionnalités à valeur ajoutée, soit en permettant de réaliser d’importantes économies de maintenance.
La remédiation peut également être nécessaire parce que le service souffre de fiabilité et fait perdre de la crédibilité et même du chiffre d’affaires. Mais cela reste très compliqué à démontrer et souvent le budget ne permet guère plus que quelques actions ponctuelles...
Le mur de la confusion : changement contre stabilité
1. Les tensions internes
Notre exemple de projet chez Cotradis vous paraît peut-être un peu sombre, mais par expérience, c’est une configuration fréquente. Nous le reverrons plus tard, mais les études menées au niveau international mettent en évidence un taux d’échec de 80 % des projets informatiques. Et, malheureusement, le cheminement de Cotradis est assez classique.
Il serait nécessaire d’apprendre de ces problèmes mais, dans les organisations en silos, un échec est rarement considéré dans son ensemble. La notion d’échec est elle-même sujette à débat et c’est sans doute le premier constat sur lequel l’organisation devra se mettre d’accord. Mais chacun analyse la situation en fonction de sa perspective. Assister à une session de retour d’expérience ou un post-mortem est édifiant. L’habitude des projets en échec est tellement ancrée que l’on finit par adjoindre un terme morbide à une simple réunion de débriefing…
Lors d’un retour d’expérience vous pourrez, ou avez, sûrement constaté que chacun apporte sa vision des problèmes. La MOA assure que le périmètre était convenablement dressé et que la vision ainsi que les enjeux étaient clairement énoncés. Les études argueront d’avoir mobilisé les ressources suffisantes, d’avoir mené les activités qu’elles s’étaient engagées à réaliser et d’avoir livré le produit dans le meilleur délai possible en tenant compte des nombreux changements qui lui ont été demandés en cours de développement. Les opérations...
Les challenges qui vous attendent
L’objectif de présenter cette expérience autour du cas Cotradis est de fournir une mise en perspective sur les raisons qui conduisent une organisation à devenir dysfonctionnelle malgré le recours à des frameworks méthodologiques aussi rationnels qu’ITIL.
Chacun voulant s’assurer que le prochain projet soit mieux construit, pense tenir la solution en améliorant son fonctionnement interne. Mais améliorer localement un processus veut dire aussi imposer un mode d’interaction plus ferme avec les autres services. Pour améliorer son processus interne, il est nécessaire d’imposer un contrôle drastique des flux entrants pour qu’ils répondent le mieux possible à son propre besoin, afin de fournir un travail de qualité et produire en sortie un livrable qui sera irréprochable. Cela conduit donc en fait à rigidifier le process de construction dans sa globalité et génère de la friction entre chacun des maillons de la chaîne de production. Imaginez plusieurs roues de Deming autonomes, chacune appuyant son optimisation interne sur son interaction avec les autres. Comme nous pouvons le voir dans le schéma suivant, cela crée de la friction entre les services et finalement rend très incertain le résultat : amélioration ou détérioration ?
C’est ce que donne une organisation où chaque service cherche à s’améliorer en ne faisant que renforcer la rigidité de ses processus existants.
Pour apporter des solutions globales qui permettent de construire des produits fiables, et en même temps de répondre au besoin d’innovation et de réactivité du métier, il va donc falloir sortir du piège de l’amélioration unitaire des services et...
Les bénéfices attendus du DevOps
1. Innover
Le monde d’aujourd’hui est digital, ce qui signifie littéralement que le logiciel est entré dans la chaîne de valeur de la plupart des entreprises. Ne pas intégrer le digital dans sa chaîne de valeur les condamne à plus ou moins long terme. Satya Nadella, CEO de Microsoft, le répète à l’envi, "every company is a software company".
Mais intégrer le digital dans la chaîne de valeur, c’est aussi prendre conscience que le service IT passe d’une fonction de support à une fonction de production de valeur. Nous ne produisons pas de la valeur de la même façon que nous fournissons un service de support. Dès lors que l’on entre dans l’apport de valeur business, il devient clé de pouvoir réagir le plus rapidement possible aux attentes du marché, sous peine d’être dépassé immédiatement par des compétiteurs plus audacieux.
Bien sûr, il y a des nuances à apporter selon les marchés et les cultures d’entreprise. La valeur pour certaines entreprises est aussi simplement d’être très fiable. Mais même pour ces entreprises "piliers", il n’est pas impossible qu’un nouveau venu vienne bousculer le modèle business par des coûts moindres et une technologie plus performante.
Les entreprises doivent innover pour se maintenir proches de leurs clients. Elles doivent transformer leur IT pour recueillir le feedback utilisateur dès que possible, pour proposer, risquer et revenir en arrière si nécessaire. C’est une nouvelle compétence à acquérir, s’appuyant sur l’ingénierie.
On parle énormément de disruption des marchés, "d’uberisation"...
Les trois voies du DevOps
Dans un article publié en 2012, Gene Kim synthétise ce qu’apporte le DevOps en énonçant trois fondamentaux clés à partir desquels il est possible de décliner toutes les pratiques qui permettent à une entreprise de mettre en place le DevOps.
Première voie : penser le système dans sa globalité
Il s’agit de privilégier l’amélioration du système dans son ensemble et non en se contentant d’améliorations locales au niveau des services. En clair, il s’agit de désiloter l’organisation.
Deuxième voie : amplifier la boucle de feedback
Le DevOps est un moyen d’obtenir le feedback des utilisateurs afin de mieux le comprendre et de coller à ses besoins. Cette boucle de feedback doit pouvoir être raccourcie le plus possible pour améliorer dans son ensemble la capacité novatrice de l’entreprise.
Troisième voie : une culture de l’apprentissage continu
Un principe fort du Lean et de l’agilité est de mettre en place une organisation qui place en son cœur la capacité à apprendre de chacune de ses actions, succès ou échecs, et d’améliorer continuellement sa façon de procéder.
Ces trois voies font bien écho aux problèmes rencontrés dans notre exemple et peuvent servir de repère à toutes les actions et tentatives qu’une organisation souhaite mettre en place pour que la culture DevOps soit au centre de ses pratiques d’ingénierie.
Autre référence utile :
Gene Kim, Kevin Behr, George Spafford, "The Phoenix project: A Novel About IT, DevOps, and Helping Your Business Win"