Audit de maintenabilité applicative : comparer les preuves avant de reprendre un logiciel

Une PME peut hériter d’une application qui fonctionne encore, mais dont la connaissance s’est dispersée. Le développeur historique n’est plus disponible, la documentation date de plusieurs versions et les incidents sont expliqués à partir de souvenirs. Dans cette situation, commander un « audit complet » ne suffit pas : il faut d’abord décider quelles preuves permettront de reprendre le logiciel sans découvrir ses fragilités au premier changement.

Un audit de maintenabilité applicative ne remplace ni un audit de sécurité ni un plan de reprise d’activité. Son objectif est plus ciblé : rendre visible ce qu’il faudra comprendre, modifier, surveiller et transmettre pour maintenir l’application dans la durée. La bonne prestation dépend donc de la décision à prendre, du niveau de dépendance au logiciel et de la qualité des éléments réellement disponibles.

Trois niveaux d’audit selon la décision à prendre

Le premier choix consiste à ne pas confondre un état des lieux documentaire, une analyse technique approfondie et une vérification en conditions d’exploitation. Ces trois niveaux peuvent se compléter, mais ils ne produisent pas les mêmes preuves.

La cartographie convient lorsqu’une nouvelle équipe doit d’abord reprendre la connaissance du système. L’audit technique ciblé devient pertinent lorsqu’un chantier d’évolution, de migration ou de correction est envisagé. La vérification d’exploitation est indispensable lorsque le principal risque concerne la continuité du service, le diagnostic d’incident ou la capacité à réagir sans dépendre d’une seule personne.

Option 1 : commencer par les preuves de reprise

Une prestation de reprise utile commence par les éléments qui permettent à une autre équipe d’agir. Le prestataire doit identifier les dépôts, branches utiles, chaînes de livraison, environnements, bases de données, services externes, certificats, comptes techniques et tâches planifiées. Chaque élément devrait être relié à un propriétaire, une dépendance connue et une procédure observable.

Le résultat attendu n’est pas une liste de technologies. C’est une carte de responsabilités. Qui peut déployer ? Qui valide une migration de données ? Quel service appelle l’application ? Quelle configuration différencie la recette de la production ? Que se passe-t-il si un fournisseur externe ne répond plus ? Une cartographie qui ne permet pas de poser ces questions reste descriptive, mais pas opérationnelle.

Les journaux font partie de cette première preuve. La CNIL recommande de tracer les activités métier, les interventions techniques, les anomalies et les événements de sécurité, en évitant de recopier inutilement des données personnelles.

Dans une reprise applicative, il faut donc vérifier non seulement la présence de logs, mais aussi leur utilité : identifiant de l’acteur, date, heure, action, référence de l’objet concerné, corrélation avec la version déployée et possibilité d’accès par l’équipe qui devra enquêter.

Option 2 : analyser la maintenabilité sans se perdre dans le code

Une revue technique ne doit pas transformer chaque défaut en chantier prioritaire. Elle doit relier les constats à des décisions concrètes : peut-on corriger rapidement un incident ? Ajouter une règle métier sans créer d’effet de bord ? Modifier un flux sans casser un consommateur ? Reproduire un problème dans un environnement maîtrisé ?

Pour obtenir une analyse exploitable, le périmètre peut être organisé autour de quelques axes :

• structure du code et séparation des responsabilités ;
• couverture et pertinence des tests sur les parcours critiques ;
• gestion des configurations et des secrets ;
• dépendances externes, traitements différés et tâches planifiées ;
• déploiement, migrations de données et retour arrière ;
• journalisation, supervision et capacité à relier une erreur à une action.

Cette approche complète un audit de sécurité applicative, mais ne le remplace pas. Une application peut présenter peu de vulnérabilités visibles et rester très difficile à maintenir. À l’inverse, une dette technique importante n’implique pas automatiquement qu’il faille réécrire le logiciel. Le livrable doit donc distinguer les risques bloquants, les risques acceptables à court terme et les améliorations à planifier.

Option 3 : vérifier la continuité par un scénario contrôlé

La troisième option consiste à vérifier ce que l’équipe peut réellement faire lorsqu’un problème survient. L’exercice peut rester limité à un scénario hypothétique : une version doit être retirée, un traitement ne produit plus son résultat attendu ou une dépendance externe devient indisponible. L’objectif n’est pas de simuler une crise spectaculaire, mais d’observer les décisions et les preuves disponibles.

Un scénario de reprise peut vérifier les points suivants :

• identifier le service concerné à partir d’un signal utilisateur ou d’une alerte ;
• retrouver la version, la configuration et les changements récents ;
• déterminer quelles données ont été lues ou modifiées ;
• appliquer une mesure de réduction d’impact documentée ;
• choisir entre correction, relance, compensation et retour arrière ;
• conserver les éléments utiles pour expliquer la décision.

Cette vérification ne produit pas un résultat de performance ou de disponibilité inventé. Elle produit une liste de faits observés : procédure absente, accès manquant, log inutilisable, dépendance inconnue, étape non testée ou responsabilité non attribuée. C’est cette liste qui permet ensuite de demander un devis de remédiation raisonnable.

Une chronologie simple pour cadrer la prestation

1. Décrire la décision à prendre : reprise par une nouvelle équipe, évolution, migration, réduction du risque ou préparation d’un contrat de maintenance.

2. Délimiter le système : application, interfaces, données, environnements, traitements planifiés et services indispensables.

3. Rassembler les preuves disponibles : dépôt, documentation, tickets, configurations, journaux, procédures et historique des incidents.

4. Choisir le niveau d’audit adapté au risque principal, plutôt que demander toutes les analyses simultanément.

5. Faire valider les constats par les responsables métier et techniques, en séparant les faits vérifiés des hypothèses.

6. Transformer les résultats en décisions : corriger maintenant, surveiller, documenter, tester davantage ou accepter temporairement.

Les conclusions peuvent être rapprochées d’une méthode de cadrage des logs de données et d’une recette de non-régression avant mise en production. Ces compléments ne servent pas à multiplier les contrôles, mais à relier l’audit aux décisions qui suivront.

Les livrables à demander dans un devis

Un devis d’audit de maintenabilité devrait préciser le périmètre observé, les accès nécessaires, les entretiens prévus, les environnements examinés et les exclusions. Il doit aussi décrire les livrables de façon vérifiable :

• cartographie applicative et registre des dépendances ;
• liste des risques classés par impact et décision associée ;
• constats reproduisibles, avec leur source ou leur preuve ;
• priorisation des actions sans promesse de gain non mesuré ;
• procédure de diagnostic ou de reprise testée lorsque le périmètre le permet ;
• recommandations de maintenance, de documentation et de recette.

Le bon audit n’est donc pas celui qui produit le rapport le plus volumineux. C’est celui qui permet à une équipe identifiée de savoir quoi reprendre, quoi vérifier et quoi décider avant la prochaine évolution. Pour une PME, cette lisibilité vaut souvent mieux qu’une promesse générale de modernisation.