AGCG Genuine
Consulting Group

Scanners automatiques, rapports hebdomadaires, CVSS, plans de patching, comités de suivi… Sur le papier, la gestion des vulnérabilités semble maîtrisée. Les indicateurs sont là, les processus sont décrits, les instances de suivi existent.

Dans la réalité, ce dispositif masque souvent un phénomène silencieux : le backlog de vulnérabilités explose, ne se résorbe jamais vraiment, et devient une dette cyber massive. Ce “tas de sable” invisible grossit mois après mois. Personne ne le regarde vraiment. Personne n’en rend compte clairement. Jusqu’au jour où un incident révèle brutalement une vulnérabilité “connue depuis 18 mois”… mais jamais traitée.

Pour AGCG Genuine Consulting Group, le backlog est devenu l’un des échecs silencieux les plus sous-estimés de la cybersécurité moderne.

1.1. Un modèle hérité du monde IT, inadapté au volume cyber actuel

La gestion des vulnérabilités repose souvent sur une logique simple : « on détecte → on classe → on corrige ». Un modèle hérité du patch management des années 2000. Sauf que :

• un système peut remonter des milliers de vulnérabilités en une seule analyse,
• les environnements Cloud évoluent en permanence,
• les dépendances logicielles explosent,
• le shadow IT multiplie les surfaces,
• les responsabilités sont tellement diluées que plus personne n’est réellement accountable.

Le modèle n’a pas changé, mais le volume, lui, a été multiplié par 100.

---

1.2. Les équipes reçoivent des rapports… mais pas de décisions

Les scanners produisent des milliers de lignes, des CVE sans contexte, des scores CVSS techniques, des notes abstraites. Les équipes cyber doivent prioriser, mais elles n’ont ni le mandat, ni les arbitrages métier, ni la visibilité budgétaire nécessaires pour trancher.

Résultat : on corrige au fil de l’eau, sur ce qui remonte en alerte ou en audit, mais le backlog croît mécaniquement, faute de décisions structurantes du COMEX ou de la DSI.

---

1.3. Un backlog mélangé : vieilles vulnérabilités, faux positifs, assets inexistants

L’un des problèmes systémiques du backlog est sa pollution intrinsèque :

• anciens assets supprimés mais restés dans l’outil,
• doublons,
• faux positifs jamais purgés,
• vulnérabilités déjà corrigées mais non rescannées,
• périmètres migrés, environnements intermédiaires oubliés,
• organisation IT éclatée, responsabilités floues.

Entre 25 % et 40 % d’un backlog type peut n’être que du bruit inutile, jamais nettoyé.

---

1.4. Aucun lien explicite entre vulnérabilités et impacts métier

Les organisations évaluent les vulnérabilités en CVSS, mais les dirigeants décident en impact métier. Tant que la cyber ne traduit pas clairement :

• disponibilité,
• confidentialité,
• intégrité,
• exposition financière,
• dépendances critiques, continuité d’activité, image de marque,

…les remédiations n’apparaissent pas prioritaires pour les métiers et le COMEX.

---

1.5. Des équipes qui travaillent “au fil de l’eau”, sans feuille de route structurée

Sans trajectoire, la dynamique est toujours la même :

• on corrige ce qui crie le plus fort,
• on traite au volume ce qui sort des rapports,
• on répond aux audits et aux contrôles régulateurs,
• on “gère des tickets” plutôt qu’un portefeuille de risques.

Personne ne pilote réellement :

• la dette historique,
• la dette applicative,
• la dette infrastructure,
• la dette Cloud,
• la dette organisationnelle.

Le backlog n’est pas un problème technique : c’est une dette stratégique.

« Le backlog de vulnérabilités n’est pas un détail opérationnel : c’est l’un des indicateurs les plus révélateurs de la perte de maîtrise cyber d’une organisation. »

— AGCG Genuine Consulting Group

2.1. Une dette cyber invisible mais massive

Un backlog de 20 000 vulnérabilités n’est pas un problème opérationnel. C’est un signal de gouvernance qui révèle une accumulation de :

• dette technique,
• dette d’architecture,
• dette process,
• dette organisationnelle.

Chaque vulnérabilité non traitée est un risque non arbitré. Le backlog mesure la distance entre le niveau de risques accepté… et le niveau de risques réellement supporté.

---

2.2. Une perte de contrôle qui s’aggrave avec le Cloud

