Accélérer la transformation digitale via DevOps

Share this post:

« Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s’adaptent le mieux aux changements ». Charles Darwin aurait-il théorisé avant l’heure sur l’évolution de l’IT, et plus globalement des entreprises ? Une des clés pour relever le défi de la transformation digitale est l’approche DevOps .

En tant qu’architecte informatique, j’ai commencé ma carrière par du développement, j’ai créé quelques frameworks pour le web. Avant l’existence de Struts, je cherchais déjà à traiter les enchaînements de pages. Après mes études, mes débuts dans le milieu IT m’ont permis de découvrir tout un univers que j’ai vite appréhendé en déployant mes développements sur les environnements de production – un métier que j’appelle aujourd’hui « intégrateur d’applications ». Ce métier fait le lien entre le développement et la production : il permet de développer, contrôler, vérifier, améliorer son code afin de répondre au mieux aux besoins du  métier, tout en prenant en compte les contraintes que les administrateurs systèmes ont pu exprimer.

La démarche DevOps

Je me suis donc lancé dans cette aventure professionnelle sans mettre de nom sur le métier que je faisais. L’apparition du terme DevOps a clairement résonné avec mon approche. Ceci m’a amené à structurer sa définition. Dans cet article, je proposerai donc ma vision personnelle de la démarche DevOps.

• À quelles difficultés les entreprises font-elles face et en quoi DevOps peut les aider ?
• Quels sont les objectifs de DevOps ?
• Quels sont les 5 piliers essentiels à la réussite d’une transformation digitale avec DevOps ?
• Quelles perspectives et quelles évolutions sont indispensables pour que la méthodologie survive aux grands changements qu’apportent les nouvelles pratiques/technologies comme le cloud ou l’intelligence artificielle ?

DevOps : une capacité d’accélération pour l’entreprise

Ma définition de DevOps s’est affinée au fil des différents projets que j’ai pu accompagner, tant dans le domaine des télécoms que dans le domaine bancaire. J’ai pu constater que le secteur n’est finalement pas un sujet différenciant dans l’approche DevOps.

DevOps donne la capacité à une entreprise d’accélérer le déploiement de ses produits afin de saisir les opportunités du marché via un équilibre coûts/qualité/risques. Tout au long de cette démarche, l’exploitation des retours des utilisateurs permet d’améliorer la valeur des produits.

Une culture DevOps commune…

DevOps repose sur le développement d’une culture commune (qui permet au métier de parler IT et à l’IT de parler métier), ainsi que sur le partage des enjeux de chacun (métier, développement et production) dans une approche conjointe centrée sur l’utilisateur. La mise en œuvre d’une « usine de fabrication », outillée et automatisée, est au cœur de la démarche DevOps . Elle permet de créer un produit via des chaînes de fabrication qui respectent et contrôlent les standards architecturaux afin de faciliter le travail collaboratif et incrémental.

DevOps couvre tous les aspects du cycle de vie du produit logiciel et repose sur des éléments de mesure propres à chaque partie prenante :

• Le client : quelle est son adhésion à l’application, sa satisfaction, son engouement… ?
• Le métier : quelle est la valeur produite, quel est le retour sur investissement… ?
• L’équipe : quelle est sa vélocité, quelles sont les valeurs des indicateurs projet… ?
• La production : quel est le niveau de service fourni, quels sont les temps de réponse… ?
• La culture : quel est le niveau d’adoption de la méthode, la satisfaction des équipes… ?

Certains diront que la définition ne souligne pas assez l’importance de l’approche métier, de la sécurité ou de ne plus avoir d’Ops. Ils préfèreront alors les termes « BizDevOps », « DevSecOps » ou « noOps ». L’ensemble de ces concepts reste valide mais tend à privilégier une discipline particulière. Ma proposition de définition se veut la plus générale possible, sans mettre en avant une pratique plus qu’une autre.… pour faire tomber le mur de confusion.

DevOps est né d’une réalité : les systèmes d’informations sont bâtis sur deux cultures opposées

