Chapitre 2 : DevOps dans la transformation digitale

La transformation digitale est la réponse de chaque entreprise face au défi que représente l’essor des technologies numériques. Concrètement cela suppose la dématérialisation de ses processus, évolution centrée sur une innovation à laquelle participent des concepts et des solutions technologiques tels que l’agile, le cloud, le big data, le machine learning et la mobilité.

Cette transformation est efficace si elle s’inscrit dans une démarche globale dont DevOps peut être la clé…

DevOps est agile, c’est un fait, mais il ne suffit pas de l’affirmer, il faut le comprendre.

Pour entendre que DevOps est agile, il faut comprendre ce qui se cache derrière le mot agile. Aujourd’hui il a été utilisé dans tellement de contextes différents que sa véritable signification s’est diluée dans la conscience générale.

La dilution et l’incompréhension de l’agilité ont pour conséquence d’affecter son image au sein de l’entreprise et de complexifier son adoption.

Prenons l’exemple d’une direction générale qui décrète que le groupe doit désormais être agile sans plus de précisions. En réalité, cette direction ne sait pas exactement quelle signification mettre derrière le mot agile. Imaginez maintenant l’écart de compréhension que ce flou va engendrer parmi les directions, les équipes et les salariés.

Finalement, le retour sur investissement semble inexistant pour les principaux intéressés.

L’agilité a été perçue comme une notion marketing apparentée à une coquille vide.

Il est vrai que le mot agile peut avoir plusieurs sens selon le contexte où il est utilisé :

• Une organisation peut être agile quand elle est prête à se remettre en cause en cycles d’amélioration continue et à changer sa hiérarchie et ses règles de management périmètre après périmètre. Le changement n’est plus subi mais perçu comme générateur d’efficacité dans chaque département de l’entreprise. Cette vision de l’agilité est relativement neuve, centrée sur les comportements, les ressources humaines et l’organisation hiérarchique d’une entreprise.

• Le processus de R&D, l’innovation et le marketing produit peuvent être agiles. C’est le cas notamment de la conception de nouveaux produits innovants ou des méthodes marketing de recherches de signaux faibles annonciateurs de changement pour l’entreprise. L’iPhone ou l’iPad sont souvent cités en exemple de ces produits conçus de manière agile. Le Lean Startup est une méthode agile qui formalise un certain nombre de concepts qui se prêtent à cette thématique.

• L’outil informatique lui-même peut être agile dans sa conception et son architecture. L’apport des démarches d’architecture orientée services (voire microservices) avec la décorrélation complète du moteur d’exécution applicatif et des interfaces utilisateurs contribuent à l’atteinte de cet objectif. La mobilité, les nouveaux devices que ce soient les smartphones, les tablettes ou les objets connectés, tirent directement parti de cette approche.

• Enfin le processus de gestion des projets et des hommes autant que le run peuvent être agiles. C’est dans ce cadre que l’on exploite pleinement les méthodes de projet agiles ou la démarche DevOps, en s’appuyant sur un processus agile de bout en bout, autrement dit du besoin client à la livraison client.

On voit bien que la signification du mot agile dépend du contexte dans lequel on l’utilise. Mais on comprend également que l’agilité s’appuie sur des valeurs communes qui s’appliquent totalement à une démarche DevOps. Et ces valeurs ne se résument pas au manifeste agile qui est le socle commun de ces méthodes, ce serait bien trop limité. Pour pouvoir s’appliquer à la fois aux développements, à l’infrastructure, à la conception de produits ou encore au marketing, ces valeurs se doivent d’être plus étendues.

Nous sommes dans une démarche itérative, incrémentale et collaborative, nous sommes dans une démarche agile, quels que soient le contexte ou le domaine d’application.

DevOps respecte de manière tout à fait évidente les valeurs fondamentales de l’agilité, et s’inscrit dans la filiation des méthodes agiles traditionnelles.

Lorsque les méthodes agiles traditionnelles sont correctement mises en oeuvre, elles génèrent souvent une forme d’enthousiasme auprès des utilisateurs et des populations métiers.

Malheureusement, l’enthousiasme initial de l’utilisateur se transforme vite en frustration quand la coopération des services de développement et de gestion des opérations n’est pas agile et que les différents services informatiques ne collaborent pas ensemble dans la direction attendue par les métiers.

