Évaluation des vulnérabilités de sécurité : le guide complet

Une évaluation des vulnérabilités de sécurité est un contrôle structuré qui repère les points faibles d’une application et en évalue la gravité. Pour autant, ses résultats ne vous disent pas quelles failles un attaquant pourrait réellement exploiter. Cette preuve, ce sont les services de tests d’intrusion qui l’apportent : des spécialistes y mènent de véritables attaques dans des conditions maîtrisées.

Détecter les faiblesses tôt est devenu plus urgent. Dans le 2026 Data Breach Investigations Report de Verizon, les vulnérabilités logicielles ont dépassé les mots de passe volés comme principal point d’entrée dans une entreprise, avec 31 % des violations de données.

Le sujet souffre aussi d’un problème de vocabulaire, car beaucoup emploient « évaluation des vulnérabilités » et « évaluation des risques » de manière interchangeable. En réalité, une évaluation des vulnérabilités identifie ce qui est défaillant ou exposé dans votre application, tandis qu’une évaluation des risques mesure l’importance de chaque problème pour votre activité. Ce guide explique la différence, détaille pas à pas une évaluation des vulnérabilités de sécurité et montre où ce contrôle s’intègre dans la QA courante.

Évaluation des vulnérabilités vs évaluation des risques vs tests d’intrusion

Évaluations des vulnérabilités, évaluations des risques et tests d’intrusion sont souvent confondus, car tous trois portent sur des faiblesses de sécurité. Pourtant, chacun répond à une question différente, et connaître ces questions est le moyen le plus rapide de les distinguer :

• Évaluation des vulnérabilités : le National Institute of Standards and Technology (NIST) américain la définit comme un « examen systématique » destiné à « identifier les lacunes de sécurité ». En pratique, une évaluation des vulnérabilités de sécurité passe l’application au crible pour trouver chaque point faible et évalue la gravité de chaque constat.
• Évaluation des risques : le NIST décrit l’évaluation des risques comme un moyen pour les décideurs « d’évaluer et de hiérarchiser les risques ». Ce contrôle croise les faiblesses connues avec les menaces et le contexte métier pour estimer la probabilité d’une attaque et l’ampleur des dégâts qu’elle causerait. Les réponses varient selon les circonstances, car une même faille peut être un problème mineur sur une page de test que personne ne visite, mais un problème urgent sur votre page de paiement.
• Tests d’intrusion : avec votre autorisation, des spécialistes en sécurité tentent de s’introduire dans le système, souvent en passant par les faiblesses les plus graves relevées lors d’une évaluation. Seul un test d’intrusion répond à la question que les deux autres contrôles laissent ouverte : quelqu’un peut-il réellement entrer, et jusqu’où un attaquant pourrait-il aller une fois à l’intérieur ? Cette preuve est la principale raison pour laquelle les tests d’intrusion sont importants, même pour les équipes qui lancent déjà des scans fréquents.

Le tableau ci-dessous compare les trois en un coup d’œil.

Pourquoi un test d’intrusion doit suivre l’évaluation

Un test d’intrusion mené après une évaluation des vulnérabilités montre aussi si les scores de gravité étaient justes. Par exemple, une faiblesse notée « moyenne » peut se révéler être un maillon d’une chaîne d’attaques qui aboutit aux données clients, tandis qu’une faille « critique » peut se trouver derrière une page de connexion qu’aucune personne extérieure ne peut atteindre. Chaque surprise est remontée à l’équipe d’évaluation, qui classe ensuite plus justement les problèmes similaires la fois suivante. Si vous hésitez encore, les compromis entre tests d’intrusion et analyse des vulnérabilités se résument à la profondeur, au budget et au calendrier.

Le processus d’évaluation des vulnérabilités de sécurité en cinq étapes

Les prestataires de sécurité découpent ce travail en cinq à huit étapes, mais le terrain couvert reste le même. Le processus d’évaluation des vulnérabilités ci-dessous en est la forme la plus courte : il montre ce qui se passe à chaque étape et ce que vous devez recevoir à la fin.

Étape 1 : définir ce qui sera contrôlé

