La rationalisation du parc applicatif et des infrastructures est un enjeu classique pour un DSI. Les nouveaux impératifs budgétaires, environnementaux et sanitaires imposent d’accélérer ces chantiers avec une approche méthodique et de nouvelles techniques de conception.
La crise sanitaire que nous vivons est un accélérateur de tendances. Le contexte actuel pousse notamment les décideurs en charge des roadmaps technologiques, qui ont vu pour certains leur budget diminuer drastiquement, à accélérer l’optimisation des coûts liés aux applications qui tournent au sein de leur SI. Un chantier de rationalisation qui, motivé pour réduire son impact environnemental avant la crise sanitaire, est aujourd’hui une obligation pour débloquer des marges de manœuvre nécessaires à l’accélération de la transformation du SI.
Une application qui tourne coûte forcément. De l’énergie et de l’argent que ce soit pour son hébergement, sa consommation CPU et sa maintenance. Au-delà du coût c’est autant de lourdeur dans l’analyse d’impact et de faisabilité pour innover et répondre à la transformation des processus vers des standards plus élevés. C’est aussi une augmentation de la surface d’attaque en termes de sécurité, surtout sur des applications peu maintenues.
Dès lors, les questions suivantes se posent. Que dois-je garder ou supprimer parmi mes applications, leurs fonctionnalités et la manière dont elles sont développées et s’exécutent ? Est-ce que toutes les déclinaisons (mobile, desktop, etc.) d’un service sont utiles ? Sur quelle application investir du temps ? Quelles-sont celles que dois-je mutualiser ? Et de quelle manière ?
Analyser le parc applicatif existant à la loupe
Pour décider de manière rationnelle, raisonnée, il faut disposer de données factuelles et fraîches sur la performance globale de ses applications. Rationaliser commence donc par traquer de manière objective et à l’aide de KPIs adaptés pour connaître à la fois le nombre d’applications, leurs fonctionnalités et coûts, leur taux d’utilisation, le gain généré, leur redondance avec son parc applicatif ou celui de son écosystème.
Il faut s’appuyer sur une méthode d’assessment qui permet de passer au crible toutes les applications. Cet assessment inclut l’agrégation de données et statistiques qui viennent de la CMDB, des APM, des scans de sécurité, des outils d’analytics web et workstation, etc.
La synthèse doit permettre de motiver et partager les enjeux de rationalisation avec les utilisateurs et responsables métier.
Rationaliser les applications c’est aussi rationaliser les fonctionnalités. C’est donc le bon moment pour déclencher une démarche de conception de la cible et la trajectoire avec les équipes impactées pour ne pas tomber dans le piège de la refonte iso-fonctionnelle.
L’occasion de soigner l’UX (l’expérience utilisateur) pour une adoption plus simple des équipes dont les processus quotidiens vont changer.
Concevoir, développer et héberger avec des nouveaux standards technologiques
Pour rationaliser son parc, il est possible d’agir dès la conception de l’application. Il faut penser à inclure les principes de la sobriété numérique dès les premières étapes c’est-à-dire créer des applications répondant au principe d’utilité, de durabilité et d’accessibilité. Il est également essentiel de favoriser la mise en commun de services sur une unique application, tel que Microsoft a pu le faire récemment sur mobile avec la suite Office. Cela favorise une expérience fluide (applicatif moins lourds, une seule connexion, etc.) de nouvelles possibilités pour les utilisateurs et un parc applicatif plus restreint à maintenir.
Enfin, il faut veiller à limiter l’usage des données, leur stockage et leur transfert pour éviter d’alimenter le syndrome du “data rich, information poor”. Cela favorise la collecte de moins de données, mais plus pertinentes et surtout harmonisées et exploitables. Moins de données demandées aux utilisateurs c’est aussi un premier pas vers des données plus justes et ayant plus de valeur.
Dans le développement pur de son application, les standards évoluent aussi et les bonnes pratiques sont connues. Un développeur architecte qui est intégré dès la conception permet d’éclairer l’équipe produit sur l’impact énergétique des différentes options.
De manière générale, on essayera de solliciter le moins possible la capacité de calcul des appareils et le transfert de données sur le réseau. Cela passe notamment par une utilisation frugale des médias lourds, une conception des APIs favorisant les calculs proches des sources de données ou encore l’utilisation de technologies qui, à performances équivalentes, sont moins énergivores que les autres.
Une attention particulière à l’hébergement est clé
Plutôt que de maintenir ses propres serveurs qui sont aujourd’hui soit sous performants car sous-dimensionnés soit trop coûteux car sur-dimensionnés, réfléchir à passer les applications dans le Cloud public peut s’avérer être une très bonne stratégie. Elle va offrir la possibilité de piloter ses coûts en fonction de sa consommation réelle et ainsi, gagner en performance avec une capacité qui s’adapte à son utilisation, le tout sur des data-center ayant un impact écologique moindre.
Les deux impulsions de réduction/rationalisation des coûts et la sobriété environnementale sont une opportunité de déclencher de manière très concrète la transformation des applications et des processus qu’ils soutiennent. La rationalisation est rendue possible par des données et KPI partagés, un travail sur les processus, et doit être associée à des techniques de conception modernes qui permettent de répondre aux nouveaux standards et critères de performance.