L’idée de DevOps est de pousser les démarches agiles jusqu’aux équipes de production en passant par une collaboration agile basée sur la confiance. DevOps hérite pleinement de la culture agile des méthodologies projets pratiquées depuis des années.

DevOps n’est pas agile seulement parce qu’elle respecte les valeurs fondamentales de l’agilité, elle est agile parce que, comme les autres méthodes à succès, elle apporte sa pierre dans l’édifice des bonnes pratiques liées à l’agilité :

• Scrum est la méthode agile la plus populaire aujourd’hui. C’est effectivement la démarche la plus séduisante car elle se concentre sur l’aspect managérial des hommes. Sa similitude avec le rugby qui en a inspiré le nom est significative : on parle d’équipe et d’esprit d’équipe avant tout. Les hommes, l’équipe et la responsabilisation des membres de l’équipe sont les maîtres mots.
• XP Programming est la méthode agile la plus en vogue auprès des ingénieurs. En effet, elle introduit les pratiques d’ingénierie agile les plus abouties et bénéficie d’une réputation sans faille concernant la qualité des produits logiciels développés.
• Agile UP est la méthode agile partageant le plus de concepts avec les méthodes classiques. Cette méthode est en effet une évolution du Rational Unified Process d’IBM puis du Unified Process avec Ivar Jacobson notamment pour y introduire les principes de l’agilité. En conséquence, c’est aussi la méthode agile la plus facile à introduire auprès d’équipes évoluant depuis des années avec des méthodes classiques.En d’autres termes, agile UP est la méthode agile la mieux adaptée à la conduite du changement aujourd’hui.
• Lean est une méthode issue du monde industriel dont les principes se sont rapidement imposés au sein du monde agile. La recherche de l’industrialisation et de l’optimisation toujours dans une optique de processus orienté client est fondamentale. Les principes de cette méthode sont, comme nous l’avons vu, au coeur de la culture DevOps.
• Lean Startup est une méthode dérivée du Lean orientée pour les entrepreneurs autant internes qu’externes à une entreprise. Elle vise à rationaliser l’état d’esprit innovant des start-up tout en supprimant les causes d’échecs et de gâchis. Cette approche scientifique orientée produit se combine également très bien avec une démarche DevOps orientée IT.
• Kanban est une méthode assimilée aux méthodes agiles, bien que non itérative de prime abord. En réalité, cette méthode combine plusieurs itérations de cérémonies parallèles couplées à un backlog à flux tendu. Kanban se concentre sur l’industrialisation du processus agile au moins sur son aspect développement.

Il existe d’autres méthodes agiles, mais nous nous sommes limités ici aux plus populaires. Dans toutes ces approches, de nombreux aspects différents de l’agilité sont couverts : le management des hommes (Scrum), la qualité du logiciel (XP), l’adoption du changement (agile UP), l’industrialisation (Kanban) et l’optimisation (Lean) du processus agile.

Cette énumération ne couvre pas un aspect essentiel : la collaboration. C’est le point fort de DevOps qui se concentre sur les aspects de collaboration du processus agile, du besoin client à la livraison au client. DevOps reprend donc les principes de l’agile et les complète.

L’attraction qu’exerce le cloud computing sur l’industrie des technologies de l’information rend plus impérieuse encore la nécessité pour les développeurs de logiciels et les responsables des opérations de collaborer, pour la création ainsi que l’exploitation d’applications et de services innovants et massivement scalables.

Le cloud offre aujourd’hui la possibilité de créer et déployer de nouvelles applications et leur infrastructure sous-jacente en quelques minutes. Toutefois de multiples changements sont requis afin d’en tirer le meilleur parti : définition des modèles de nouveaux services, automatisation de leur déploiement, gestion des configurations et des mises à jour, monitoring des performances, remontée d’alertes, et enfin et surtout intégration des processus de développement.

Tout cela n’est pas sans incidence sur le métier du responsable opérationnel. À l’ère du cloud, celui-ci devra savoir exploiter au mieux les capacités de virtualisation mises à disposition dans les data centers en déléguant totalement les opérations d’infrastructure qui jadis étaient de sa responsabilité.

