Ce que comprend l'audit technique d'une application web, et quand en faire un

Points clés

• Un audit technique est une évaluation indépendante et écrite d'une application web : comment elle est construite, où sont les risques et quoi corriger, dans quel ordre.
• Un audit utile couvre l'architecture, le code, la sécurité, l'infrastructure et l'exploitation, pas seulement les résultats d'outils d'analyse automatique.
• La partie la plus précieuse du livrable est le plan priorisé : des constats classés par risque et par effort, rédigés pour que n'importe quelle équipe compétente puisse agir.
• L'audit type d'une application web métier prend 2 à 3 semaines avec un ou deux ingénieurs seniors et coûte 5 000 à 15 000 € HT.
• Un audit est le plus rentable avant une grande décision : un investissement ou un rachat, une montée en charge, un changement d'équipe ou une réécriture envisagée.

Quand vous dépendez d'un logiciel que vous n'avez pas écrit, ou que vous ne savez pas lire facilement, il est difficile de savoir s'il est en bon état. Vos développeurs peuvent dire que tout va bien ; une nouvelle recrue peut dire que tout est cassé. Un audit technique remplace les opinions par une vision structurée et étayée. Voici ce que comprend un bon audit et comment en tirer le meilleur parti.

Qu'est-ce qu'un audit technique ?

Un audit technique est l'examen d'un système logiciel par des ingénieurs indépendants de l'équipe qui l'a construit. Ils lisent le code, examinent l'infrastructure et le processus de déploiement, échangent avec les personnes qui exploitent le système et produisent un rapport écrit de constats et de recommandations.

Il se distingue d'activités voisines :

Un audit comprend une revue de sécurité du code et de la configuration, mais ce n'est pas un test d'intrusion offensif. Si vous en avez besoin, il se cadre séparément.

Quand en avez-vous besoin ?

• Avant un investissement ou un rachat. La due diligence technique vous dit ce que vous achetez réellement et ce que coûtera son fonctionnement.
• Avant une montée en charge. Sachez ce qui cassera en premier avant que vos utilisateurs ne le découvrent.
• Après un changement d'équipe ou d'agence. Obtenez un état des lieux indépendant au moment où le savoir change de mains.
• Quand vous dépendez d'une équipe externe et voulez un second avis sur son travail.
• Quand les incidents se répètent et que la cause profonde reste floue.
• Quand quelqu'un propose une réécriture. Un audit vous dit si le système peut être repris. Voir reprendre ou réécrire.

Ce que couvre un bon audit

Architecture

• Le découpage du système en composants, et la clarté des responsabilités.
• Le modèle de données : représente-t-il fidèlement l'activité, et tiendra-t-il quand elle évoluera ?
• Les intégrations : comment les systèmes externes sont connectés, et ce qui se passe quand ils tombent en panne.
• La tenue en charge : où apparaîtront les goulets d'étranglement quand l'usage augmentera.

Qualité du code et maintenabilité

• Lisibilité et cohérence : un nouvel ingénieur peut-il comprendre et modifier le code sans risque ?
• La couverture de tests des comportements les plus importants.
• La santé des dépendances : bibliothèques obsolètes, abandonnées ou vulnérables.
• Les duplications, le code mort et les zones que tout le monde a peur de toucher.

Sécurité

• L'authentification et la gestion des sessions.
• Les autorisations : les règles d'accès sont-elles appliquées de façon cohérente, ou dispersées dans le code ? Nous expliquons pourquoi c'est important dans structuring authorization (en anglais).
• Le traitement des entrées et les grandes familles de failles, comme celles du Top 10 de l'OWASP. Le contrôle d'accès défaillant est la première catégorie de la liste (OWASP A01), et c'est aussi le constat grave le plus fréquent dans nos audits.
• Pour une liste plus systématique, l'OWASP Application Security Verification Standard définit des exigences de sécurité vérifiables par niveau.
• La gestion des secrets : identifiants dans le code, les journaux ou des documents partagés.
• L'exposition aux failles connues des frameworks et dépendances. React2Shell (en anglais) montre à quelle vitesse une faille de framework est exploitée.

Infrastructure et exploitation

• L'hébergement, les environnements et la configuration.
• Le déploiement : est-il reproductible, ou dépend-il de l'ordinateur d'une seule personne ?
• Les sauvegardes : existent-elles, et quelqu'un a-t-il testé leur restauration ?
• Supervision, journaux et alertes : sauriez-vous qu'il y a un problème avant vos clients ?
• La performance de livraison : à quelle fréquence l'équipe déploie, combien de temps une modification met à arriver en production, et à quelle fréquence elle échoue. Les indicateurs DORA (en anglais) offrent un vocabulaire commun utile.
• L'historique des incidents et les procédures de reprise.

