TL;DR
Le marché du PTaaS (Penetration Testing as a Service) a atteint 2,32 milliards de dollars en 2024 et croît à un rythme annuel de 16,6 % (Credence Research, 2025). Ces plateformes combinent automatisation et accès à des testeurs humains via une interface cloud, en promettant tests plus fréquents, résultats plus rapides et couverture continue.
Selon Gartner, les organisations utilisant le PTaaS réaliseront d’ici 2026 jusqu’à dix fois plus de tests que celles qui recourent uniquement au pentest traditionnel. Ces chiffres sont réels et le phénomène est légitime.
Mais le PTaaS est une réponse à la question "à quelle fréquence peut-on tester ?" et non à la question "est-ce qu’un attaquant déterminé peut compromettre nos actifs les plus critiques ?" Ces deux questions n’ont pas la même réponse, et elles ne se posent pas avec les mêmes outils.
Le test d’intrusion est confronté depuis plusieurs années à une tension réelle. D’un côté, les périmètres à tester s’élargissent en permanence : applications web, API, environnements cloud, chaînes CI/CD, systèmes industriels, postes de travail, Active Directory. De l’autre, les cycles de livraison logicielle s’accélèrent, et attendre six mois entre deux pentests ne correspond plus au rythme auquel les surfaces d’attaque évoluent.
Le PTaaS est né de cette tension. Il promet de réconcilier fréquence et couverture, en s’appuyant sur des plateformes cloud qui automatisent une partie du travail de test et mettent en relation les organisations avec des testeurs humains disponibles rapidement. C’est une réponse légitime à un problème réel. Mais une réponse légitime peut rester incomplète, et dans le cas du PTaaS, l’incomplétude est structurelle : elle ne tient pas à des lacunes corrigeables par la prochaine version de la plateforme, mais à la nature même de ce qu’un algorithme peut et ne peut pas faire.
Qu’est-ce que le PTaaS et comment ça fonctionne
Une réponse au pentest annuel
Le modèle traditionnel du test d’intrusion repose sur un cycle annuel ou biannuel : une organisation mandate un prestataire pour une mission de durée définie, le prestataire produit un rapport, l’organisation corrige les vulnérabilités identifiées, et on recommence l’année suivante. Ce modèle a ses vertus, notamment celle d’engager des testeurs humains expérimentés sur un périmètre défini. Mais sa limite est évidente : le monde change entre deux cycles, et les vulnérabilités qui apparaissent entre deux tests restent invisibles jusqu’au prochain rapport.
Le PTaaS propose un modèle alternatif. Une plateforme cloud centralise la gestion des missions de test, l’orchestration des outils, la remontée des vulnérabilités et la communication entre testeurs et équipes clientes. L’automatisation prend en charge les phases répétitives : découverte de la surface d’attaque, scan des ports, identification des technologies exposées, détection des vulnérabilités connues dans les versions logicielles utilisées.
Les trois composantes techniques d’une plateforme PTaaS
L’automatisation du scan de surface. La plateforme déploie en continu des outils de reconnaissance et de scan sur les actifs enregistrés, identifiant en temps quasi réel les nouvelles expositions, les changements de configuration, les ports ouverts inattendus et les versions logicielles présentant des CVE connues. C’est la brique qui justifie la promesse de "test continu".
L’accès à un réseau de testeurs humains. Les plateformes PTaaS s’appuient sur des communautés de chercheurs en sécurité ou des réseaux de pentesters accrédités, disponibles pour des missions de test manuel dans des délais courts, parfois inférieurs à 72 heures. Le modèle varie selon les plateformes : certaines rémunèrent les testeurs à la vulnérabilité trouvée, d’autres facturent des missions forfaitaires avec affectation d’équipes dédiées.
La plateforme de suivi et de remédiation. Les vulnérabilités identifiées sont centralisées dans une interface où les équipes clientes peuvent les prioriser, les assigner à des équipes de développement, suivre leur correction et demander une vérification de la remédiation sans relancer une mission complète. C’est souvent la valeur ajoutée la plus concrète pour les équipes DevSecOps.
Ce à quoi le PTaaS sert réellement
Tests de conformité fréquents sur des périmètres standardisés. Pour un éditeur SaaS qui doit répondre à des questionnaires sécurité lors de chaque cycle de vente, pour une organisation qui cherche à satisfaire les exigences de test annuel d’un référentiel comme SOC 2 ou PCI DSS sur des périmètres d’applications web standardisées, ou pour une organisation soumise aux obligations de tests de base annuels du règlement DORA, le PTaaS offre une solution plus rapide et plus économique que de mandater un cabinet à chaque cycle.
Surveillance continue de la surface d’attaque. La brique d’automatisation continue est genuinement utile pour détecter les expositions nouvelles qui apparaissent entre deux missions de test manuelles. Une nouvelle application déployée sans passer par le processus de sécurité habituel, un port ouvert par erreur sur un serveur de production, une nouvelle version d’une bibliothèque avec une CVE critique : ces changements sont visibles quasi immédiatement dans une plateforme PTaaS correctement configurée.
Couverture de périmètres larges avec retour rapide. Pour une organisation qui doit évaluer rapidement la sécurité de nombreuses applications ou API, le PTaaS permet de paralléliser les tests sur un volume de cibles que le modèle traditionnel ne pourrait couvrir dans le même délai. C’est particulièrement pertinent pour les organisations qui gèrent des portefeuilles d’applications web diversifiés.
Intégration dans les cycles DevSecOps. Les plateformes PTaaS les mieux conçues s’intègrent dans les pipelines CI/CD, permettant de déclencher des tests automatisés à chaque déploiement et d’alerter les équipes de développement sur les nouvelles vulnérabilités introduites dans leur code.
Ce à quoi le PTaaS ne sert pas
Évaluer la résistance réelle à un attaquant déterminé. C’est la limite fondamentale, et elle est structurelle. Un test PTaaS, même avec une composante manuelle, est un test orienté par la plateforme : les testeurs travaillent dans un cadre défini, avec des outils qui orientent leur exploration et des workflows qui structurent leur démarche. Ce cadre est conçu pour produire de la couverture et de la répétabilité. Mais un attaquant réel n’a pas de workflow. Il cherche un seul chemin vers son objectif, et ce chemin passe souvent par une combinaison de failles individuellement anodines que ni l’automatisation ni un testeur contraint par un périmètre standardisé n’aurait pensé à assembler. Un test d’intrusion mené par un cabinet spécialisé commence différemment : par une question, pas par un périmètre.
Détecter les vulnérabilités de logique métier. Les vulnérabilités de logique métier exploitent la façon dont une application est supposée fonctionner, pas un bug dans son code. Un processus de commande qui peut être manipulé pour valider un achat sans paiement. Un contrôle d’accès qui fonctionne correctement dans les cas prévus mais laisse passer un enchaînement d’actions légitimes combinées de façon inattendue. Ces vulnérabilités n’ont pas de signature CVE. Elles ne correspondent à aucune règle de scan. Elles ne sont repérées que par un testeur qui comprend ce que l’application est censée faire. C’est exactement le type de test que couvre notre pentest applicatif web et mobile.
Évaluer l’Active Directory et les chemins de compromission internes. L’Active Directory est la cible centrale de la grande majorité des attaques en environnement d’entreprise. Identifier les chemins qui mènent à l’escalade de privilèges nécessite une analyse humaine de la structure Active Directory. Les outils de cartographie comme BloodHound produisent un graphe de relations qui doit être interprété par un analyste humain capable de distinguer un chemin théorique d’un chemin réellement exploitable dans le contexte spécifique de l’organisation. L’audit Active Directory, les techniques comme le LLMNR/NBT-NS Poisoning ou l’élévation de privilèges requièrent une compréhension contextuelle que l’automatisation ne peut pas reproduire.
Tester des environnements industriels ou non standard. Les plateformes PTaaS sont conçues pour tester des environnements web, des API, des infrastructures cloud et des réseaux IT classiques. Elles n’ont pas été conçues pour les environnements OT/ICS, les protocoles industriels comme Modbus, DNP3 ou OPC-UA, les équipements SCADA ou les architectures propriétaires. Un pentest industriel ne s’automatise pas : il requièrt une compétence spécialisée sur des protocoles et des équipements qui sortent du périmètre de toute plateforme PTaaS.
Pourquoi ce n’est pas magique
Un algorithme peut-il remplacer le jugement d’un pentester ?
C’est la question centrale, et la réponse honnête est non. Pas parce que les algorithmes seraient insuffisamment développés ou que les plateformes PTaaS seraient mal conçues, mais parce que le problème qu’un pentester humain résout n’est pas un problème algorithmique.
Un algorithme est conçu pour reconnaître des patterns. Il teste des conditions connues, applique des signatures existantes, parcourt des chemins d’exploration définis lors de son entraînement. C’est exactement ce dont on a besoin pour détecter des CVE connues dans des versions logicielles identifiées, pour vérifier qu’une configuration basique de sécurité est en place, pour cartographier mécaniquement une surface d’exposition.
Mais un attaquant sophistiqué ne suit pas des patterns connus. Il observe, adapte, improvise. Il voit qu’un mécanisme de réinitialisation de mot de passe renvoie des messages d’erreur légèrement différents selon que l’adresse email existe ou non, et il en déduit une énumération d’utilisateurs. Il remarque qu’un commentaire HTML dans le code source d’une page d’administration mentionne un endpoint interne, et il l’explore. Il constate qu’une validation de saisie côté serveur est absente précisément sur l’étape 3 d’un processus en cinq étapes, parce que les développeurs ont supposé que l’étape 2 avait déjà validé. Aucun de ces chemins n’est dans un manuel. Aucun n’a de CVE. Aucun ne se détecte par scan.
Et surtout, dans un test d’intrusion, on ne sait jamais vraiment sur quoi on va tomber. C’est précisément ce qui distingue structurellement un pentest d’un scan. Un scan cherche ce qu’il sait chercher. Un pentester cherche ce qu’il n’a pas encore trouvé, en s’adaptant à ce que l’environnement révèle au fil de l’exploration. La découverte d’une configuration inhabituelle sur un serveur de fichiers peut réorienter toute la stratégie d’exploration. Une relation de confiance inattendue entre deux domaines Active Directory peut ouvrir un chemin que personne n’avait anticipé. C’est fondamentalement une activité humaine d’investigation et d’adaptation, pas d’application de règles.
La profondeur n’est pas scalable
Le PTaaS vend de la scalabilité. C’est sa proposition de valeur centrale : tester plus de cibles, plus fréquemment, avec moins de friction administrative. Cette promesse est tenue dans sa dimension quantitative. Mais la profondeur, elle, ne s’automatise pas.
Un test d’intrusion mené pendant cinq jours par deux pentesters expérimentés sur un périmètre défini produit quelque chose qu’aucune plateforme PTaaS ne produit : une compréhension de la logique de l’environnement testé, une exploration des interactions entre systèmes, une reconstruction des chemins d’attaque réalistes que suivrait un vrai adversaire avec un vrai objectif. Cette profondeur ne s’obtient pas en multipliant le nombre de scans automatisés. Elle s’obtient en passant du temps dans l’environnement, en comprenant son organisation, en suivant des intuitions que l’expérience développe.
La notion de faux sentiment de couverture
C’est le risque le plus insidieux du PTaaS bien utilisé. Une organisation qui reçoit chaque mois un rapport PTaaS avec un score de risque en baisse et une liste de vulnérabilités corrigées peut légitimement croire que sa sécurité s’améliore. Et elle a probablement raison sur le périmètre que la plateforme teste.
Ce qu’elle ne sait pas, c’est ce que la plateforme ne teste pas. Les vulnérabilités de logique métier. Les chemins de compromission internes via Active Directory. Les configurations héritées dans les zones peu documentées de l’infrastructure. Les combinaisons de failles individuellement mineures qui, assemblées, donnent un accès critique. Le monitoring Active Directory peut détecter certains comportements anormaux côté authentification et accès. Mais ni lui ni une plateforme PTaaS ne peuvent répondre à la question "si quelqu’un est déjà dans notre réseau avec un compte valide, jusqu’où peut-il aller ?" Cette question nécessite un exercice mené par des humains avec la liberté d’exploration d’un vrai attaquant.
Vos outils de test automatique ont trouvé ce qu’ils cherchaient. Mais ont-ils cherché ce qu’un vrai attaquant chercherait ?
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Non, c’est une catégorie différente. Le PTaaS optimise la fréquence et la scalabilité des tests sur des périmètres connus. Le pentest traditionnel mené par un cabinet spécialisé optimise la profondeur et la capacité à identifier ce qu’on ne cherchait pas. Ces deux objectifs ne se substituent pas l’un à l’autre : ils répondent à des questions différentes.
Pour les obligations de tests de base annuels, un PTaaS bien calibré peut contribuer à satisfaire les exigences documentaires. En revanche, les tests avancés TLPT (Threat-Led Penetration Testing) imposés par DORA aux entités significatives du secteur financier suivent la méthodologie TIBER-EU et ne peuvent pas être réalisés via une plateforme PTaaS standard : ils requièrent une mission conduite par des testeurs externes indépendants selon un cadre de threat intelligence spécifique à l’entité testée.
Certaines plateformes incluent des modules de test de l’infrastructure interne. Mais un vrai audit Active Directory nécessite une cartographie des chemins de compromission, une analyse des configurations héritées, et une interprétation contextuelle des résultats que les modules automatisés ne fournissent pas. Les techniques comme le LLMNR/NBT-NS Poisoning, la détection de chemins d’élévation de privilèges ou la cartographie par BloodHound requièrent un analyste humain pour distinguer ce qui est théoriquement exploitable de ce qui l’est réellement dans le contexte de l’organisation.
Le bug bounty est un programme ouvert et permanent où des chercheurs en sécurité soumettent des vulnérabilités découvertes de façon autonome, rémunérés à la découverte, sans garantie de couverture d’un périmètre défini. Le PTaaS est une prestation structurée avec un périmètre, un délai et des engagements de résultat. Les deux modèles peuvent s’appuyer sur les mêmes réseaux de testeurs, mais leurs objectifs et leur utilité diffèrent fondamentalement.
La question n’est pas laquelle des deux options choisir, mais pour quelle question. Si la question est "nos applications web ont-elles des vulnérabilités connues ?" ou "pouvons-nous documenter une couverture de test fréquente ?" : le PTaaS est adapté. Si la question est "un attaquant déterminé peut-il compromettre nos actifs les plus critiques, et si oui comment ?" : seul un test d’intrusion mené par des professionnels avec la liberté d’exploration d’un vrai adversaire peut y répondre.
Non. Un pentest applicatif web et mobile inclut une analyse manuelle de la logique métier, des flux d’authentification, des contrôles d’accès et des interactions entre composants que les modules automatisés d’une plateforme PTaaS ne couvrent pas. Les vulnérabilités de logique métier, souvent les plus impactantes pour une organisation, sont par définition invisibles à l’automatisation.
Les vulnérabilités issues de la composante automatisée peuvent inclure des faux positifs qui nécessitent validation. Celles issues des tests manuels réalisés par des testeurs humains dans le cadre de la plateforme sont généralement fiables, avec des nuances selon la profondeur d’engagement et le temps alloué. La question n’est pas tant la fiabilité des résultats trouvés que l’exhaustivité de ce qui n’a pas été cherché.
Le PTaaS scélarise la couverture et la fréquence. Il ne remplace pas le jugement d’un pentester humain face à un environnement qu’il n’a jamais vu. Ce que les plateformes trouvent, et ce qu’elles ne peuvent structurellement pas chercher.