Dans un premier temps, l’évolution vers le cloud s’est traduite par une séparation des responsabilités entre la gestion du logiciel et des données, de celle de l’infrastructure physique. Grâce à la virtualisation des serveurs, du stockage et du réseau, les systèmes physiques sont devenus totalement découplés des éléments numériques qu’ils hébergent.

Mais aujourd’hui, la machine virtuelle qui, après le serveur, était devenue peu à peu l’élément de référence pour le déploiement, est en train de céder la place à l’application elle-même.

En effet, avec le cloud, il faut revoir la façon dont les applications sont conçues, produites, déployées et mises à jour. Mais comment gérer le cycle de vie complet d’une application, avec la fourniture de ses ressources, la gestion de la configuration, le déploiement, les mises à jour logicielles, la supervision et le contrôle d’accès ?

Cette évolution vers un modèle centré sur l’application a entraîné une accélération de la mise à disposition de mécanismes d’automatisation de provisioning, de configuration, voire de l’orchestration des services proposés par les différents acteurs du cloud. Les plateformes cloud ont donc elles aussi été adaptées pour faciliter l’application de ce nouveau modèle.

Les services génériques proposés répondent aux multiples scénarios applicatifs cibles. Aussi doivent-ils offrir le niveau de configuration et d’extensibilité requis, mais surtout, ils doivent être exposés par une API. En conséquence, l’infrastructure du cloud, à l’instar de l’application, devient dépendante du code. Les descriptions de configuration peuvent donc être fournies aux services cloud via des API bien définies. Elles sont directement corrélées aux profils de services IaaS et PaaS que propose le cloud afin de provisionner et configurer les services cibles et leurs différentes ressources connexes. En conséquence, la composante infrastructure as code de DevOps, que nous avons déjà évoquée, devient incontournable lorsqu’il s’agit du cloud.

Avec le cloud, l’infrastructure est de moins en moins sous le contrôle des directions informatiques et la probabilité d’interdépendances de services liés à des SLA différents devient de plus en plus forte. Toute solution d’échelle significative étant sujette au dysfonctionnement, les architectures doivent évoluer vers un modèle FailSafe afin de garantir l’évolutivité, la disponibilité et la fiabilité du système. Cette évolution se traduit par de multiples activités au cours de la phase de conception :

• Découper l’application en composants fonctionnels en établissant des niveaux de priorité vis-à-vis de la criticité métier et du coût.
• Définir un modèle décrivant le comportement de l’application attendu en production (variations de charge planifiées et facilités par les modèles d’autoscaling proposés par le cloud…).
• Définir un modèle de disponibilité pour chaque composante de l’application et hiérarchiser les étapes de remédiation selon une classification de modes de défaillance établie en amont.
• Identifier les points et les modes de défaillance en adoptant, comme nous l’avons vu précédemment, une démarche d’analyse et de modélisation de la résilience des services de l’application.

Comme on peut le constater, ces éléments sont susceptibles d’impacter aussi bien les développeurs que les équipes de gestion opérationnelle.

Big data et machine learning peuvent également contribuer à la mise en oeuvre d’une démarche DevOps. Ces deux notions ne sont pas nécessairement liées mais sont complémentaires.

Le big data vise à collecter un grand volume de données (individuellement potentiellement petites) ou des données volumineuses (de l’ordre du péta-octet), ayant un fort potentiel de variabilité ou de vélocité, à les stocker et à les rendre exploitables. Le big data ne cible pas nécessairement l’analyse prédictive des données. Rendre la donnée compréhensible est un but suffisant dans un premier temps.

Le machine learning vise à exploiter des données pour les analyser avec une approche scientifique et statistique. Il est important de noter que le machine learning est une discipline d’intelligence artificielle et en ce sens le but de l’analyse est clairement de faire des prévisions pour pouvoir prendre des décisions. Pour faire ces prévisions, il n’est pas toujours nécessaire de faire du big data, autrement dit de disposer d’une quantité astronomique de données.

En 2012, un statisticien nommé Nate Silver a pu prédire avec succès les résultats de l’élection américaine dans tous les états en partant de données pesant à peine 200 ko. Autre exemple, en 2014 la société française Data Publica propose un découpage pour la réforme des régions basé sur un algorithme intelligent utilisant uniquement des données fournies par l’INSEE pesant à peine 1,7 Mo. Ces exemples mettent en lumière une notion fondamentale que tout praticien de business intelligence se doit de connaître : la pertinence des données.

