Dev et Ops, une alliance impossible ?

Dans quelle mesure peut-on fusionner les deux approches afin de gagner en efficacité ? Quels changements organisationnels cela implique-t-il ? Le point.

Définition et enjeux  

Le DevOps peut se définir comme un processus d’alignement des équipes informatiques qui combine « Dev » (en charge des améliorations, nouvelles fonctionnalités et changements applicatifs) et « Ops » (en charge de l’exploitation des applications et des infrastructures). Il consiste à adopter des pratiques agiles et une automatisation forte tout au long de la chaîne de valeur informatique, des besoins de l'entreprise au développement, jusqu'aux opérations informatiques. 

Le DevOps s’inscrit ainsi dans une logique disruptive dans la mesure où il couvre l’ensemble des modalités de la transformation de la DSI : il régit à la fois le processus de construction et d'exécution, l’outillage de livraison de logiciels, l’organisation entre Dev et Ops, mais aussi l’architecture et la sécurité. En somme l’objectif de ce nouveau paradigme informatique est de délivrer le produit final aux utilisateurs finaux dans un cadre temporel restreint, et ce, dans un réel souci d’efficience.

Les avantages qui lui incombent sont nombreux et ont déjà fait leurs preuves au sein de plusieurs entreprises notamment avec le raccourcissement du délai de mise sur le marché, le perfectionnement de la qualité du service et la diminution des coûts d'exploitation et de test grâce à l'automatisation et à l'amélioration continue.

Néanmoins, les spécificités de chaque équipe (Dev et Ops) constituent un frein à leur travail collaboratif. Dans quelle mesure peut-on fusionner ces deux approches afin de gagner en efficacité ? Quels changements organisationnels cela implique-t-il et comment surmonter concrètement le mur de l’incompréhension ?

Repenser l’existant pour devenir le leader de demain  

Si les natifs du numériques sont pionniers dans cette pratique et ont obtenu des fréquences de déploiement considérables, il n’en reste pas moins que le DevOps s’est propagé à de nombreux secteurs d’activité et beaucoup d’entreprises en ont bénéficié. En 2016, le marché du DevOps atteint 2,6 milliards de dollars et connaît une forte croissance du fait de deux phénomènes incompressibles : l’accélération du time to market et l’émergence de nouvelles technologies liées au génie logiciel. Selon une étude de Gartner réalisée en 2017, la pratique DevOps constitue la deuxième priorité des DSI qui ont déjà commencé à hiérarchiser leurs déploiements DevOps à plus grande échelle. Aujourd’hui, 44% des entreprises françaises ont des projets en cours ou à venir qui incluent une dimension DevOps.

L’union fait la force : quels changements culturels pour la DSI ?

Paradoxalement, si le changement inhérent au DevOps peut impliquer des prestataires externes, c’est surtout la culture interne qui doit être intrinsèquement repensée. En effet la conduite du changement nécessite de démolir le mur de la confusion qui peut exister entre les Dev et les Ops afin qu’ils visent les mêmes objectifs et évaluent les mêmes risques pour répondre aux attentes des entreprises. La culture DevOps est nécessaire car elle permet d’examiner les échecs, de favoriser l'approche test & Learn et d’encourager les équipes à capitaliser sur leurs erreurs, toujours dans une logique de progression. Or, cela ne peut être effectif que si la direction soutient cette évolution des pratiques en adoptant un leadership transformationnel: un bon manager a un fort impact sur la capacité d'une équipe à expérimenter, à faire, défaire et refaire en étant constamment soutenue. Le changement doit être fondamentalement horizontal.

Il existe plusieurs modèles d’organisation qui peuvent coexister dans une seule et même organisation : le modèle DevOps à équipe unique prône une approche multidisciplinaire où une équipe autonome est en charge de la construction et la gestion de l’application. Il comprend toutes les compétences requises pour concevoir, développer, tester, déployer et exécuter une application.

Dans le modèle dit « collaboratif », les équipes Dev et Ops restent séparées mais collaborent étroitement. Elles adoptent également des pratiques qui aident à réduire les silos, via par exemple la participation des équipes de développement à l'analyse des incidents ou inversement la participation des équipes d’opérations lors des phases de design applicatif.

Un processus de livraison continu

L’objectif du DevOps est de s’inscrire dans un processus de continuité nécessitant souvent une refonte du processus de livraison de logiciels pour garantir un délai d’exécution plus court et une meilleure qualité de code. Cela implique quatre fondements clés :

- Éliminer les temps d'attente entre les étapes grâce à une évaluation Lean identifiant ces temps d'attente et trouvant des solutions pertinentes. Il est possible par exemple de responsabiliser ses équipes de livraison en supprimant des comités décisionnels trop récurrents.

- Automatiser un maximum de tâches : la séquence de compilation du code, l'exécution des tests, la configuration des environnements et la préparation du déploiement. Néanmoins, cela nécessite un outillage approprié car les changements de processus doivent être effectués avec la mise en œuvre d'une chaîne d'outils intégrée.

- Revoir la séquence de livraison : la conception et le développement continueront d'être le point de départ. L'étape suivante consistera à automatiser tous les tests d'affilée : unité, intégration fonctionnelle, métier, sécurité, etc. puis à réaliser quelques tests manuels avant de lancer un déploiement de production en un clic.

- Réduire drastiquement la taille des changements relatifs à la production. Les grandes versions comportent des risques élevés tandis que les petites versions génèrent moins d'incidents et facilitent l'analyse des causes profondes.

Un outillage approprié

Le DevOps ne peut exploiter tout son potentiel sans un outillage approprié. Le département informatique doit fournir une chaîne d'outils en libre-service aux équipes qui prendront en charge l'ensemble du pipeline de distribution. Le défi de la mise en œuvre réside dans le choix des solutions les plus appropriées disponibles sur le marché. Il est essentiel que les outils soient sélectionnés de manière collaborative, en impliquant les Dev, les Ops ainsi que les experts en sécurité. Bien que les équipes projets puissent créer leur propre chaîne d'outils, le partage d'actifs induit une réduction des coûts et une mise en œuvre de meilleures pratiques communes.

Architecture et sécurité

Afin de limiter l’interdépendance des applications, on a recours à de nouveaux modèles architecturaux qui garantissent une implémentation réussie du DevOps. Notamment, l’architecture en microservices présente des avantages significatifs pour les équipes DevOps : avec des microservices plus petits, l'équipe de codage développe des compétences visant à être plus opérationnel sur un périmètre fonctionnel optimisé. De même, les équipes DevOps peuvent mettre à jour un microservice unique et indépendant. Enfin, le temps d'arrêt de l'application est raccourci.

Par ailleurs, il est nécessaire que les pratiques de sécurité soient respectées dans l’application du DevOps. Cette imprégnation de la culture de la sécurité au  niveau des équipes doit se faire de manière horizontale et graduelle. L’autonomie de l’équipe sera renforcée car elle pourra tester plus efficacement la conformité à la sécurité et augmenter sa productivité Cependant ceci implique que les équipes sécurité doivent s’appuyer sur les principes d’automatisation et de standardisation afin de ne pas ralentir le processus de livraison continue. La transparence devrait être garantie avec des applications et des infrastructures de surveillance "scorecard".

En conclusion, si l’atout majeur du DevOps est de gérer simultanément les multiples aspects de la transformation, cela nécessite en amont un cadrage rigoureux de la cible et la mise en place d’une équipe pilote à même d’appréhender les enjeux de mise en œuvre. La transformation s’appuie certes sur des outils mais la culture de la coopération doit permettre de réunir les équipes, au-delà de leurs différences.