Toute évaluation des vulnérabilités de sécurité commence par un périmètre écrit, car l’équipe ne peut contrôler que ce que chacun a accepté d’inclure. Ce document liste les applications, les fonctionnalités et les types d’utilisateurs concernés. Les rôles utilisateurs méritent une attention particulière, car un client, un agent du support et un administrateur voient chacun une version différente de la même application. Une faille peut donc ne toucher qu’un seul type de compte, tandis que les deux autres n’y sont jamais confrontés. Les composants tiers ont aussi leur place dans le périmètre, c’est-à-dire les bibliothèques de code prêtes à l’emploi et les services externes sur lesquels repose votre application. Votre équipe n’a pas écrit ces éléments, si bien que leurs failles passent facilement inaperçues si personne ne les vérifie délibérément. Le document doit aussi préciser ce qui est exclu, comme les systèmes propres d’un prestataire de paiement, que vous n’avez pas l’autorisation de tester.

Étape 2 : scanner l’application et l’examiner manuellement

Une fois le périmètre validé, des outils automatisés effectuent un premier passage. Certains analysent le code source à la recherche de schémas risqués, tandis que d’autres sondent l’application en fonctionnement comme le ferait le navigateur d’un attaquant. En parallèle, des outils d’analyse des dépendances comparent vos composants tiers à des bases de données publiques de failles connues. La référence en la matière est la liste Common Vulnerabilities and Exposures, où chaque faille divulguée possède son propre identifiant. Cette étiquette permet à un rapport de scan de désigner le problème exact.

Cependant, la détection par motifs ne repère que les problèmes déjà rencontrés. Les contrôles automatisés passent donc à côté des failles de logique métier, c’est-à-dire des règles qui déterminent ce que les utilisateurs peuvent faire dans votre application. Par exemple, un scanner ne remarquera généralement pas que votre tunnel de paiement accepte n’importe quel prix renvoyé par le navigateur. Quiconque modifie ce montant avec les outils intégrés au navigateur pourrait alors payer moins que le total réel. Un testeur qui parcourt le tunnel de paiement cherche justement ce type de faille. C’est à cause de cet angle mort que nous menons chaque évaluation des vulnérabilités de sécurité selon une séquence fixe. D’abord, nous cartographions les chemins qu’un attaquant pourrait emprunter pour pénétrer dans l’application. Ensuite, nous lançons les outils et confirmons les constats manuellement.

Étape 3 : éliminer les fausses alertes

Les scanners signalent tout ce qui ressemble à un problème connu, si bien qu’un rapport brut contient généralement des faux positifs. Ces alertes pointent des problèmes qui n’existent pas dans votre configuration ou qui sont inaccessibles. Avant que le rapport ne parvienne à vos développeurs, un spécialiste en sécurité examine chaque constat et élimine le bruit. Cette vérification ajoute aussi le contexte qu’aucun outil ne voit, par exemple si la page concernée est publique ou protégée par une connexion. Ce passage supplémentaire fait gagner à vos développeurs des jours qu’ils auraient sinon passés à traquer des alertes qui n’ont jamais été réelles.

Étape 4 : classer les constats par gravité et probabilité

Même une fois les fausses alertes écartées, la liste est généralement plus longue que ce qu’une équipe peut traiter d’un coup. Le 2026 State of Software Security report de Veracode a révélé que 82 % des organisations accumulent déjà une dette de sécurité, c’est-à-dire des failles laissées ouvertes pendant plus d’un an : décider quoi corriger en premier est donc essentiel. Trois ressources publiques aident à fixer ces priorités :

• Gravité : le Common Vulnerability Scoring System évalue la gravité d’une faiblesse sur une échelle de 0 à 10.
• Probabilité d’attaque : l’Exploit Prediction Scoring System estime la probabilité qu’une faille publiée soit ciblée dans les 30 prochains jours.
• Menaces actives : un catalogue des vulnérabilités exploitées connues, publié par l’agence américaine Cybersecurity and Infrastructure Security Agency, recense les failles que des criminels exploitent déjà.

Cependant, aucun de ces scores ne sait quoi que ce soit de votre activité. Une évaluation des risques comble cette lacune en mettant chaque constat en regard de ce qu’une attaque pourrait réellement vous coûter.

Étape 5 : corriger les problèmes, puis vérifier les correctifs

Une fois l’ordre établi, le rapport d’évaluation des vulnérabilités de sécurité donne aux développeurs tout ce dont ils ont besoin pour agir : chaque faiblesse confirmée, sa note, les étapes pour la reproduire et un correctif recommandé. L’équipe traite ensuite la liste en commençant par le haut, et les testeurs revérifient chaque modification dès qu’elle est livrée. Sans ce second regard, un correctif pourrait combler une brèche tout en en ouvrant une autre, ou casser une fonctionnalité qui marchait jusque-là. Un constat n’est considéré comme clos qu’une fois que les testeurs ont confirmé la disparition de la faiblesse.

Les vulnérabilités applicatives courantes à évaluer