Une démarche DevOps est tributaire de la collecte de données, aussi bien concernant l’usage par l’utilisateur du produit (télémétrie) que dans l’aspect opérationnel de la démarche (monitoring). En ce sens et de par son aspect agile, l’application rigoureuse des principes DevOps permet de limiter la collecte uniquement aux données pertinentes.

L’application des notions d’expérimentation et d’apprentissage permet de continuellement remettre en cause ce choix des données collectées, la pertinence pouvant évoluer au cours du temps.

La collecte de données pertinentes ne préjuge en rien de la quantité de données à collecter et en cela les principes du big data s’appliquent pleinement pour réussir à exploiter ces données. Un exemple courant est l’exploitation issue des logs des différents outils de la chaîne de déploiement automatisée DevOps.

Mais l’aspect le plus intéressant reste le lien possible entre les données collectées sur l’usage fait par l’utilisateur du produit (télémétrie) et les modèles de machine learning. En effet, les modèles prédictifs de plus en plus évolués liés à cette discipline pourraient anticiper demain les futurs besoins des utilisateurs en se basant sur leurs usages actuels.

Un outil puissant pour inventer les produits de demain…

La mise en oeuvre de solutions liées au big data et la définition des modèles de machine learning adaptés au cycle de développement logiciel viennent enrichir DevOps qui bénéficie ainsi de l’expérimentation et du traitement des données les plus pertinentes.

Si les grandes tendances de la transformation digitale s’apparentaient à une famille, DevOps et la mobilité seraient certainement frère et sœur tant cette démarche est adaptée au monde de la mobilité. En effet, aujourd’hui le monde de la mobilité est constitué d’un modèle applicatif distribué via des magasins applicatifs : de l’iPhone à Windows en passant par Android et Mac OS X, tous les systèmes possèdent désormais leurs stores qui deviennent de plus en plus le lieu privilégié par les utilisateurs pour s’approvisionner en applications.

Ce modèle a cela de particulier qu’il est réellement hyperconcurrentiel. Les éditeurs rivalisent de créativité pour répondre aux besoins des utilisateurs et il n’est pas rare de trouver une dizaine d’applications différentes pour répondre à une de nos attentes.

Face à cette concurrence exacerbée, on pourrait croire que les applications font la course aux fonctionnalités. C’est peut-être parfois le cas, mais la clé de la réussite est en réalité l’adéquation entre la fonctionnalité offerte et notre besoin réel. Et si une chose est bien constante, c’est le changement : nos besoins évoluent régulièrement et rapidement.

L’application qui évoluera avec nous a le plus de chance de rencontrer le succès car elle aura un avantage concurrentiel constant sur son marché.

Il n’existe pas aujourd’hui des centaines de façon de faire pour réussir ce challenge imposé par les utilisateurs : seule l’agilité de bout en bout mise en oeuvre avec une démarche DevOps permet de tenir ce rythme effréné.

Mais la mise à jour et l’enrichissement continus des applications ne sont pas le seul atout d’une démarche DevOps dans le monde la mobilité. Il existe un autre paradoxe dont nous nous accommodons sans problème aujourd’hui et qui paraîtra bien incompréhensible demain : les applications mono-plateforme.

Très concrètement aujourd’hui, lorsque vous voulez utiliser votre application préférée, vous devez la télécharger trois fois en moyenne : une fois sur votre ordinateur de bureau, une fois sur votre tablette et une dernière fois sur votre smartphone. Quand cette application est bien conçue, il est possible de continuer une tâche commencée sur un autre device depuis n’importe lequel d’entre eux mais le plus souvent ce n’est pas le cas.

Les applications universelles et les environnements de travail multistations vont devenir la norme du monde informatique. L’agilité des architectures orientées services, voire micro-services, vont s’imposer par nécessité. L’avènement de ce parc applicatif moderne ne fera que renforcer nos attentes en fonctionnalités utiles et évolutives. Nous entrerons alors réellement dans l’ère de la mobilité avec toutes ses caractéristiques espérées depuis longtemps.

