1. Définir le périmètre de la revue
Inventoriez le site public, l’espace d’administration, les API, les formulaires et les intégrations qui soutiennent votre activité. Identifiez qui maintient chaque composant et quelles données il traite. Une boutique avec paiement, un portail client et un site vitrine demandent des périmètres différents ; le nombre de pages ne suffit pas à décrire cette différence.
Avant de commencer, convenez par écrit des domaines, environnements, comptes de test, dates et limites. Précisez qui autorise les vérifications, comment signaler un incident et quand arrêter les tests. Les services tiers nécessitent une vérification de leurs conditions et autorisations ; leur présence sur votre site ne les inclut pas dans le périmètre autorisé.
2. Demander une méthode explicable
OWASP WSTG propose une méthodologie de test des applications web. ASVS fournit des exigences pour vérifier les contrôles de sécurité. Ces références servent à préciser le travail ; elles ne certifient pas qu’une entreprise ou un site est invulnérable. [1] [2]
Demandez que la proposition précise les domaines examinés et les exclusions : configuration, authentification, droits, gestion des sessions, traitement des entrées et fonctions métier pertinentes. La combinaison d’outils et de revue manuelle doit correspondre au périmètre convenu. Un contrôle automatique isolé ne démontre pas que chaque parcours de l’application a été examiné.
3. Examiner les accès et les changements en contexte
Préparez la liste des profils : visiteur, client, salarié et administrateur, selon le cas. L’équipe d’audit doit comprendre les droits de chacun. Une fonction apparemment normale peut poser problème si elle est accessible à un profil qui n’en a pas besoin. Fournissez des comptes dédiés, évitez les identifiants personnels partagés et prévoyez leur suppression à la fin de la mission.
La revue devrait aussi examiner la maintenance du CMS, des extensions et des dépendances. Demandez qui approuve les mises à jour, où elles sont testées et comment revenir à une version précédente. Constater une version ancienne est utile ; définir sa priorité exige de comprendre son exposition, son usage réel et les protections existantes.
4. Exiger des constats exploitables
Chaque constat devrait décrire le composant concerné, les preuves minimales nécessaires, l’impact possible, les conditions de survenue et une recommandation précise. Le rapport doit protéger les informations sensibles : limitez captures et données de test au nécessaire et convenez des destinataires ainsi que de la durée d’accès au document.
Exemple hypothétique : si un compte aux droits limités peut consulter un document réservé, le rapport doit expliquer la séparation des droits attendue, celle observée et la correction proposée. Il n’est pas nécessaire de copier des documents réels pour démontrer le problème. La synthèse pour la direction doit rendre la priorité technique compréhensible sans exagérer l’impact.
5. Distinguer correction et vérification
Clarifiez si le devis couvre uniquement l’audit, également les corrections ou une vérification ultérieure. Attribuez à chaque action un responsable et une échéance convenue. Si l’hébergeur et l’agence de développement interviennent, définissez qui coordonne les changements et qui confirme le bon fonctionnement des fonctions essentielles.
Clore une tâche ne prouve pas que le problème a disparu. Conservez les preuves de la vérification ultérieure et documentez les limites restantes. Des changements importants dans les accès, paiements ou intégrations peuvent nécessiter une nouvelle revue du périmètre. Un audit décrit un état à un instant donné ; il ne remplace pas la maintenance continue.
6. Préparer un premier échange utile
Préparez une description de l’activité, les principales URL, les technologies connues, les prestataires impliqués et les dates à éviter. N’envoyez ni mots de passe ni bases de données au premier contact. Expliquez votre préoccupation : continuité du service, droits des clients, changement récent ou manque de visibilité sur la maintenance.
Pour travailler depuis Barcelone avec des équipes dans d’autres pays, convenez de la langue du rapport, des fuseaux horaires et d’un interlocuteur opérationnel. La proximité facilite la coordination, mais la qualité repose sur un périmètre précis, des preuves claires et un suivi. Ce sont des critères utiles pour comparer les propositions et obtenir une amélioration vérifiable.