Chapitre 6 : DevOps vu par le management

Pour les managers des équipes, une démarche DevOps peut être vue avec enthousiasme et défiance à la fois. En effet, promouvoir, améliorer et optimiser la collaboration est généralement accueilli favorablement par les responsables qui ont pour mission de rendre leur équipe la plus efficiente possible. Dans le même temps, ces démarches de collaboration imposent des évolutions, voire des transformations pour les organisations comme pour les personnes et comme souvent le changement amène une certaine forme de méfiance. L’être humain refuse et craint naturellement ce qu’il ne connaît pas. Levons donc le voile sur les impacts des démarches des DevOps pour les managers.

Si nous voulons viser la mise en œuvre d’une démarche de collaboration agile comme le préconise DevOps, il faut comprendre que cela implique des changements et nécessite d’adopter préalablement un certain nombre de pratiques.

Aussi, avant même de parler de collaboration, il est nécessaire que chaque partie prenante marque sa volonté de collaborer et adopte les prérequis nécessaires à la réussite de cette collaboration.

Dans l’objectif ultime et vital de s’aligner toujours mieux et toujours plus vite sur la stratégie globale de l’entreprise, il existe donc des préalables indispensables à mettre en œuvre par tous : être industrialisé, agile et fiable dans sa production, être agile dans ses développements, être prêt à travailler ensemble pour trouver un mode de collaboration consensuel et enfin être en capacité de communiquer avec les métiers et les décideurs business.

DevOps : la culture de la collaboration

Choisir de mettre en œuvre des pratiques DevOps signifie clairement souhaiter améliorer la collaboration et la confiance entre les équipes internes mais aussi avec l’ensemble des parties prenantes de la DSI.

Il n’est pas faux de dire que toute l’entreprise ou presque fait partie de ces parties prenantes. Dès lors, la mise en œuvre de DevOps a un impact sur la qualité de la collaboration de l’ensemble de l’entreprise.

Réussir à mettre en œuvre une collaboration agile au travers de pratiques et d’une organisation adaptée semble donc le modèle d’avenir dans un monde toujours plus collaboratif et réactif. Il est évident que ce modèle est un changement de culture pour l’entreprise mais sa nature agile permet de le mettre en œuvre avec douceur.

Enfin, il faut s’employer à diffuser cette culture à ses partenaires, fournisseurs et de manière générale l’ensemble des parties prenantes externes à votre organisation. Sans qu’il soit nécessaire qu’ils soient aussi matures que vous,

Concrètement, cela signifie que le monde de la production et des infrastructures doit être en mesure d’absorber une accélération des mises en production logicielles et une amélioration significative de sa réactivité face aux demandes comme face aux incidents.

Pour y parvenir, il n’existe ni recette miracle, ni incantation mystique, ni potion magique. Les opérations doivent être suffisamment structurées et industrialisées pour être en capacité d’absorber ce changement d’environnement et dans le même temps éviter toute rigidité qui mettrait à mal cette réactivité. On peut parler ici de la recherche du « just enough process ».

Pour y parvenir, il ne semble pas inutile de s’appuyer sur des frameworks de bonnes pratiques tel qu’ITIL ou sur des normes ISO, quand la norme n’est pas directement imposée par les régulateurs du secteur d’activité. Rien de cela n’est incompatible avec l’agilité tant que l’on ne tombe dans l’excès de la rigidité. De même, DevOps étant par nature agnostique aux technologies, un framework orienté technologiquement, y compris pour le cloud ou la mobilité, ne sera pas adapté à cette démarche.

La rigidité non, mais la fiabilité oui, afin de maîtriser suffisamment son patrimoine et les impacts qu’il peut subir tout en cherchant à les anticiper en permanence. Être industrialisé et structuré semble donc être un indispensable. De plus, tout ce qui est figé est voué à mourir et on ne peut absorber le changement et être suffisamment réactif si l’on recherche systématiquement la stabilité.

Il est également possible de s’appuyer sur des technologies de dématérialisation et aller jusqu’à l’adoption du cloud, qu’il soit privé ou public. Ce n’est pas un prérequis, simplement un formidable accélérateur potentiel pour adopter ce changement. Ce n’est qu’en réussissant à être à la fois proactif et réactif face aux demandes du monde des études et développements, mais surtout face aux demandes des métiers qui leur sont liés que les opérations seront en mesure de réussir à collaborer efficacement au service de toute l’entreprise.

Si le monde de l’infrastructure et de la production doit être un minimum agile, c’est tout autant le cas du monde des études et du développement. Pourquoi en effet, demander d’accélérer les déploiements pour passer d’une fois par an à plusieurs fois par semaine, si la moindre fonctionnalité nécessite dix-huit mois pour être développée ?

