====== Script de présentation — Processus Patching SANEF ======

<WRAP round info>
**Format :** présentation DSI, ~18 minutes de parole + Q&A\\
**Ton :** oral, direct, factuel. Préférer des phrases courtes. Regarder l'auditoire, pas le slide.\\
**Astuce :** les phrases en //italique// sont des respirations / silences volontaires, souvent plus efficaces que les arguments.
</WRAP>

----

===== Slide 1 — Titre (30 s) =====

<code>
[entrée en scène, attendre quelques secondes]
</code>

Bonjour à tous, merci d'être là.

On va parler ce matin du **patching des serveurs SANEF** — de comment ça se passe aujourd'hui, de ce que ça coûte réellement à l'équipe SECOPS, et de ce qu'on est en train de mettre en place pour changer la donne.

L'idée, c'est de vous montrer pourquoi l'automatisation qu'on développe — **PatchCenter Web** — n'est pas juste un outil de confort : c'est un vrai levier de sécurité pour SANEF.

//[pause — transition slide]//

----

===== Slide 2 — Sommaire (30 s) =====

Voilà rapidement le plan.

On va commencer par **dérouler le processus** étape par étape — pour qu'on ait tous la même image en tête de ce que fait concrètement un patcheur dans sa semaine.

Ensuite on va regarder **la réalité du terrain** : combien d'heures ça prend, et surtout ce qui se passe quand le patcheur doit aussi faire autre chose — les tickets iTop, les tours de garde, la météo sécurité.

Et on finira par **l'apport de l'automatisation** : ce qu'on a déjà — SQATM — et ce qu'on est en train de livrer — PatchCenter Web.

----

===== Slide 3 — Vue d'ensemble (1 min) =====

Le patching d'un serveur, ce n'est pas un geste unique. C'est **quatre phases étalées sur la semaine**.

Première phase, le **jeudi à 14 heures** : le COMEP SECOPS. C'est là qu'on répartit les serveurs à patcher entre les intervenants.

Deuxième phase, **jeudi après-midi et vendredi** : la préparation — ce qu'on appelle aussi le pré-patching. C'est toute la qualification serveur avant de toucher à quoi que ce soit.

Troisième phase, **du lundi au jeudi** de la semaine suivante : l'exécution — le fameux **Jour J**.

Et quatrième phase, **le vendredi** : le nettoyage. On supprime les snapshots des serveurs patchés dans la semaine, et on fait le ménage sur les vieux kernels.

//[pointer le callout en bas]//

Un point important : **on ne patche jamais le vendredi**. Pourquoi ? Parce que si un incident survient, on ne veut pas le traîner tout le weekend. Donc le vendredi est dédié à tout le reste — prépa de la semaine suivante, nettoyage, iTop, météo.

----

===== Slide 4 — Affectation (45 s) =====

Donc on démarre le jeudi au COMEP. 14 heures.

Chaque intervenant repart avec **sa liste de serveurs pour la semaine**. En cible on est à **20 serveurs par intervenant**. C'est un chiffre important à garder en tête, on va y revenir.

Le livrable du COMEP, c'est une liste enrichie : domaine, environnement, OS, responsable applicatif, criticité. Avec ça, le patcheur peut démarrer la qualification immédiatement.

----

===== Slide 5 — Préparation (1 min 30) =====

La préparation — c'est là que le gros du temps invisible se joue.

Pour **chaque serveur**, il faut faire **13 étapes** :

//[parcourir la liste à l'écran, ne pas la lire]//

Ça va de la recherche dans la console Qualys, à l'analyse des vulnérabilités, au SSH pour vérifier l'espace disque, le satellite, le dry-run yum... et ensuite seulement la partie "humaine" : **contacter le responsable applicatif** et lui proposer des créneaux.

//[pointer le KPI à droite]//

Résultat : **20 à 30 minutes par serveur** de travail actif. Pour 20 serveurs par patcheur par semaine, ça fait **6h40 à 10 heures** — rien que sur la préparation.

Et encore — je ne compte pas le temps d'attente de la validation du responsable. Qui peut prendre 1 heure, ou 48 heures. Donc le patcheur jongle avec une dizaine de serveurs en parallèle, tous à des états différents.

----

===== Slide 6 — Jour J (1 min 30) =====

On arrive au Jour J — forcément entre lundi et jeudi.

Là encore, **13 étapes par serveur**.

