Tribunes

La révolution DevOps : cinq questions incontournables du DG au DSI

Les géants américains de l'internet ont popularisé une nouvelle organisation des DSI, appelée DevOps, qui améliore significativement la réactivité et la qualité de l'informatique, et pose ainsi un nouveau défi aux entreprises et aux DSI traditionnelles qui ont emprunté d'autres voies. Voyons cinq questions que tout DG ne manquera pas de poser prochainement à son DSI sur ce sujet d'importance.

PublicitéComment caractériser DevOps ?

DevOps est un mot formé de la contraction du mot « développement » et du mot « opérations » qui correspond au mot français « production ». DevOps est une approche qui prône le rapprochement des équipes de développement informatique et de production dans le but d'améliorer la réactivité des DSI et de diminuer la durée comprise entre la demande de la modification d'un service IT et sa mise en ligne.

Conformément aux préceptes du lean management dont il est issu, DevOps s'attaque aux gaspillages que génèrent les délais de mise à disposition des infrastructures, ceux causés par la mise en production des applications ainsi que ceux induits par un processus de "changement en production" beaucoup trop bureaucratique. Le manque de réactivité des Opérations conduit à présenter cette structure comme un silo fermé sur lui-même. Ce cloisonnement serait dû au fait que les opérations sont missionnées sur la « stabilité» de la production, alors que les études sont incitées, au contraire, à produire de nombreuses «évolutions» de manière « réactive ». Les partisans de DevOps soulignent enfin la focalisation des études sur le service quotidiennement en ligne, alors que les productions seraient restées sur une vision basée sur les applications qui distingue leur développement (le build) et leur exploitation (le run).

DevOps est donc prôné par les « Dev ». Qu'en disent les « Ops » ?

Les productions expliquent que si leur attachement à la stabilité est bien réel, il faut l'entendre comme la stabilité du fonctionnement des services IT en production, et pas du tout comme la stabilité du périmètre ou du nombre de ces services !
La limitation des dates autorisées de mise en production s'explique moins par le besoin de tranquillité des productions, qui voient au contraire leur charge d'installation concentrée sur quelques jours, que par l'objectif d'obtenir une période de rémission suffisante dans les défauts de fonctionnement des services IT après les corrections consécutives à la dernière vague d'installation ! Les livraisons de logiciels inaptes à la mise en production mettent les exploitations en défaut par rapport aux engagements qu'elles prennent quant à la disponibilité des services IT et expliquent la réticence des exploitants à une augmentation de leur fréquence.
Les productions récusent aussi bien le parallèle implicite entre études/production et Build/Run que celui déjà décrit entre études/production et réactivité/stabilité.

La production n'est pas plus l'entité exclusivement en charge du « Run », que les études ne sont celles en charge du Build. En effet, les études participent à l'exploitation des services à au moins deux titres : elles sont impliquées dans le diagnostic et la résolution d'incidents lorsqu'ils touchent la couche applicative et mènent souvent des vérifications quotidiennes du bon fonctionnement des traitements critiques pour le compte des métiers.
Les études ne sont pas davantage l'organisation exclusivement en charge de la fabrication des services (Build), puisque les productions créent, à l'occasion des mises en production, les paramétrages qui permettent aux logiciels proprement applicatifs d'utiliser les outils d'infrastructure : paramétrages des serveurs d'application, des ordonnanceurs de traitements, des outils de sauvegarde ou d'archivage, de surveillance, etc.

PublicitéPour des raisons historiques liées à la sanctuarisation des ressources nécessaires à la fourniture des services aux métiers, les productions traditionnelles sont constituées pragmatiquement des seuls personnels habilités à intervenir sur les machines de production.
La mission de la DSI, qui consiste à fournir des services alignés sur les besoins métiers et dotés d'une sûreté de fonctionnement correcte, ne coïncide donc pas avec le découpage actuel entre département études et productions : Si les études sont seules en charge de l'alignement fonctionnel, la sûreté de fonctionnement de la couche applicative implique assurément aujourd'hui les deux structures.
L'intérêt de DevOps est de résoudre très différemment la difficulté que cette double mission représente.

Au-delà de la coopération entre études et production, le principe «you build it, you run it » n'est-il pas une définition organisationnelle plus radicale de DevOps ?

L'organisation habituelle des DSI bute sur l'amélioration des processus situés à l'articulation des études et de la production, ce que le standard des bonnes pratiques ITIL appelle la « transition des services » : gestion des mises en production (release management and deployment), gestion des changements, test et validation des services.
DevOps résout cette difficulté par le changement radical de l'organisation de la DSI. La solution utilisée par les géants de l'internet est basée sur un principe simple, exprimé par Werner Vogels, CTO d'Amazon : "We have this principal of 'you build it, you run it. You are responsible for what the customer sees, in short." Dès lors, une seule équipe fabrique le logiciel et l'exploite dans la durée. La mission majeure de la DSI étant de fournir des services alignés sur les besoins du métier et fiables, l'organisation des équipes se fait tout simplement par ensemble de services IT ou groupe d'applications.