Les méthodes traditionnelles de gestion de projet issues de l’analogie avec le monde du BTP seront complètement obsolètes. La démarche DevOps apporte une grande partie de la solution dans ses principes mais il est absolument certain que sa mise en oeuvre évoluera grandement en même temps que la maturité du marché.

À cela on peut objecter que cette analyse s’applique seulement au monde du grand public et que le monde professionnel sera globalement préservé de ces bouleversements à venir.

S’il est vrai que le rythme d’adaptation du monde professionnel, notamment en ce qui concerne le parc applicatif interne et les progiciels, est souvent plus lent, ce serait une erreur de penser que les impacts de ces changements majeurs seront minimes pour l’entreprise.

Il y a au moins deux raisons de penser que les professionnels seront en première ligne du changement.

Tout d’abord, il est déraisonnable de croire que les murs de l’entreprise sont imperméables à une culture grand public. De la même manière que nous avons vu le phénomène BYOD (Bring Your Own Device) en entreprise, les utilisateurs vont devenir de plus en plus exigeants vis-à-vis des applications professionnelles. Celles-ci, y compris les progiciels des grands éditeurs, vont devoir répondre à des attentes à la fois d’ergonomie et de réactivité qui deviendront la norme dans le grand public.

Ensuite, il ne faut pas oublier que refuser ostensiblement ces avancées laisse une image d’archaïsme au sein de sa force de travail mais également par viralité en dehors. Au-delà de l’impact sur les ressources humaines dont les talents sont de plus en plus disputés aujourd’hui, cela n’est pas de nature à créer un avantage concurrentiel sur son marché. Or, l’ergonomie et le design alliés à la réactivité sont les principaux prérequis à développer pour espérer acquérir un avantage concurrentiel sur son marché.

Pour conclure, il est certain que les exigences d’un monde mobile poussent tous les marchés dans tous les secteurs à adopter un jour une démarche DevOps. Il faut néanmoins être pragmatique et réaliste : toutes les démarches DevOps ne se ressembleront pas, elles dépendront du marché, du contexte, de la taille de l’entreprise, de sa culture et de ses enjeux. Il paraît évident que certains secteurs mettront plus de temps que d’autres à percevoir la nécessité de cette transformation.

Pour certaines entreprises, cette adoption se fera à marche forcée ; pour d’autres ce sera plus en douceur. Mais il paraît évident que pour survivre toutes passeront par là. On peut faire l’analogie avec l’agilité ou d’autres sujets de transformation digitale. On l’a vu,

DevOps est complémentaire mais également indispensable au succès de ces démarches.

Initialement et principalement destiné aux designers, le design thinking est une méthodologie de créativité inventée au milieu du siècle dernier. Cette méthode préconise de situer en amont des projets pour identifier les besoins des utilisateurs, voire les anticiper, en s’appuyant sur trois à sept étapes selon les versions autour desquelles il faut itérer, sans forcément suivre un ordre préétabli.

Les principales étapes de cette méthodologie sont :

• Empathy. Au cours de cette étape, l’objectif est de ressentir l’audience cible du service, pressentir ses plaisirs et ses frustrations pour mieux percevoir ces désirs. Dans les faits, une rencontre et des interviews sont très utilisées.
• Define. Lors de cette étape, il faut définir et affiner ses objectifs en fonction de la perception empathique que l’on a acquis. Les enjeux sont liés aux objectifs et groupés par audiences pour toujours être au plus proche à la fois du besoin et du désir de son audience cible.
• Ideate. C’est la phase de divergence de la méthode. Elle cherche à trouver des idées créatives, simples et intelligentes pour répondre aux besoins et aux désirs de l’audience cible. Cette phase itère de manière très régulière avec la suivante pour également diverger sur les contraintes ventuelles qui peuvent être détectées dans les phases suivantes.
• Prototype. C’est la phase de convergence de la méthode. L’objectif est ici de construire des solutions démontrables à partir des idées retenues lors de la phase précédente, de relever les difficultés ou contraintes qu’elles peuvent représenter et de définir les solutions appropriées pour pouvoir ensuite les tester.
• Test. Cette étape est celle de l’expérimentation auprès de l’audience cible, de l’apprentissage et de la rétrospective. Elle permet de confronter à la réalité l’ensemble des hypothèses retenues et éventuellement de pivoter pour reprendre un terme cher au Lean Startup dont la philosophie est très proche.