Multi-cloud, conteneurs, pipelines CI/CD, micro-services : les surfaces d’attaque explosent, les dépendances se multiplient et se recomposent en continu. Un backlog qui explose est souvent le symptôme d’un Cloud mal maîtrisé :

• absence de tagging robuste,
• environnements orphelins ou non inventoriés,
• périmètres partagés entre plusieurs équipes,
• pipelines non sécurisés et déployant en continu des images vulnérables.

---

2.3. Un biais de perception qui trompe les dirigeants

Les directions pensent souvent que « s’il y avait un vrai problème, on m’en parlerait ». Mais les équipes cyber filtrent, simplifient, et ne remontent que ce qu’elles jugent “présentable”. Parfois par souci de pédagogie, parfois par peur d’alerter sans solution.

Résultat : le COMEX et la direction IT sont aveugles sur l’ampleur réelle de la dette. Le backlog reste un impensé stratégique, alors qu’il devrait être un indicateur clef du pilotage de la résilience.

À travers nos missions (finance, industrie, transports, retail, secteur public), AGCG a développé une approche en quatre temps pour transformer un backlog subi en trajectoire pilotée.

3.1. Nettoyage du backlog : la phase la plus sous-estimée

Nous commençons toujours par un travail de nettoyage systématique :

• dédoublonnage,
• retrait des assets obsolètes ou supprimés,
• purge des faux positifs,
• re-scan de validation sur les périmètres critiques,
• segmentation du backlog par périmètre (applications, infra, Cloud, filiales, environnements).

Entre 25 % et 40 % du backlog disparaît immédiatement, ce qui redonne de la lisibilité et de la crédibilité aux chiffres.

---

3.2. Priorisation métier : la seule qui fonctionne

Nous relions chaque vulnérabilité – ou groupe de vulnérabilités – à :

• l’application ou l’asset concerné,
• le processus métier supporté,
• la criticité de l’asset,
• les dépendances internes et externes,
• les contraintes réglementaires ou contractuelles associées.

Cette mise en contexte fait apparaître :

• les 3 urgences réelles,
• les 5 leviers structurants,
• la dette critique invisible qui n’apparaissait pas dans les rapports techniques.

---

3.3. Construction d’un plan de réduction de dette sur 6 à 18 mois

Le backlog ne se traite pas “au fil de l’eau”. Il se traite en vagues structurées :

• par périmètre (applications critiques, environnements Cloud, infra réseau…),
• par chantiers (applicatif / infra / Cloud),
• par programmes (réduction de dette par domaine, basés sur un modèle ROSI),
• avec des KPI explicites (réduction mensuelle par périmètre, dette résiduelle, effort consommé).

---

3.4. Mise en place d’un pilotage COMEX

Le COMEX et la direction IT reçoivent enfin une vision consolidée :

• dette par périmètre et par domaine,
• trajectoire visuelle de réduction,
• risques non arbitrés mis en évidence,
• ROSI par chantier,
• effort vs impact, dans un langage compréhensible par les décideurs.

À partir de là, le COMEX peut décider de :

• financer certains chantiers,
• contourner ou accepter certains risques,
• réarchitecturer des systèmes devenus intenables,
• désinvestir sur des périmètres obsolètes.

Le backlog de vulnérabilités n’est pas un simple “flux d’anomalies” à traiter quand on a le temps. C’est un indicateur stratégique de perte – ou de reprise – de maîtrise.

Quand il n’est pas piloté :

• la dette cyber enfle,
• les risques augmentent,
• les équipes s’épuisent,
• les décisions se fragmentent,
• les incidents deviennent inévitables.

Quand il est pris en main :

• la dette diminue de manière visible,
• la priorisation devient claire,
• la gouvernance se renforce,
• le COMEX retrouve la visibilité,
• la cyber redevient un levier de transformation, et non un centre de coûts subi.

Le backlog de vulnérabilités est aujourd’hui l’un des signaux de gouvernance les plus révélateurs de la maturité cyber. Il marque la frontière entre :

• une organisation qui subit sa dette,
• et une organisation qui pilote sa résilience.

L’expérience AGCG montre qu’une approche structurée, business-driven et consolidée permet non seulement d’assainir la dette, mais surtout de restaurer la maîtrise opérationnelle et la confiance des dirigeants.

Le backlog n’échoue pas parce qu’il est volumineux. Il échoue parce qu’il n’est pas traité au bon niveau : celui de la décision stratégique. Notre rôle, chez AGCG, est précisément de le rendre lisible, actionnable et utile – enfin.