Une fois le processus clarifié, reste à savoir quoi vérifier. Une communauté à but non lucratif, l’Open Worldwide Application Security Project (OWASP), offre un bon point de départ. Elle publie l’OWASP Top 10, un classement des risques de sécurité des applications web les plus critiques. L’édition actuelle date de 2025, et ses dix entrées constituent une checklist pratique pour toute évaluation des vulnérabilités de sécurité :

1. Contrôle d’accès défectueux : les utilisateurs peuvent voir des données ou effectuer des actions qui devraient leur être interdites, par exemple ouvrir la facture d’un autre client en changeant un numéro dans l’adresse web. L’édition 2025 inclut également dans cette catégorie la falsification de requêtes côté serveur. Dans cette attaque, quelqu’un pousse votre système à récupérer des pages pour son compte.
2. Mauvaise configuration de sécurité : mots de passe par défaut, messages d’erreur trop détaillés et stockage cloud laissé accessible au public offrent aux attaquants une porte d’entrée facile.
3. Défaillances de la chaîne d’approvisionnement logicielle : les risques s’introduisent par le code prêt à l’emploi, les outils de build et les mises à jour que votre équipe n’a pas écrits.
4. Défaillances cryptographiques : un chiffrement faible ou absent rend les mots de passe et les données de paiement lisibles par quiconque les intercepte.
5. Injection : l’application traite la saisie d’un attaquant comme une commande. L’injection SQL le fait sur les bases de données, et le cross-site scripting le fait dans les navigateurs des autres utilisateurs.
6. Conception non sécurisée : la faille réside dans la conception elle-même, si bien qu’aucun codage, aussi rigoureux soit-il, ne pourra la corriger ensuite.
7. Défaillances d’authentification : une gestion faible des connexions et des sessions permet aux attaquants de deviner des mots de passe ou de prendre le contrôle de comptes.
8. Défaillances d’intégrité des logiciels ou des données : l’application fait confiance à des mises à jour, des plugins ou des données sans vérifier leur provenance.
9. Défaillances de journalisation et d’alerte de sécurité : les attaques passent inaperçues parce que personne n’enregistre ni n’examine les activités suspectes.
10. Mauvaise gestion des conditions exceptionnelles : l’application échoue de manière non sécurisée face à un événement imprévu, par exemple en exposant des données après qu’un service de paiement a cessé de répondre.

La place de l’évaluation des vulnérabilités dans la QA

Les cinq étapes décrites plus haut constituent un contrôle ponctuel, dont les résultats deviennent vite obsolètes. Beaucoup d’entreprises traitent encore l’évaluation des vulnérabilités de sécurité comme un audit annuel. Or leurs applications reçoivent des mises à jour toutes les quelques semaines, et un contrôle annuel ne peut pas suivre ce rythme. Les attaquants ont eux aussi accéléré. L’équipe Mandiant de Google a indiqué dans M-Trends 2026 que le délai moyen d’exploitation d’une vulnérabilité est passé sous zéro, à environ -7 jours. Autrement dit, les attaques commencent régulièrement avant même qu’un correctif n’existe.

Une meilleure approche fait de l’évaluation une composante régulière de la QA, avec une profondeur adaptée à votre fréquence de livraison :

• À chaque modification du code : des contrôles automatisés du code et des composants s’exécutent en même temps que vos autres tests et signalent les nouveaux problèmes en quelques minutes.
• À chaque version : un scan de l’application en fonctionnement et une revue manuelle couvrent les fonctionnalités modifiées.
• Avant un lancement majeur ou un audit : une évaluation complète de toute l’application passe en premier, suivie d’un test d’intrusion.

Ce rythme s’inscrit dans une pratique plus large appelée test shift-left. L’idée est de détecter les problèmes dès les premières étapes d’un projet, tant que le code est encore frais dans l’esprit du développeur. Des contrôles réguliers évitent aussi un goulet d’étranglement juste avant le lancement. Dans cet esprit, notre équipe de tests de sécurité intègre ce travail à votre calendrier de livraison existant, pour que les revues ne retardent jamais la mise en production.

Pour les entreprises qui vendent dans l’UE, l’évaluation régulière a désormais aussi une dimension juridique. Depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants de signaler toute vulnérabilité de leur produit activement exploitée par des attaquants. Une alerte précoce doit être envoyée dans les 24 heures suivant sa découverte. Une équipe qui contrôle déjà chaque version a plus de chances de trouver ses propres faiblesses avant même que ce compte à rebours ne commence.

