14 pentests menés en 2025-2026 : ce que le continu apporte vraiment, et les cas où l’annuel reste le bon choix

Quand un directeur technique m’envoie un message à vingt heures pour me demander « continu ou annuel ? », la vraie question n’est presque jamais celle-là. C’est plutôt : ai-je les moyens de traiter ce que le pentest va me remonter ? Et cette question, elle décide de tout — le modèle, le budget, la valeur produite, la crédibilité de la fonction sécurité auprès du reste de l’entreprise.

Depuis dix-huit mois, nous avons piloté quatorze missions dans les deux modèles : sept en continu (contrat pluri-annuel, vagues courtes tous les mois ou tous les deux mois), sept en annuel classique (mission unique de deux à quatre semaines). Cet article est un condensé de ce que ces missions ont appris — sur les coûts réels, les délais de correction, le bruit produit, et surtout sur les cas où chaque modèle brille ou déçoit.

Ce que le modèle annuel fait bien, mesuré

On a tendance, dans les articles sur le sujet, à traiter l’annuel comme un vestige. C’est une erreur d’analyse. Sur six de nos missions annuelles en 2025-2026, la valeur produite était nette et documentée. Trois raisons expliquent pourquoi le format tient encore.

Un livrable qui coche une case réglementaire. Une certification ISO 27001, un renouvellement SOC 2 Type II, un audit RGPD, une réponse à un appel d’offres qui exige « un pentest annuel réalisé par un tiers » : le format annuel est celui qui parle le langage des auditeurs. Sur cinq de nos missions, c’était le déclencheur — pas un besoin technique, un besoin contractuel.

Une profondeur d’attaque supérieure sur la fenêtre. Deux à quatre semaines à temps plein permettent d’enchaîner des chaînes d’exploitation complexes qu’une vague de trois jours ne rendra jamais. Sur une mission menée pour un éditeur logiciel français, la faille finale reposait sur l’enchaînement de quatre vulnérabilités de gravité moyenne — le genre de scénario qui demande le temps de poser une hypothèse, de tester une piste morte, de revenir en arrière, de trouver l’angle décalé. Un modèle continu, structuré autour de tickets et d’objectifs de vague, décourage cette exploration profonde.

Un coût prévisible, une charge encadrée. Un pentest annuel externe sur une application web de complexité moyenne coûte entre 6 000 et 15 000 € HT en France en 2026, hors périmètres particuliers. C’est une ligne budgétaire annuelle, isolée, facile à défendre. Le continu, à périmètre équivalent, tourne à 2 500 – 4 500 € HT par mois, soit 30 000 à 54 000 € HT sur l’année : deux à cinq fois plus, ce qui n’est pas anodin pour une entreprise entre 50 et 250 personnes.

Là où l’annuel lâche, et pourquoi

Les limites de l’annuel n’apparaissent pas dans le rapport. Elles apparaissent trois mois après la restitution, quand on revient sur le terrain. Nous avons observé trois angles morts systématiques.

Le rythme du code a doublé, le rythme du test n’a pas bougé. Sur deux de nos clients, l’équipe produit met en ligne entre huit et douze déploiements par semaine. Le pentest de mai teste une application qui n’existe plus en juillet. Nous avons quantifié : sur un an de commits, entre 37 % et 54 % du code testé avait été réécrit ou supprimé avant la mission suivante. C’est un problème de couverture, pas de qualité de test.

Le délai entre découverte et correctif reste artisanal. C’est la donnée qui nous a le plus surpris. Sur six clients en modèle annuel, le délai médian entre l’identification d’une faille de gravité haute et sa mise en production corrigée était de 84 jours. Pas parce que les équipes travaillent lentement : parce qu’un rapport qui débarque en bloc de trente pages, un mois après la mission, se retrouve derrière la roadmap trimestrielle. Il faut re-hiérarchiser, arbitrer, planifier — et un correctif jamais planifié n’arrive jamais.

La régression n’est presque jamais vérifiée. Un tiers seulement des correctifs sont retestés dans un modèle annuel classique, faute de retour explicite prévu au contrat. On ferme des tickets sur du déclaratif. Sur une mission de retest facultatif, nous avons trouvé que 31 % des correctifs étaient soit incomplets, soit avaient introduit une nouvelle faille en périphérie.

