Tests d’intrusion applicatifs

Oui, lorsqu'il est réalisé avec l'accord de l'ayant droit du système. Le Code pénal punit l'accès à un système informatique et la détérioration de données « sans droit » ; l'accord du propriétaire supprime ce caractère illicite. C'est pourquoi nous intervenons uniquement sur mandat écrit, qui fixe le périmètre, la période et les techniques autorisées.

Sources : Code pénal suisse, art. 143bis et 144bis ; Conseil fédéral, rapport sur la promotion du piratage éthique, 29.11.2023

Souvent, oui. Si l'application tourne chez un hébergeur ou sur une plateforme cloud, il faut respecter ses règles sur les tests de sécurité et, selon les cas, obtenir son accord. Nous le vérifions avec vous au cadrage.

De préférence sur un environnement de préproduction représentatif, avec des comptes de test. Si le test doit se faire en production, nous adaptons les techniques pour ne perturber ni le service ni les données, et convenons des créneaux avec vous.

Un scanner automatique détecte des failles connues et des erreurs de configuration. Le test d'intrusion va plus loin : un ingénieur cherche les failles de logique, de contrôle d'accès ou d'enchaînement que les outils ne voient pas, et vérifie ce qu'un attaquant pourrait réellement en faire.

Après chaque changement important et, en règle générale, au moins une fois par an pour une application exposée sur internet. Pour un logiciel soumis au Cyber Resilience Act, les tests doivent être efficaces et réguliers, avec une fréquence proportionnée au risque.

Sources : Règlement (UE) 2024/2847, annexe I, partie II, point 3 ; guide de la Commission C(2026) 5252, §238 à 240

En boîte noire, nous partons de rien, comme un attaquant externe. En boîte grise, avec des comptes de test et la documentation, nous couvrons davantage dans le même temps : c'est l'approche la plus courante. En boîte blanche, avec le code source, nous vérifions en profondeur les mécanismes de sécurité.