Le renseignement sur les correctifs et leur déploiement ne sont pas des outils raccordés à la plateforme : ils y sont intégrés, au-dessus du même référentiel. L'analyse du risque et le déploiement du correctif forment une seule chaîne, sans export ni recoupement manuel entre les deux.
Le scanner de vulnérabilités produit une liste. La CMDB en décrit une autre. L'outil de déploiement travaille sur un troisième périmètre. Entre les trois, quelqu'un exporte, recoupe et arbitre à la main — et pendant ce temps la fenêtre d'exploitation reste ouverte.
Le problème n'est pas le nombre de CVE publiées. C'est qu'aucun de ces outils ne sait, seul, lesquelles concernent des machines réellement présentes, réellement exposées et réellement critiques dans votre parc.
Patch Intelligence et Patch Management lisent l'inventaire du system of record. Pas d'export, pas de recoupement, aucun écart de périmètre entre ce qui est analysé et ce qui est corrigé.
Sévérité, existence d'un exploit connu, activité observée, et criticité métier de la machine concernée — plutôt que le seul score CVSS appliqué uniformément.
Patch Intelligence signale les correctifs connus pour provoquer des régressions applicatives. Vous le savez avant de les pousser, pas après.
Anneaux successifs, fenêtres de maintenance négociées, populations pilotes puis généralisation. Systèmes d'exploitation et applications tierces dans le même mouvement.
L'état après correction est reconstaté par la découverte, pas simplement déclaré par l'outil de déploiement. Le référentiel confirme — ou signale que le correctif n'a pas pris.
Taux de couverture, âge des correctifs manquants et exposition résiduelle sont mesurables à tout instant. C'est ce que demandent NIS 2, DORA et les auditeurs.
Le scan de conformité des correctifs n'est pas un produit séparé qu'il faudrait raccorder : c'est le même moteur qui constate l'état machine par machine, avec ou sans agent, et qui déclenche ensuite la campagne. Les politiques — anneaux, fenêtres, cadence Patch Tuesday, traitement hors cycle — se paramètrent une fois et s'exécutent seules.
L'écart entre ce qui est constaté et ce qui est attendu devient la liste de travail. Aucun export, aucun rapprochement manuel entre l'outil qui mesure et celui qui corrige.
La cadence mensuelle de Microsoft structure le cycle, mais elle ne le résume pas : publications hors cycle, éditeurs tiers et correctifs de firmware suivent la même chaîne.
Pilotes, puis IT, puis métiers, puis serveurs et production. Chaque anneau valide le suivant, et un échec arrête la progression au lieu de se propager.
Une vulnérabilité activement exploitée sort du cycle et part sur toutes les populations sous 24 à 48 heures. C'est une exception documentée, pas une habitude.
Les fenêtres de maintenance sont négociées avec les métiers, et la procédure de retour arrière est écrite avant d'en avoir besoin — pas improvisée le soir où il faut s'en servir.
Agent décroché, service arrêté, espace disque insuffisant : les causes récurrentes d'échec sont remédiées automatiquement plutôt que rejouées à la main chaque mois.
État réel du parc corrigé et non corrigé, y compris les machines que l'inventaire précédent ne voyait pas. C'est le point de départ, et il surprend souvent.
Serveurs, postes nomades, postes de production, équipements en magasin : chacun a ses contraintes de disponibilité et son niveau de risque acceptable.
Anneaux de déploiement, calage sur le Patch Tuesday, fenêtres négociées avec les métiers, et procédure de retour arrière écrite avant d'en avoir besoin.
La majorité des vulnérabilités exploitées ne concerne pas le système d'exploitation. Le catalogue applicatif tiers est traité au même titre.
Les échecs récurrents — agent décroché, service arrêté, espace disque insuffisant — sont traités automatiquement plutôt que rejoués manuellement.
Des indicateurs lisibles par un RSSI et par un comité de direction : exposition résiduelle, délai moyen de correction, tendance.
Pour la gestion du poste de travail et des correctifs, nous déployons les deux. Elles ne visent pas le même type de parc, et le choix se fait sur le vôtre — pas sur nos habitudes.
Découverte continue, gestion multi-OS, mobiles sous MDM, remédiation autonome des dérives et patch piloté par le risque — le tout au-dessus du même référentiel que le service management.
Le bon choix si votre parc est surtout composé de postes de travail et de mobiles, et si vous voulez une chaîne continue du poste jusqu'au service desk.
Un agent unique qui tient des dizaines de milliers de machines, y compris mal ou rarement connectées, avec une évaluation de conformité permanente plutôt que par campagne.
Le bon choix si vous administrez de très grands parcs de serveurs, des machines hors réseau une partie du temps, ou si la conformité continue est une obligation contractuelle ou réglementaire.