Ce que le continu change vraiment — et ce qu’il exige en face

Le principal argument commercial du continu est « vous êtes testé en permanence ». Ce n’est pas faux, mais c’est une lecture superficielle du modèle. Ce qui change réellement, en pratique, se joue sur trois axes.

La restitution devient un flux, pas un événement. Chaque vulnérabilité tombe dans un ticket, avec preuve, gravité, chemin de reproduction et proposition de correctif. L’équipe produit reçoit ces tickets au fil de l’eau, dans le même outil que le reste du travail. C’est le seul changement structurel du continu, et c’est celui qui explique la chute du délai de correction : quand une faille arrive dans le sprint en cours au lieu d’une réunion trimestrielle, elle est traitée dans le sprint en cours.

L’effort est étalé, mais il existe. C’est le point que les commerciaux de PTaaS minimisent, et qui est pourtant la première cause d’abandon. Un continu produit entre trois et huit tickets par mois, dont un tiers demande une décision d’architecture, pas seulement un correctif ponctuel. Comptez 3 à 6 jours-homme par mois côté équipe interne pour traiter la file, sans quoi la pile monte et le modèle devient l’équivalent moderne de la boîte mail à quatre mille non-lus.

Le périmètre est vivant, pas figé. Un pentest annuel définit le périmètre en semaine 0 et n’y revient plus. Le continu part de l’idée que le périmètre change tous les mois — nouvel endpoint, nouveau microservice, nouvelle intégration tierce. C’est cet avantage qui justifie l’écart de prix, mais seulement si votre organisation a effectivement un rythme de mise en production soutenu. Sur une application stable qui n’évolue que deux à trois fois par an, ce périmètre vivant devient un argument théorique — et l’écart de prix, une facture qui l’est moins.

La matrice de décision qui a marché sur nos 14 missions

Après quatorze missions, on cesse de raisonner en critères théoriques. Trois questions décident réellement du bon modèle, dans cet ordre.

1. Quel est votre rythme de mise en production sur le périmètre à tester ? En dessous d’un déploiement par mois, l’annuel suffit. Entre un par mois et un par semaine, la question devient légitime. Au-delà d’un déploiement par semaine, le continu produit un retour sur investissement quasi immédiat en évitant les régressions de sécurité entre deux missions annuelles.

2. Avez-vous une personne nommée qui gère la file des correctifs de sécurité ? Pas une équipe, une personne — un référent sécurité produit, un responsable sécurité applicative, un RSSI qui s’implique dans le suivi. Si la réponse est « on verra en réunion », le continu accumulera de la dette technique de sécurité plus vite que ce qu’il en résout. Restez sur un annuel bien préparé, avec une réunion de suivi tous les trois mois pour trancher les correctifs restants.

3. Le pentest est-il l’exigence d’un tiers, ou une exigence interne ? Un pentest exigé pour un renouvellement de certification, un audit client ou un appel d’offres est un pentest qui doit tenir dans un rapport unique daté. Le format annuel, ici, est le chemin le plus court. Un pentest exigé par le comité de direction pour réduire le risque produit est un pentest de flux — le continu est fait pour ça.

Cinq pièges que nous voyons revenir, dans les deux modèles

Le périmètre fantôme. On signe le pentest sur un périmètre « l’application principale » sans lister les sous-domaines exposés, les API secondaires, les environnements de recette accessibles depuis Internet. Sur deux missions, la vraie faille était sur un environnement de recette qui n’était pas au périmètre parce que personne ne l’avait mentionné. Résultat facturable : zéro. Risque réel : maximal. Écrivez le périmètre en URL, pas en noms d’applications.

La restitution qui ne quitte pas la salle. Une réunion de restitution à sept personnes, dont trois qui n’ont pas ouvert le rapport, produit une décision molle. La bonne pratique : envoyer le rapport quarante-huit heures avant, exiger une lecture des sections « synthèse exécutive » et « criticités hautes », arriver en réunion avec la liste des trois arbitrages nécessaires, pas quinze slides descriptives.

Le rapport « ne rien trouver » lu comme un bon résultat. Un pentest sans faille critique n’est pas nécessairement bon signe. Il peut vouloir dire que le périmètre est mal défini, que le budget de mission était trop court, ou que l’équipe pentest a évité les zones difficiles. Demandez toujours le journal de tentatives, pas seulement le rapport final : c’est là que se voient l’effort réel et les hypothèses écartées.

