Les applications ne sont jamais figées et évoluent en permanence. Pour intégrer ces changements, toutes les entreprises mettent en œuvre une démarche, dont la référence reste le processus Release Management décrit dans ITIL. Dans les plus matures, il peut même être externalisé, par exemple sous la dénomination Mise en production (MEP).Les tâches inhérentes à ces changements sont souvent  découpées entre le développement, l’intégration, l’exploitation… et alourdissent fatalement le processus, trop lent pour répondre aux attentes des métiers.

One arrow of many hitting the center of the target

Pour réduire ces délais, DevOps se propose de casser les barrières et d’aborder les problématiques de la mise en production et de l’exploitation dès le développement. Mais DevOps est appliqué le plus souvent sur de nouvelles applications, développées avec des technologies récentes et opérées dans le cloud. Qu’en est-il des applications legacy, dont la gestion, très optimisée, a généralement trouvé son rythme de croisière ? A-t-on vraiment intérêt à bousculer cette maîtrise, et si oui, comment le faire avec succès ?

  1. L’éligibilité à DevOps

Avant d’ordonner le branle-bas de combat DevOps, revenons à sa motivation première : aller plus vite dans l’intérêt des métiers. Or, pour quantité d’applications legacy, le time to market n’est pas un enjeu capital. Leur stabilité, si ! Non seulement engager une transformation DevOps autour d’une application de paye ou de reporting financier n’apporterait que des bénéfices marginaux aux utilisateurs, mais ce serait faire courir des risques énormes à l’entreprise. En amont de tout projet DevOps sur le legacy, il demandez-vous si le bénéfice escompté vaut réellement le risque et l’investissement d’une transformation de ce qui fonctionnait bien jusque-là.

  1. DevOps n’est pas (forcément) un levier d’économies

Gardons à l’esprit que DevOps permet avant tout d’aller plus vite. Pas de faire moins cher. S’il est possible que le passage à DevOps engendre des économies, ce n’est pas systématique. Par ailleurs, ce calcul financier doit être réalisé sur l’ensemble de la chaîne de valeur : c’est le métier, utilisateur de l’application qui doit estimer que l’accélération de la mise en œuvre des évolutions lui sera bénéfique. C’est donc à lui, d’une part, de le démontrer et, d’autre part, d’assumer les éventuels surcoûts que cela induira. Pour l’IT, c’est là l’un des aspects les plus délicats des projets DevOps car elle se retrouve souvent tiraillée entre des demandes antagonistes : réaliser des économies d’un côté et transformer ses services de l’autre.

  1. Créer le nouveau standard

Une fois le bien-fondé de la transformation DevOps démontré et son périmètre arrêté, vous devez rapidement créer le nouveau processus d’intégration applicative vers lequel seront versées les applications éligibles. Ce standard opérationnel DevOps doit établir l’outillage, les méthodes, les organisations et les compétences qui seront mis en œuvre de façon systématique. Les standards s’imposent alors de plus en plus clairement, et vos choix se simplifient. En vous concentrant sur des outils cohérents avec l’environnement legacy, la technologie n’est plus un problème.

  1. Deux modes de fonctionnement, une seule culture

Cette cible DevOps doit aussi rester cohérente avec vos méthodes traditionnelles « non DevOps ». Le risque, en effet, est de créer deux entités parallèles au sein de la DSI, cloisonnées, irréconciliables et susceptibles d’engendrer des coûts superflus et des complications managériales. Malgré des approches différentes, vous devez maintenir une porosité entre vos équipes. Conserver cette culture unique est aussi un moyen de valoriser les Ops qui peuvent parfois ressentir DevOps comme une revanche du développement et un reniement de leur rigueur. Rigueur sans laquelle votre entreprise aurait pu – et pourrait encore – connaître de coûteux déboires.

  1. Lentement mais sûrement

DevOps est une profonde transformation dans la mesure où toutes les dimensions opérationnelles sont remises en cause : outillage, organisation, processus, compétences, culture. À ce titre, elle représente un investissement lourd et risqué, notamment du point de vue humain. Vous devez veiller à l’acculturation et au développement des compétences, tant pour les Dev que pour les Ops, car la volonté souvent affichée d’aller trop vite peut avoir de lourdes contreparties.

Mener des projets pilotes est aussi essentiel car ils impulsent une dynamique et une courbe d’apprentissage, encore faut-il encadrer et limiter l’expérimentation de manière à pouvoir en tirer et en digérer les enseignements.

Pour le legacy, l’adoption de DevOps, de ses outils et de ses principes, doit se faire lentement pour se faire sûrement. C’est le modeste prix à payer pour que la stabilité, la sécurité et les performances de votre système d’information ne soient pas les victimes collatérales d’une course irraisonnée à l’agilité.

Julien Dumazer est Directeur Général Adjoint de l’activité Econocom Services pour la région Sud, il définit la stratégie autour des métiers d’infogérance (utilisateurs et de production) et applicatifs. Julien pilote l’ensemble des agences régionales (Bordeaux, Toulouse, Marseille, Lyon, Grenoble), regroupant plus de 1400 collaborateurs.

DUMAZER Julien