Vétustes, obsolètes, coûteuses, les applications historiques souvent appelées ‘Legacy’ sont généralement peu documentées et d’autant plus difficiles à maintenir que les nouvelles générations connaissent peu voire pas du tout les anciennes technologies (cobol, delphi, powerbuilder, Visual Basic et autres environnements historiques).
Les éléments que l’on pensait immuables nécessitent une part de plus en plus importante du budget rien que pour le maintien en condition opérationnelle, sans même parler d’évolution ou encore de sécurité. Le résultat est que cette dette technologique mange souvent une part significative du budget réduisant la quantité disponible pour les projets innovants ou permettant simplement de faire progresser le système d’information.
Sous la pression des métiers, le passage au cloud semble néanmoins s’imposer pour certaines de ces applications pourtant robustes et éprouvées sur le plan fonctionnel et l’audit d’applications est souvent un bon réflexe.
En effet, il devient de plus en plus crucial pour les DSI de moderniser leurs applications pour :
- Mieux répondre aux besoins métier et aux attentes des utilisateurs
- Être plus réactifs et flexibles
- S’intégrer avec d’autres systèmes
- Tirer parti des nouvelles technologies
- Améliorer la performance des processus métiers
- Répondre aux enjeux de sécurité
- Lutter contre la dégradation progressive des performances
- Parfois pour réduire également des coûts de maintenance qui explosent
- Appréhender l’avenir sereinement et être mieux armé pour prendre le virage de la transformation numérique notamment vers une architecture ouverte plus extensible dans le cloud.
Comment imaginer aujourd’hui une application qui traite des données en volume sans penser à se structurer pour exploiter les avantages du Cloud ?
La question est de savoir : comment conserver la valeur du portefeuille applicatif existant, sans pour autant entraver l’innovation et la flexibilité tout en offrant une expérience utilisateur dans l’air du temps ?
Des stratégies de modernisation ont émergé : Défaire et Remplacer (Rip & Replace), Enlever et Changer (Lift & Shift) et Déplacer et Améliorer (Move & Improve). Alors, en l’occurrence, faut-il :
- Réhéberger une application « en l’état » (lift and shift) sur l’infrastructure cloud en tant que service ?
- Remanier, voire reconstruire, une application pour profiter pleinement du nouvel environnement et de la nouvelle plateforme, dans le but de gagner en agilité ou de faire des économies ?
- Remplacer un système existant par une application SaaS prête à l’emploi (en abandonnant le système actuel) ?
Ces stratégies n’ont ni le même impact ni les mêmes conséquences ou implications, et encore moins le même niveau de risque en cas de difficulté ou d’imprévu, surtout dans un contexte où les ressources techniques de bon niveau sont de plus en plus rares.
Par conséquent, beaucoup de questions se posent sur le respect des bonnes pratiques, la maturité pour prendre le virage du Cloud, et sur le niveau d’investissement et le chemin qu’il reste à parcourir avant de parvenir à une solution satisfaisante.
L’audit d’applications pour répondre à toutes vos questions
L’audit d’applications permet de faire un état des lieux pour savoir où l’on est, en traitant l’ensemble des sujets fondamentaux de l’application
- La méthodologie et les processus de développement
- L’architecture et les technologies utilisées : pour détecter une potentielle obsolescence
- L’état du code
- L’évolutivité de la solution
- La dette technique et son niveau
Si le logiciel est ancien, il est vraisemblable que les approches de programmation utilisées lors de sa conception soient très éloignées de l’état de l’art actuel et cela peut être fortement limitant pour accéder aujourd’hui à des plates-formes plus modernes.
L’audit d’applications permet également de s’assurer
- Que les processus et la méthodologie mis en place puissent supporter une évolution de l’application : DevOps, niveau de couverture de tests, montée en charge, intégration avec d’autres systèmes etc.
- De la possibilité d’un déploiement automatisé de la nouvelle version. En effet, un déploiement manuel peut prendre plusieurs jours dans des cas extrêmes.
Enfin l’audit d’applications doit prévenir des éventuelles incompatibilités avec le futur, notamment au niveau de la conception.
Dans le cas d’une application pour laquelle les coûts de maintenance explosent, on s’interroge plus particulièrement sur :
- L’adaptabilité de la méthodologie et des processus à l’ampleur de l’application et d’autant plus s’ils n’ont pas été revus lors des dernières évolutions
- La potentielle industrialisation avec mise en place de méthodes et d’outils de génie logiciel pour limiter au maximum le processus manuel de maintenance, laborieux, risqué et coûteux.
Il convient aussi d’évaluer le niveau de la dette technique. Lorsque le logiciel se complexifie et que les bonnes pratiques de développement ne sont pas respectées (développement de tests unitaires, documentation, découpage de l’application etc…), la dette technique croit fortement et anormalement.
Dans le cadre d’une démarche d’audit chez SoftFluent, nous étudions chacun des axes suivants : architecture, implémentation, cycle de développement, documentation…
Sur chaque axe, il existe des bonnes pratiques dont nous cherchons à évaluer la mise en œuvre au regard de l’état de l’art des méthodes actuelles, avec par exemple une échelle pouvant être celle-ci :
- Vide : Non applicable
- 0 : Notion Inexistante dans le projet / Manquement grave
- 1 : Réalisation inadaptée ou non conforme aux standards nécessitant un travail en profondeur en urgence
- 2 : Insuffisance induisant un risque opérationnel. Des points de remédiations doivent être pris en compte à court terme
- 3 : Risque modéré ou maîtrisé. Des points de remédiations doivent être pris en compte à moyen terme.
- 4 : Sujet présentant des anomalies mineures n’impactant pas le fonctionnement de la solution. Remédiations non urgentes
- 5 : Ne présente pas de lacunes particulières, conforme aux besoins
SoftFluent mène ensuite les étapes de revue de l’application :
- Revue d’architecture sur la base du code et vérification de la cohérence avec les documents et règles édictées,
- Interviews des interlocuteurs clés,
- Revue des techniques de codage, avec utilisation de divers outils d’analyse jugés nécessaires suivant le contexte : Outils d’analyse statiques comme l’analyse statique de code intégrés à Visual Studio ou NDepend, comptage de lignes de code, analyse de dépendances, etc…
- Sélection des points significatifs à remonter et d’exemples pertinents.
En fonction des résultats obtenus, SoftFluent propose des pistes de réflexion sur le futur de l’application :
- Identification des parties à conserver et des parties à migrer,
- Pistes de réécriture et/ou de refonte,
- Préconisations sur les technologies à utiliser ou à envisager,
- Recommandations d’architecture évolutive flexible et maintenable dans le temps.
- Conseils d’organisation ou de méthodologie
- Préconisations en matière de processus Devops
- Alimentation de la réflexion sur la stratégie globale d’évolution du patrimoine logiciel
D’expérience, l’audit d’applications ‘legacy’ est souvent le point de départ d’une nouvelle ère qui permet de transformer significativement l’approche de nos clients pour passer un cap important qu’il soit technologique mais également de maturité de l’équipe en matière de méthodes.