Ça commence par un message Teams pour prévenir, on prend le snapshot vCenter, on met le serveur en maintenance dans Centreon si c'est de la prod, on fait un snap pré-patch des services et des ports — parce qu'on veut pouvoir comparer après reboot. Ensuite seulement, le yum update. Le reboot. La reconnexion. Le check post-patch. Et enfin la **validation par le responsable applicatif** — qui peut demander 15 minutes ou plus si le service n'est pas immédiatement disponible.

//[pointer les KPIs]//

Le temps actif : **35 à 65 minutes par serveur**. Sur 20 serveurs, on est entre **11h40 et 21h40** par semaine rien que sur l'exécution.

//[petit silence]//

Pourquoi pas le vendredi ? On l'a dit : **au moins 24 heures de recul avant le weekend**. Si un service tombe dimanche, on veut pouvoir le détecter le vendredi.

----

===== Slide 7 — Nettoyage (45 s) =====

Le vendredi, on **regroupe le nettoyage** de toute la semaine.

Suppression des anciens snapshots, suppression des vieux kernels. Environ 1 heure 40 pour le lot de 20 serveurs.

Pourquoi on fait ça en un bloc le vendredi ? Pour deux raisons.

D'abord : on veut **garder le snapshot pendant au moins 24 heures** après le patch, au cas où une anomalie apparaîtrait en production.

Ensuite : c'est un **contexte mental unique**. Traiter les 20 snapshots d'un bloc, c'est beaucoup plus efficace que d'y revenir serveur par serveur.

----

===== Slide 8 — Synthèse temps (1 min) =====

Donc si on additionne tout ça pour **un seul serveur** :

  * Préparation : 20-30 minutes
  * Jour J : 35-65 minutes
  * Nettoyage : 5 minutes

Total : **60 à 100 minutes par serveur**. En moyenne, **1 heure 15**.

//[pointer les KPIs du bas]//

**1 heure 15 par serveur. 20 serveurs par semaine. 25 heures de patching pur.**

//[silence — laisser le chiffre s'installer]//

----

===== Slide 9 — La réalité du patcheur (1 min 30) =====

Maintenant, la vraie question : **est-ce que le patcheur a 25 heures disponibles ?**

Regardons son budget. Le patcheur travaille **5 jours sur 7**, **7 heures par jour** — donc **35 heures par semaine**.

//[pointer la barre]//

Sur ces 35 heures :
  * **28 heures** du lundi au jeudi sont la fenêtre d'exécution des Jours J
  * **3,5 heures** le jeudi après-midi pour le COMEP et le début du pré-patching
  * **7 heures** le vendredi pour finir le pré-patching et nettoyer

Et dans ces 35 heures, le patching seul consomme **entre 20 et 33 heures**.

Autrement dit : **entre 57 % et 95 % du temps disponible**.

//[insister]//

Dans le meilleur des cas — si tous les patches passent sans accroc, si personne ne traîne sur la validation, si aucun incident — il reste 2 heures de marge par semaine.

Et encore. **On n'a pas parlé des autres missions.**

----

===== Slide 10 — Missions annexes (1 min) =====

Parce qu'un patcheur SECOPS n'est pas que patcheur.

//[lister lentement]//

Il doit aussi :
  * Traiter les **tickets iTop** de sécurisation serveur — permanent, 2 à 5 heures par semaine
  * Faire les **mises à jour agents Qualys** et **SentinelOne** — 2 à 6 heures par semaine
  * Prendre le **tour de garde** sur les alertes SentinelOne et Defender — 3 à 6 heures quand c'est son tour
  * Produire la **météo sécurité** — 2 à 4 heures quand c'est son tour

Au total : **9 à 21 heures de missions annexes**.

//[pointer le callout rouge]//

Faites le calcul avec moi :
  * Budget disponible : **35 heures**
  * Patching seul : **20 à 33 heures**
  * Missions annexes : **9 à 21 heures**
  * **Charge totale réelle : 29 à 54 heures par semaine**

//[silence]//

Le patcheur est **structurellement en surcharge**. Pas occasionnellement. Structurellement.

----

===== Slide 11 — Conséquence sécurité (1 min 30) =====

Et c'est là que ça devient **un sujet de sécurité**, pas juste un sujet d'organisation.

//[ton plus grave]//

Quand un patcheur est en surcharge et qu'il prend son tour de garde sur les alertes SentinelOne et Defender, qu'est-ce qui se passe ?

//[lire les points avec poids]//

  * Les alertes sont **triées en surface** — on regarde la criticité apparente, on coche, on passe
  * Les **faux positifs ne sont pas requalifiés** — le bruit de fond s'accumule et masque les vrais incidents
  * Les **vrais incidents sont détectés tardivement** — un ransomware, une exfiltration, un lateral movement
  * L'**enrichissement de contexte** — corrélation process, réseau, utilisateur — n'est pas fait
  * Les **règles de détection** ne sont jamais affinées, parce qu'on n'a pas le temps de faire ce retour d'expérience

