Audit technique d'une application : la checklist avant de reprendre un projet

Votre application existe, elle tourne, plus ou moins, mais vous avez perdu la maîtrise : le prestataire historique est parti, le développeur qui « savait » a quitté l'entreprise, ou vous envisagez de confier les évolutions à une nouvelle équipe. Avant d'investir un euro de plus, une étape s'impose : l'audit technique. Voici ce qu'il doit couvrir, ce qu'il doit livrer, et comment décider ensuite.

Quand auditer ?

Quatre situations où l'audit n'est pas un luxe mais une assurance :

• Reprise de projet : vous changez de prestataire ou internalisez. L'audit établit l'état réel de ce que vous récupérez.
• Avant d'investir : une refonte ou une évolution majeure se décide sur des faits, pas sur l'intuition de celui qui vend la refonte.
• Incidents à répétition : lenteurs, pannes, bugs récurrents. L'audit remonte aux causes plutôt que d'empiler les rustines.
• Due diligence : rachat d'entreprise ou levée de fonds, quand le logiciel fait partie de la valeur.

Axe 1 : Le code et sa maintenabilité

• Le code est-il versionné (Git), avec un historique exploitable ? Un projet livré en .zip est un signal d'alarme.
• Quelle est la lisibilité réelle : conventions, structure, nommage, commentaires utiles ?
• Y a-t-il des tests automatisés, et couvrent-ils les parcours critiques (paiement, inscription, calculs métier) ?
• Les dépendances sont-elles à jour ? Des bibliothèques abandonnées ou des versions avec vulnérabilités connues ?
• Peut-on installer le projet de zéro en suivant la documentation ? Chronométrez : c'est le meilleur test de la doc.

Axe 2 : L'architecture et les données

• L'architecture est-elle proportionnée au besoin (ni bricolage, ni usine à gaz microservices pour 200 utilisateurs) ?
• Le modèle de données est-il cohérent : intégrité, migrations gérées, pas de champs mystères que plus personne n'ose toucher ?
• Les environnements sont-ils séparés (développement, test, production) avec un déploiement reproductible ?
• Quelles dépendances externes (API tierces, services cloud) et que se passe-t-il si l'une tombe ou change ses tarifs ?
• Les sauvegardes existent-elles, et ont-elles déjà été testées en restauration ? Une sauvegarde jamais restaurée n'est pas une sauvegarde.

Axe 3 : La sécurité

• Authentification et gestion des droits : qui peut voir et faire quoi, et est-ce vérifié côté serveur ?
• Données personnelles : conformité RGPD, chiffrement en transit et au repos, localisation de l'hébergement.
• Secrets (mots de passe, clés d'API) : stockés proprement ou écrits en dur dans le code ?
• Vulnérabilités classiques : injections, failles XSS/CSRF, uploads non contrôlés, dépendances vulnérables.
• Journalisation : peut-on savoir qui a fait quoi en cas d'incident ?

Axe 4 : La performance et l'exploitation

• Temps de réponse réels sur les parcours critiques, à charge normale et en pointe.
• Requêtes de base de données problématiques (N+1, absence d'index), souvent 80 % des lenteurs.
• Monitoring : sait-on que l'application est en panne avant que les clients n'appellent ?
• Coûts d'infrastructure : proportionnés à l'usage, ou hérités d'un dimensionnement au doigt mouillé ?

Dette technique : mesurer sans dramatiser

Toute application en production a de la dette technique. C'est normal, elle témoigne que le produit a vécu. La question n'est pas « y a-t-il de la dette ? » mais « où bloque-t-elle concrètement ? » : les évolutions qui prennent trois fois trop de temps, les zones que personne n'ose modifier, les bugs qui reviennent. Un bon audit hiérarchise la dette par impact business, pas par pureté technique.

Le livrable d'un bon audit

Méfiez-vous des audits qui concluent systématiquement « tout est à refaire », surtout quand celui qui audite vend la refonte. Un livrable sérieux contient :

1. Une synthèse lisible par un dirigeant (2 pages) : état général, risques majeurs, décision recommandée.
2. Un état des lieux factuel par axe (code, architecture, sécurité, performance), avec preuves.
3. Un plan d'action priorisé : quick wins (jours), chantiers moyens (semaines), fond (mois), chacun avec effort estimé et bénéfice attendu.
4. Une recommandation claire : reprendre, stabiliser puis évoluer, ou refaire (et pourquoi).

Durée typique : 2 à 5 jours pour une application de taille PME, avec accès au code, à un environnement de test et aux personnes clés.

Et après : reprendre, stabiliser ou refaire ?

Dans la majorité des cas, la bonne réponse n'est pas la refonte totale (longue, risquée, coûteuse) mais la reprise progressive : stabiliser d'abord (sauvegardes, monitoring, correctifs critiques), documenter, puis faire évoluer par étapes. La refonte ne s'impose que quand les fondations bloquent réellement le métier, et l'audit doit le démontrer, pas l'affirmer. Pour le renfort qui suit (quelques jours par semaine, ou un CTO à temps partagé), voir CTO externalisé ou lead développeur freelance.

C'est exactement le type de mission que mène Web-Jungle en reprise de projet et direction technique : audit en quelques jours (au forfait, à partir de 1 500 € HT, prix affiché), plan d'action priorisé, puis reprise du projet si vous le souhaitez, avec le code documenté et la main rendue à vos équipes. Si votre prestataire a disparu avec les accès, cet article détaille comment reprendre la main.

Une application à auditer ou à reprendre ? Réserver mon appel gratuit (30 min).