Les Devs apportent de nouvelles fonctionnalités pour satisfaire les utilisateurs – qu’ils soient clients ou collaborateurs. Ils impulsent le changement et la nouveauté à travers l’ajout permanent de nouvelles fonctionnalités ou l’amélioration de celles déjà délivrées.

Les Ops ont pour objectif de satisfaire l’utilisateur en lui garantissant la stabilité, la qualité de service (temps de réponse, disponibilité et intégrité) et la sécurité des infrastructures.

Ceci entraîne un mur de confusion entre les 2 types de rôles permettant de faire vivre un système d’information. Cette confusion née des objectifs antagonistes s’est souvent illustrée par la mise en silos des équipes pour spécialiser les activités et les métiers. Nous ne retrouvons pas ce type d’écart dans les petites structures où les équipes travaillent de concert et où la mise en place des principes DevOps est quasiment naturelle.

Difficultés et écueils de la démarche DevOps

La démarche DevOps mise en place par les acteurs du changement doit prendre en compte ces 2 positions antagonistes pour progresser. Le mur de confusion fait apparaître clairement une des mécaniques essentielles de ce changement : l’adhésion des personnes. On serait tenté d’instaurer simplement un rapprochement entre les 2 équipes – je l’ai souvent entendu lors de mes interventions. Mais l’expérience prouve que les changements profonds attendus ne se réalisent pas sans accompagnement. Rien n’est naturel lorsqu’il s’agit de bousculer ses habitudes de travail et dépasser le traditionnel « on a toujours fait comme cela ! ».

Pour mettre en place une transformation DevOps réussie, il est d’abord nécessaire de se pencher sur les objectifs à atteindre.

DevOps : accélération, équilibre, amélioration continue

Pour mettre en place une transformation DevOps réussie, il est d’abord nécessaire de se pencher sur les objectifs à atteindre, de l’accélération à l’amélioration continue de l’expérience client.

L’accélération : accélérer la livraison d’un produit, en d’autres termes le « time-to-market », permet de passer rapidement d’une idée à sa mise sur le marché. C’est un objectif stratégique majeur sur les secteurs concurrentiels. Lorsqu’une entreprise est la première à proposer au marché une idée novatrice, elle a de bonnes chances de se positionner comme acteur majeur sur le long terme.

L’équilibre : DevOps permet de trouver l’équilibre optimal coût/qualité/time-to-market. L’augmentation de la vitesse de livraison ne doit en effet pas entraîner une hausse des coûts ou une dégradation de la qualité du produit. J’ai rencontré trop d’équipes ayant cherché à obtenir un produit 0 défaut, pour un coût le plus faible possible et un temps de mise sur le marché ultra-court. Ce type d’exigence mène à des dysfonctionnements majeurs qui menacent l’équipe, le projet, voire même l’entreprise.

L’amélioration continue : DevOps permet de livrer souvent pour prendre en compte les retours des utilisateurs afin d’améliorer en continu l’expérience client.

Dès lors comment atteindre ces objectifs ? L’approche classique souvent croisée est une focalisation extrême sur les outils, ce que les professionnels appellent souvent la « toolchain » ou le CI/CD (pour « Continuous Integration » et « Continuous Deployment »). Or les outils ne font pas tout. Ils sont indispensables mais pas suffisants. En outre, un nombre incalculable d’outils apparait et disparait régulièrement. Les outils sont par nature éphémères et imposent une mise à jour très régulière de la « toolchain ».

Au-delà des outils, j’ai pu constater qu’une transformation DevOps réussie reposait sur 5 grands piliers. C’est ce que nous aborderons dans le prochain volet de cet article.

Les piliers CALMS d’une transformation DevOps réussie

Au-delà de l’outillage, communément invoqué par les entreprises, le critère de réussite d’une transformation DevOps – qui reprend les grands principes de la méthode Agile – repose sur 5 grands piliers : la culture, l’automatisation, le lean management, la mesure et le partage. C’est ce que j’appelle en synthèse les piliers « CALMS » pour « Culture, Automatisation, Lean Management, Measure, Share »

