Si la DSI se pose des questions sur le cloud, celui-ci lui en pose aussi sur sa performance et son agilité. L’une des approches possibles consiste à s’inspirer des modèles de cloud pour les déploiements logiciels et à mettre en place un centre de service de transformation.
La transformation de l’offre des fournisseurs de matériels et d’applications en offre tarifée à l’usage déplace les lignes et va probablement inciter les directions générales à aiguillonner l’organisation des activités de leur DSI sous forme de services refacturés, au moins autant qu’Itil et la méthode ABC l’ont fait ces dernières années.
Que répondre en effet au DG qui, au-delà du choix d’un cloud hybride, public ou privé, se demande pourquoi sa DSI n’a pas remarqué spontanément qu’elle pouvait proposer formellement des services regroupés autour de la gestion des infrastructures, des plateformes et des progiciels, alors qu’il s’agit d’activités quotidiennes, mises à contribution pour tous les projets et les applications en production ?
On aurait pu s’attendre à une innovation équivalente au cloud au sein des grandes DSI, débouchant sur un fonctionnement plus compétitif en termes de sécurité, mais tout aussi réactif, organisé et clair, sur son prix que le sont les offres commerciales. Or, combien de DSI, même lorsqu’elles tiennent un catalogue des plateformes autorisées, disposent-elles d’un prix de revient interne de la mise à disposition d’une infrastructure précise ou d’un modèle analytique du coût d’un environnement applicatif avant personnalisation ? Combien de projets ont-ils des budgets dans lesquels ces lignes apparaissent en euros ?
Plus largement, au-delà des nuages et sans viser nécessairement une démarche d’externalisation, un DG peut pressentir que d’autres ensembles de services doivent être tout à fait susceptibles d’une amélioration similaire à celle apportée par le cloud pour la mise à disposition de l’infrastructure. Mais comment identifier les activités fréquentes pouvant donner lieu à des services à la demande, dont une innovation technologique judicieusement mise en œuvre baisserait les coûts globaux et faciliterait la tarification interne ?
La réponse définitive à cette question réside dans les démarches d’innovation continue qui institutionnalisent la détection des opportunités et leur mise en œuvre. A défaut de ces démarches d’envergure, un schéma plus modeste, mais éprouvé, consiste à suivre les évolutions des outils et des logiciels que l’on emploie, pour détecter si leur amélioration ne pourrait pas donner lieu à une transformation organisationnelle qui en démultiplierait les effets. Les déploiements applicatifs au sein d’une DSI peuvent être améliorés d’une manière radicale, bien qu’incrémentale et progressive, en utilisant une approche qui a fait le succès du cloud : périmètre du service intuitif, simplicité de la demande, innovation technologique, élasticité du coût et existence d’acteurs de la transformation.
Définir le périmètre du service de déploiement
Le déploiement d’applications est un sujet précis, quasiment intuitif, qui correspond immédiatement à un ensemble de services opérationnels dont Itil garantit la cohérence. Dans certains cas, le fonctionnement de la DSI doit être aménagé pour que le périmètre de ces services soit suffisamment conséquent. Le ROI de l’automatisation ne peut intervenir que si le fonctionnement cible porte sur l’ensemble des environnements d’intégration, de qualification, de formation et non pas seulement sur les environnements de production et de pré-production. Le périmètre sera donc constitué de toutes les activités, depuis la livraison des projets pour l’intégration et la qualification, jusqu’au déploiement sur les environnements de recette.
Le périmètre prend en compte tous les environnements de qualification et recette, toutes les applications, les versions majeures du système d’information et les correctifs, les projets et les maintenances, ainsi que toutes les mises en production. Il correspond à une mission simple : l’objectif est le déploiement rapide des composants applicatifs, avec une parfaite maîtrise des différentes versions installées à tout moment sur les environnements de recette et de production.
Une opportunité de gains de productivité
L’ingrédient technologique de l’innovation est l’arrivée sur le marché d’un ensemble d’outils dédiés aux déploiements dont les fonctionnalités sont désormais très intéressantes. Citons Nolio, commercialisé par Computer Associates et Serena, UrbanCode Deploy d’IBM, DeployIT de Xebialabs, Application Deployment de BMC, sans oublier les offres Open Source. Les fonctionnalités proposées découlent d’une analyse consensuelle en quatre points de la complexité croissante des déploiements :
- L’activité de déploiement augmente et prend différentes formes, du fait des mises en production correctives, des versions majeures mensuelles et mineures hebdomadaires, ainsi que des mises en production agiles en continu.
- Pour les tenants des méthodes agiles et le mouvement « DevOps » qu’ils ont initiés, la lenteur d’installation sur les différents environnements post développement constitue un goulet d’étranglement vers la mise en production fréquente des fonctionnalités développées en sprint. Les équipes de Développement et les Opérations doivent être fédérées autour d’un processus outillé de déploiement. Pour les autres parties prenantes de la DSI, la mise en production trimestrielle des versions majeures du système d’information représente une pointe de charge et un risque tel qu’elle doit être industrialisée et outillée.
- La complexité de l’architecture technique des applications n-tiers et les dépendances à respecter entre les différents éléments rendent les séquences de déploiement plus délicates.
- La diversité des infrastructures techniques des environnements de test, reposant sur du cloud computing, et de production, mettant en œuvre des clusters, impose de variabiliser les procédures en fonction des infrastructures de chaque environnement.
Les fonctionnalités, présentes dans l’un ou l’autre des outils qui découlent de cette analyse, peuvent être regroupées en quatre ensembles : les fonctionnalités de l’installation (comment déployer), la gestion des déploiements et l’interface de demande (quand déployer), les fonctionnalités portant sur la version à déployer (quoi déployer) et les fonctionnalités d’architecture d’entreprise. En termes d’ingénierie, l’automatisation des déploiements doit évidemment fournir un mécanisme d’intégration et de déploiement continu pour la mise au point des développements agiles, mais aussi permettre la livraison de correctifs unitaires en production, comme la mise place de trains de livraison mensuels ou trimestriels. La solution doit donc supporter l’alimentation en parallèle des environnements de test et de production pour les différents horizons de mise en production auxquels la DSI contribue à tout instant, et aussi gérer correctement toutes les configurations applicatives correspondantes.
Élaborer une trame de livraison
Pour tenir ces objectifs et satisfaire les préconisations Itil, il convient d’établir un découpage pérenne des applications en deux niveaux. Les composants applicatifs (fonctionnels et/ou structurels) du premier niveau sont eux-mêmes décomposés par technologie pour définir le second. Ce découpage est la « trame de livraison » que doivent respecter les livraisons des projets. La trame est convenue de façon pragmatique au titre de la mise en place du Plan de gestion de configuration logiciel (PGCL) de chaque application. La stabilité du découpage, d’une livraison à l’autre, permet de comparer deux versions d’un même « composant » de l’application ou deux versions d’un ensemble de plusieurs composants. La stabilité du découpage permet aussi de fusionner des livraisons successives de la même application, correspondant au même déploiement, et de mettre ainsi au point l’application. Les outils de gestion de configuration logicielle et de déploiement s’appuient également sur ce découpage pour automatiser efficacement l’ensemble des étapes de la mise au point jusqu’au déploiement, ainsi que le reporting associé.
On comprend dès lors que le service de gestion des releases et des déploiements fournit bien une forte valeur ajoutée, puisqu’il permet non seulement la mise en production rapide de versions majeures du SI, mais traite également le flux d’intégration continue, tout en gérant la librairie définitive des logiciels, ainsi que toutes les versions d’applications qui empruntent les dernières étapes du cycle de développement. Tout comme pour le cloud, l’amélioration de la performance de la DSI naît également, dans ce cas, d’une innovation technologique et organisationnelle, ainsi que de l’industrialisation des procédés opérationnels. Il s’agit d’une autre « innovation de processus », analogue sur ce plan à l’externalisation des TMA, à la mutualisation de centres de développement, à la constitution de centres de qualification transversaux à la DSI, à la mise à disposition d’environnements et d’infrastructures sous forme de services, etc.
Les atouts d’un centre de service de transformation
Cette cible est-elle pour autant envisageable ? Et que vaut une innovation que l’on saurait décrire sans l’atteindre ? Le dernier volet de cette innovation réside dans la solution organisationnelle pour la conduite du changement qui permet la mise en œuvre de la solution décrite. Elle se nomme « centre de service de transformation » et catalyse la transformation innovante. À la différence du cloud privé, l’amélioration des déploiements ne peut venir de l’acclimatation en interne d’une offre commerciale et doit donc relever d’un changement interne ou d’une intervention externe éphémère. S’agissant d’une activité opérationnelle incontournable, la solution organisationnelle du centre de service (CDS) de transformation est particulièrement pertinente. L’engagement de celui-ci est de permettre simultanément d’assurer le service au quotidien et de l’industrialiser pour tenir la charge opérationnelle à moyens finis.
Le pilotage interne du CDS poursuit l’objectif que l’activité, à l’issue de plusieurs mois de fonctionnement, puisse se poursuivre en interne avec des effectifs très restreints et une charge de mise en production fortement allégée. Ainsi, le responsable du centre de service répartit périodiquement ses ressources entre l’activité opérationnelle, l’extension de périmètre et l’amélioration continue du niveau de service dans le cadre de sa délégation et de son budget, afin d’atteindre au mieux les différents objectifs opérationnels et de transformation poursuivis.
Pendant cette phase d’industrialisation, les indicateurs d’activité et de performance, correspondant à chacun des services, évaluent les gains de productivité obtenus grâce à l’avancement de la transformation et mesurent le volume d’activité du centre de service, ainsi que la qualité du service rendu.
Indicateurs d’activité et unités d’œuvre : vers l’élasticité des coûts de déploiement
Les indicateurs se distinguent des unités d’œuvre, qui sont la base de la valorisation en euros des services et permettent l’élasticité de la dépense. En effet, les unités d’œuvre découlent des indicateurs d’activité, mais ne doivent pas générer de coûts administratifs inutiles dans la relation de sous-traitance (coût de transaction). Elles ne correspondent ainsi pas à la maille la plus fine des activités du service, mais à un compromis entre la précision et le coût de gestion. On privilégiera par exemple une unité d’œuvre synthétique du type : « Les vingt premières livraisons tous environnements confondus (intégration, recette, pré-production, production) pour une application complexe dans le cadre d’une version majeure trimestrielle du système d’information. » Le coût global du service varie alors avec l’activité de maintenance et le nombre de projets de la DSI, démultipliant ainsi l’impact budgétaire des arbitrages.
La réversibilité et l’innovation sont souvent décrites comme des sujets critiques lors de l’externalisation d’une activité. L’absence d’innovation n’est pas un risque pour le CDS de transformation car l’amélioration du fonctionnement du service est l’objectif principal. Cette amélioration fait l’objet d’une gouvernance explicite qui en mesure les progrès et suit les livrables. La réversibilité est inscrite dans le principe du centre de transformation, puisque la solution est déployée dans un temps limité sur l’ensemble du SI. La réversibilité porte sur les savoir-faire pour l’utilisation courante, ainsi que pour la prise en compte de nouvelles technologies, le logiciel de déploiement et les paramétrages effectués.
Les procédés outillés simplifient grandement les tâches opérationnelles et permettent la poursuite de la fourniture du service par un nombre très limité d’intervenants de profil « gestionnaire de livraison et déploiement », situés éventuellement au sein d’une structure plus large en charge des clouds internes ou hybrides, ainsi que de la gestion des environnements. Le service peut ainsi être fourni par la suite en interne ou par un centre de service classique externalisé. À l’issue de cette réversibilité, la DSI a donc bien transformé ses activités de déploiement, initialement réparties sur plusieurs équipes et peu industrialisées, en un ensemble de services outillés, éventuellement entièrement automatiques, refacturables en interne, plus rapides et plus sûrs, améliorant ainsi son agilité, sa transparence et la maîtrise de ses coûts.
Vers une organisation de la DSI orientée services
La part la plus séduisante de l’innovation numérique est assurément le développement de nouvelles offres métiers en symbiose avec les nouvelles technologies telles que les données massives ou les smartphones. Mais n’oublions pas que les DSI consacrent 80 % de leur budget à des projets plus traditionnels ou à des tâches de maintenance. Que le produit fonctionne sur un smartphone ou un terminal plus ancien, il relève de la même discipline professionnelle, l’ingénierie logicielle, et s’appuie sur des activités d’architecture, d’infrastructure, d’écriture, de qualification et de déploiement.
L’offre cloud montre que les principaux processus d’ingénierie constituent de vrais enjeux d’innovation et ne doivent pas former la partie immergée d’un iceberg informatique. L’innovation sur les processus bat au même rythme informatique que l’innovation dans les produits. L’amélioration de la performance de la DSI prend alors la forme d’un mouvement vers des organisations orientées services.
Cette évolution vers les services épouse les pratiques d’externalisation et prolonge l’approche de l’organisation centrée sur les processus qui peinent parfois à traverser les silos organisationnels, du fait du poids hiérarchique insuffisant des propriétaires de processus face aux chefs de service. L’organisation centrée sur les services vise à pallier ce défaut et est finalement la déclinaison pragmatique de l’approche processus.
Notons enfin que la notion de service est ici un peu plus fine que celle préconisée par Itil, car ces services ne se résument pas à ceux à destination des métiers ou des utilisateurs, mais reposent sur une notion plus récursive puisque chacun, au sein même de la DSI devient client et fournisseur de services. Comme dans toutes les approches récursives, le découpage en services présente le risque de la maille disparate, trop fine, et de l’impuissance. Il est important alors de s’appuyer sur une connaissance des métiers de la DSI pour déterminer le bon périmètre d’innovation sur lequel constituer un centre de services de transformation.
Ce périmètre ne préjuge pas du découpage en centres de services de fonctionnement, internes ou externes, qui peuvent s’organiser à une maille plus large que celle utilisée pour les CDS de transformation et regrouper, en régime de croisière, différents ensembles de services sous la même responsabilité : centre de service pour la qualification des systèmes, centre de service d’architecture, d’environnement, de développement de logiciel critique, de tierce maintenance, etc.
Certains, souvent fournisseurs, conseillent aux DSI de devenir des courtiers de services externalisés auprès des directions métiers, sous peine de voir complètement disparaître leur rôle d’intermédiation. C’est probablement aller trop loin car les SI sont, comme leur nom l’indique, des systèmes qui ne peuvent être uniquement gérés par morceaux, confiés aux uns et aux autres. Les DSI qui parient sur la transparence peuvent conduire une évolution de leur organisation, qui permette de comparer les services achetés et ceux produits en interne. L’innovation est alors poussée idéalement jusqu’à ce qu’un montant en euros des prestations de services internes puisse être déterminé sur la base de coûts complets au sens de la méthode Activity Based Costing. Ce prix de revient n’empêche évidemment pas des mécanismes d’abondement et de refacturation interne, qui participent à la mise en œuvre des orientations stratégiques de la direction.
Le fonctionnement de ces services, éventuellement partiellement externalisé, doit être adapté à l’élasticité de la demande des directions métiers pour rendre la DSI budgétairement agile. Le cloud a montré que cette évolution vers plus d’agilité est assurément possible et la transformation de la DSI vers une organisation orientée service ne demande qu’à être poursuivie.
Cet article a été écrit par Alain Sacquet, consultant.
| Les fonctionnalités des solutions dédiées aux déploiements | |
| Les fonctionnalités de l’installation (comment déployer) |
|
| La gestion des déploiements et l’interface de demande (quand déployer) |
|
| Les fonctionnalités d’architecture d’entreprise |
|
| Les fonctionnalités d’architecture d’entreprise |
|
