# D'un problème de vulnérabilité à un changement en production · Stilla > Le scanner détecte des milliers de problèmes, mais la correction de ces problèmes en production est toujours un travail manuel. URL: https://stilla.eywo.digital/fr/blog/from-vulnerability-to-change/ Language: fr Last updated: 2026-10-25 [← Retour au blog](https://stilla.eywo.digital/fr/blog/) Sécurité23 juillet 2026Mis à jour 25 octobre 20264 min luÉquipe Eywo # D'un problème de vulnérabilité à un changement en production Le scanner détecte des milliers de problèmes, mais la correction de ces problèmes en production est toujours un travail manuel. Comment lier les vulnérabilités aux serveurs, services et changements afin que les plus importants soient corrigés en premier lieu. L'équipe de sécurité reçoit un long export du dernier scan. Des milliers de lignes, chacune avec un ID de vulnérabilité, une adresse IP et un score de gravité. Quelqu'un les divise par équipe et les envoie. Les opérations essaient alors de déterminer quels sont les serveurs concernés, à quel service ils appartiennent et quand ils peuvent être modifiés. Un mois plus tard, le prochain export arrive, et personne ne peut dire avec certitude ce qui a été corrigé depuis le précédent. Derrière cette situation se trouvent des personnes fatiguées des deux côtés. La sécurité a l'impression que les opérations ne l'écoutent pas. Les opérations ont l'impression de recevoir des listes sans contexte ni priorités. Et la direction pose une question simple à laquelle personne ne peut répondre rapidement : sommes-nous dans une meilleure position qu'il y a un mois ? ## Pourquoi un export de scanner ne suffit pas Un scanner fait ce pour quoi il est conçu : il trouve des versions de logiciels vulnérables. Ce qu'il ne sait pas, c'est quel rôle joue un serveur, quel service s'exécute dessus et qui est responsable de ce service. Sans cela, une découverte ne peut pas être transformée en travail de manière sensée. Nous voyons souvent les mêmes faiblesses : - les découvertes sont classées par score seul, même si dans la réalité des opérations, il importe davantage de savoir si une vulnérabilité est activement exploitée, - les délais de correction ne sont pas dérivés de la gravité, de sorte qu'une découverte critique peut attendre autant qu'une mineure, - le chemin de la découverte à la modification passe par e-mail et par des tickets créés manuellement, - l'état de la correction est reconstitué à partir de plusieurs feuilles de calcul et est toujours à la traîne. ## Comment aborder le problème Une découverte de vulnérabilité ne devient significative que lorsqu'elle est connectée à la CMDB. Une fois que nous savons sur quel serveur elle se trouve, nous savons également quel service elle met en risque, qui est le propriétaire de ce service et quelle est la fenêtre de maintenance. Ce n'est que alors que nous pouvons décider de l'ordre et du moment. La priorité devrait suivre deux questions : quelle est la gravité de la vulnérabilité et est-elle activement exploitée ? Le délai suit de la réponse. Le chemin vers une correction devrait passer par le processus normal de changement, de sorte que même une correction urgente respecte l'impact sur les services, avec des délais plus courts. ## Comment Stilla gère le problème Stilla **importe les découvertes de votre scanner** et les fait correspondre à des éléments de la CMDB. Les vulnérabilités sont alors visibles par serveur et par service, de sorte que chaque propriétaire de service voit ce qui le concerne. La priorisation s'appuie sur cela : - les **vulnérabilités activement exploitées (KEV)** sont clairement signalées afin qu'elles ne se perdent pas parmi les autres, - les **délais de correction basés sur la gravité** fixés lorsqu'une découverte doit être corrigée, - un **mode accéléré pour les problèmes critiques**, convenu à l'avance dans l'accord de correctif avec le propriétaire du service, fournit un chemin plus court sans contourner la responsabilité. Le chemin de la découverte à la correction est un **plan de correctif par vagues**. Les serveurs sont regroupés par service et fenêtre, et le plan génère les changements en une seule étape. Chaque changement passe par le calcul de l'impact, la vérification des fenêtres de maintenance, les gels et la détection des collisions. Les nœuds redondants peuvent être corrigés un à la fois de sorte que le service reste disponible. Le **tableau de bord de vulnérabilité et de correction** montre combien de découvertes sont ouvertes, lesquelles approchent de leur délai et comment la correction progresse par service. La sécurité et les opérations regardent les mêmes données, ce qui met fin au débat sur quelle feuille de calcul est à jour. ## Une image partagée au lieu de passer des listes La gestion des vulnérabilités n'est pas seulement une discipline de sécurité. C'est un travail opérationnel qui nécessite un contexte : serveurs, services, propriétaires et changements. Lorsque ces informations sont connectées, la sécurité n'a pas à poursuivre et les opérations n'ont pas à deviner. Les deux parties peuvent voir ce qui doit être corrigé en premier, qui approuve et quand cela se produira. Et la question de la direction sur le fait de savoir si les choses sont meilleures qu'il y a un mois a une réponse sur un seul écran. L'importation de découvertes, la priorisation des vulnérabilités, la planification des correctifs et le tableau de bord de correction sont inclus dans l'édition Business. **Stilla Business** Pour les opérations qui souhaitent connecter la supervision, la sécurité et les fournisseurs. [Comparer les éditions →](https://stilla.eywo.digital/fr/editions/) ## Plus d'articles [Sécurité·16 juillet 2026 ### Gestion des correctifs sans négociation mensuelle Chaque mois, la même série d'emails pour savoir quand les serveurs peuvent être redémarrés. Un accord de correctif avec le propriétaire du service transforme une négociation récurrente en une règle établie. Business4 min lu](https://stilla.eywo.digital/fr/blog/patching-without-monthly-negotiation/)[CMDB·25 octobre 2026 ### Le réseau virtuel dans la CMDB : du groupe de ports au commutateur leaf Entre une machine virtuelle et le réseau physique se trouve une couche que la plupart des CMDB ne voient pas – les commutateurs virtuels, les groupes de ports et les liaisons ascendantes d'hôte. Pourtant, c'est exactement là que l'on décide quels services un changement de réseau affectera. Standard4 min lu](https://stilla.eywo.digital/fr/blog/virtual-network-in-the-cmdb/)[Gouvernance·25 octobre 2026 ### NIS2 et DORA : ce que l’exploitation IT doit pouvoir prouver Les deux réglementations posent la même question : savez-vous quels services sont impactés par une interruption, qui en est responsable et qu'est-ce qui a changé et quand ? Sans cartographie des dépendances fiable, les réponses sont compilées manuellement, souvent sous pression de temps. Standard3 min lu](https://stilla.eywo.digital/fr/blog/nis2-dora-evidence/)