La promesse tenue de réactivité repose sur le pivotement de l'organisation d'une spécialisation par les ressources : machines de développement d'un coté et de production de l'autre, vers une spécialisation par couches, infrastructure d'un coté, puis paramètres de l'application en production et application de l'autre.
Un aspect particulièrement vertueux de cette organisation est que la responsabilité de la sûreté de fonctionnement des applications se trouve affectée à ceux qui ont le moyen de la construire. L'équipe applicative DevOps va pouvoir fiabiliser l'installation des corrections des services IT, modifier les procédures de reprises automatiques en cas d'incidents, mettre en place des tableaux de bord temps réel de suivi du volume d'activité et de bon fonctionnement, et même architecturer l'application pour la rendre exploitable.
L'équipe a à la fois la mission d'exploiter les logiciels dans la durée et les moyens de rendre leur fonctionnement sûr.

DevOps serait-il la manifestation d'une autre façon de « faire de l'informatique » dans l'entreprise au-delà même d'un changement d'organisation des DSI ?

Le bouleversement DevOps des DSI ne s'arrête pas au pivotement de l'organisation d'une approche par machine, vers une approche par couche logicielle : Les équipes applicatives DevOps constituent non seulement un basculement de « spécialisation » organisationnelle, mais aussi un changement radical du « mode » d'organisation.
Selon le vocabulaire Lean, DevOps revient à organiser les équipes en Unités Autonomes de Production qui s'opposent au mode « ligne ». Les nouvelles équipes applicatives agiles regroupent en effet les différentes activités réparties jusque-là linéairement sur différentes équipes dans le modèle en cascade. Remarquer que DevOps correspond à un mode d'organisation en atelier intégré incite à redécouvrir le coté taylorisé du fonctionnement des DSI actuelles.
Le mode ligne en vigueur se caractérise par un processus de développement séquentiel, de l'expression des besoins, au codage, test, mise en service jusqu'au décommissionnement applicatif. Il s'agit bien là d'un modèle fordiste, où chaque activité successive est confiée à un acteur différent.

L'optimisation Lean de ce modèle conduit à la mutualisation de chaque étape pour toutes les applications, puis à la mise en place d'outils de workflow de façon à réaliser le convoyage du logiciel, d'un poste de travail à l'autre et à optimiser capacités de traitement et flux de travail, comme pour tout autre processus industriel ou administratif.
Globalement dans cette approche économique et méthodologique, la contribution des informaticiens internes est limitée, la connaissance des logiciels est diffuse et renouvelée, le recours à l'externalisation recherché et l'investissement technique réduit à son minimum.
Le modèle DevOps est l'exact opposé de ce paradigme. Il se développe dans les sociétés telles qu'Amazon où l'entreprise est perçue par ses clients à travers son informatique, inséparable du modèle d'affaire de l'entreprise. Amazon est autant une société de haute technologie qu'un logisticien des petits colis. L'atelier flexible réunit des informaticiens aux compétences multiples, vise l'intelligence du produit, la réactivité et la proximité des métiers. L'unité autonome de production traite durablement l'ensemble des besoins d'évolution du service IT dont elle s'occupe en continu.

La performance est obtenue par une ingénierie de haut de gamme et l'investissement dans les outils de développement aux mains d'ingénieurs de hauts niveaux. L'engagement collectif dans la durée contribue à la motivation des ressources dont le coût unitaire n'empêche pas du tout la rentabilité d'un modèle d'une très grande productivité tant globale qu'individuelle et permet le développement rapide de logiciels fiables, alignés sur les besoins des métiers.
DevOps dans sa déclinaison organisationnelle radicale apparaît comme un nouveau paradigme des technologies numériques en entreprise.

Comment introduire DevOps dans les entreprises traditionnelles ?

Paradoxalement, bien que le fonctionnement actuel et l'approche DevOps diffèrent radicalement, la trajectoire d'adoption de DevOps est assez claire. La transformation s'effectue par application, tout d'abord en fournissant l'infrastructure nécessaire sous forme de service.
Le pas à franchir ensuite pour respecter la règle DevOps qui confie la sûreté de fonctionnement des applicatifs aux anciennes études est petit. En effet, dans beaucoup de DSI, la production est un silo poreux où les personnels des études disposent de droits en lecture sur les machines de production. Sur ce point, le passage en DevOps s'apparente à une opération vérité.

La question des mises en production est plus sensible. La MEP est l'activité de fabrication (Build) qui revient à la production, du fait de ses droits sur les machines dans l'organisation actuelle. Le salut réside dans l'automatisation des installations qui présente deux avantages majeurs. Non seulement elle augmente la réactivité et réduit les risques de la mise en ligne, mais elle diminue aussi l'antagonisme entre les structures « Dev » et « Ops » : la question de savoir qui réalise l'action perd de sa charge conflictuelle dès lors que plus personne ne s'y consacre.
Enfin, rien n'empêche la cohabitation durable des deux modèles sur des sous ensembles distincts du système d'information de l'entreprise. La coexistence constitue déjà souvent la règle, bien qu'à petite échelle. Le bon équilibre à atteindre est un sujet d'architecture d'entreprise à traiter de façon pragmatique.

Quelle que soit la cible retenue, et bien que la transformation suscitée par DevOps puisse être progressive, la tâche d'adaptation qui attend les DSI s'annonce considérable et passionnante.

Article rédigé par

Alain Sacquet, Consultant et auteur
Alain Sacquet est ingénieur de l'école Centrale Lille et a consacré sa carrière à la direction de programmes et à l'architecture d'entreprise. Il crée avec Jérôme Gautier le cabinet Marte Conseil en 2000 pour combiner les meilleures expertises de transformation organisationnelle et de management avec l'ingénierie la plus pointue. Il travaille aujourd'hui chez Timspirit.

Alain Sacquet est l'auteur de « Mettre en oeuvre DevOps » publié chez Dunod.