//[pointer le callout rouge]//

Et là, on parle d'**incidents de sécurité majeurs**. Ransomware, fuite de données, indisponibilité.

**Le coût d'une seule alerte EDR ratée — c'est sans commune mesure avec le coût de l'automatisation du patching.**

//[silence]//

Voilà pourquoi automatiser le patching, ce n'est pas du confort. C'est de la sécurité.

----

===== Slide 12 — SQATM .exe (45 s) =====

On a déjà fait un pas dans cette direction : **SQATM .exe** est en production depuis un moment.

Cet outil automatise la **phase qualification** — la fameuse préparation des 20-30 minutes par serveur.

//[parcourir le tableau]//

La recherche Qualys plus l'analyse des vulnérabilités passe de 5 minutes à 30 secondes.\\
Le check SSH — disque, satellite, dry-run — passe de 5 minutes à 10 secondes, et surtout on le fait sur 100 serveurs en parallèle.\\
Le tagging Qualys est instantané.

**Gain estimé : 60 à 70 % sur la phase préparation.**

//[transition]//

Mais SQATM ne couvre que la partie qualification. Pour automatiser le Jour J, il fallait passer au niveau au-dessus.

----

===== Slide 13 — PatchCenter Web (1 min 30) =====

C'est l'objet de **PatchCenter Web**.

//[présenter les 3 colonnes]//

Trois grands volets.

**Préparation** — on centralise tout : vue unifiée des 1165 serveurs, audit SSH parallélisé, détection automatique des correspondances prod / hors-prod, workflow de validation intégré, et les tags Qualys auto-appliqués via les Tag Rules.

**Jour J** — on orchestre tout : snapshot vCenter via API, maintenance Centreon via API, notifications Teams automatiques, snap pré et post archivé, yum update en job asynchrone, reboot et reconnexion orchestrés, et détection automatique des régressions.

**Gouvernance** — c'est ce qui manquait le plus : la validation prod / hors-prod **bloquante**, l'historique complet par serveur, l'audit log exportable pour la conformité, et l'authentification LDAP AD SANEF avec 4 profils — admin, coordinateur, opérateur, viewer.

//[conclure]//

Et surtout : le tableau de suivi est **en temps réel**. Fini les Excel.

----

===== Slide 14 — Comparaison chiffrée (1 min) =====

Si on met les trois scénarios côte à côte, serveur par serveur :

//[parcourir le tableau rapidement]//

En mode manuel, on est à **60-100 minutes par serveur**.\\
Avec SQATM, on descend à **40-70 minutes** — **gain de 30 %**.\\
Avec PatchCenter Web, on descend à **15-30 minutes** — **gain de 70 à 75 %**.

//[pointer la dernière ligne]//

**On divise le temps par 3 à 4.**

Et ce qui est intéressant, c'est que **le gain ne vient pas du yum update lui-même** — ça reste le même temps à l'OS de mettre à jour les paquets. Le gain vient de **la suppression des gestes répétitifs** : snapshot, Centreon, notifs, suivi. C'est là que se cache tout le temps perdu.

----

===== Slide 15 — Impact hebdomadaire (1 min) =====

Traduisons ça au niveau hebdomadaire, pour les **20 serveurs par patcheur**.

//[parcourir les 3 lignes]//

En manuel : le patching occupe 20 à 33 heures. Reste 2 à 15 heures. **Insuffisant pour absorber les missions annexes.**

Avec SQATM : on libère 10 à 12 heures supplémentaires. Ça tient si le patcheur n'est pas en tour de garde.

**Avec PatchCenter Web : 5 à 10 heures de patching. Il reste 25 à 30 heures.**

//[laisser respirer]//

**25 à 30 heures par semaine libérées — par patcheur.**

De quoi assurer sereinement les tickets iTop, la garde EDR, la météo. Et même **monter la cadence** si le besoin opérationnel le demande — passer de 20 à 25, 30 serveurs par semaine, sans embaucher.

----

===== Slide 16 — Bénéfices qualitatifs (45 s) =====

Au-delà du temps, il y a tout ce qui est plus difficile à chiffrer mais tout aussi important.