Les démarches DevOps visent à optimiser la collaboration et donc à aligner les modes de fonctionnement sur une temporalité et un rythme de travail commun. Les études et le développement comme les infrastructures et la production doivent donc être suffisamment agiles pour y parvenir.

Aussi, pour les équipes études et développement, il s’agit d’adopter un certain nombre des pratiques préconisées dans les méthodes agiles sans chercher toutefois à coller nécessairement à une méthode particulière et l’appliquer à la lettre.

Il s’agit avant tout d’adopter les valeurs et de faire le tri entre les pratiques proposées dans les principales méthodes agiles pour adopter ce qui semble pertinent dans votre contexte. Traditionnellement, on s’appuie beaucoup sur Scrum pour les pratiques de collaborations, sur XP pour les pratiques d’ingénierie et sur Agile-UP pour les principes de cadrage et de gestion de projet. Je n’hésite pas à compléter mes investigations avec Lean Startup ou Kanban pour la gestion d’anomalies.

Il n’y a pas une seule bonne façon d’être agile mais des centaines de bons choix en fonction de chaque contexte. Il est indispensable d’adopter les pratiques compatibles avec votre contexte pour réussir une démarche DevOps, mais il est impossible de spécifier dans un livre celles qui vous correspondent vraiment.

C’est en vous appuyant sur ces pratiques que vous allez réussir à créer une collaboration efficace tant avec les opérations qu’avec le métier.

Dès lors que les différentes parties prenantes du monde de l’informatique deviennent mutuellement suffisamment agiles, elles peuvent initier une démarche de collaboration DevOps. Il s’agit alors de chercher à construire une confiance mutuelle et d’introduire les principes d’automatisation pour pérenniser cette confiance.

Une bonne collaboration n’est pas uniquement nécessaire pour assurer un meilleur fonctionnement de la direction des systèmes d’informations globalement, elle est surtout indispensable pour pouvoir s’aligner sur les exigences du métier et des utilisateurs. Par ailleurs, il faut comprendre qu’il est impossible de s’aligner sur les besoins des utilisateurs et du métier sans chercher à impliquer ces représentants autant et aussi souvent que possible.

Et pourtant, il parait peu probable que les représentants du métier et des utilisateurs s’investissent dans cette démarche, si une tension constante plus ou moins visible existe entre les différentes composantes des équipes informatiques. Et quand bien même, ils accepteraient de collaborer dans un premier temps, malheureusement, cela ne saurait se confirmer dans le temps.

C’est pourquoi il est si important d’initier les mécanismes d’organisation et de collaboration DevOps au sein des équipes informatiques en travaillant les clés de confiance de chacun avant d’impliquer pleinement les équipes métiers pour réussir cet alignement nécessaire sur leurs besoins.

Il est d’ailleurs probable qu’une relation existe déjà avec les équipes métiers. L’implication est alors plus ou moins importante en fonction de la culture de l’organisation ou de la mise en œuvre ou non de méthodes agiles.

La mise en œuvre de DevOps va aider à renforcer et à étendre les relations avec les équipes métiers en s’appuyant sur les échanges existants tout en les faisant évoluer pour intégrer les équipes de production. C’est particulièrement le cas lorsque des méthodes agiles sont pratiquées préalablement à DevOps. Par exemple, le formalisme des scénarios de tests pourra être partagé par tous tout en ne sollicitant les interlocuteurs métiers qu’une seule fois.

Les démarches de collaboration DevOps ne visent pas seulement à améliorer la collaboration de manière agile et efficace, elles s’alignent complètement dans la stratégie future des entreprises et elles deviendront certainement indispensables à toutes les entreprises de demain avec plus ou moins d’urgence selon leurs marchés et leur secteur d’activité.

Une étude du Forrester d’octobre 2015 montre, par exemple et sans surprise, une appétence plus grande du secteur financier ou des services que de l’industrie traditionnelle.

En effet, les bénéfices délivrés par ce type de démarche permettent de gagner en flexibilité, en réactivité et en qualité pour l’ensemble du système d’information. Or l’informatique est aujourd’hui au cœur de toutes les entreprises, au centre de toutes les activités et en support de tous les produits et services. Ne pas réussir à adopter ce type de démarche revient à rater sa transformation digitale et à se mettre en retrait par rapport aux capacités des concurrents.

