Test d’intrusion pour PME en Normandie : quand le réaliser, quel périmètre et quels livrables ?

Un test d’intrusion ne remplace pas un audit cybersécurité

Les termes diagnostic, scan de vulnérabilités, audit et test d’intrusion sont régulièrement confondus. Ils répondent pourtant à des objectifs différents et ne produisent pas les mêmes décisions.

Le diagnostic donne une première vision des priorités

Un diagnostic examine la posture générale de l’organisation : comptes, sauvegardes, messagerie, postes, accès distants, pratiques internes et capacité de réaction. Il permet d’identifier les premiers écarts et de décider des chantiers à engager.

Cette approche est particulièrement utile lorsque l’entreprise ne sait pas encore par où commencer ou ne dispose pas d’une cartographie claire de son système d’information.

Le scan recherche automatiquement des vulnérabilités connues

Un scanner interroge les équipements ou applications pour repérer des versions obsolètes, des services exposés, des configurations faibles ou des vulnérabilités déjà référencées.

Le résultat constitue un point de départ. Il doit être vérifié, car un outil automatisé peut remonter des faux positifs, ignorer le contexte métier ou classer comme critique une faiblesse qui n’est pas réellement exploitable dans l’environnement concerné.

Le test d’intrusion vérifie des scénarios d’exploitation

Le pentester combine des outils, une analyse manuelle et son expérience pour comprendre les chemins d’attaque possibles. Il ne se limite pas à constater qu’une vulnérabilité existe : il cherche à déterminer ce qu’elle permettrait d’obtenir dans les limites autorisées.

Le test peut ainsi mettre en évidence l’enchaînement de plusieurs faiblesses apparemment secondaires : un service exposé, un compte insuffisamment protégé, des droits trop larges puis un accès à une donnée sensible.

L’audit peut couvrir un périmètre plus large

Un audit cybersécurité peut examiner l’architecture, les configurations, l’organisation, les procédures, les accès, les sauvegardes ou le code source. Le test d’intrusion constitue donc une activité d’audit parmi d’autres, avec une orientation offensive.

L’ANSSI distingue notamment, dans son référentiel PASSI, les audits d’architecture, de configuration, de code source, les tests d’intrusion et les audits organisationnels et physiques. Une PME n’a pas nécessairement besoin de toutes ces prestations en même temps.

Dans quelles situations un pentest devient-il pertinent ?

Avant la mise en production d’une application

Une application métier, un portail client, une plateforme de réservation ou une API peut traiter des données importantes et être accessible depuis Internet. Un test avant l’ouverture permet de vérifier les contrôles d’accès, la gestion des sessions, les droits des utilisateurs, les échanges avec les autres services et la protection des données.

Le test doit être suffisamment anticipé pour laisser le temps de corriger puis de vérifier les faiblesses découvertes.

Après une transformation importante du système d’information

Une migration vers le cloud, l’ouverture d’un nouveau site, le remplacement d’un pare-feu, une fusion d’entreprises ou l’ajout d’un accès distant modifient la surface exposée. Lorsque ces changements touchent des services critiques, un pentest peut vérifier que les nouvelles interconnexions n’ont pas créé de chemin d’accès inattendu.

Lorsqu’un client, un assureur ou un donneur d’ordre demande des preuves

Certains partenaires souhaitent disposer d’éléments tangibles sur la sécurité d’un prestataire. Un rapport de test peut alors compléter les politiques internes, les preuves de sauvegarde, la gestion des correctifs ou les mesures de protection des accès.

La demande doit être étudiée avant de commander la prestation. Un questionnaire peut exiger un test d’intrusion, alors qu’un autre attend surtout un audit de configuration ou une analyse de risques.

Pour vérifier l’efficacité de corrections

Après un premier audit, une compromission ou un programme de sécurisation, le test permet de vérifier que les mesures mises en œuvre réduisent réellement les possibilités d’intrusion. Dans ce contexte, le périmètre doit reprendre les faiblesses initiales et les chemins d’attaque identifiés. Un nouveau scan isolé ne suffit pas toujours à confirmer que l’ensemble du scénario est neutralisé.

Quand faut-il commencer par autre chose ?

Le pentest n’est pas systématiquement la première action à mener. Si l’entreprise ne connaît pas précisément ses équipements, ses applications, ses comptes administrateurs ou ses services accessibles depuis Internet, une évaluation et un audit de cadrage seront souvent plus utiles. Ils permettront de choisir un périmètre pertinent et d’éviter de tester un élément secondaire pendant qu’un risque plus important reste hors champ.

Il est également préférable de corriger les faiblesses déjà connues avant de financer un test approfondi. Des systèmes qui ne sont plus maintenus, des comptes sans MFA, des accès distants oubliés ou des sauvegardes jamais restaurées nécessitent d’abord des décisions de base.

Le test d’intrusion ne remplace pas non plus :