.

La culture : à la croisée des personnes, des processus et des outils

Centrée sur l’amélioration continue, la culture DevOps repose sur 3 dimensions : les personnes, les processus et les outils.

La connaissance les outils et de leurs différentes fonctions est évidemment essentielle dans une approche DevOps.

Côté processus, la culture DevOps repose sur la notion de « Continuous Integration – CI » et de « Continuous Deployment — CD » que l’on peut regrouper sous le nom de « Continuous Delivery » quand la maturité des équipes est déjà avancée. Ce processus doit être défini conjointement par les Devs et les Ops (au sens large, cela inclut l’ensemble des acteurs du système d’information) afin que toutes les étapes soient connues et partagées. La fluidité du processus et des transitions nécessite un maximum de standardisation. C’est un prérequis, ou tout du moins un facilitateur majeur, à l’automatisation.

Les personnes : le rapprochement des personnes passe par la mise en place d’une équipe au sein de laquelle la compréhension des engagements, des objectifs, des enjeux et des contraintes de chacun est prise en compte. Il est souvent difficile pour un développeur d’appréhender le fait qu’un Ops ait pu faire une astreinte et ne soit pas forcément disponible pour régler un problème. Inversement, un Ops peut ne pas bien comprendre pourquoi un développeur reste bloqué sur sa réalisation si l’environnement de test n’est pas disponible…

L’automatisation : shift-left et continuous testing

L’automatisation permet de livrer plus rapidement en optimisant les coûts et les efforts humains.  Nous sommes sur une chaîne de fabrication dont chaque étape peut être automatisée : fabriquer automatiquement le code, l’assembler automatiquement, le tester automatiquement, le déployer automatiquement… L’un des principes fondamentaux que nous pouvons mettre en avant est le « shift left ». Il vise à ce que le produit soit, le plus tôt possible dans la chaîne de conception, à l’image de ce qu’il sera en production. Les études démontrent en effet que le coût de correction d’une anomalie est d’autant plus important que l’erreur est découverte tard dans le processus de fabrication. C’est là que le principe du « continuous testing » prend tout son sens.

Les différents tests continus mis en place doivent répondre aux exigences des « quality gates ». Ces jalons fixent les critères de qualité définis par les Devs, mais aussi les Ops (capacités techniques, sauvegarde, mise en production sans interruption, sécurité…). Les Ops démontrent une meilleure adhésion à un processus lorsque les contrôles nécessaires pour préserver la stabilité du système sont garantis. Les Devs et les Ops doivent donc travailler ensemble sur la mise en place de standards dès le développement et tout au long du processus de déploiement pour éviter de refaire le packaging une fois le produit arrivé en préproduction.

A noter que dans l’automatisation, la standardisation est un point essentiel. L’arrivée du Cloud a démontré que le principe des containers (comme « Docker ») permet d’industrialiser la création des environnements dès le début de la chaîne en y intégrant les contraintes de chacun. C’est donc un facteur essentiel d’amélioration du time-to-market.

Le Lean Management

Le time-to-market n’est pas qu’une histoire de culture ou d’automatisation. Les processus de fabrication des logiciels entrent aussi en ligne de compte. Pour cela, il convient de comprendre, inspecter, analyser chacune des étapes de cette fabrication.

• La création d’une « Stream Value Map » permet ainsi de définir chaque étape du processus de fabrication – de l’idéation jusqu’aux retours utilisateurs.
• Une fois ces étapes identifiées, les relations existantes entre chacune d’elles doivent être établies.
• Vient la troisième phase de cette évaluation, qui analyse le temps que prend chaque étape. Cette phase est essentielle pour identifier les étapes qui prennent le plus de temps et garantir le time-to-market. Il est évident que plus une étape de fabrication sera automatisée, plus le temps sera optimisé.
• La dernière phase repose sur l’analyse de tous ce processus et l’identification des axes d’amélioration.