L’ensemble des modèles métiers de demain s’appuieront sur des innovations technologiques existantes et inexploitées ou qui seront inventées. Leur adoption facilitée par une démarche agile et DevOps et la capacité à les exploiter est sans doute une des clés de ces futures sucess story.

Adopter ces démarches, c’est s’y préparer ; les refuser ou les négliger risque fort de vous pénaliser pour longtemps.

Il ne s’agit pas de vous faire croire que sans DevOps, le Uber de votre activité va surgir pour vous faire disparaître, mais simplement de prendre conscience du niveau d’ancrage de ce modèle dans nos usages quotidiens même à notre insu. Ce sont ces usages que les entreprises devront supporter, adopter et reproduire car ils vont se généraliser et ils sont entièrement bâtis inconsciemment sur des modèles DevOps.

Pour illustrer la valeur de ce modèle, choisissons un exemple simple et parlant. Ainsi imaginez que vous êtes éditeur d’un service destiné au grand public qui s’appuie sur l’outil informatique. Pour faire simple, prenons l’exemple d’une application disponible sur smartphone, peu importe que vous soyez une grande entreprise ou un développeur indépendant, vous proposez une expérience disruptive valorisée par les utilisateurs.

On peut d’ailleurs supposer que même si vous avez été le premier à proposer cette expérience, une concurrence féroce est vite apparue et qu’il est fort probable que votre application n’est pas restée longtemps la seule de ce type dans les stores d’applications mobiles.

Grâce aux mécanismes de collaboration DevOps et notamment à ses cycles de feedbacks continus, vous avez détecté un nouveau besoin auquel vous pouvez répondre par une fonctionnalité logicielle. Toujours dans notre logique, le métier a pu rapidement qualifier le besoin, le définir et l’expliciter avant de demander sa réalisation technique et sa mise en production. On peut introduire ici toutes les notions d’itération agile, de minimum valuable product et de rings de déploiement par exemple.

Le fait est que grâce à cette mécanique vous avez pu être réactif et avez proposé une expérience valorisante avant vos concurrents. Vous avez pu créer un avantage concurrentiel plus ou moins durable et allez sans doute gagner des parts de marchés. Il faut également noter dans cet exemple, la mécanique de mise à disposition via des magasins d’applications qui se généralisent sur tous nos appareils y compris sur Windows et sur Mac OS.

Imaginez maintenant que ce n’est pas vous qui avez mis en œuvre ces démarches DevOps mais vos concurrents. Ils sortent avant vous cette nouvelle expérience dans leur application. Que se passe-t-il ? Dans un premier temps, l’utilisateur peut être fidèle et espérer que vous serez réactif et proposerez rapidement quelque chose de similaire puis se lassant, il risque fort de supprimer votre application pour installer l’application concurrente.

On peut d’ailleurs noter que les périodes de fidélité se réduisent de plus en plus dans un monde d’hyperconsommation. Il est ensuite d’ailleurs peu probable que l’utilisateur ainsi perdu revienne à votre application après avoir été déçu de la confiance placée en vous.

Autrement dit adopter une démarche et une organisation DevOps dans un monde où la consommation des services informatiques tend de plus en plus vers le modèle de la mobilité va devenir réellement indispensable pour tous, à plus ou moins long terme.

Si DevOps est une approche de collaboration agile, il n’en demeure pas moins qu’une collaboration efficace nécessite une organisation adéquate. Nous verrons que de notre point de vue, il n’existe pas une organisation type mais des organisations différentes selon les contextes, les contraintes et les objectifs.

Aussi variées soient ces organisations, nous pouvons les classer en trois grandes familles et en extraire les grands principes communs.

Le modèle prôné par Amazon est sans doute le plus connu et il peut facilement passer pour le modèle ultime dans l’esprit de certains. Il présente sans aucun doute un certain nombre d’avantages mais il nous paraît difficilement applicable dans de nombreux contextes. Il faut commencer par rappeler qu’Amazon a très tôt appliqué les principes du DevOps dans sa jeune histoire sans avoir eu besoin de se transformer depuis un modèle plus traditionnel et il est difficile de transposer son modèle principalement orienté web à l’ensemble des cas de figures de l’industrie.

Néanmoins, cette entreprise a poussé très loin les principes de collaboration et d’automatisation du DevOps et son modèle d’organisation est un cas d’école. Il faut tout de même se rappeler que d’autres entreprises sont allées aussi loin dans ce modèle, mais de manière différente avec des modèles d’organisation différents. Nous pouvons par exemple citer Facebook, Google ou encore Microsoft.

Le principe de l’organisation d’Amazon a été dicté par le désormais emblématique paradigme You build it, you run it de Werner Voegels CTO du groupe.