Réaliser un inventaire technologique
Identifier et recenser les composants de l’application
L’inventaire technologique de l’application consiste à déterminer les ressources, à recenser les composants utilisés par l’application, le produit ou le système à auditer. Nous recherchons les composants applicatifs actifs, puis, pour chacun de ces composants, nous listons les composants techniques qui ne sont autres que technologies utilisées en elles mêmes. Les composants applicatifs sont par exemple : une application mobile ou une base de données. Les composants techniques : le système d’exploitation Debian 10.9, la base de données Maria DB 10.3, le framework de développement mobile Xamarin,…
A partir de quelles ressources pouvez-vous réaliser l’inventaire technologique ? Où trouver les informations sur les technologies utilisées ?
- La documentation d’architecture (spécifications techniques) est le plus souvent une mine d’informations. Référez-vous au cahier des charges de l’application.
- Le gestionnaire de sources (Gitlab, Github…) est un outil collectant le code source, avec une gestion des versions tracées et des revues de codes. Il est utilisé pour produire des applications et gérer des tickets de support reliés à des bugs. Vous pourrez y trouver des informations sur les technologies et les composants utilisés.
- Échanger avec l’équipe de développeurs. En priorité, questionnez un profil technique (le chef de projet ou un développeur) qui travaille sur l’application concernée.
- Enfin, selon votre niveau de compétences, prenez le temps d’explorer et d’inspecter les ressources techniques. Par exemple, inspectez le code source, les bases de données de l’application, les fichiers de configuration, les serveurs…
Les composants applicatifs et les composants techniques
Une application peut comprendre différents composants applicatifs, qui mettent en œuvre différents composants techniques. Pour bien comprendre ce dont il s’agit, voici un exemple d’architecture technique que nous rencontrons régulièrement chez AxioCode :
- Composant applicatif n°1 : une application web en front-end
Composant technique associé : le framework de développement Angular dans sa version 11.2.6.
Le “front-end” correspond à ce que l’utilisateur peut voir et avec lequel il peut interagir directement.
Un framework est en quelque sorte une boîte à outils de développement.
- Composant applicatif n° 2 : une application back-end, en l’occurrence une API
Composant technique associé : la version 5.2.6 du framework Symfony
Le “back-end” représente tout ce qui se passe en arrière-plan sans que l’utilisateur ne s’en rende compte.
Une API est une application qui va permettre à un système tiers d’interagir avec une entité informatique. Dans notre exemple, l’API permettra à l’application web en front-end et à l’application mobile d’interagir avec la base de données pour afficher les informations qui y sont enregistrées et les mettre à jour.
- Composant applicatif n° 3 : une application mobile.
Composant technique associé : le framework de développement Xamarin version 4.8.0
- Composant applicatif n° 4 : une base de données
Composant technique associé : la base de données MariaDB version 10.3
- Autres composants techniques :
– Le langage de programmation PHP 7.4
– L’API Google Maps dans sa version 3.44
– Le système d’exploitation du serveur web Debian 10.9
– Le serveur web Nginx 1.14.2
L’inventaire des technologies étant fait, voyons comment vérifier qu’elles sont toujours maintenues, à jour, et sans faille de sécurité.
Vérifier les versions des composants techniques
Vérifiez si un composant technique est à jour. Pour cela, visitez le site web de l’éditeur du composant technique et consultez la page d’information sur les versions supportées.
Sachez qu’un numéro de version est le plus souvent défini selon la sémantique SemVer avec trois chiffres :
- Le numéro de version majeure dès qu’il y a des changements non rétrocompatibles,
- Le numéro de version mineure lors d’ajouts de fonctionnalités rétrocompatibles
- Le numéro de version de correctif dès qu’ il y a des corrections d’anomalies rétrocompatibles.
La rétrocompatibilité est l’aptitude d’un matériel ou logiciel à prendre en charge le même ensemble d’instructions qu’un système plus ancien.
Par exemple, la version 5.2.6 de Symfony indique qu’il s’agit de la 5° version majeure de ce framework, de la 2° version mineure de cette version 5 et de la 3° version de correctifs apportés à cette 2° version mineure.
A partir de la version du composant que vous utilisez, nous vous recommandons de noter les informations suivantes :
- Le type de dernière mise à jour (release) :
- Active : la version est maintenue activement par l’éditeur
- Maintenance : seuls les bugs et problèmes de sécurité sont adressés
- LTS (Long Term Support) : version maintenue plus longtemps que la normale par l’éditeur, ce qui laisse le temps aux développeurs de passer à la version majeure suivante.
- La dernière date de mise à jour (release).
- Le cas échéant, la date de fin de LTS (Long Term Support)
Il est important d’organiser une veille technologique régulière. Elle permet de suivre les évolutions des versions majeures des composants techniques utilisés dans vos applications. Si vous utilisez une version obsolète, qui n’est plus maintenue, cela peut représenter un risque pour votre organisation.
Packages, Bundles, Librairies tierces et Open Source
Les composants techniques utilisent des sous-composants. Par exemple, les frameworks utilisent des sous-composants techniques appelés packages, bundles, librairies.
Ces sous-composants techniques sont bien souvent Open Source, c’est-à-dire que le code source est disponible et maintenu par une communauté de développeurs indépendants, quelquefois soutenus par des entreprises.
Ils apportent des fonctionnalités techniques intéressantes dans les projets. Cela évite aux développeurs de réécrire certaines briques comme la génération de fichier PDF, l’accès à des bases de données, etc.
De la même manière, ils doivent faire l’objet d’un suivi particulier et régulier.
Lors de votre audit, pour déterminer les versions utilisées, vérifiez ou faites vérifier les fichiers de configuration référençant les packages utilisés par l’application. Par exemple, les fichiers composer.json, package.json, pom.xml.
Utilisez les gestionnaires de packages pour détecter les versions trop anciennes, qui posent des problèmes : Packagist pour PHP, NPM pour NodeJS, Nuget pour .NET ou encore Maven pour Java.
Un exemple de liste des composants techniques
Nous vous recommandons de recenser dans un tableau les composants techniques identifiés, comme dans l’exemple ci-dessous.
Les différentes dates de sortie des versions utilisées seront à collecter. Indiquez aussi le type de version, les dates de fin du support indiquées par l’éditeur. Vous pouvez ainsi anticiper la fin de vie d’une version et réduire le risque d’obsolescence de votre application. Il est également intéressant de mettre en avant la dernière version de l’éditeur pour comparer et mettre en lumière les composants trop anciens ou qui vont devenir bientôt obsolètes.
Vous disposez maintenant d’un inventaire technologique complet. Cet inventaire en lui-même est intéressant, mais il n’est pas insuffisant pour évaluer précisément l’obsolescence des technologies utilisées.
La prochaine étape présentée ci-après propose une méthode d’évaluation du degré d’obsolescence d’une application et d’identification risques liés à l’obsolescence.
Les étapes de l’inventaire technologique en vidéo
Rediffusion du webinaire sur l’inventaire technologique d’une application web ou mobile, présenté par Antony Zanetti, Directeur Technique et co-fondateur d’AxioCode. La présentation est suivie par une séance de questions/réponses. Vous avez d’autres questions ? Posez-les nous.
Estimer le degré d’obsolescence des technologies utilisées
L’estimation du degré d’obsolescence d’une technologie repose sur deux questions :
- Quelle est la probabilité d’obsolescence de cette technologie ? Sur quels critères la mesurer ?
- Quel est l’impact de l’obsolescence de cette technologie sur l’entreprise ou l’organisation ?
Estimer la probabilité d’obsolescence d’une technologie
De nombreux critères permettent d’évaluer la probabilité d’obsolescence d’un composant technique. Nous pouvons les classer en deux catégories :
- Les critères liés à l’écosystème du composant technique, de la technologie étudiée,
- Les critères techniques.
Les critères d’évaluation d’obsolescence liés à l’écosystème
L’écosystème d’une technologie est caractérisé par l’ensemble des informations qui permettent, au final, de juger de sa pérennité.
Nous vous suggérons d’attribuer un score de risque d’obsolescence à chaque critère, par exemple de 1 (risque faible) à 9 (risque fort) comme dans l’exemple ci-dessous :
- L’éditeur de la technologie peut être évalué en fonction de son ancienneté et de la taille de ses équipes. Une grande entreprise présente un risque faible, tandis qu’une start-up a plus de chances de disparaître, sans solution de maintenance de la technologie.
- La communauté des développeurs autour de cette technologie : est-elle importante, active ? Il est possible de l’évaluer en consultant les forums et sites dédiés.
- Les ressources et documentations relatives à la technologie sont-elles complètes, régulièrement mises à jour, de qualité ?
- Quelle est la disponibilité des compétences pour cette technologie sur le marché de l’emploi ? Cela pose réellement problème pour les technologies les plus anciennes.
- Quelle est la politique de support à long terme de l’éditeur ? Vous pouvez l’évaluer en fonction du nombre d’années que l’éditeur va garantir.
- Quelle est la maturité de la technologie ? Une technologie qui vient de sortir présente plus de risques d’obsolescence qu’une technologie éprouvée depuis de nombreuses années.
Les critères techniques d’évaluation d’obsolescence
Ce sont les critères d’appréciation liés à la technologie du composant :
- La facilité de la mise à niveau de la technologie par rapport à la version utilisée par l’application que l’on audite : sera-t-il facile ou non de passer à la version supérieure ?
- La facilité du langage de programmation (le cas échéant),
- La facilité du framework de programmation (le cas échéant),
- Les failles de sécurité connues de la version du composant technique utilisée par l’application,
- Les problèmes de compatibilité avec d’autres technologies.
Un exemple d’évaluation d’obsolescence de 3 technologies
Voici un exemple de grille de notation de la probabilité d’obsolescence de trois technologies utilisées par une application.
Pour chacune des technologies, nous avons attribué une note à chaque critère, de 1 (risque faible) à 9 (risque fort). Nous obtenons ainsi une moyenne par technologie et une moyenne globale.
Dans notre exemple, la probabilité d’obsolescence de Symfony 2.8 (framework PHP web) et de Debian 6 (système d’exploitation) est élevée. La probabilité d’obsolescence de PHP 5.6 est moyenne.
Le score global est de 5.3, ce qui représente une probabilité moyenne d’obsolescence. Mais le score est proche de 6, ce qui signifie que l’application est en voie d’obsolescence. Quelques facteurs sont tout de même rassurants. Par exemple pour Symfony 2.8, l’éditeur de ce langage (SensioLabs) est sérieux et met en confiance pour passer à la version supérieure rapidement.
Estimer l’impact de l’obsolescence
Nous avons vu comment estimer la probabilité d’obsolescence d’une technologie, tant sur des critères liés à l’écosystème que sur des critères techniques. La seconde question à étudier porte sur l’impact de l’obsolescence des technologies sur l’entreprise ou l’organisation : quel sera l’impact du maintien d’une ou plusieurs technologies probablement obsolètes ?
Ces critères d’impact sont très souvent à mettre en contexte, en fonction de l’application auditée et de l’activité même de l’entreprise. Par exemple, la défaillance d’un module de paiement par carte bancaire aura un impact très important sur l’activité d’une entreprise de e-commerce.
Voici quelques exemples de critères d’impact à évaluer :
- L’exposition aux vulnérabilités et aux attaques informatiques,
- La perte financière que pourrait générer la défaillance de la technologie,
- L’atteinte à la réputation de l’entreprise,
- La non conformité de l’application,
- etc.
Passons à l’impact du risque d’obsolescence sur l’entreprise et son activité, noté de 0 à 9.
Nous vous suggérons là encore d’attribuer un score de risque d’obsolescence à chaque critère, par exemple de 1 (risque faible) à 9 (risque fort) comme dans l’exemple ci-dessous :
Dans cet exemple, nous avons évalué 4 impacts, avec des scores plus ou moins élevés : l’application présenterait un risque de vulnérabilité et exposerait le système aux attaques. Si l’application devient obsolète, il est fort probable qu’elle ne soit plus conforme et ne réponde plus complètement aux besoins. Elle représente aussi un risque élevé de perte financière pour l’entreprise en cas de défaillance.
Le score global est de 6,3, ce qui est élevé. Il y a donc risque d’impact global assez fort pour l’entreprise si cette application devient obsolète : elle représente un danger pour l’entreprise.
Evaluez l’obsolescence de votre application
La sévérité du risque d’obsolescence
Nous avons évalué 1) le niveau de probabilité d’obsolescence de l’application et 2) l’impact que l’obsolescence peut avoir sur l’entreprise. En croisant ces deux indicateurs, nous pouvons obtenir la sévérité du risque d’obsolescence..
Dans notre exemple nous avons un niveau de probabilité d’obsolescence de 5,3. C’est un niveau de probabilité “moyen” mais tout de même proche de “élevé”. L’impact de l’obsolescence est de 6,3 donc plutôt élevé.
Le croisement des 2 indicateurs nous donne une sévérité du risque élevée. Dans cet exemple, nous sommes face à une application obsolète, à un niveau qui n’est pas loin d’être critique.
Quelles technologies mettre à jour ?
Lorsqu’une application présente un degré d’obsolescence très élevé, cela peut signifier qu’il est trop tard pour l’améliorer. Il sera moins coûteux et moins risqué de développer une nouvelle application en remplacement, avec les méthodes et les technologies adéquates. Mais cette solution “révolutionnaire” est celle du dernier recours, fort heureusement la moins fréquente. Autant que possible, il faut privilégier une méthode d’amélioration par étapes.
Par où commencer ? Il semble évident de prioriser la mise à jour des technologies ayant la probabilité d’obsolescence la plus élevée. Il faut toutefois tenir compte des compétences disponibles pour réaliser les travaux nécessaires, ainsi que de la facilité et/ou de la rapidité de mise à jour.
En conclusion
Vous avez en main les clés d’analyse de l’obsolescence des technologies utilisées pour votre application. Nous vous avons expliqué comment recenser les technologies et évaluer leur pérennité. Nous avons vu sur quels critères vous pouvez évaluer la probabilité d’obsolescence des technologies utilisées et sur quels critères vous pouvez estimer l’impact de l’obsolescence sur votre organisation. En croisant ces deux paramètres, vous pouvez déterminer la sévérité du risque d’obsolescence des technologies pour votre application.
Une application professionnelle vous pose problème ? Vous n’avez pas les compétences en interne ? Vous n’avez pas le temps d’analyser votre application ? AxioCode peut vous aider.
Demandez conseil à un expert ou faites un diagnostic autonome rapide de votre application.
Evaluez l’obsolescence de votre application
Vous pouvez bénéficier de notre service d’audit dédié aux applications web et mobiles. Vous obtiendrez ainsi une étude détaillée de votre application et une feuille de route.