Nous nous basons sur une vision communément admise sur les grandes étapes d’un processus de fabrication symbolisé par le schéma suivant :

La mesure

La mesure est le moteur de l’amélioration continue et de l’usine de fabrication. Les questions que chaque équipe se pose dans la création de son produit doivent trouver des réponses dans l’analyse des mesures. J’ai défini 5 axes permettant d’alimenter le fameux « feedback utilisateur » afin d’augmenter la qualité du produit développé.

Les apports métier : indispensable pour dans le cadre d’une méthode Agile, la mesure des apports métier est essentielle pour prioriser les fonctionnalités. Les apports peuvent être l’augmentation de revenu, l’augmentation d’audience, la valorisation de l’image de la société, etc. Une participation du métier dans l’identification des 3 à 5 indicateurs majeurs à mettre en place permettra de lancer la transformation.

La valeur utilisateur : la notion de NPS, Net Promoter Score, montre l’appétence du client pour l’entreprise ou le produit. Cette notion rejoint et complète la satisfaction client afin de guider les orientations que doit prendre le métier.

La production : niveau de service, taux d’usage de l’application, stabilité… sont des éléments qui vont permettre de fixer des priorités. En effet, si une fonctionnalité a une forte valeur métier mais qu’elle n’est pas utilisée, une priorité pourra lui être donnée pour qu’elle soit retravaillée.L’équipe de développement ou l’équipe produit : vélocité de l’équipe, lead time, time-to-market, qualité du code produit, couverture de tests … sont autant d’indicateurs nécessaires pour pouvoir mettre en place le bon pilotage.

La transformation : il s’agit de mesurer l’acculturation à la démarche, le partage, la satisfaction de l’équipe, la compréhension du produit et des nouvelles pratiques ; tant à l’intérieur de l’équipe qu’à l’extérieur.

Le partage

Le partage peut se voir à plusieurs niveaux. Nous avons vu que dans la culture, il est important de partager les contraintes, les objectifs et les résultats pour faciliter la compréhension du travail de l’autre et pour casser le mur de confusion.

Dans ce domaine, de nombreux outils d’animation sont disponibles pour que chacun partage et échange sur son métier. On peut citer le team building ou la « Stream Value Map » qui permet souvent aux participants de découvrir que telle activité existe ou qu’elle est manquante.

Le partage de la mesure et la mesure du partage sont tout autant essentiels. Non pas que tout soit mesurable, mais c’est un élément fondamental : si on explique à chacun les résultats de son travail, on transmet plus clairement ses objectifs et cela cultive l’esprit d’appartenance à une équipe et à une entreprise.Enfin il est important de partager aussi avec les personnes en dehors de la transformation. Une transformation DevOps ne se fait pas en quelques jours. C’est un travail continu. Nous commençons avec quelques équipes, puis nous étendons cela à l’ensemble de l’entreprise à un rythme plus ou moins rapide en fonction des budgets et des orientations. Il est cependant primordial de ne pas laisser naître un mur de confusion entre ceux qui font une transformation DevOps et les autres, les innovants et les « legacy-oriented », les jeunes et les anciens … Le partage des résultats et les orientations de l’entreprise en termes de transformation DevOps est primordial pour obtenir l’adhésion de chacun.

Nous verrons dans le dernier volet de cette série quelles perspectives et quelles évolutions sont indispensables pour que la méthodologie survive aux grands changements qu’apportent les nouvelles pratiques et les nouvelles technologies.

Intelligence artificielle, automatisation… : faire évoluer DevOps

Dans l’entreprise, la transformation DevOps est un combat de tous les jours. Comme nous l’avons vu, elle répond à 3 objectifs : la réduction du time-to-market, l’équilibre du triptyque qualité / coûts / risques et l’obtention du feedback utilisateur. Nous avons proposé un cadre de transformation reposant sur 5 piliers dit « CALMS » — Culture, Automatisation, Lean Management, Measurement, Sharing. Le succès de cette transformation repose sur des prérequis et sur la capacité d’adaptation de la démarche via, par exemple l’intelligence artificielle et l’automatisation.

