Quand faut-il lancer un test d’intrusion ?

Un scan automatisé remonte surtout des signatures connues, des configurations faibles ou des patterns techniques. Un pentest manuel relit les rôles, les logiques métier, les enchaînements d’actions et les contournements réels, ce qui permet de trouver des défauts qu’un outil seul ne remontera pas proprement.

Pas nécessairement. Un pentest devient surtout pertinent avant une ouverture externe importante, après une évolution majeure sur l’authentification, sur les rôles ou sur l’API, ou lorsqu’un produit commence à porter des données et des actions à fort impact. Entre deux pentests, l’hygiène de sécurité continue reste indispensable.

Le bon périmètre se décide autour des parcours à plus forte exposition : authentification, reset, zones d’administration, uploads, exports, endpoints publics, actions sensibles, intégrations externes et comptes à privilèges. Un pentest utile préfère un périmètre borné et critique à un périmètre trop large mais superficiel.

Oui. Une API peut être testée seule à condition de disposer d’un périmètre clair, d’exemples de rôles, de jeux de jetons réalistes, des endpoints à couvrir et du contexte métier minimal pour comprendre ce qu’une action autorisée ou non autorisée signifie réellement.

Oui, si le périmètre est cadré pour cela. Les défauts les plus coûteux portent souvent sur l’autorisation, le contournement d’étapes, la lecture d’objets d’autrui, les exports sensibles ou les actions possibles avec un rôle insuffisamment borné. C’est précisément ce qui différencie un pentest utile d’un simple scan.

C’est généralement préférable. Un environnement proche de la production permet de tester sans risquer d’interrompre un flux réel. Lorsque la production doit être testée, le périmètre, les horaires, les protections et les scénarios autorisés doivent être encadrés plus strictement.

Le cadrage initial, la liste des scénarios autorisés, les créneaux de test, les comptes dédiés, les sauvegardes vérifiées et les points de contact côté métier et technique limitent fortement le risque. Un bon pentest n’est pas un test chaos ; c’est une mission contrôlée.

Le rapport doit décrire le périmètre, la méthode, les scénarios testés, les vulnérabilités confirmées, leur exploitabilité, les preuves minimales et les recommandations de correction. Le plus utile reste souvent la priorisation : ce qui expose immédiatement, ce qui peut être planifié et ce qui mérite un retest.

Oui, au moins sur les points critiques. Le retest vérifie que la faille est bien corrigée, que le correctif n’a pas déplacé le problème ailleurs et que le scénario initial n’est plus exploitable. Sans retest, la fermeture du sujet reste souvent théorique.

Le budget varie surtout avec la taille du périmètre, le nombre de rôles, le type d’API, la présence de logique métier sensible et le niveau de restitution attendu. Un pentest borné reste plus lisible et plus rentable qu’un périmètre trop large dont les résultats deviennent peu actionnables.