À quelle fréquence faire un pentest ? Guide 2026

Un pentest annuel reste le socle universellement recommandé en 2026, complété par des pentests event-driven (après changement significatif, incident, acquisition, refonte d'authentification) et ajusté selon le type d'actif, la criticité et les exigences réglementaires. Pour les organisations soumises à PCI-DSS v4.0, HDS, DORA ou NIS2, la fréquence minimale est imposée par le référentiel. Pour les autres, la cadence se calcule sur trois axes : rythme d'évolution du périmètre, niveau de maturité des contrôles continus (SAST, DAST, SCA), appétence au risque de l'entreprise. Cet article détaille les cadences par type d'actif, les exigences des principaux référentiels (PCI-DSS, ISO 27001, HDS, DORA, NIS2, SOC 2), les triggers event-driven, les modèles économiques (pentest ponctuel, PtaaS, bug bounty, red team) et un plan pluriannuel chiffré pour trois tailles d'organisation.

Les facteurs qui déterminent la bonne fréquence

Un pentest annuel universel est un compromis de gouvernance, pas une vérité technique. La bonne fréquence se calcule en fonction de cinq facteurs qui interagissent.

Criticité de l'actif : une application traitant du paiement, des données de santé ou de la propriété intellectuelle à haute valeur justifie une cadence plus serrée qu'un site marketing statique.

Rythme d'évolution : une application mise à jour toutes les deux semaines avec des changements d'architecture justifie un pentest trimestriel ou un PtaaS continu. Une application stable avec 2 releases majeures par an se satisfait d'un pentest annuel ciblé sur les changements.

Maturité des contrôles continus : une organisation avec SAST, DAST, SCA et threat modeling systématique en pipeline a moins besoin de pentests fréquents pour les classes couvertes par ces outils. Le pentest se concentre alors sur les classes que les outils automatisés manquent (logique métier, chaînes d'exploitation, logic flaws).

Exigences réglementaires : certains référentiels imposent une fréquence minimale non négociable (détaillé section suivante).

Profil d'attaquants réels : une entreprise visée par des adversaires motivés (secteur public, défense, banque systémique) doit s'outiller plus fortement qu'une PME à faible exposition.

Cadences recommandées par type d'actif

Le type d'actif dicte une cadence de référence. Ces fréquences sont des lignes de base ajustables selon les facteurs décrits plus haut.

Exigences réglementaires 2026

Les principaux référentiels en vigueur en France et en Europe imposent ou recommandent des cadences spécifiques. À connaître pour justifier le budget et éviter la non-conformité.

PCI-DSS v4.0 (paiement carte bancaire)

• Requirement 11.4.1 : tests d'intrusion internes et externes au moins une fois par an, et après tout changement significatif.
• Requirement 11.4.3 : tests d'intrusion de la segmentation tous les 6 mois pour les entités service providers.
• Méthodologie reconnue : référence explicite aux standards NIST SP 800-115, OWASP, OSSTMM ou équivalents.
• Applicable à toute entité traitant, transmettant ou stockant des données de carte de paiement.

ISO 27001:2022

• Contrôle A.8.8 (Gestion des vulnérabilités techniques) : évaluation régulière, fréquence à justifier par analyse de risque.
• Contrôle A.8.29 (Tests de sécurité) : tests de sécurité à planifier selon la criticité.
• La norme ne fixe pas de fréquence, mais un audit annuel est la pratique standard alignée avec le cycle de certification.

HDS (Hébergement Données de Santé)

• Référentiel HDS v1.1 : audit technique obligatoire annuel incluant pentest applicatif et infrastructure.
• Applicable à tout hébergeur de données de santé en France.

DORA (Digital Operational Resilience Act, effectif janvier 2025)

• Article 24 : tests de résilience opérationnelle numérique programmés annuellement au minimum sur les systèmes TIC critiques.
• Article 26 : TLPT (Threat-Led Penetration Testing) tous les 3 ans pour les entités financières significatives, en alignement avec TIBER-EU ou méthodologie équivalente acceptée par l'autorité compétente.
• Applicable aux établissements de crédit, entreprises d'investissement, établissements de paiement, gestionnaires de crypto-actifs, prestataires critiques tiers TIC.

NIS2 (transposée en France en 2025)

• Article 21 : mesures techniques et organisationnelles appropriées, incluant évaluations régulières de l'efficacité des mesures.
• Pas de fréquence explicite, mais la pratique recommandée par l'ANSSI est annuelle pour les entités essentielles et importantes.

SOC 2 Type II

• Pas d'exigence formelle de pentest, mais les auditeurs SOC 2 exigent en pratique un pentest annuel pour valider les critères de sécurité.

RGPD

• Article 32 : sécurité appropriée au risque. Pas de fréquence imposée mais un pentest annuel est la pratique documentée pour démontrer la conformité à l'article 32 en cas de contrôle CNIL.

Habilitations Défense et LPM

• Les OIV au sens de la Loi de Programmation Militaire (LPM) sont soumis à des audits PASSI dont la fréquence est fixée par l'ANSSI dans les arrêtés sectoriels (typiquement annuelle pour les systèmes d'information d'importance vitale).

Calendar-driven versus event-driven

Deux approches coexistent et doivent être combinées.

Calendar-driven : pentest à date fixe, inscrit au plan annuel, budgétisé en avance. Avantage : prévisibilité, gouvernance, budget maîtrisé. Inconvénient : peut passer à côté d'une exposition critique introduite juste après le pentest annuel.

Event-driven : pentest déclenché par un événement identifié. Les événements qui justifient un pentest en dehors du calendrier :

• Refonte d'authentification ou d'autorisation (nouveau SSO, migration OAuth, nouveau provider IAM).
• Migration cloud majeure (on-premise vers AWS/Azure/GCP, multi-cloud, changement de provider).
• Intégration d'un nouveau fournisseur critique (payment processor, analytics, LLM API).
• Acquisition ou cession d'activité (due diligence sécurité post-M&A).
• Incident de sécurité avéré ou suspecté (valider la remédiation et rechercher des compromissions adjacentes).
• Changement massif d'équipe tech (onboarding de plus de 30 % de la force de développement).
• Mise en conformité avec un nouveau référentiel (certification initiale ISO 27001, PCI-DSS, HDS).

Approches économiques : ponctuel, PtaaS, bug bounty, red team

Quatre modèles de consommation se combinent dans un plan sécurité mature.

Pentest ponctuel traditionnel

Mission cadrée en jours, livrée en rapport PDF + restitution orale. Coût 5 000 à 50 000 € selon scope. Convient aux besoins réguliers prédictibles et aux exigences réglementaires (PCI-DSS, HDS, DORA, PASSI).

Pentest as a Service (PtaaS)

Abonnement à une plateforme (Cobalt, Synack, HackerOne Pentest, NetSPI, Yogosha). Missions à la demande via panel de testeurs vérifiés, délivrables dans la plateforme, retests illimités, métriques continues.

Avantages : rapidité de déclenchement (3 à 7 jours au lieu de 4 à 8 semaines), suivi dans le temps, retests gratuits, métriques consolidées. Convient aux organisations matures avec volume récurrent.

Limites : ne remplace pas les prestations qualifiées PASSI quand la régulation l'exige. Moins adapté aux missions red team complexes.

Coût indicatif en France 2026 : 25 000 à 150 000 € annuels selon volume, contre des missions classiques équivalentes qui coûteraient 40 à 80 % plus cher à couverture équivalente.

Bug bounty continu

Programme public ou privé via HackerOne, YesWeHack, Intigriti, Bugcrowd. Récompense au résultat, surveillance continue par la communauté.

Complémentaire au pentest, pas substituable. Un bug bounty trouve les vulnérabilités exploitables à distance accessibles à un hunter motivé. Il ne produit pas de rapport méthodologique, ne garantit pas une couverture exhaustive, ne satisfait pas la plupart des exigences réglementaires seul.

Budget annuel typique : 30 000 à 200 000 € pour un programme actif (payouts + gestion + plateforme).

Red team

Engagement adversarial simulant un attaquant motivé avec objectifs business (exfiltrer la base client, atteindre un VIP, compromettre un système critique). Durée 30 à 90 jours, scope étendu (technique + social + parfois physique).

Cadence recommandée : tous les 2 à 3 ans pour les organisations matures soumises à adversaires sérieux. Obligatoire sous DORA (TLPT triennal) pour les entités financières significatives. Coût 50 000 à 300 000 € par engagement.

Plan pluriannuel — exemples chiffrés

Trois profils d'organisations et leur plan pentest annuel type en France 2026.

PME 50-200 salariés, 3 à 5 applications critiques

Année 1
- Pentest applicatif principal (SaaS produit) : 15 000 €
- Pentest infra externe                         : 6 000 €
- Retest remédiation                            : 3 000 €
Total année 1                                   : 24 000 €
 
Année 2
- Pentest applicatif principal                  : 15 000 €
- Pentest applicatif secondaire                 : 10 000 €
- Pentest infra externe                         : 6 000 €
- Retest                                        : 3 000 €
Total année 2                                   : 34 000 €
 
Année 3 (montée en maturité)
- Pentest applicatif principal + API            : 20 000 €
- Pentest AD interne                            : 12 000 €
- Pentest infra externe                         : 6 000 €
- Retests                                       : 5 000 €
Total année 3                                   : 43 000 €

ETI 500-2000 salariés, 10 à 20 applications

Budget annuel 70 000 à 150 000 € incluant :

• Pentests applicatifs annuels sur les 5 applications les plus critiques.
• Pentest AD interne annuel.
• Pentest infra externe annuel ou semestriel.
• Pentest cloud annuel sur l'environnement production principal.
• 3 à 5 pentests event-driven pour les nouveaux produits.
• Éventuellement abonnement PtaaS pour les applications secondaires.

Grand groupe soumis à DORA ou NIS2

Budget annuel 300 000 à 1 000 000 € incluant :

• Red team triennal de type TIBER-EU : 150 000 à 400 000 € (amorti sur 3 ans).
• Pentests PASSI qualifiés annuels sur les SIIV (Systèmes d'Information d'Importance Vitale).
• PtaaS continu sur le portefeuille applicatif non critique.
• Bug bounty privé sur les applications client.
• Pentests event-driven sur toutes les mises en production critiques.

Ce qui fait échouer un plan pentest

Cinq écueils fréquents à éviter, observés sur les missions en France.

Pentest annuel qui se répète à l'identique : même prestataire, même scope, même méthodologie pendant 5 ans. Le cabinet reproduit ses biais et rate les nouvelles surfaces. Solution : alterner 2 à 3 cabinets sur cycle de 3 à 5 ans.

Remédiation non suivie : le rapport est livré, les findings ne sont jamais corrigés. Le pentest suivant trouve les mêmes vulnérabilités. Solution : intégrer les findings dans l'outil de gestion de vulnérabilités (DefectDojo, Jira, Kenna) avec SLA par criticité et revue mensuelle.

Scope qui ne reflète pas la surface réelle : le pentest est cadré sur l'application principale mais ignore les APIs internes, les shadow IT, les environnements de staging exposés. Solution : phase de cartographie initiale avant le scope définitif, révisée annuellement.

Absence de retest : les remédiations ne sont jamais validées. Le budget est alloué aux nouvelles missions sans vérifier les précédentes. Solution : inclure systématiquement un retest dans chaque mission, ou prévoir un retest séparé 60 à 90 jours après livraison.

Sur-investissement en fréquence, sous-investissement en contrôles continus : faire un pentest tous les 3 mois sur une organisation sans SAST, DAST, SCA ni threat modeling. Solution : d'abord mettre en place les contrôles continus qui captent les vulnérabilités courantes, puis calibrer la fréquence pentest sur les classes non couvertes par ces outils.

Points clés à retenir

• Un pentest annuel est le socle recommandé, imposé ou attendu par la plupart des référentiels (PCI-DSS, HDS, ISO 27001, SOC 2, DORA, NIS2).
• La fréquence réelle doit s'ajuster selon criticité, rythme d'évolution, maturité des contrôles continus et profil d'attaquants.
• Calendar-driven (cadence fixe) et event-driven (triggers) se combinent, jamais s'opposent. Les organisations matures inscrivent la liste des triggers dans leur politique sécurité.
• Pentest ponctuel, PtaaS, bug bounty et red team sont des modèles complémentaires. Les grandes organisations combinent les quatre.
• Avant d'augmenter la fréquence, maximiser la profondeur, varier les prestataires et suivre les remédiations. La fréquence sans qualité ni suivi génère du faux confort de sécurité.

Pour aller plus loin

• Qu'est-ce qu'un pentest - définition, méthodologie PTES et cadre légal en France.
• Méthodologie de pentest API - audit spécifique des interfaces REST et GraphQL.
• Différence entre scan et pentest - complémentarité des approches automatisées et manuelles.
• Pentest externe : définition, méthode, tarifs - focus sur le périmètre Internet.