Comment nous centrons chaque évaluation sur les risques réels

Sur nos propres projets, chaque évaluation des vulnérabilités de sécurité part des risques les plus importants du produit. Lorsque nous avons testé ICONOMI, une plateforme de gestion d’actifs crypto, la protection des comptes utilisateurs passait en premier. Nous avons vérifié la création des mots de passe, la vérification d’identité avec téléversement de documents et la détection des VPN. Nos ingénieurs ont aussi soumis au parcours d’inscription des saisies volontairement erronées, comme des caractères spéciaux dans les noms ou des fichiers très volumineux, afin de mettre au jour des faiblesses cachées.

Union54 avait une autre priorité. Le produit reposait sur une interface de programmation d’applications (API), la connexion qui permet aux programmes de communiquer entre eux. Notre équipe a testé cette API pour s’assurer d’une authentification et de contrôles d’accès corrects, afin que chaque type de compte ne puisse accéder qu’aux données qui lui étaient destinées. Dans les deux projets, le travail de sécurité s’inscrivait dans une mission QA plus large, l’approche que recommande cette section.

Transformer les constats en correctifs, puis les valider

Une évaluation des vulnérabilités de sécurité ne porte ses fruits que si ses résultats débouchent sur de vraies corrections. Pour y parvenir, trois éléments comptent :

1. Classez les faiblesses selon leur impact sur votre activité.
2. Corrigez-les dans cet ordre et testez à nouveau chaque correctif.
3. Réalisez un test d’intrusion sur les problèmes les plus graves pour voir ce qu’un attaquant pourrait réellement exploiter.

Sautez l’une de ces étapes, et le rapport devient un document de plus sur lequel personne n’agit. C’est pourquoi QAwerk prend en charge l’ensemble du cycle dans une seule mission, de l’évaluation et de la hiérarchisation des risques jusqu’aux retests et aux tests d’intrusion pratiques. Faites vérifier votre application par notre équipe sécurité.

FAQ

Une évaluation des vulnérabilités est-elle la même chose qu’une évaluation des risques ?

Non. Une évaluation des vulnérabilités de sécurité est un contrôle technique : elle examine l’intérieur de votre application et indique quelles faiblesses existent et quelle est leur gravité. Une évaluation des risques relève du jugement métier. Elle met ces faiblesses en regard des menaces probables et des pertes possibles, puis détermine quels problèmes méritent en priorité budget et attention. Les deux contrôles sont utiles, mais chacun s’adresse à un public différent.

Quelle est la différence entre évaluation de sécurité et tests de sécurité ?

Une évaluation de sécurité mesure le niveau de protection d’une application et aboutit à un rapport aux constats hiérarchisés. Le travail pratique, comme l’exécution de scanners, la revue du code ou les tentatives d’attaque, fournit les éléments sur lesquels repose ce verdict. En bref, les tests rassemblent les faits, et l’évaluation en tire les conclusions. Les tests d’intrusion vont le plus loin, car des spécialistes tentent réellement de s’introduire dans le système.

Que recevez-vous à l’issue d’une évaluation des vulnérabilités ?

Vous devez recevoir un rapport rédigé pour deux publics. Une courte synthèse indique aux managers le niveau d’exposition de l’application et les problèmes à traiter en priorité. La partie technique fournit aux développeurs chaque problème confirmé avec sa gravité, la preuve de son existence et un correctif suggéré. Un rapport qui se contente de reprendre la sortie brute d’un scanner n’a pas encore été examiné par un spécialiste.

Qui doit réaliser une évaluation des vulnérabilités ?

Les développeurs peuvent et doivent lancer eux-mêmes des scans automatisés, car cette habitude permet de détecter tôt les problèmes courants. Cependant, une évaluation complète donne de meilleurs résultats avec une équipe indépendante. Les spécialistes externes n’ont pas d’attachement au code et apportent l’expérience acquise sur de nombreux autres produits. Beaucoup d’entreprises combinent les deux approches, avec des contrôles automatisés à chaque version et une revue externe avant les lancements majeurs.

Une évaluation des vulnérabilités couvre-t-elle l’infrastructure réseau ?

Une évaluation des vulnérabilités peut inclure les réseaux, mais il s’agit d’un travail distinct qui exige d’autres compétences. Une évaluation réseau porte sur les serveurs, les pare-feu et les ports ouverts. Une évaluation applicative couvre les logiciels qu’utilisent vos clients, notamment les sites web, les applications mobiles et les API qui les relient. Les grandes organisations ont souvent besoin des deux, généralement réalisées par des spécialistes différents.