Contexte produit et organisation

• La façon de travailler de l'équipe : mises en production, relectures, documentation.
• Les endroits où l'activité souffre le plus, pour relier les constats à un impact réel.

Combien de temps dure un audit, et combien coûte-t-il ?

Pour une application web métier courante, un audit technique prend 2 à 3 semaines avec un ou deux ingénieurs seniors et coûte 5 000 à 15 000 € HT. Les principales variables sont la taille du code, le nombre de services et d'intégrations, et la part d'infrastructure à examiner. Une revue de sécurité ciblée sur une seule application peut être plus courte ; une due diligence sur une plateforme à nombreux services prend plus de temps.

Dans les audits que nous avons menés en 2025 et 2026, les rapports comptaient entre 25 et 60 constats, dont généralement 4 à 8 jugés critiques ou élevés. La plupart des constats critiques concernaient les autorisations, la gestion des secrets et des sauvegardes jamais testées, plutôt que des failles exotiques.

Ce que vous devez recevoir

• Une synthèse pour les décideurs non techniques : état général, principaux risques, prochaines étapes recommandées.
• Des constats détaillés, chacun avec des preuves, un niveau de gravité et une recommandation concrète.
• Un plan de remédiation priorisé, qui distingue ce qu'il faut corriger tout de suite, ce qu'il faut planifier et ce qui peut attendre.
• Une séance de restitution pour discuter des constats et répondre aux questions.

Le test d'un bon rapport : une équipe compétente que vous n'avez jamais rencontrée pourrait-elle agir à partir de lui, sans les auditeurs dans la pièce ?

Comment se préparer

1. Donnez un accès en lecture aux dépôts de code source.
2. Décrivez l'infrastructure : hébergement, services, environnements, outils tiers.
3. Prévoyez du temps avec quelqu'un qui connaît le système pour quelques échanges.
4. Partagez les problèmes connus et l'historique des incidents. Les auditeurs trouvent davantage quand ils savent où ça fait mal.
5. Précisez la décision que l'audit doit éclairer : un investissement, une montée en charge, une réécriture, un changement de prestataire. Elle oriente ce qui reçoit le plus d'attention.

Un accès à la production est rarement nécessaire, et quand il l'est, il doit être délimité et convenu à l'avance.

Ce qui se passe après l'audit

Le rapport n'est utile que si quelqu'un agit. Les suites habituelles :

• Votre équipe corrige les constats, en suivant le plan priorisé.
• Les auditeurs aident sur les points critiques, en particulier la sécurité et la stabilisation.
• Le système a besoin d'une remise en état plus profonde, et l'audit devient la première phase d'une reprise d'application.

Aucune de ces suites ne doit conditionner l'audit lui-même. Un audit indépendant n'est indépendant que s'il n'engage à rien.

Questions fréquentes

Un audit va-t-il perturber mon équipe ? Très peu. L'essentiel du travail consiste à lire du code et de la documentation ; votre équipe intervient pour quelques échanges et pour répondre aux questions.

Un outil d'analyse automatique suffit-il ? Les scanners sont utiles pour repérer les failles connues des dépendances, mais ils ne peuvent pas juger l'architecture, le modèle de données, la maintenabilité ni la pertinence des règles d'accès pour votre activité. Un bon audit utilise ces outils et va au-delà.

Combien de temps prend un audit technique ? Deux à trois semaines pour une application web métier courante, avec un ou deux ingénieurs seniors. Les plateformes plus grandes, avec de nombreux services, peuvent demander quatre à six semaines.

À quelle fréquence faut-il auditer ? Aux grandes étapes de décision, et quand le système ou l'équipe change significativement. Pour un système critique, une revue périodique évite que de petits problèmes ne s'accumulent.

---

Vous voulez un regard indépendant sur votre code avant une décision importante ? Découvrez notre offre d'audit technique, ou parlons-en. Si vous choisissez qui travaillera ensuite sur le système, notre comparaison entre agence, freelance et équipe interne peut vous aider, et notre guide des prix couvre les budgets de remise en état.

Sources

• OWASP, Top 10 Web Application Security Risks et A01: Broken Access Control (en anglais)
• OWASP, Application Security Verification Standard (en anglais)
• DORA, DORA's software delivery metrics: the four keys (en anglais)