DevOps change fondamentalement l’esprit d’une entreprise car la démarche touche les processus, les outils et surtout les femmes et les hommes de l’entreprise. Un accompagnement de leur manager est primordial pour amener les collaboratrices et les collaborateurs à se sentir investis. Pour une transformation DevOps réussie, le management doit prendre conscience de son rôle d’accompagnant de la transformation.

Cette transformation impulsée par le management s’accompagne aussi de transformations des organisations pour permettre d’aller au bout de la culture DevOps (rapprochement des métiers, IT et production).

Avenir de DevOps, plusieurs défis restent à relever

D’un point de vue culturel, les entreprises ne doivent pas se laisser distraire par les différents courants tentant de mettre une priorité sur une discipline (BizDevOps / DevSecOps / NoOps / DevIAOps…). Chacune de ces disciplines traduit des actions d’amélioration continue dans la transformation DevOps. La culture DevOps doit donc les absorber, en faire une synthèse, pour améliorer son approche globale.

Au niveau de l’automatisation, deux grands axes de réflexion se dégagent. À très court terme, il convient d’intégrer tous les nouveaux outils qui arrivent ou les concepts que l’on souhaite promouvoir, comme la sécurité. À moyen terme, l’intelligence artificielle doit prendre sa place dans l’automatisation , comme elle a déjà sa place dans l’analyse et le monitoring de production. Elle impactera directement la qualité du produit.

Le Lean Management reste un point de départ, mais il ne doit pas cacher la remise en cause continue et surtout la complexification de la démarche DevOps dans un univers cloud hybride. DevOps doit prendre en compte les évolutions du cloud et fédérer l’ensemble des technologies d’un SI. Le cloud n’est ainsi pas le seul objectif : l’adoption de toolchains ouvertes permettant d’être multi processus d’intégration et multi processus de déploiement reste un enjeu essentiel pour répondre à l’hybridation. Cela passera par la standardisation des processus avant leur unification tel que nous pouvons le voir au travers des initiatives de modernisation des toolchains pour le mainframe.

Le dernier élément lié à DevOps : les bénéfices apportés par la culture du partage contribue à l’automatisation de la connaissance du SI. Tant par la mise en place de bons indicateurs au niveau de l’entreprise que par la gestion et le maintien des cartographies à jour de ce qui existe dans le système d’information. En effet si DevOps est le lien entre les changements issus des Devs et la stabilité gérée par les Ops alors l’automatisation de cette cartographie et le partage avec l’ensemble du SI est un graal à atteindre pour aboutir à un DevOps glissant vers une gestion s’appuyant sur l’intelligence artificielle pour ne pas la limiter au « ChatOps ».

Une dernière remarque : mon expérience de la transformation DevOps m’a permis de constater qu’elle ne se fait pas en un jour. Un point m’a paru essentiel : une transformation DevOps qui ne part pas de l’adhésion des Ops et de la production ne fonctionne pas. Il est important dans la transformation que le management de l’Ops soit le plus fédérateur possible. Les initiatives que j’ai vues partir des études ou du métier pour imposer une démarche DevOps n’ont pas abouti et se sont limitées aux premiers piliers.

N’hésitez pas à me contacter  pour échanger sur ces sujets DevOps, c’est toujours avec passion que je confronte les expériences. « Keep CALMS and Adopt DevOps !»

Pour nous rejoindre, quelques liens vers des offres d’emplois : Chez IBM Sur LinkedIn

Cet article a pu être rédigé grâce aux discussions et projets réalisés avec de nombreux experts :  Sébastien Alonzo, Benoit Blancard, Pierre Castel, Gilles Piedeloup, Dominique Provost¸ Vivien Rossat, Alain Zoccolella, sans oublier Jacques Zablocki ainsi que tous les collaborateurs IBM, Orange et BNPP.