• la mise à jour régulière des systèmes et des applications ;
• la sécurisation des comptes et des privilèges ;
• la supervision des alertes ;
• les sauvegardes isolées et les tests de restauration ;
• la préparation des équipes ;
• une procédure de réponse en cas d’incident.

Une faiblesse détectée ne devient utile que si l’organisation est capable de la corriger, d’en suivre la remédiation et d’en tirer une décision durable.

Quel périmètre choisir pour une PME ?

Le périmètre doit être lié à une question précise. « Tester toute l’entreprise » n’est pas un cadrage suffisamment clair.

Les services accessibles depuis Internet

Le test externe examine ce qu’une personne située hors de l’entreprise peut découvrir et tenter d’exploiter : adresses IP publiques, pare-feu, VPN, portails, services d’administration, serveurs de messagerie ou applications publiées. Il est adapté pour mesurer l’exposition visible sans disposer d’un accès interne préalable.

Le réseau interne et les postes

Le test interne part d’un accès déjà présent dans l’organisation, par exemple un poste utilisateur ou une prise réseau. Il vérifie les possibilités de déplacement entre les équipements, l’accès aux serveurs, les partages, les privilèges et la segmentation. Ce scénario répond à une question différente : que pourrait faire un attaquant après la compromission d’un poste ou d’un compte ?

Les applications Web et les API

Une application nécessite un périmètre fonctionnel précis : profils utilisateurs, rôles, données manipulées, interfaces d’administration, API, moyens de paiement éventuels et services tiers. Le test doit vérifier les contrôles d’accès et les logiques propres à l’application, pas seulement les vulnérabilités techniques du serveur qui l’héberge.

Le Wi-Fi et les accès sur site

Un test Wi-Fi nécessite généralement une présence physique. Il peut examiner la séparation entre les réseaux internes et invités, les mécanismes d’authentification, la configuration des bornes et les possibilités d’accès au système d’information.

Pour une entreprise implantée à Caen, dans le Calvados ou ailleurs en Normandie, cette partie peut justifier une intervention locale, tandis que les tests Web ou externes sont souvent réalisables à distance. Cybeary accompagne les TPE et PME à Caen et en Normandie pour cadrer ce type de besoin.

Les identités et les environnements cloud

Microsoft 365, Google Workspace, Azure ou d’autres services cloud nécessitent une approche adaptée. Dans de nombreux cas, un audit de configuration, des identités et des privilèges sera plus pertinent qu’un pentest traditionnel.

Le cadrage doit notamment tenir compte des conditions d’utilisation de l’éditeur, des licences disponibles, des journaux accessibles et des actions autorisées sur la plateforme.

Boîte noire, grise ou blanche : que signifient ces approches ?

Dans une approche en boîte noire, le prestataire dispose de très peu d’informations. Il se rapproche de la situation d’un attaquant externe qui découvre sa cible.

En boîte grise, quelques éléments lui sont fournis : un compte utilisateur, une documentation limitée ou un accès standard. Cette méthode permet souvent de consacrer davantage de temps aux scénarios intéressants plutôt qu’à la seule phase de découverte.

En boîte blanche, le prestataire dispose d’informations détaillées sur l’architecture, les comptes de test ou le code. La couverture peut être plus approfondie, mais le scénario est moins proche d’une attaque totalement externe.

Aucune méthode n’est universellement meilleure. Le choix dépend de la question posée, du temps disponible et du niveau de couverture attendu.

Le cadrage protège autant l’entreprise que le prestataire

Un test d’intrusion doit être explicitement autorisé. Le document de cadrage précise les systèmes concernés, les techniques permises, les exclusions, les horaires, les contacts et la procédure à suivre en cas d’effet imprévu.

Il doit notamment définir :

• les domaines, applications, adresses IP et sites inclus ;
• les environnements exclus ou particulièrement sensibles ;
• les plages horaires autorisées ;
• les tests interdits ou soumis à validation préalable ;
• les seuils d’arrêt ;
• les contacts disponibles pendant la prestation ;
• la gestion des preuves et des données collectées ;
• les modalités d’alerte en cas de vulnérabilité critique ;
• la date de fin et la destruction sécurisée des éléments de travail.

Les prestataires, hébergeurs ou éditeurs concernés doivent également être identifiés. Tester une infrastructure appartenant à un tiers sans autorisation adaptée peut exposer l’entreprise à un risque contractuel ou juridique.

Comment se déroule un test d’intrusion ?

La mission commence par un atelier de cadrage. L’entreprise présente ses objectifs, son architecture, ses contraintes et les activités qui ne doivent pas être perturbées. Le prestataire transforme ces éléments en périmètre de test et en règles d’engagement.

Une phase de reconnaissance permet ensuite d’identifier les services, les technologies et les points d’entrée prévus. Les tests techniques combinent alors recherche de vulnérabilités, vérifications manuelles et tentatives d’exploitation maîtrisées.

