Aller au contenu
Verion
6 min de lecture

Choisir son prestataire d'audit de sécurité : les bonnes questions à poser

Méthode, profil des auditeurs, format du rapport, périmètre réel : les questions qui permettent de comparer des devis d'audit de sécurité qui semblent équivalents.

  • Audit
  • Conformité
Composition géométrique abstraite illustrant la comparaison de plusieurs propositions d'audit

Deux propositions d’audit peuvent afficher le même nombre de jours et un tarif comparable tout en recouvrant des travaux radicalement différents : d’un côté l’exécution d’un outil automatisé dont la sortie est remise en forme, de l’autre plusieurs jours d’analyse manuelle. Rien dans le devis ne permet de distinguer les deux. Les questions ci-dessous, oui.

Sur la méthode

« Quelle part de la mission est manuelle ? » C’est la question la plus discriminante. Un scan automatisé coûte quelques heures et trouve ce que vos propres outils trouveraient. La valeur d’un audit se situe dans la logique métier, les contrôles d’accès et les enchaînements, que seul un humain identifie. Une réponse honnête ressemble à : « une demi-journée d’outillage et de reconnaissance, quatre jours de tests manuels ».

« Sur quel référentiel vous appuyez-vous ? » Les réponses attendues mentionnent l’OWASP Testing Guide, l’OWASP ASVS, éventuellement le PTES ou les guides de l’ANSSI. Un prestataire qui ne cite aucun référentiel travaille à l’intuition ; la couverture dépendra alors entièrement de l’auditeur affecté.

« Comment adaptez-vous la méthode à une application SaaS multi-tenant ? » Une réponse pertinente évoque immédiatement le besoin de deux organisations distinctes, de plusieurs rôles, et le test systématique des références croisées entre tenants. Si la question ne provoque rien de spécifique, l’expérience du modèle SaaS est probablement limitée.

Sur les personnes

« Qui réalisera concrètement la mission ? » Il n’est pas rare que la proposition soit portée par un profil senior et l’exécution confiée à un profil junior. Demandez le nom et le parcours de la personne qui testera, pas seulement la présentation du cabinet.

« Cette personne a-t-elle déjà audité des applications comparables ? » Comparable ne signifie pas « du même secteur » mais « de la même nature technique » : API REST ou GraphQL, SaaS multi-tenant, SSO d’entreprise, architecture distribuée.

« Combien de personnes interviendront, et sur quels aspects ? » Sur les missions longues, un binôme croisant deux regards produit souvent de meilleurs résultats qu’un auditeur unique.

Sur le livrable

« Puis-je voir un rapport d’exemple anonymisé ? » Une demande légitime, à laquelle tout prestataire sérieux répond. Ce qu’il faut y regarder : les constats sont-ils localisés précisément ? Le mécanisme est-il expliqué ou seulement nommé ? Les recommandations sont-elles adaptées à une pile technique ou génériques ? Y a-t-il une synthèse lisible par un non-technicien ? La section « périmètre et limites » est-elle honnête ?

« Le rapport est-il rédigé en français ? » Question triviale en apparence, mais un rapport que votre équipe et vos clients lisent facilement se traite plus vite.

« Fournissez-vous une attestation transmissible à nos clients ? » Un document court mentionnant le périmètre, les dates, la méthode et le niveau de risque résiduel, sans les détails techniques exploitables. C’est ce que vous transmettrez à vos prospects ; le rapport complet, lui, ne se diffuse pas.

« La contre-vérification des correctifs est-elle incluse ? » Si oui, dans quel délai et pour combien de jours. Si non, à quel tarif. C’est un point à trancher avant la signature, pas après.

Sur le déroulement

« Comment nous alertez-vous en cas de découverte critique ? » La bonne réponse est immédiate, par un canal convenu, sans attendre la fin de la mission. Découvrir dans le rapport final qu’une faille critique était connue depuis huit jours est une mauvaise surprise.

« Que se passe-t-il si vous trouvez une compromission déjà en cours ? » Cela arrive. Le prestataire doit avoir une procédure : arrêt des tests, alerte immédiate, préservation des traces, et une position claire sur ce qu’il fait ou ne fait pas ensuite.

« Comment sont protégées les données auxquelles vous accédez ? » Chiffrement des postes, durée de conservation des éléments collectés, procédure de destruction en fin de mission, engagement de confidentialité nominatif.

Sur le cadre contractuel

Quelques points à vérifier systématiquement : l’existence d’une autorisation écrite de tests signée par les deux parties, qui protège autant l’auditeur que vous ; une assurance responsabilité civile professionnelle couvrant ce type de prestation ; les conditions de vos propres fournisseurs, certains hébergeurs exigeant une déclaration préalable ; et le sort des données à l’issue de la mission.

Les signaux qui doivent alerter

Certains éléments justifient de creuser davantage :

  • Un engagement de résultat du type « nous garantissons la sécurité de votre application ». Aucun audit ne peut le garantir.
  • Un prix très inférieur aux autres propositions à périmètre égal. Le nombre de jours réellement passés est la seule variable d’ajustement.
  • L’absence de questions de la part du prestataire sur votre architecture avant de chiffrer. Un devis sérieux suppose de comprendre ce qui sera testé.
  • Un discours centré sur les outils ou sur les certifications de l’entreprise plutôt que sur la méthode et les profils.
  • La confusion entretenue entre audit, pentest et scan automatisé dans la proposition commerciale.

Comparer sur une base commune

Pour que la comparaison ait un sens, transmettez à chaque prestataire le même document : périmètre précis, exclusions, technologies, nombre approximatif d’endpoints, rôles existants, environnement disponible, contraintes de calendrier et objectif de la mission (préparation d’un questionnaire client, refonte de l’authentification, réassurance générale).

Vous obtiendrez alors des propositions réellement comparables, et vous verrez immédiatement lesquelles ont été lues attentivement, ce qui est déjà une information sur la mission à venir.

Publié par Verion. Cet article a une visée pédagogique : il décrit des mécanismes et des bonnes pratiques, sans fournir de procédure d'exploitation.

← Retour à tous les articles

À lire ensuite

Composition géométrique abstraite évoquant un rythme de contrôles répétés dans le temps
6 min

À quelle fréquence faire auditer son SaaS

Rythme annuel, audits déclenchés par événement, contrôles continus : comment construire une cadence d'audit proportionnée au risque réel de votre plateforme SaaS.

  • Audit
  • Méthodologie
Prendre contact

Besoin d'un regard extérieur sur votre plateforme ?

Nous auditons exclusivement des applications SaaS. Décrivez votre besoin en quelques lignes, nous revenons vers vous sous 24 heures ouvrées.

  • Réponse sous 24 h ouvrées
  • Périmètre écrit avant démarrage
  • Sans engagement