Une longue tribune sur l’agilité de Clément Guillin, Beijaflore, Principal, Head of IT Strategy, Transformation & Governance. Mais détaillée.
La vie au sein d’une direction des systèmes d’information n’est pas un long fleuve tranquille… Souvenez-vous, à la fin des années 90, à l’aube du 21ème siècle, nous avons vécu la course effrénée à la rationalisation des organisations informatiques dans les grands Groupes, avec la mise en place du modèle « Client – Fournisseur » entre la DSI et les directions métiers. Poussé à l’extrême dans les grandes organisations, ce modèle « client – fournisseur » a été implémenté à l’intérieur même des DSI, entre les équipes dites de « production informatique » en charge de l’exploitation des solutions et les équipes dites « Etudes » (ou « DSI métiers »), en charge du développement des nouvelles solutions SI (les projets métiers). Ce mouvement, principalement tiré par des espoirs, souvent justifiés, de réduction de coût au travers d’une mutualisation des moyens informatiques, a généré la création d’énormes entités de Production informatique et créé une couche d’interface complexe, prenant parfois la forme d’une épaisse chape de béton étanche, entre les équipes de production et les DSI métiers. Ces entités sont devenues des entreprises à part entière, des « mammouths » au sein de l’entreprise, prenant souvent la forme juridique de GIE informatique. Si le rationnel économique est évident, on peut s’interroger aujourd’hui sur l’adéquation de ces modèles organisationnels aux besoins actuels des métiers.
La création d’organisations informatiques de moyens mutualisés a généré des fortes réductions de coûts mais induit de la rigidité sur la fonction SI
Interrogez aujourd’hui les directeurs métiers et les responsables d’entités Etudes (ou DSI métiers) sur leur niveau de satisfaction et leurs attentes par rapport à ces organisations « mammouthesques » de production informatique mutualisée. Je parle ici d’un temps que les moins de 20 ans ne peuvent pas connaître… Je ne parle pas des GAFA (Google, Amazon, Facebook, Apple), ni de Spotify, modèle d’agilité repris par de nombreuses entreprises, mais de nos bons vieux Groupes européens dont les couches de systèmes d’information se sont empilées avec les années, en partant du vieux COBOL, en passant par la découverte de l’architecture client-serveur, la mise en place d’architectures n-tiers, les langages objets, un peu de Java par-ci et du Python par-là plongeant dans les abysses de Data Lakes… Je côtoie depuis plus de 20 ans des DSI et sirecteurs métiers et quand je les interroge, tous, sans exception, me citent spontanément un besoin, leitmotiv incontournable dans ce nouvel univers de transformation digitale : l’agilité !
Certains sirecteurs métiers ou DSI métiers avouent même ouvertement remettre en concurrence la fonction informatique mutualisée de leur propre Groupe avec des services IT proposés à l’extérieur par des acteurs, souvent issus du monde du « Cloud », plus agiles et moins chers… Ils choisissent et déploient eux-mêmes des solutions agiles sans parfois même prendre la peine d’en informer leurs collègues au sein de la DSI mutualisée, de l’autre côté de la chape de béton… C’est ce qu’on appelle le « shadow IT », le cauchemar des DSI qui découvrent souvent sur le tard la façon dont ils ont été court-circuités. Au-delà des discours policés qui justifient économiquement ces GIE de production informatique mutualisée dont ils sont parfois eux-mêmes issus, très peu de ces directeurs sont pleinement satisfaits de ces organisations de moyens mutualisés, et tous citent l’agilité comme axe de progrès stratégique.
Ce mouvement tiré par les métiers et par l’offre du marché poussent les dirigeants de ces organisations informatiques mutualisées à revoir en profondeur leur modèle de fonctionnement : processus, organisations et outils, tout est à transformer vers plus d’agilité, faute de quoi les mammouths de l’informatique mutualisée ne survivront pas à l’impact de la comète de la transformation digitale…
Une première réponse pour réinjecter de l’agilité dans les organisations a été apportée par les méthodes de développement agiles, Scrum en tête, mais ces dernières s’avèrent incomplètes…
Les équipes Etudes (ou DSI métiers), pressurisées par les métiers pour mettre sur le marché des produits et services dans des délais de plus en plus courts (la fameuse réduction du « time-to-market »), ont depuis longtemps intégré des concepts d’agilité et revu en profondeur leur manière de travailler. Quelle est l’entreprise qui n’utilise pas aujourd’hui de méthodologie de développement informatique dite « agile » ? C’est un constat implacable, la quasi-totalité des organisations en charge de développement informatique utilisent aujourd’hui, sur tout ou partie de leur périmètre, des méthodes agiles : Scrum, Kanban, XP ou dérivé maison. Et celles qui ne le font pas sont en passe de le faire. Si la bonne vieille méthode du « cycle en V » reste utilisée pour les développements sur les SI hérités des couches historiques (les SI dits « legacy »), les méthodes agiles sont très largement privilégiées pour les nouveaux développements, sur de nouvelles solutions, sur des architectures modernes, de type Cloud notamment.
Si les équipes de développement (les « Dev ») sont matures en matière d’agilité, qu’en est-il du bout de la chaîne de fabrication du système d’information, à savoir des équipes regroupées dans ces usines de production mutualisée (les « Ops ») ? Force est de constater que le concept d’agilité dans ces équipes « Ops » est moins développée que dans les DSI métiers.
Mais alors si les Devs sont agiles et livrent à un rythme soutenu de nouvelles versions de SI à mettre en production et que les Ops n’ont rien revu de leur processus, organisation et outils pour supporter ce rythme… que va-t-il se passer ? Inutile d’être informaticien et les métiers l’ont bien compris car ils le subissent : tout le travail amont et les gains d’agilité des développements seront perdus ! En créant au passage de la tension et de l’irritation au sein de l’entreprise…
L’agilité dans les DSI n’est pas une petite affaire limitée aux équipes de Dev, ou aux Ops. L’agilité ne générera de gains qu’au travers une réflexion globale de refonte des processus, de l’organisation et des outils de toute chaîne de fabrication des solutions informatiques, impliquant les métiers et la DSI. Pour dépasser les clivages Etudes / Production, et souvent les enjeux de pouvoir entre Directions, cette réflexion doit s’inscrire dans une réelle stratégie d’entreprise, portée par la Direction Générale, avec une gouvernance tripartite métiers – DSI métier – production mutualisée.
Le concept de DevOps étend l’agilité à l’ensemble de la chaîne de fabrication du système d’information et le succès de sa mise en œuvre passe par un programme de transformation complet de la fonction SI
Le premier travail pour gagner en agilité a souvent déjà été réalisé. C’est la partie la plus simple. Il s’agit du déploiement des méthodes agiles dans les DSI métiers. Je ne reviendrai pas dessus, il y a pléthores de points de vue savants sur le sujet.
Le second travail, plus compliqué, consiste à rendre perméable, telle une membrane souple, la chape de béton qui cloisonne les équipes de Développement et de Production. L’idée est vieille comme l’informatique : faire travailler ensemble toutes les parties prenantes de la chaîne de fabrication d’une solution SI, à savoir les équipes Dev et les Ops. Exit la relation « Client – Fournisseur » qui peut scléroser un projet ou le syndrome de la demande d’un environnement technique incomplète ou mal formulée qui tourne en boucle des jours avant de trouver une réponse. Tout le monde se parle et avance, main dans la main, sur le même plateau, réel ou virtuel, pour une réactivité sans faille. C’est la philosophie qui se cache derrière le concept de « DevOps » sur lequel je vais revenir.
Mettons-nous à la place d’un dirigeant (DG, DSI métier ou DSI de moyens mutualisés) : si je casse la chape de béton, cette frontière entre Etudes (Dev) et Production (Ops) et que je rassemble à nouveau les équipes dans des silos métiers verticaux, comment vais-je pouvoir garantir l’optimisation de mes ressources informatiques, leur mutualisation et la cohérence de mes infrastructures informatiques au sein du Groupe ?
Faut-il dissoudre ces GIE informatiques de moyens mutualisés pour gagner en agilité ? Ce serait ruiner des années d’effort et des investissements considérables consentis pour les mettre en place alors que les gains de ces mutualisations sont bien présents et fièrement affichés : on parle en plusieurs dizaines de pourcents d’économie sur des montants pouvant aller à des centaines de millions. La réponse est bien évidemment non. Sauvons les mammouths et rendons-les agiles !
Il est possible d’ouvrir la frontière qui sépare les Dev et les Ops, sans pour autant redessiner de nouveaux organigrammes et transformer en profondeur les organisations. La clé est de redéfinir les interactions entre les équipes sans forcément modifier les lignes hiérarchiques managériales associées. C’est donc un travail principalement sur les processus et les outils associés. Au-delà du beau schéma du mur de Berlin démantelé entre Dev et Ops, le véritable fondement « DevOps » se trouve dans un travail sur l’interaction entre les acteurs avec la mise en œuvre de nouveaux outils et de nouveaux leviers technologiques au sein des métiers traditionnels de la DSI. La dimension de conduite de changement est bien entendu primordiale dans ce changement culturel où la collaboration sera privilégiée en cassant les silos de la relation « client – fournisseur ».
DevOps, ce sont 3 piliers d’agilité concomitants supportés par des outils et une nouvelle culture d’entreprise : le Continuous Delivery, l’Infrastructure as Code et de nouvelles architectures.
Les méthodes agiles de type Scrum reposent sur des cycles de développement itératifs courts, des « sprints » dans le langage expert agile. En bout de chaîne, la mise en production des développements est souvent un goulot d’étranglement. Le Continuous Delivery est une réponse pour fluidifier l’ensemble de la chaîne de développement en automatisant les différentes étapes (build, test, deploy, …) et en orchestrant les déploiements. Supporté par des outils du marché tels que Git, Jenkins ou Puppet, la mise en production des versions du logiciel se fait de manière automatisée en limitant au maximum l’intervention manuelle des équipes « Ops ».
L’Infrastructure As Code, second pilier du DevOps, s’inscrit dans la continuité des méthodes agiles Scrum et du Continuous Delivery en apportant de l’agilité sur les infrastructures sous-jacentes à la chaîne de fabrication logicielle.
L’infrastructure as Code (IaC) ou “infrastructure programmable” est une méthode consistant à provisionner et à configurer son infrastructure, ainsi que réaliser des déploiements, via du code. Avec l’IaC, le développeur peut « programmer » le déploiement des ressources physiques et Cloud, c’est-à-dire de n’importe quel composant d’infrastructure (hyperviseur, VM, OS, stockage, …). Là où des séries de scripts permettaient principalement d’automatiser une série d’opérations à répéter sur différents serveurs, les outils d’Infrastructure as Code proposent des langages évolués tels que Ruby ou Python destinés à décrire son infrastructure, permettant de réaliser des opérations plus complexes.
Plus besoin d’armées d’administrateurs systèmes pour lancer des scripts de paramétrage de serveurs à la demande des développeurs, avec le délai et les erreurs qu’on peut imaginer. Avec l’IaC, les développeurs peuvent directement, eux-mêmes, à travers quelques lignes de codes, disposer immédiatement des infrastructures dont ils ont besoin. La mise à disposition d’une infrastructure qui prenait auparavant plus d’une semaine avec des formulaires de demandes et des échanges entre les équipes Dev et Ops (régulés parfois par des contrats de services internes rigides entre Dev et Ops !), se fera en quelques secondes à l’aide de lignes de codes écrites par les développeurs.
On mesure ici toute la dimension disruptive apportée par modèle IaC et les gains associés. Traiter son infrastructure IT comme un logiciel permet d’assurer la traçabilité et la fiabilité de cette dernière. En effet, chaque changement sur l’infrastructure peut être versionné et testé. Non seulement les problèmes de configuration sont anticipés, mais il devient possible de revenir sur une version précédente de sa configuration ; permettant ainsi de réparer les problèmes de configuration ou de reconstruire son infrastructure très rapidement.
Si l’IaC apporte un véritable gain de temps et une diminution des risques grâce à l’automatisation et aux pratiques de développement, elle permettra également de réduire les coûts d’exploitation par une meilleure maitrise de son infrastructure et une recentralisation de ses ressources humaines sur des tâches à valeur ajoutée.
Le métier d’administrateur système va peu à peu disparaître et se déporter vers les équipes de développement au travers de services automatisés, commandés par du code, à l’aide de bibliothèques d’API. On pourrait parler d’APIsation du monde des infrastructures, en référence à l’UBERisation de notre économie… Bien sûr, tout ne se fera pas si simplement : nouveaux outils, nouvelles compétences. Les solutions de gestion de configuration supportant l’IaC telles que Puppet, Chef, Ansible, CFEngine ou encore SaltSack introduisent de nouvelles compétences à la frontière entre développeur et administrateur système. Les développeurs devront monter en compétences pour maîtriser les outils et surtout les enjeux et les risques inhérents à ce nouveau mode de provisionning des infrastructures. Une mauvaise maîtrise des outils et des processus inadaptés généreront des catastrophes en chaîne dès lors que le code contiendra une erreur, par exemple un écart de configuration avec ce qui est déclaré dans les outils, lié à une opération de patch ou bug fixing manuelle non répercutée dans le code.
Enfin, troisième pilier DevOps, l’architecture. Inutile de mettre en place des solutions de Continuous Delivery ou d’IaC si l’architecture sous-jacente du système d’information est rigide et incompatible avec les principes d’agilité induits par les deux piliers précédents. La réflexion sur la mise en place d’une démarche DevOps sera accompagnée par des architectes qui travailleront à la mise en place d’architectures supportant les besoins des métiers en termes de : scalabilité, disponibilité, exploitabilité, déploiement. Dans cette recherche d’architecture agile, le Cloud sera un facilitateur.
Le chemin vers l’entreprise agile est une opération de transformation complexe aux acteurs et aux dimensions multiples : processus, organisations, outils et technologies
En conclusion, la transformation vers une entreprise agile n’est pas un projet classique parmi d’autres. C’est une opération de transformation complexe qui requiert le sponsorship de la Direction Générale pour un alignement de l’ensemble des acteurs de la chaîne de fabrication du système d’information, des métiers de l’entreprise jusqu’aux exploitants informatiques. Refonte de processus, choix et implémentation d’outils, transformation d’infrastructures, ajustements d’organisation et accompagnement des collaborateurs : autant de dimensions qui nécessitent la mobilisation d’experts et souvent l’assistance d’un cabinet extérieur pour garantir et sécuriser la réussite de la transformation. Le big bang vers l’entreprise agile est rarement une bonne idée car certains périmètres « legacy » hérités du passé ne se prêtent pas à la mise de en place d’agilité. Procéder par domaine et avec des périmètres pilotes sera la démarche à privilégier, quitte à créer une DSI à 2 vitesses, une informatique « bi-modale » avec un périmètre agile dans le Cloud pour les nouvelles solutions répondant aux enjeux de transformation digitale, et un périmètre classique, robuste mais aux cycles plus « longs » pour supporter le SI legacy hérité du passé. De quoi rendre le DSI schizophrène pensez-vous ? Mais le DSI n’est-il pas un homme agile ?
