Retour d'expérienceLecture : 4 min

Pourquoi un score de conformité peut baisser quand on progresse

Dans mon laboratoire AWS, le taux de conformité mesuré par Prowler a reculé de 57,3 % à 57,0 % juste après une amélioration de la configuration, parce que Prowler n'audite que ce qui existe et que le nombre de contrôles évalués avait augmenté.

Publié
Juillet 2026
Contexte
Laboratoire · compte AWS, région de Paris, audit Prowler en lecture seule
Projet lié
Audit de sécurité d'un environnement AWS

Le symptôme

Pour un audit de sécurité AWS, j'ai monté un laboratoire dans mon propre compte AWS, en région de Paris. Le scénario : héberger des sauvegardes hors site qu'un rançongiciel ne peut pas effacer. L'environnement est mal configuré exprès : un bucket S3 de sauvegarde public et sans versioning, une instance EC2 avec SSH ouvert à tout Internet, un compte de service IAM doté de AdministratorAccess.

Prowler l'a audité trois fois, depuis un compte dédié en lecture seule (SecurityAudit et ViewOnlyAccess). Premier scan, sur les référentiels CIS, RGPD et PCI-DSS : 47,8 % de conformité. Après huit remédiations : 57,3 %. Puis, après le chiffrement par une clé KMS et un second bucket verrouillé par Object Lock, le taux est redescendu à 57,0 %.

Ce que le symptôme écarte déjà

Avant de chercher une régression, les faits permettaient déjà de raisonner :

  • Entre les deux derniers scans, j'ai ajouté des protections : un second bucket avec Object Lock en mode Conformité, et le chiffrement SSE-KMS avec une clé que je gère. Aucune des deux n'affaiblit la configuration.
  • Un taux est un rapport entre deux nombres. Il peut baisser parce que le premier diminue, ou parce que le second augmente.
  • La question devient : sur combien de contrôles le taux est-il calculé, à chaque scan ?

Le nombre de contrôles a changé

Prowler indique, à chaque scan, le nombre de contrôles évalués. Il est passé de 186 à 213, puis à 232. Prowler n'audite que ce qui existe : activer CloudTrail ou créer le second bucket ajoute de nouveaux contrôles à satisfaire, dont une partie échoue au départ.

Le même effet jouait déjà au deuxième scan, puisque CloudTrail faisait partie des huit remédiations. Les corrections pesaient alors plus que les nouveaux contrôles, et le taux montait. Au troisième scan, l'effet des nouveaux contrôles l'a emporté, de peu : le taux a perdu 0,3 point.

Taux de conformité

Scan 147,8 %

Scan 257,3 %

Scan 357,0 %

Contrôles évalués

Scan 1186

Scan 2213

Scan 3232

Scan 1 : état initial · Scan 2 : après 8 remédiations · Scan 3 : après KMS et Object Lock

Fig. 1Le taux de conformité calculé par Prowler (échelle de 0 à 100 %) et le nombre de contrôles évalués (échelle de 0 à 250), à chaque scan.

Pourquoi un ratio peut reculer quand la configuration s'améliore

L'explication est générale, et les chiffres qui suivent servent d'illustration : ils ne viennent pas du laboratoire. En substance, un taux de conformité rapporte les contrôles réussis aux contrôles évalués. Sur 100 contrôles, 57 réussis donnent 57 %. Ajoutons une ressource qui apporte 10 nouveaux contrôles, dont 5 réussissent au départ : on obtient 62 sur 110, soit 56,4 %. Rien n'a été dégradé. Le taux baisse parce que le périmètre audité a grandi.

Le taux mélange donc deux mouvements : ce que l'on corrige, et ce que l'on ajoute au périmètre. Seul, il ne dit pas lequel l'emporte.

Lire le taux avec deux autres chiffres

Le taux se lit avec le nombre de contrôles évalués, qui donne la taille du périmètre, et avec les échecs par gravité, en valeur absolue. Les corrections ont suivi l'ordre de gravité donné par Prowler : d'abord le SSH ouvert à tout Internet, de gravité critique, limité à l'adresse IP d'administration.

Entre le premier et le dernier scan, les échecs critiques sont passés de 5 à 3, les hauts de 20 à 14. Ces deux chiffres comptent les échecs restants, gravité par gravité : ils disent si le risque baisse, ce qu'un pourcentage ne dit pas seul.

Ils montrent aussi le chemin restant : 57 % est loin du compte, avec 3 échecs critiques et 14 hauts. Parmi les familles encore en échec, certaines n'étaient pas abordées par mes corrections : alertes sur les événements sensibles de CloudTrail, journaux de flux réseau, détection des menaces native d'AWS, gestion des identifiants IAM.

Ce que j'en retiens

  • Un taux se donne avec son dénominateur. « 57 % sur 232 contrôles » ne dit pas la même chose que « 57 % » : le périmètre audité change à chaque ressource ajoutée.
  • Les échecs par gravité, en valeur absolue, disent ce qui reste à traiter. Deux échecs critiques en moins comptent plus que quelques dixièmes de point.
  • Mesurer régulièrement plutôt que par scans ponctuels : sur un prochain audit, j'automatiserais Prowler à intervalle régulier, avec un suivi de l'évolution. Une variation du taux s'expliquerait par ce qui a changé entre deux mesures, et une modification qui rouvre un échec serait repérée en quelques jours.