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, posant ainsi un nouveau défi aux entreprises et aux DSI traditionnelles qui ont emprunté d’autres voies.
Comment répondre aux cinq questions-clés qui ne manqueront pas d’être posées aux DSI ?
1. Qu’est ce que 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.
Deux visions à réconcilier
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 en seraient restées à une vision basée sur les applications qui distinguent leur développement (le Build) et leur exploitation (le Run).
2. DevOps est donc prôné par les « Dev ». Mais qu’en disent les « Ops » ?
Les équipes de production 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 équipes de production, 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 équipes d’exploitation 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.
Les missions de la DSI handicapées par le découpage études/production
Pour des raisons historiques, liées à la sanctuarisation des ressources nécessaires à la fourniture des services aux métiers, les équipes de production traditionnelles sont constituées, logiquement, 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 production : 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.
3. 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. Dès lors, une seule équipe fabrique le logiciel et l’exploite dans la durée, selon le principe You build it, you run it. 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 ensembles de services IT ou groupes d’applications.
Une réorganisation indispensable
La promesse tenue de réactivité repose sur l’évolution de l’organisation, d’une spécialisation par les ressources (machines de développement, d’un côté, et de production, de l’autre) vers une spécialisation par couches : infrastructure, d’un côté, 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 élaborer l’architecture de 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.
4. 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 à l’évolution 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 côté 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.
Renforcer l’autonomie des équipes
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 principe. Il se développe dans les sociétés telle qu’Amazon, où l’entreprise est perçue par ses clients à travers son système d’information, 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 spécifique et l’investissement dans les outils de développement est aux mains d’ingénieurs de haut niveau. L’engagement collectif dans la durée contribue à la motivation des ressources, dont le coût unitaire n’empêche pas 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.
5. 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 équipes é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é.
Les atouts d’une automatisation
La question des mises en production est plus sensible. La mise en production 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.
Cet article a été rédigé par Alain Sacquet, consultant chez Timspirit.
Une réduction de plus de 10 % des délais et des ressources
Selon les résultats d’une enquête mondiale, réalisée auprès de 1 425 entreprises par le cabinet d’études Vanson Bourne pour CA Technologies, les gains mesurés par les entreprises françaises grâce à l’adoption de DevOps sont significatifs : elles rapportent en effet, en moyenne, une réduction de 12 % de leurs délais de commercialisation de logiciels/services, une diminution de 11 % des ressources nécessaires au développement et au déploiement de logiciels, ainsi qu’une baisse de 18 % du temps consacré à la résolution de problèmes au niveau des applications et à leur maintenance. De même, neuf entreprises françaises sur dix ayant ou prévoyant d’avoir recours au DevOps, espèrent profiter de la disponibilité de leurs applications sur davantage de plateformes, afin de s’adapter à la digitalisation du parcours des clients. Ce taux est supérieur à celui de l’Italie (76 %), s’approche de ceux de l’Allemagne (92 %) et du Royaume-Uni (96 %).
Dès lors, rien de surprenant à ce que 83 % des entreprises françaises aient prévu d’adopter l’approche DevOps au cours des cinq prochaines années (54 % d’ici 2 ans et 29 % d’ici 5 ans). Le facteur d’adoption de DevOps le plus important est la nécessité d’améliorer la qualité et la performance des applications (49 % des entreprises en France – deuxième taux le plus élevé après l’Allemagne). Viennent ensuite la nécessité d’améliorer l’expérience client (35 %) et l’adaptation de son parcours numérique : en assurant davantage de déploiements simultanés sur différentes plateformes.