Audit de code avant reprise : ce qu'on regarde et ce que ça révèle
31/08/2026
Reprendre une application développée par une autre équipe revient à acheter une maison sans visite. Elle tient debout, on voit la façade, et on ignore tout de la charpente. L'audit de code est la visite technique : il dit ce qui est sain, ce qui va lâcher, et ce que coûtera la remise à niveau.
Cet article décrit les sept axes examinés, ce que contient un livrable utile, et les signaux qui indiquent qu'une application ne vaut pas la peine d'être reprise en l'état. Il s'adresse autant à celui qui hérite d'une application qu'à celui qui hésite entre garder son prestataire et en changer.
Pourquoi auditer avant de s'engager
Un contrat de maintenance signé sans audit repose sur une hypothèse : que l'application est dans un état normal. Quand elle ne l'est pas, deux issues, toutes deux mauvaises.
Soit le prestataire découvre l'ampleur du travail après la signature et passe ses premiers mois à rattraper l'existant au lieu de maintenir, ce que le client vit comme une facturation sans contrepartie. Soit il a prévu large dans son prix, et le client paie une prime de risque sur une application qui allait finalement bien.
L'audit supprime cette incertitude pour les deux parties. Il transforme une négociation à l'aveugle en discussion sur des faits. C'est aussi pour cette raison qu'un prestataire qui accepte de reprendre n'importe quelle application sans regarder le code n'est pas rassurant.
Les 7 axes examinés
1. La sécurité
Le premier axe, parce que c'est celui dont les conséquences sont les plus lourdes. On cherche les failles classiques : contrôle d'accès insuffisant, données sensibles exposées, injections possibles, secrets présents dans le code ou dans l'historique des versions.
Un point mérite une attention particulière sur les applications récentes : le code produit avec l'aide d'outils de génération présente une proportion notable de vulnérabilités, en particulier sur la gestion des droits. Notre article sur la fiabilité du code généré par IA détaille ce que révèlent les analyses sur ce point.
2. Les dépendances
Toute application repose sur des bibliothèques externes. On inventorie leurs versions, on identifie celles qui portent des vulnérabilités connues, et on mesure le retard accumulé.
Ce retard est l'indicateur le plus parlant de l'état d'entretien réel. Une application dont les dépendances n'ont pas bougé depuis deux ans n'a pas été maintenue, quoi qu'en dise le contrat en cours. On regarde aussi si certaines bibliothèques ne sont plus développées, car une dépendance abandonnée devient un cul-de-sac.
3. L'architecture
On regarde comment le code est organisé : séparation des responsabilités, couplage entre les parties, cohérence des choix. L'objectif n'est pas de juger l'esthétique mais la capacité à évoluer.
La question pratique est simple : pour ajouter une fonctionnalité, faut-il toucher un endroit ou quinze ? La réponse détermine le coût de toutes les évolutions à venir.
4. Les tests
On mesure la couverture, mais surtout on lit ce que les tests vérifient réellement. Une couverture élevée composée de tests qui ne vérifient rien de significatif donne une fausse sécurité.
L'absence totale de tests n'est pas rédhibitoire, c'est très courant. Elle change en revanche la méthode de reprise : il faut alors écrire des tests de caractérisation avant de modifier quoi que ce soit, sujet traité dans notre article sur la reprise d'une application non documentée.
5. Les données
Le schéma de la base, sa cohérence, la présence d'un historique de migrations, la qualité des données existantes. On vérifie aussi les sauvegardes, et surtout on teste une restauration.
C'est le point où l'on trouve le plus souvent une mauvaise surprise. Une sauvegarde jamais restaurée n'est pas une sauvegarde, et beaucoup d'applications en production tournent avec ce faux filet depuis des années.
6. Les performances et les coûts
Temps de réponse, requêtes coûteuses, comportement sous charge. On regarde en parallèle la facture d'infrastructure, car une application mal optimisée se paie tous les mois en surdimensionnement.
Ce croisement révèle souvent des économies immédiates, qui financent une partie de la remise à niveau.
7. L'exploitabilité
Le dernier axe est le plus négligé et conditionne tous les autres. Peut-on déployer une correction en sécurité ? Existe-t-il un environnement de test ? Les journaux applicatifs permettent-ils de comprendre un incident ? Sait-on quand l'application tombe, ou l'apprend-on par un utilisateur ?
Une application impossible à déployer sans risque est une application qu'on ne corrigera pas, même en sachant quoi corriger.
Le livrable attendu
Un audit dont le résultat est un avis oral ne sert à rien. Le livrable utile tient en quatre parties.
Un état des lieux par axe, qui dit ce qui va, ce qui ne va pas, et à quel point. Une liste de corrections hiérarchisée par urgence réelle, en distinguant ce qui menace la sécurité ou la continuité de ce qui relève du confort. Un chiffrage de la remise à niveau, séparant ce qui est indispensable avant d'entrer en maintenance de ce qui peut attendre, à mettre en regard du budget de maintenance courant. Une recommandation explicite sur la suite : maintenir en l'état, remettre à niveau puis maintenir, ou reconstruire.
Ce dernier point est celui qui engage. Un audit qui conclut systématiquement qu'il faut tout refaire mérite d'être lu avec méfiance, surtout quand il émane de celui qui refera.
Les signaux qui doivent alerter
Certains constats pèsent plus lourd que d'autres dans la décision de reprendre ou non.
- Aucun historique de versions. Sans historique, on hérite d'un état sans savoir comment il a été atteint, et le coût d'appropriation grimpe fortement.
- Des secrets en clair dans le code. Au delà de la faille, c'est un indicateur de pratiques générales, et ce qu'on trouve en surface annonce ce qu'on trouvera en profondeur.
- Une base de données sans migrations. Toute évolution du schéma devient une opération manuelle risquée.
- Aucun environnement de test. Chaque correction se déploie alors directement en production.
- Des dépendances abandonnées au cœur du système. Elles imposeront tôt ou tard une réécriture partielle, à un moment que vous ne choisirez pas.
Un ou deux de ces signaux se traitent. Quatre ou cinq ensemble orientent vers une reconstruction progressive plutôt que vers une maintenance classique. La décision entre les deux est développée dans notre article sur le choix entre reprendre et refaire.
Comment nous procédons
Nous commençons par un cadrage court et gratuit : la taille de l'application, sa technologie, son criticité, et l'accès dont vous disposez au code. Cet échange suffit à dire si l'audit a du sens et à en fixer la durée.
L'audit lui-même prend en général de trois à huit jours selon la taille du système, et se déroule sur le code réel, pas sur une présentation. Nous demandons un accès en lecture au dépôt, un accès à l'infrastructure si possible, et un entretien avec quelqu'un qui connaît le fonctionnement métier, même de manière non technique.
Le livrable vous appartient, y compris si vous décidez de confier la suite à quelqu'un d'autre. Un audit qui ne serait exploitable que par son auteur ne serait pas un audit mais un devis déguisé.
Quand l'application est saine, l'audit débouche directement sur un contrat de maintenance applicative. Quand elle ne l'est pas, il débouche sur un chantier de remise à niveau chiffré, puis sur la maintenance une fois le socle assaini. Dans les deux cas, vous savez ce que vous signez.
Questions fréquentes
Qu'est-ce qu'un audit de code avant reprise ?
C'est l'examen d'une application existante pour déterminer son état réel avant de s'engager à la maintenir ou à la faire évoluer. Il couvre la sécurité, les dépendances, l'architecture, les tests, les données, les performances et la capacité à l'exploiter au quotidien.
Combien de temps prend un audit de code ?
Généralement de trois à huit jours selon la taille et la complexité de l'application. Un cadrage préalable d'une heure suffit à déterminer la durée nécessaire et à vérifier que l'audit se justifie.
Que faut-il fournir pour réaliser un audit ?
Un accès en lecture au dépôt de code avec son historique, idéalement un accès à l'infrastructure et aux journaux, et un entretien avec une personne qui connaît le fonctionnement métier. À défaut de dépôt, un audit reste possible sur les fichiers déployés, mais le résultat est moins complet.
Un audit conclut-il toujours qu'il faut tout refaire ?
Non, et c'est un mauvais signe quand c'est le cas. La majorité des applications sont maintenables après une remise à niveau ciblée. La reconstruction ne se justifie que face à un cumul de problèmes structurels.
L'audit est-il utile si je garde mon prestataire actuel ?
Oui. Un regard extérieur sur l'état du code donne une base factuelle pour discuter des priorités techniques avec votre équipe en place, en particulier sur la sécurité et la dette accumulée.
Que se passe-t-il après l'audit ?
Vous disposez d'un état des lieux, d'une liste de corrections hiérarchisée et d'un chiffrage. Selon l'état constaté, la suite est soit un contrat de maintenance direct, soit un chantier de remise à niveau préalable, soit une recommandation de reconstruction progressive.