Le PTaaS choisi sur le seul argument « plateforme ». Une belle interface avec des tickets colorés ne remplace pas la qualité des consultants derrière. Demandez la liste nominative des pentesteurs affectés à votre compte, leurs certifications (OSCP, PNPT, CRTP), et leur rotation prévue. Un PTaaS qui refuse de nommer ses opérateurs est un PTaaS que vous n’avez pas encore choisi.

L’absence de coordination avec le bleu. Que vous soyez en annuel ou en continu, un pentest est infiniment plus utile s’il se conclut par une session purple team avec votre SOC ou votre équipe de détection : quelles attaques ont été détectées, lesquelles sont passées, combien de temps entre l’action offensive et l’alerte. Sans cette étape, le pentest reste un exercice de découverte de vulnérabilités et rate la moitié de sa valeur pédagogique. Notre méthode complète est décrite dans notre article sur le purple team pour PME.

Ce que dit la conformité en 2026 — NIS2, DORA, ISO 27001

Sur la question de la fréquence, les textes récents ne tranchent pas de manière binaire, et c’est utile de le savoir avant de signer.

La directive NIS2, transposée en droit français, exige des « évaluations régulières de l’efficacité des mesures de gestion des risques », sans fixer de cadence. L’ANSSI, dans ses avis d’avril et de juin 2026, tolère le pentest annuel comme minimum acceptable pour les entités importantes, mais recommande une cadence renforcée pour les entités essentielles exposées à Internet. Notre audit de périmètre NIS2 aide à situer votre organisation.

Le règlement DORA, applicable aux entités financières depuis janvier 2025, va plus loin : il impose des tests de pénétration fondés sur la menace (TLPT) au moins tous les trois ans pour les entités significatives, avec un cadre méthodologique proche de TIBER-EU. Ces tests ne remplacent pas les pentests classiques : ils s’y ajoutent, et exigent en pratique une combinaison des deux modèles.

La certification ISO 27001 ne prescrit pas de fréquence de pentest, mais la clause 8.8 (« gestion des vulnérabilités techniques ») et l’annexe A.8.29 (« tests de sécurité en cours de développement ») orientent clairement vers un dispositif continu pour les organisations qui développent leurs propres applications. Un pentest annuel documenté reste néanmoins accepté par la majorité des auditeurs certificateurs français.

Autrement dit : les textes n’imposent pas le continu, mais ils encouragent une posture qui, sur le terrain, y ressemble beaucoup. Le format n’est plus qu’un choix d’implémentation.

Budget, séquencement, et ce qu’il faut négocier

Quelques ordres de grandeur observés en 2026 sur le marché français, à ajuster selon la nature du périmètre (web, mobile, API, cloud, industriel).

• Pentest annuel web complet sur une application de complexité moyenne : 6 000 à 15 000 € HT, incluant restitution et retest léger.
• Pentest annuel avec red team courte (2 jours de scénario offensif) : 18 000 à 28 000 € HT.
• Pentest continu (PTaaS) sur périmètre équivalent : 2 500 à 4 500 € HT / mois, soit 30 000 à 54 000 € HT / an.
• Modèle hybride (1 audit annuel long + 2 vagues courtes) : 18 000 à 22 000 € HT / an.
• TLPT DORA-compatible : 80 000 à 150 000 € HT, tous les trois ans, hors coût interne de préparation.

Trois clauses à faire écrire noir sur blanc, quel que soit le modèle. Le retest est-il inclus ? Non par défaut sur un annuel, oui sur un continu — vérifiez le nombre inclus. La liste nominative des consultants est-elle communiquée avant le démarrage ? Un prestataire sérieux répond sans hésiter. Quel est le SLA de découverte critique ? Sur un continu, une faille critique doit vous parvenir sous quatre heures ouvrées, pas dans le rapport de vague.

Enfin, un point rarement discuté : la clause de sortie. Un contrat de continu se signe généralement sur un an minimum. Négociez une fenêtre de sortie anticipée après trois mois, sans pénalité, si la file de tickets non traités dépasse un seuil défini ensemble. C’est le garde-fou qui protège les deux parties d’un modèle qui ne fonctionne pas dans votre contexte.

Questions fréquentes