La gestion des parcs applicatifs constitue un enjeu de taille pour les DSI : obsolescence, coûts cachés ou autres failles de sécurité rôdent dans l’ombre.
Pour maintenir un patrimoine logiciel cohérent, le décommissionnement logiciel est la clé. Tour d’horizon d’une pratique salvatrice.
Qu’est-ce que le décommissionnement logiciel ?
Concrètement, le décommissionnement logiciel peut se définir comme une pratique consistant à retirer certaines applications du système d’information d’une entreprise.
Le décommissionnement logiciel poursuit généralement un ou plusieurs des objectifs suivants :
- Le plus souvent, l’enjeu d’un tel processus est d’identifier les applicatifs n’étant plus utilisés et/ou devenus obsolètes. Ces derniers sont ensuite déconnectés progressivement avant d’être complètement supprimés du SI.
- Si certains outils doivent être démantelés, les données qu’ils stockent et gèrent sont souvent précieuses. Le décommissionnement logiciel peut donc aussi être utilisé pour comme une opportunité de transférer des informations d’un système à l’autre de manière propre et ordonnée.
- Dans certains cas de figure, les entreprises requièrent au décommissionnement pour faire le point sur l’utilisation effective des logiciels en service puis définir un plan d’action : réduction du nombre de licences, recherche d’une alternative ou au contraire souscription à une offre supérieure.
Quels sont les avantages du décommissionnement logiciel ?
C’est un fait : l’essor du numérique a entraîné une explosion du portefeuille applicatif pour les entreprises, quelle que soit leur taille et secteur d’activité.
Dans ce contexte de digitalisation massive, le décommissionnement logiciel est parfois laissé de côté par les DSI, ou sans cesse reporté à des échéances plus lointaines. Pourtant, il présente de nombreux avantages :
1 – Réduire les coûts
Une application, même si elle n’est plus utilisée, continue à générer des frais pour une entreprise : stockage des données, maintenance et support technique (de plus en plus onéreux au fil du temps) et licences ou abonnements.
Puisque le retrait des logiciels permet de mettre hors service le cœur applicatif et l’infrastructure lui étant liée, la société fait baisser ses coûts : moins de maintenance, de contrats de support, moins de souscriptions actives, moins d’électricité consommée…
2 – Valoriser les données stratégiques
Comme évoqué dans le paragraphe précédent, les informations stockées dans les applications obsolètes et/ou non utilisées peuvent avoir une grande importance.
Mais au-delà de l’absolue nécessité de leur récupération, leur migration constitue une belle opportunité opérationnelle pour les DSI : mise à jour, accessibilité, reformatage ou encore suppression des doublons.
3 – Rationaliser le parc applicatif
Parfois sans même en avoir conscience, les DSI pilotent des parcs applicatifs trop fournis ou, plus rarement, sous-équipés.
Un des cas les plus courants est la redondance des modules fonctionnels : une application est utilisée pour remplir une mission que pourrait parfaitement effectuer un autre système déjà en place, parfois plus performant ou mieux intégré.
La rationalisation par le décommissionnement consiste ainsi à faire l’inventaire de l’existant, puis à effectuer un tri pour ne conserver que les applications essentielles, quitte à mettre à niveau les plus archaïques d’entre elles. Cela impose une réflexion au niveau des workflows et des processus métier.
4 – Optimiser la sécurité du SI et des données
Les systèmes vieillissants ou laissés à l’abandon constituent souvent des failles de sécurité dans les systèmes d’information. Véritables bombes à retardement, elles peuvent être exploitées par des personnes mal intentionnées, avec des conséquences souvent très impactantes.
Le décommissionnement logiciel est l’occasion pour une entreprise de se réapproprier ces données, en leur offrant une meilleure protection contre les risques externes tout en restreignant leur accès aux utilisateurs disposant des autorisations nécessaires.
5 – Opérer une mise en conformité avec la réglementation
Le durcissement de la réglementation en matière de confidentialité des données – aussi bien au niveau national qu’européen – exerce une pression constante sur les DSI.
Grâce au décommissionnement logiciel, une société peut faire le point sur sa stratégie de gouvernance des données : où sont stockées les données utilisateurs ? Sont-elles accessibles en cas de litige ? Les durées d’archivage maximales sont-elles respectées ? Leur suppression est-elle automatisée ?
6 – S’adapter aux nouveaux besoins des métiers
Au gré des innovations et du marché, les entreprises changent, et avec elles, leurs collaborateurs. Une opération de décommissionnement peut donc parfaitement servir à auditer les besoins internes et faire le point sur la mise à jour du parc applicatif.
Par exemple, un ERP satisfaisant à première vue peut très bien faire l’objet d’un remplacement ou d’une mise à jour si les échanges avec les équipes utilisatrices mettent en exergue des lacunes ou dysfonctionnements majeurs.
Comment initier le décommissionnement logiciel en entreprise ?
Le décommissionnement logiciel n’est pas une procédure anodine et est le plus souvent géré par des prestataires externes. Mais en amont de cette phase opérationnelle, il convient de valider la pertinence de l’opération. Pour ce faire, plusieurs étapes permettent de réaliser un état des lieux du parc applicatif :
1 – Effectuer un inventaire des logiciels dans l’entreprise
La première phase consiste à établir une cartographie exhaustive des différents logiciels présents dans le SI de l’entreprise. Le document produit fait office de base documentaire pour la suite des événements.
Mais une telle opération n’est pas toujours évidente à réaliser. Pour pallier cette difficulté, l’aide d’une CMDB est appréciable : il s’agit d’un outil comparable à un inventaire ou une gestion d’assets intelligente pour les différents systèmes IT, dont font partie les logiciels. Ainsi, pas de risque d’oubli : chaque application possède une entrée dans la BDD.
2 – Associer un coût à chaque application
Pour déterminer avec précision les frais liés à chaque logiciel, plusieurs paramètres peuvent être utilisés : licences, abonnements, maintenance, administration, stockage, consommation d’énergie, éventuelles mises à jour…
L’intérêt d’une telle étape est de mettre un montant exhaustif en face de chaque système afin d’en faciliter le tri. Ici encore, une CMDB peut grandement fluidifier le processus, puisqu’elle regroupe en général les contrats et autres documents financiers propres à chaque élément lié à l’IT.
3 – Déterminer la valeur métier des applications
La décision de démissionner une application se base également sur son degré d’efficacité vis-à-vis de la ou les problématiques qu’elle vise à résoudre : c’est ce qu’on appelle la valeur métier.
Plusieurs critères rentrent en ligne de compte pour la définir, à retrouver dans le tableau de synthèse ci-dessous :
- FonctionÀ quoi sert le logiciel au quotidien ?
- QuantitéPar combien de collaborateurs internes ou d’acteurs externes l’application est-elle utilisée ?
- Fréquence d’utilisationLe système est-il utilisé de temps à autre ou sur un rythme plus soutenu ?
- Dernière utilisationÀ quand remonte la dernière utilisation du logiciel ?
- AnciennetéQuelle est la date de sortie de l’application ? Ainsi que celles de ses modules complémentaires éventuels ?
- ÉvolutionLe système bénéficie-t-il de mises à jour régulières ? Quelle est la nature de ces dernières ?
- PotentielL’application est-elle indispensable ou d’autres logiciels peuvent-ils occuper le même rôle ? Le cas échéant, qu’implique le passage à un autre système ? Formation, migration, frais…
4 – Identifier les éventuels cas de “Shadow IT”
Le terme de Shadow IT (ou de Rogue IT) renvoie à la création et la mise en œuvre d’un ou plusieurs systèmes informatiques au sein d’une entreprise sans le consentement explicite de la DSI.
Cette pratique suscite des débats houleux : ses défenseurs la considèrent comme une excellente source d’innovation pouvant servir d’ébauche à une future application “officielle”. Ses détracteurs la voient quant à eux comme une pratique délétère pour l’entreprise, notamment sur l’aspect sécuritaire.
L’objectif ici n’est pas d’émettre un avis sur la question. En fait, l’intérêt de répertorier ces cas de Shadow IT est de mettre au jour des développements alternatifs, le plus souvent destinées à combler des lacunes ou absences sur les outils “officiels”.
Ainsi, établir cette “cartographie de l’ombre” se montre particulièrement utile afin de mettre le doigt sur des applications peu efficaces, pour lesquelles l’entreprise continue de payer avec un ROI faible, voire nul.
Par la suite, il est donc possible d’orienter le décommissionnement logiciel sur la base des résultats obtenus, mais aussi de discuter avec les métiers concernés pour aboutir à une solution satisfaisante pour tous.
5 – Faire l’acquisition de logiciels adaptés
À partir du moment où une liste de décommissionnement applicatif est créée, la réflexion doit s’orienter vers le futur. Le plus souvent, les faiblesses et menaces identifiées peuvent être comblées à l’aide de nouvelles applications ou de mises à jour. Pour éviter de reproduire les erreurs passées, il est donc primordial de sélectionner des applications à même de :
- Se substituer à une utilisation marginale d’un grand logiciel nécessitant une licence (par exemple la collecte de données & le reporting avec un ERP).
- Permettre la mise en place d’une solution métier ciblée (exemple : établir un rapport RSE) sans investissement lourd dans un logiciel métier standard trop foisonnant, rigide du point de vue des process et pas assez spécifique.
- Remplacer les solutions de type Shadow IT par une alternative sécurisée du point de vue des données et de la DSI.
Au-delà d’une dénomination technique et peu avenante, le décommissionnement logiciel propose une véritable remise à plat du patrimoine applicatif des entreprises. Que garder ? Que jeter ? Quoi modifier et comment s’y prendre ? Autant de questions auxquelles le décommissionnement applicatif peut répondre.
Pour conclure, rappelons que ce travail requiert une étroite collaboration entre la DSI et les “key users” (les métiers), qui sont – ne l’oublions pas – les premiers concernés par l’évolution des outils internes.