Lorsqu’une faiblesse importante est découverte, le prestataire applique la procédure d’escalade définie. L’objectif n’est pas de poursuivre une démonstration au-delà de ce qui est nécessaire, mais de collecter une preuve suffisante pour évaluer le risque.

La mission se termine par l’analyse, la rédaction du rapport et une restitution. Après correction, un nouveau passage ciblé — souvent appelé contre-test — vérifie que les vulnérabilités traitées ne sont plus exploitables.

Quels livrables faut-il exiger ?

Un bon rapport doit être utile à la direction comme aux personnes chargées des corrections.

Une synthèse compréhensible par les décideurs

La synthèse présente le périmètre, les principaux scénarios constatés, leurs conséquences possibles et les décisions à prendre. Elle doit permettre de distinguer les urgences des améliorations de fond.

Un rapport technique exploitable

Chaque vulnérabilité doit être décrite avec suffisamment de précision pour être comprise et corrigée :

• système ou fonction concernée ;
• conditions nécessaires à l’exploitation ;
• preuve observée pendant le test ;
• conséquence technique et impact métier ;
• niveau de priorité argumenté ;
• recommandation de correction ;
• éventuelles dépendances avec d’autres constats.

Un classement « critique, élevé, moyen, faible » sans explication du contexte ne suffit pas.

Un plan de remédiation hiérarchisé

Les corrections doivent être regroupées dans un plan réaliste. Certaines peuvent être appliquées rapidement, tandis que d’autres nécessitent une modification d’architecture, une évolution applicative ou une décision budgétaire.

La responsabilité de chaque action doit être claire : équipe interne, éditeur, hébergeur, développeur ou prestataire informatique. Une protection managée peut ensuite aider à suivre les alertes et les écarts persistants.

Une restitution et un contre-test

La restitution permet de répondre aux questions et d’éviter les mauvaises interprétations. Le contre-test confirme ensuite les corrections sur le périmètre convenu. Sans cette dernière étape, l’entreprise sait qu’une action a été réalisée, mais ne dispose pas toujours de la preuve que le chemin d’attaque est effectivement fermé.

Quel budget prévoir pour un test d’intrusion ?

Il n’existe pas de prix unique sérieux sans connaître le périmètre. Le budget dépend principalement du nombre de systèmes, de la profondeur des contrôles, de la documentation disponible, du type d’accès, des contraintes horaires et des livrables attendus.

Un test ciblé sur une application simple ne mobilise pas les mêmes compétences ni le même temps qu’une mission couvrant plusieurs sites, un annuaire d’entreprise, des services cloud et différentes applications métiers.

Pour comparer des propositions, il faut regarder :

• le nombre de jours réellement consacrés aux tests et à l’analyse ;
• la part de vérification manuelle ;
• les compétences mobilisées ;
• la précision du périmètre ;
• la qualité des livrables ;
• la restitution ;
• le contre-test inclus ou non ;
• les modalités de protection des informations.

Une offre très peu coûteuse peut correspondre à un scan automatisé accompagné d’un rapport standard. Ce service peut avoir une utilité, mais il ne doit pas être présenté comme l’équivalent d’un test d’intrusion approfondi.

Un premier cadrage cybersécurité permet de vérifier si le pentest est la prochaine action utile et d’établir un devis proportionné au risque réellement étudié.

Faut-il choisir un prestataire qualifié PASSI ?

La qualification PASSI de l’ANSSI encadre les prestataires qui souhaitent faire qualifier leurs activités d’audit, notamment les tests d’intrusion. Elle apporte des garanties concernant le prestataire, son personnel et le déroulement des audits.

Toutes les PME ne sont pas juridiquement tenues de recourir à un prestataire qualifié pour chaque test. En revanche, cette qualification peut être exigée ou fortement attendue dans certains contextes réglementés, contractuels ou sensibles.

Le choix doit donc tenir compte des obligations applicables, des demandes du donneur d’ordre, de la criticité du système testé et du niveau de garantie attendu. Il ne faut jamais présenter une prestation comme « PASSI » si le prestataire et la portée de qualification ne correspondent pas précisément à la mission.

Un pentest ne garantit pas l’absence de vulnérabilité

Un test fournit une photographie à une date donnée, sur un périmètre et avec un temps définis. Une application peut évoluer, un nouveau service peut être publié et une vulnérabilité inconnue peut être découverte après la mission.

La valeur du pentest tient donc autant aux faiblesses trouvées qu’aux décisions prises ensuite. Les corrections doivent être suivies, les changements importants contrôlés et la protection intégrée à une démarche continue. Les scénarios critiques doivent aussi alimenter la continuité et la reprise d’activité.

Pour les PME de Caen, du Calvados et de Normandie, Cybeary peut aider à distinguer un diagnostic, un audit de configuration et un test d’intrusion, puis à coordonner la remédiation avec les équipes ou prestataires concernés. Cette approche évite de commander une prestation isolée sans lien avec la réalité du système d’information.