MaintenanceMéthodeChoisir un prestataireApplication métier
Auditer une application existante avant de la reprendre
7 min de lecture
Auditer une application avant de la reprendre, c'est vérifier six choses : le code, ses dépendances, la sécurité, les données, l'hébergement et la documentation. L'objectif n'est pas de noter le travail du prestataire précédent, mais de répondre à une question de dirigeant : peut-on faire évoluer cette application sans risque, et à quel coût, ou vaut-il mieux la reconstruire ? Un bon audit se termine par une recommandation écrite et argumentée.
Cet article détaille ce qu'il faut examiner, ce que doit contenir le livrable, et comment trancher entre reprise et refonte.
Quand un audit s'impose
Quatre situations reviennent souvent :
- le prestataire s'arrête ou ne répond plus, et une autre équipe doit prendre le relais ;
- le développeur interne part, en laissant une application que personne d'autre ne connaît ;
- vous rachetez une entreprise ou un logiciel, et l'application fait partie de ce que vous payez ;
- l'application ralentit, plante ou coûte de plus en plus cher à faire évoluer, sans que personne sache dire pourquoi.
Dans tous ces cas, la tentation est de demander directement un devis d'évolution. C'est prématuré : un prestataire qui chiffre sans avoir lu le code chiffre une hypothèse. L'audit transforme cette hypothèse en constat.
Les six domaines à examiner
| Domaine | Ce qu'on vérifie | Signal d'alerte |
|---|---|---|
| Code | Lisibilité, structure, tests | Personne ne peut expliquer un module |
| Dépendances | Versions, failles connues, licences | Versions en fin de support |
| Sécurité | Accès, données exposées, secrets | Mots de passe dans le code |
| Données | Modèle, qualité, sauvegardes | Restauration jamais testée |
| Hébergement | Comptes, coûts, supervision | Comptes au nom du prestataire |
| Documentation | Installation, déploiement, règles | Aucune procédure écrite |
Le code
L'auditeur ne lit pas tout ligne par ligne : il cherche à savoir si une autre équipe peut comprendre et modifier le code sans tout casser. La norme ISO/IEC 25010, dont la version de 2023 décrit neuf caractéristiques de qualité d'un logiciel, range sous la maintenabilité la modularité, la réutilisabilité, l'analysabilité, la modifiabilité et la testabilité. C'est une bonne grille : le code est-il découpé en parties indépendantes, les règles métier sont-elles lisibles, existe-t-il des tests automatisés qui préviennent une régression ?
Le langage et le framework comptent aussi. Une application écrite avec des outils courants et documentés trouve facilement une équipe de reprise ; un framework abandonné ou une surcouche maison la rend dépendante de ceux qui l'ont écrite.
Les dépendances
Une application moderne assemble des dizaines, souvent des centaines, de bibliothèques externes. Chacune peut avoir une faille connue ou ne plus être maintenue. L'OWASP, la fondation de référence en sécurité applicative, place d'ailleurs les défaillances de la chaîne d'approvisionnement logicielle au troisième rang de son Top 10 2025.
Des outils d'analyse de composition (SCA), comme OWASP Dependency-Check, listent les dépendances et signalent celles qui ont des vulnérabilités publiquement connues. Le résultat peut prendre la forme d'une nomenclature logicielle (SBOM), que l'agence américaine de cybersécurité CISA décrit comme une liste des ingrédients qui composent un logiciel.
Il faut aussi vérifier les versions du socle. Le projet Node.js, par exemple, recommande de n'utiliser en production que des versions encore maintenues ; une application restée sur une version en fin de vie ne reçoit plus de correctifs de sécurité. Enfin, l'audit relève les licences des composants open source, dont certaines imposent des obligations en cas de redistribution.
La sécurité
L'audit de sécurité d'une reprise n'est pas un test d'intrusion complet, mais il doit couvrir les points qui coûtent cher : contrôle des accès (un utilisateur peut-il voir les données d'un autre ?), stockage des mots de passe, secrets écrits en clair dans le code, données exposées par l'API, journalisation. Le référentiel OWASP ASVS, dont la version 5.0 est parue en mai 2025, fournit une liste d'exigences vérifiables sur laquelle s'appuyer. Nous détaillons les priorités dans les essentiels de la sécurité d'une application métier.
Les données
Les données valent souvent plus que le code. L'audit vérifie le modèle (les tables ont-elles un sens, les doublons sont-ils fréquents ?), les sauvegardes et surtout leur restauration : une sauvegarde jamais restaurée est une hypothèse. Si l'application traite des données personnelles, c'est aussi le moment de vérifier qu'elles figurent au registre des activités de traitement que la CNIL demande de tenir, et que les durées de conservation sont appliquées.
L'hébergement
Qui détient les comptes ? C'est la question la plus simple et la plus souvent mal réglée. Hébergeur, nom de domaine, services d'envoi d'e-mails, paiement, stockage de fichiers : chaque compte au nom de l'ancien prestataire est un point de blocage. L'audit liste ces comptes, leurs coûts mensuels, la supervision en place et la procédure de déploiement. Notre article sur la réversibilité détaille ce qu'il faut pouvoir récupérer.
La documentation
Le test est concret : une personne extérieure peut-elle installer l'application sur son poste et la déployer à partir des seuls documents fournis ? Si la réponse est non, la reprise passera par une phase de découverte, qu'il faut chiffrer.
Le livrable : ce que vous devez recevoir
Un audit utile ne se résume pas à une note globale ni à une liste de centaines d'alertes produites par un outil. Le rapport doit contenir :
- un résumé lisible par un dirigeant, en une page : l'état général, les trois risques principaux, la recommandation ;
- un état des lieux par domaine, avec les constats et leurs preuves (fichier, version, capture) ;
- les risques classés par gravité, en distinguant ce qui est urgent (une faille exploitable, une sauvegarde absente) de ce qui peut attendre ;
- un plan d'action : ce qu'il faut corriger avant toute évolution, et dans quel ordre ;
- une recommandation argumentée entre les options décrites plus bas.
Les problèmes relevés ne sont pas tous des fautes. Une partie relève de la dette technique, ces raccourcis pris à un moment pour aller vite, qui se remboursent avec intérêts. Nous l'expliquons sans jargon dans la dette technique expliquée à un dirigeant.
Reprendre, remettre à niveau ou reconstruire
| Option | Quand la choisir | Risque principal |
|---|---|---|
| Reprise en l'état | Code sain, socle à jour, documentation correcte | Faible |
| Reprise avec remise à niveau | Code compréhensible, dépendances ou sécurité à traiter | Coût de remise à niveau sous-estimé |
| Refonte progressive | Certaines parties saines, d'autres non | Coexistence de deux systèmes |
| Reconstruction | Socle abandonné, code incompréhensible, données saines | Reproduire les erreurs de l'ancienne version |
La reconstruction n'est pas un échec : quand le socle technique n'est plus maintenu, elle coûte parfois moins cher, sur trois ans, qu'une remise à niveau qui n'en finit pas. Mais elle ne se décide pas sur une impression. L'ancienne application reste précieuse : elle montre ce qui est réellement utilisé et devient un excellent cahier des charges. Notre article sur la refonte d'un logiciel métier qui n'est plus maintenu détaille cette démarche.
Deux règles évitent les mauvaises décisions. Récupérez d'abord les données : quelle que soit l'option, elles doivent être exportables et compréhensibles. Séparez l'audit de la vente : si l'équipe qui audite est aussi celle qui reprendra, demandez un rapport écrit dont chaque recommandation repose sur un fait vérifiable, et faites-le relire si l'enjeu le justifie.
Préparer l'audit pour qu'il soit rapide
L'essentiel du temps d'un audit part souvent en demandes d'accès. Avant de commencer, réunissez :
- l'accès en lecture au dépôt de code complet, avec son historique ;
- les accès à l'hébergement, au nom de domaine et aux services tiers ;
- une copie anonymisée ou un accès en lecture à la base de données ;
- les contrats passés avec l'ancien prestataire, pour savoir ce qui vous a été cédé (voir la propriété du code source) ;
- une personne qui connaît l'usage réel de l'application et ses irritants.
Par où commencer
Si vous devez reprendre une application, commencez par vérifier ce que vous pouvez obtenir : le code, les accès, les données. Chez LPR Studio, nous partons de l'existant plutôt que de le juger sur sa réputation, puis nous traduisons la décision en écrans concrets. Si une refonte s'impose, le prototype visuel de la nouvelle version est gratuit et présenté en visio sous 5 jours ouvrés, avant tout engagement. Les trois façons de financer la suite sont décrites sur la page des offres.