//[balayer rapidement]//

  * **Fiabilité** : on ne peut plus oublier un snapshot ou une maintenance Centreon
  * **Traçabilité** : tout est historisé, exportable pour audit
  * **Gouvernance** : les validations prod / hors-prod deviennent bloquantes
  * **Scalabilité** : un intervenant peut piloter 20 serveurs en parallèle
  * **Onboarding** : un nouveau patcheur est opérationnel en quelques jours
  * **Qualité** : le snap pré/post standardisé détecte les régressions de façon fiable
  * **Conformité** : les tags Qualys automatiques alimentent directement les KPI
  * **Communication** : les notifications Teams standardisées donnent de la visibilité projet

----

===== Slide 17 — Feuille de route (45 s) =====

Où on en est concrètement aujourd'hui.

//[colonne verte]//

**Déjà livré :** SQATM en production. PatchCenter Web avec le catalogue des 1165 serveurs, la correspondance prod / hors-prod, les exclusions patch, le workflow de validation, la gestion des agents Qualys et le déploiement, l'intégration bidirectionnelle iTop, et l'authentification LDAP multi-profils.

//[colonne orange]//

**À venir :** l'orchestration vCenter et Centreon automatique, l'intégration Teams native, l'exécution patching end-to-end en un clic, le module reporting pour la DSI, et l'extension aux serveurs Windows via WSUS et MECM.

On est sur une livraison progressive — on n'attend pas que tout soit fini pour en profiter. Chaque brique livrée apporte déjà du gain.

----

===== Slide 18 — Conclusion (1 min) =====

Je conclus avec **trois messages** à retenir.

//[pointer le premier carré]//

**Un.** Le patching manuel est un **coût caché**. On le voit peu parce qu'il est étalé sur la semaine, mais c'est **20 à 33 heures par semaine par patcheur**.

**Deux.** Le patcheur est **structurellement en surcharge**. Dès qu'il cumule patching, garde et iTop, il dépasse son budget horaire. Ce n'est pas une question de motivation — c'est de l'arithmétique.

**Trois.** L'automatisation **libère 25 à 30 heures par semaine**. Du temps pour **analyser correctement les alertes EDR**.

//[pointer le callout final]//

Le message clé, pour vous, DSI :

//[lire posément]//

**PatchCenter Web n'est pas qu'un gain de productivité.** C'est un **levier de sécurité stratégique**.

Le temps qu'on libère sur le patching, c'est du temps qu'on rend au patcheur pour faire **son vrai métier d'analyste EDR**.

Automatiser le patching, c'est **renforcer directement la capacité de détection et de réponse aux incidents de SANEF**.

Merci.

----

===== Slide 19 — Q&A =====

//[rester en place, poser le clicker, regarder l'auditoire]//

Je prends vos questions.

----

===== Annexe — Questions fréquentes anticipées =====

==== "Pourquoi pas un outil du marché ?" ====

On a évalué. Aucun outil marché ne couvre à la fois : la nomenclature SANEF (décodage hostname), l'intégration bidirectionnelle iTop, la correspondance prod / hors-prod, et l'orchestration Centreon / vCenter spécifique SANEF. PatchCenter Web est **conçu pour le contexte**, et ça se voit dans le taux d'adoption de l'équipe.

==== "Combien ça coûte à développer vs la licence d'un outil marché ?" ====

Le développement est internalisé — pas de licence récurrente, pas de dépendance vendor. Le coût est largement en-dessous de ce qu'aurait coûté un déploiement commercial type Red Hat Satellite Insights ou BigFix sur 1165 serveurs.

==== "Et la sécurité de l'outil lui-même ?" ====

PatchCenter Web est derrière HAProxy avec TLS, authentification LDAP AD SANEF, séparation des rôles (4 profils), audit log complet. Tout transite par la VRF d'administration SANEF. Aucune exposition internet.

==== "Que devient SQATM une fois PatchCenter Web complet ?" ====

SQATM reste pertinent pour les opérations unitaires rapides et le tagging ponctuel. Les deux outils **coexistent** : SQATM = léger, rapide, unitaire. PatchCenter = orchestration lourde, campagnes, gouvernance.

==== "Risque de régression : si PatchCenter Web tombe, que fait-on ?" ====

Le patching manuel reste possible en fallback — tous les outils sous-jacents (SSH, vCenter, Centreon, Qualys) sont indépendants de PatchCenter. On ne crée pas de dépendance critique : PatchCenter Web **orchestre**, il ne **remplace** pas les outils existants.

==== "Planning de mise en service complète ?" ====

Livraison progressive en cours. Les modules catalogue, correspondance, validations et agents Qualys sont déjà en production. L'orchestration vCenter/Centreon/Teams est prévue sur les mois à venir. Le patching end-to-end en un clic est la dernière brique.

----

//— Script de présentation — SANEF DSI / Sécurité Opérationnelle — Avril 2026//