Si l’ensemble des méthodes d’innovation ne suivent pas nécessairement ces étapes, elles se retrouvent toutes autour des principes de divergence et de convergence centrées sur l’utilisateur. Nous pouvons facilement transposer les principes du design thinking sur la grande majorité des démarches d’innovation connues à ce jour.

Les méthodes d’innovation sont itératives et collaboratives par nature. Il paraîtrait absolument contre-productif, pour ne pas dire impossible, de procéder différemment pour réussir à aboutir à des solutions viables. Or les principes d’itération et de collaboration sont deux des trois principes fondamentaux de l’agilité.

Pour être complètement dans les valeurs de l’agilité, il est important d’avancer par incrément. Les méthodes d’innovation ne sont pas réfractaires à l’incrémentation, d’autant plus que la complexité des produits et services inventés de nos jours rend quasiment indispensable une avancée par petit pas.

En dehors des innovations avec un périmètre relativement modeste, la grande majorité des inventions résultantes des méthodes d’innovation sont itératives, incrémentales et collaboratives, et sont donc des méthodes agiles à part entière.

Ainsi, il n’est pas surprenant de voir par exemple le Lean Startup reprendre une grande partie des principes des méthodes d’innovation étant elle-même à la croisée des chemins avec les méthodes agiles de gestion de projet plus classique.

Et si les méthodes d’innovation sont agiles, elles sont dès lors d’autant plus complémentaires avec DevOps.

Si les méthodes d’innovation et DevOps sont agiles, elles n’ont pas les mêmes objectifs. Les premières visent à inventer des usages, des services et des produits. DevOps aide à les réaliser et à les mettre en oeuvre rapidement et efficacement. Cependant, l’innovation n’étant jamais statique et le design thinking préconisant d’itérer en permanence, les solutions mises en oeuvre ne peuvent également rester statiques et doivent en permanence s’adapter. Mieux encore, DevOps doit permettre de mieux entendre l’utilisateur pour alimenter de manière efficace le processus de création et d’innovation continue.

La complémentarité devient évidente. Les méthodes d’innovation alimentent les solutions à réaliser selon une démarche agile, et DevOps optimise sa concrétisation en réduisant au maximum les temps de mise en production et en maximisant ainsi les résultats de l’expérimentation.

Le feedback continu, inhérent aux méthodes DevOps et à ses mécanismes de collaboration, permet d’alimenter en permanence le processus de création des méthodes d’innovation afin de l’optimiser.

En résumé

Le digital est aujourd’hui au coeur de la production de valeur de toutes les entreprises. 
En ce sens, nous pouvons dire que toutes les entreprises aujourd’hui sont des entreprises digitales quel que soit le secteur d’activité ou la chaîne de valeur.

La transformation digitale vise à rendre plus agile et plus collaboratif leur informatique et leur technologie tout en étant en capacité permanente d’innover rapidement. C’est exactement l’objet d’une approche DevOps au travers d’une démarche de collaboration optimisée.

Selon une étude IDC datant de novembre 2015 et portant sur plus de 200 entreprises françaises, dont plus de la moitié a plus de 1 000 salariés, 52 % des entreprises considèrent DevOps comme le principal levier de leur transformation numérique.

Selon la même étude, les entreprises ayant mis en place une démarche DevOps bénéficient d’une nette amélioration de la collaboration entre les équipes, y compris les équipes métiers, d’une amélioration de la satisfaction client, d’un gain en qualité important, d’une vraie accélération des déploiements logiciels et d’une baisse du ratio dépenses/valeur.

DevOps est un élément clé de la transformation numérique des entreprises car complémentaire de concepts et de solutions qui accélèrent leur capacité de réponse à l’essor des technologies numériques.

DevOps respecte et étend les pratiques des méthodes agiles en s’appuyant sur ces trois grands principes : collaboration, itération et incrémentation. DevOps les met en application jusqu’au monde du support et de l’infrastructure et de la production.

Enfin, nous pouvons compléter en nous rappelant que DevOps est un accélérateur d’adoption d’un certain nombre de grands concepts d’aujourd’hui : le cloud, la mobilité, le machine learning ou encore l’innovation.