Test d'intrusion, scan, bug bounty ou red team : que choisir ?
Scan de vulnérabilités, test d'intrusion, bug bounty ou red team : objectifs, fréquence, coûts indicatifs et maturité requise pour une PME du Québec.
Faits vérifiés : octobre 2026Ce comparatif n’est pas commandité.
Notre recommandation selon votre situation
Cabinet comptable de 15 postes à Longueuil, sans exigence externe particulière
Scan de vulnérabilités
Des scans mensuels, internes et externes, suivis de correctifs, règlent l'essentiel à faible coût. Ajoutez un test d'intrusion externe quand un client ou l'assureur l'exige.
Boutique en ligne de Québec qui traite des paiements par carte sur son propre site
Test d'intrusion
Selon le questionnaire PCI DSS applicable, des tests d'intrusion annuels peuvent être exigés, en plus des scans externes trimestriels par un fournisseur approuvé (ASV).
Éditeur de logiciel infonuagique de Montréal avec une équipe de développement qui corrige vite
Programme de bug bounty
Une fois les tests d'intrusion réguliers en place et une politique de divulgation publiée, un programme privé ajoute une couverture continue de l'application.
Comparaison point par point
Critère
Scan de vulnérabilités
Test d'intrusion
Programme de bug bounty
Exercice red team
Question à laquelle il répond
Quelles failles connues sont présentes ?
Un attaquant peut-il exploiter nos failles ?
Des chercheurs trouvent-ils ce qui nous a échappé ?
Détecterions-nous une vraie attaque ?
Exploitation manuelle des failles
Non, automatisé
Oui
Oui, par les chercheurs
Oui, par scénarios complets
Fréquence typique
Au moins trimestrielle, souvent mensuelle ou continue
Annuelle et après un changement important
Continue
Ponctuelle
Portée
Large : tous les actifs connus
Définie par écrit avant le test
Définie par les règles du programme
Objectifs à atteindre plutôt qu'un inventaire
Faux positifs
Fréquents, à valider
Écartés par le testeur
Signalements de qualité inégale à trier
Résultats démontrés par le scénario
Évalue la détection et la réponse
Non
Pas l'objectif principal
Non
Oui
Exigé par PCI DSS 4.0.1
Oui selon le SAQ : scans internes et externes (ASV) au moins tous les trois mois (11.3)
Oui selon le SAQ : tests interne et externe au moins tous les 12 mois (11.4)
Non
Non
Cadre légal
Autorisation du propriétaire des systèmes
Autorisation écrite et règles d'engagement
Règles du programme et clause de refuge juridique
Autorisation écrite et règles d'engagement détaillées
Coût indicatif
Le plus bas des quatre
De quelques milliers à plusieurs dizaines de milliers de dollars CA selon la portée
Variable : frais de plateforme + primes
Sur soumission ; généralement plus élevé qu'un test d'intrusion
Un outil automatisé compare vos systèmes à une base de failles connues, sans les exploiter.
Idéal pour
Toutes les PME, en continu, pour repérer les correctifs manquants et les configurations faibles.
Prix
Licence logicielle annuelle ou service géré récurrent ; par exemple, Nessus Professional est affiché à 4 790 $ US par an (site officiel, octobre 2026), sans compter le temps d'analyse
Des testeurs qualifiés tentent de percer vos défenses avec les techniques d'un attaquant, dans une portée convenue par écrit.
Idéal pour
Les PME qui doivent démontrer leur sécurité à un client, à un assureur ou dans le cadre de PCI DSS.
Prix
Les fournisseurs canadiens publient des fourchettes très larges, de quelques milliers à plusieurs dizaines de milliers de dollars selon la portée (par exemple, Packetlabs, août 2026 : environ 5 000 à 45 000 $ CA, chiffres qu'il qualifie lui-même d'« illustratifs ») ; retest souvent facturé à part
Points forts
Démontre l'exploitabilité réelle et écarte les faux positifs
Rapport priorisé avec recommandations de correction
Reconnu par les cadres de conformité (ex. PCI DSS, exigence 11.4)
Une simulation d'attaque réaliste, guidée par des objectifs, qui évalue aussi la détection et la réponse.
Idéal pour
Les organisations matures qui ont corrigé l'essentiel et disposent d'une surveillance (SOC ou MDR).
Prix
Sur soumission ; généralement plus élevé qu'un test d'intrusion, selon la portée et la durée du mandat
Points forts
Mesure la capacité réelle de détection et de réponse
Teste des scénarios de bout en bout, comme un vrai adversaire
Révèle les failles de processus, pas seulement techniques
Limites
Coûteux et long
Peu utile si les bases ne sont pas en place
Ne recense pas toutes les vulnérabilités
Votre assureur demande si vous faites des « scans ». Un client exige un « test de sécurité ». Un consultant vous parle de bug bounty, un autre de red team. Les quatre termes se ressemblent, mais ils ne répondent pas à la même question et n'ont pas du tout le même prix.
Pour la différence avec l'audit de cybersécurité, voyez notre article audit, pentest ou scan de vulnérabilités. Ici, nous comparons les quatre façons de chercher activement des failles dans vos systèmes.
Notre méthode
Nous comparons des approches, pas des fournisseurs. Les définitions et recommandations proviennent du NIST, du NCSC britannique, de l'OWASP et du texte de PCI DSS 4.0.1, consultés en octobre 2026.
Critères retenus : question à laquelle chaque approche répond, profondeur, fréquence, portée, faux positifs, détection, exigences PCI DSS, cadre légal, coût et maturité requise.
Les prix sont des fourchettes de marché indicatives publiées par des fournisseurs, pas nos tarifs.
Le scan de vulnérabilités est un outil automatisé. Il interroge vos systèmes, compare ce qu'il trouve à une base de failles connues et produit une liste. Il ne tente pas d'entrer.
Le test d'intrusion va plus loin. Le NCSC britannique le définit comme une façon d'obtenir l'assurance qu'un système est sécuritaire en tentant d'en percer les défenses, avec les outils et les techniques qu'un adversaire pourrait employer. Le NCSC ajoute une nuance importante : le test ne devrait pas être votre principale façon de trouver des failles, mais plutôt une vérification de votre gestion des vulnérabilités, un peu comme l'audit externe vérifie le travail de l'équipe comptable.
Le bug bounty invite des chercheurs externes à signaler des failles contre une récompense, généralement en argent, souvent par l'intermédiaire d'une plateforme spécialisée.
L'exercice red team simule une attaque réaliste contre les activités de l'organisation pour évaluer l'ensemble de ses capacités de sécurité, selon la définition du NIST. On ne cherche pas toutes les failles : on vérifie si une attaque ciblée passerait inaperçue.
Ces approches s'empilent plutôt qu'elles ne se remplacent.
D'abord, le scan. C'est l'hygiène de base. PCI DSS 4.0.1, par exemple, exige des scans internes et externes au moins tous les trois mois, les scans externes étant faits par un fournisseur approuvé (ASV). Un scan mensuel suivi de correctifs règle déjà une grande partie des problèmes.
Ensuite, le test d'intrusion. Il confirme ce qu'un attaquant peut réellement faire. Le NCSC rappelle qu'un test ne valide l'absence de failles connues qu'au jour du test, et qu'il s'écoule souvent un an ou plus entre deux tests : d'où l'importance des scans entre les deux. PCI DSS exige des tests interne et externe au moins tous les 12 mois et après tout changement important. Le prix d'un test d'intrusion au Québec dépend surtout de la portée.
Puis, éventuellement, le bug bounty. L'OWASP est franc sur ses limites : beaucoup de signalements sans valeur ou de faux positifs, un budget qui peut grimper si les failles sont nombreuses, des chercheurs qui sortent parfois de la portée, et la difficulté de distinguer un test légitime d'une vraie attaque. Il le réserve aux organisations qui ont déjà un processus mature de divulgation.
Enfin, le red team. Il n'a de sens que si quelqu'un surveille vos alertes. Sans surveillance, l'exercice confirmera surtout que personne ne regarde.
Un test d'intrusion ou un exercice red team exige une autorisation écrite du propriétaire des systèmes : sans elle, l'accès peut constituer une infraction au Code criminel (art. 342.1). Le mandat précise la portée, les dates, les techniques permises et les contacts d'urgence. Pour un bug bounty, ce sont les règles publiées du programme, avec une clause de refuge juridique, qui encadrent les chercheurs ; l'OWASP recommande d'obtenir un avis juridique avant de lancer un programme.
Si vous acceptez les cartes de crédit, le questionnaire PCI DSS qui s'applique à vous détermine ce qui est obligatoire ; notre article sur PCI DSS 4.0.1 pour les PME aide à s'y retrouver.
Vous ne faites rien de régulier ? Commencez par des scans mensuels, internes et externes, et un processus pour appliquer les correctifs.
Un client, l'assureur ou PCI DSS exige une preuve ? Un test d'intrusion annuel, et après chaque changement majeur, avec un retest des corrections.
Vous exploitez une application Web ou un produit infonuagique, avec une équipe qui corrige vite ? Une politique de divulgation d'abord, puis un programme de bug bounty privé.
Vous avez un SOC ou un service MDR et les bases sont solides ? Un exercice red team mesurera si l'ensemble tient.
Pour la plupart des PME québécoises, la combinaison gagnante reste la même : des scans réguliers et un test d'intrusion ciblé au moins une fois par année.
Questions fréquentes
Un scan de vulnérabilités peut-il remplacer un test d'intrusion ?+
Non. Le scan repère des failles connues sans les exploiter et produit des faux positifs. Le test d'intrusion vérifie ce qu'un attaquant peut réellement faire, en enchaînant les failles. Les deux se complètent : le scan maintient l'hygiène toute l'année, le test valide périodiquement que votre gestion des vulnérabilités fonctionne.
Un test d'intrusion exige-t-il une autorisation écrite ?+
Oui. Accéder à un système informatique sans autorisation peut constituer une infraction au Code criminel (art. 342.1). Le mandat doit préciser la portée, les dates, les techniques permises et les personnes à joindre. Si vos systèmes sont hébergés, vérifiez aussi les règles de votre hébergeur ou fournisseur infonuagique.
Peut-on lancer un bug bounty sans avoir de politique de divulgation ?+
C'est déconseillé. L'OWASP recommande de réserver les programmes de primes aux organisations qui ont déjà un processus mature de divulgation des vulnérabilités, du personnel pour trier les signalements et un budget prévu. Commencez par publier une politique de divulgation et un moyen sûr de vous signaler une faille.
Une PME a-t-elle besoin d'un exercice red team ?+
Rarement au départ. Un exercice red team mesure votre capacité à détecter et à contrer une attaque ; sans surveillance en place, il confirmera surtout que personne ne regarde. Il devient pertinent quand les scans, les correctifs et les tests d'intrusion sont réguliers et qu'une équipe surveille les alertes.