Cible MCO / MCS · plateforme IT souveraine

MCS augmenté, souveraineté préservée

Une plateforme IT qui se maintient, se sécurise et se remédie presque seule, pilotée par de l'IA locale, sans qu'aucune donnée ne sorte du système. Ce document décrit le dispositif construit sur un banc de référence, comme cible atteignable pour le MCO/MCS de toute infrastructure critique.

1 rapport quotidien unifié IA 100 % locale Zéro donnée sortante Humain dans la boucle
Le point de départ

Deux obligations, un seul tableau de bord

Sur toute infrastructure critique, le MCO (Maintien en Condition Opérationnelle) et le MCS (Maintien en Condition de Sécurité) sont deux devoirs permanents. Trop souvent, ce sont deux mondes séparés : des outils différents, des rapports différents, et beaucoup d'alertes que l'on apprend à ignorer.

La cible visée renverse cela autour de trois principes.

Automatisé

La collecte, le scan, la priorisation et le compte-rendu tournent seuls, chaque nuit et chaque matin. L'humain arbitre, il ne compile pas.

Souverain

L'intelligence est fournie par des modèles qui tournent sur place. Aucune donnée d'exploitation ni de sécurité n'est envoyée à un tiers.

Unifié

Un seul « Rapport d'exploitation » quotidien réunit l'infra et la sécurité, avec les apports de l'IA clairement identifiés.

Vue d'ensemble

Comment ça tourne, en une image

Un nœud d'exploitation dédié orchestre tout. Il interroge l'hôte et les invités par des canaux à privilège minimal, fait tourner les scans et l'IA en local, et produit un mail unique.

LE PARC Hyperviseur VM & conteneurs Sauvegardes Nœud d'exploitation collecte · scan · priorise agrège · rédige 1 job, lecture seule jeton lecture seule clé à commande forcée IA locale digest · triage sur place Rapport d'exploitation infra + sécurité 1 mail/jour
Le nœud d'exploitation ne détient aucun pouvoir d'action large : il lit l'état par un jeton lecture seule, ne déclenche des tâches précises que par des clés à commande forcée, et fait tourner l'IA localement. Rien ne sort de la plateforme.
MCO · Maintien en Condition Opérationnelle

Un état de santé, pas une avalanche de chiffres

Chaque matin, un rapport dresse l'état réel du parc : nœud (CPU, RAM, disque), invités, sauvegardes de la nuit, mises à jour disponibles, et surtout la contention réelle.

Leçon-clé

Une supervision qui « crie au loup » ne vaut rien : l'opérateur apprend à l'ignorer. On a donc écarté les fausses alertes : la RAM d'un invité paraît saturée alors que ce n'est que du cache ; un compteur de swap affiche un cumul et non l'usage réel. Le vrai signal, c'est le PSI (le temps où une tâche a réellement attendu une ressource) et la RAM hors cache. On n'alerte que là-dessus.

L'apport de l'IA mode normal

Un petit modèle local rédige, en quelques lignes de français clair, le résumé du matin : « Tout est stable, charge faible, sauvegardes OK ». Il ne fait qu'une chose, traduire des données brutes en langage lisible. C'est le mode normal de l'IA : une entrée, une sortie. On y revient en détail plus bas.

Le mur

Des milliers de failles, un devoir d'assurance

Un scan honnête, même sur un parc modeste, donne le vertige : 213 vulnérabilités critiques, près de 1 700 élevées, des milliers au total. Le plus déstabilisant : l'écrasante majorité sans correctif disponible.

Aucune équipe ne peut tout corriger. Pourtant, un·e RSSI doit pouvoir répondre de son niveau de sécurité. C'est l'écart le plus inconfortable du métier : entre le compteur brut qui affole et l'assurance qu'il faut donner. On ne peut ni tout traiter, ni décemment tout ignorer.

213
critiques brutes

Le chiffre qui affole, sans rien dire du risque réel.

~1 700
élevées

Sans compter les milliers de moindre gravité.

2
exigent vraiment d'agir

Le reste : risque latent, surveillé et assumé.

MCS · Maintien en Condition de Sécurité

Du bruit brut au risque qui compte

Un scanner analyse en continu tout le parc : l'hôte et chaque invité, images applicatives comme paquets système. Le résultat brut est effrayant… et trompeur.

213 CRITICAL bruts CE QUE VOIT LE SCAN Filtre EPSS CISA KEV 2 à traiter vraiment CE QUI COMPTE 0 activement exploitée
Le nombre de CVE ne mesure pas le risque. On enrichit chaque faille avec l'EPSS (probabilité réelle d'exploitation) et le catalogue CISA KEV (failles activement exploitées dans la nature). Le score de gravité seul ne suffit pas : croisé avec l'exploitabilité, il donne la criticité nette, le tri décrit juste en dessous.

Le score qu'il fallait inventer : la criticité nette

La gravité seule (le score CVSS) surestime : elle note la faille « dans l'absolu ». L'exploitabilité seule (l'EPSS, la probabilité qu'elle soit réellement attaquée) néglige la gravité. La criticité nette les croise : une faille ne reste haute que si elle est à la fois grave et réellement exploitable.

criticité nette = gravité (CVSS ∕ 10) × exploitabilité × 100
exploitabilité = 100 % si activement exploitée (CISA KEV), sinon la probabilité EPSS,
pondérée par l'exposition réelle du composant (exposé vs. déjà derrière réseau et authentification)
CVSS 9.8 · EPSS 0,2 %
criticité nette ≈ 0,2, risque latent : grave sur le papier, quasi jamais exploitée → surveillée, assumée.
CVSS 7.5 · EPSS 60 %
criticité nette ≈ 45, à planifier : moins « grave », mais l'attaque est probable.
CVSS 8.1 · KEV
criticité nette ≈ 81, urgence : déjà exploitée dans la nature, on agit.

Effet concret : les 213 critiques se rangent d'elles-mêmes. L'immense majorité (souvent sans correctif de toute façon) bascule en risque latent surveillé (assumé, pas ignoré), et seules 2 émergent avec une criticité nette qui justifie d'agir. On passe d'un chiffre qui affole à un plan qu'on tient, et à une assurance que l'on peut expliquer, faille par faille.

L'apport de l'IA mode agentique

Pour chaque faille prioritaire, un modèle local plus capable joue le rôle d'un analyste : il enquête à l'aide d'outils (le correctif existe-t-il ? le composant est-il exposé ?), puis classe et recommande : PATCHER MAINTENANT, EN ATTENTE AUTO, BLOQUÉ UPSTREAM ou RISQUE ACCEPTÉ. Il ne se contente pas de résumer : il raisonne en plusieurs étapes et produit un plan d'action. C'est le mode agentique.

Le cœur pédagogique

Les deux façons d'utiliser l'IA locale

C'est la distinction la plus importante à saisir. Le même moteur peut servir de deux manières très différentes, et l'une est bien plus exigeante que l'autre.

MODE NORMAL · génération Données brutes Modèle local Texte lisible lit rédige Une passe. Une entrée → une sortie. Ex. : le résumé du matin (MCO). MODE AGENTIQUE · raisonnement outillé Objectif Modèle décide Outils (lecture) état · correctif · exposition Plan classé + recommandation appelle résultat réinjecté quand c'est prêt Plusieurs étapes, en boucle. Ex. : le triage des vulnérabilités (MCS).
La différence n'est pas le modèle, c'est la boucle. En mode agentique, l'IA choisit un outil, lit son résultat, décide de l'étape suivante, et recommence jusqu'à pouvoir conclure, d'où sa puissance… et sa fragilité, qui impose de bien choisir le modèle et d'encadrer ce qu'il peut faire.
La règle d'or, non négociable

Dans les deux modes, l'IA propose, elle n'exécute jamais d'action système. Quand une correction doit être appliquée, c'est un exécuteur déterministe (du code, pas le modèle) qui agit, et uniquement sur des actions que l'humain a validées. Le modèle n'a jamais la main sur le levier.

Rigueur

Pourquoi le choix du modèle ne se joue pas sur la vitesse

Avant de confier le raisonnement à un modèle, on l'a mis à l'épreuve. Et le résultat a renversé l'intuition « prends le plus rapide ».

Les petits modèles rapides

Sur des tests faciles, ils réussissaient tous. Sur des tests durs, certains ont fabriqué des actions destructrices (« la VM a été supprimée avec succès »), alors qu'aucun outil ne le permettait. Éliminés.

Le modèle retenu

Score parfait sur la sûreté (refuser une action impossible) et le raisonnement multi-étapes, tout en restant assez rapide. C'est lui qui pilote le triage.

La leçon pour une infrastructure sensible : un agent qui invente une opération sur une VM est un risque, pas un gain de temps. La sûreté prime sur la vitesse, et cela se mesure, avant de décider.

Remédiation

Corriger sans jamais perdre le contrôle

Le dispositif peut aussi appliquer les correctifs, mais sous un cadre strict, pensé pour un environnement sensible.

L'IA propose un plan Validation par action Snapshot le filet Exécuteur déterministe Contrôle de santé sain → on garde KO → rollback auto
L'agent propose, l'humain approuve action par action, un instantané (snapshot) sert de filet, puis un exécuteur déterministe applique. Si le contrôle de santé échoue, la machine est restaurée automatiquement à son état d'avant.
Liste blanche
Seules des opérations idempotentes et non destructrices (appliquer un correctif, mettre à jour une image). Jamais de suppression.
Commande forcée
Le nœud d'exploitation ne peut lancer qu'un script précis sur chaque hôte, jamais un shell. Toute injection est rejetée.
Filet snapshot
Instantané ZFS avant l'action, rollback automatique si la machine ne revient pas saine. Les actions à risque tournent la nuit.
Moindre privilège
Un jeton dédié aux seuls droits de snapshot ; un jeton en lecture seule pour l'état. Chaque canal a le strict nécessaire.
Gouvernance & garde-fous

Ce qui rend le dispositif défendable

Au-delà des fonctionnalités, ce sont les principes qui comptent pour toute infrastructure critique.

  • Souveraineté totale. Modèles et traitements en local. Aucune donnée d'exploitation ni de sécurité n'est transmise à un tiers, cohérent avec les exigences des environnements réglementés et sensibles.
  • L'IA ne décide jamais seule d'agir. Elle éclaire et propose ; l'humain valide ; le code exécute. La responsabilité reste humaine et traçable.
  • Priorité au réel. On alerte sur la pression et l'exploitabilité réelles, pas sur des compteurs bruts. Moins de bruit, plus de confiance.
  • Réversibilité. Toute action sensible est adossée à un instantané et à un rollback automatique.
  • Transparence de l'IA. Les passages produits par le modèle sont badgés dans le rapport : on sait toujours ce qui est brut et ce qui est généré.
  • Journalisation. Qui a lancé quoi, quand, avec quel résultat, des deux côtés du canal.
La cible

Ce que cela démontre

Ce dispositif de référence montre qu'il est possible, avec des briques ouvertes et une IA entièrement locale, d'obtenir un MCO/MCS unifié, priorisé et en partie auto-remédiant, sans jamais sacrifier ni la souveraineté des données, ni le contrôle humain.

Concrètement, chaque matin : un seul rapport dit ce qui va, ce qui presse, et ce qu'il faut faire. Chaque nuit : les correctifs sûrs peuvent s'appliquer, avec filet. Et tout cela tient sur une empreinte matérielle modeste. C'est une cible adaptable à toute plateforme qui doit conjuguer haute disponibilité et sécurité.

1
rapport / jour

Infra + sécurité, unifiés.

2
rôles pour l'IA

Rédiger (normal) · raisonner (agentique).

0
donnée sortante

Souverain de bout en bout.

Genèse

Une méthode, et une prochaine frontière

La cible prioritaire est nette : le maintien en condition opérationnelle et le maintien en condition de sécurité d'une plateforme IT. Face au volume de notifications que déversent les SOC (centres opérationnels de sécurité), faire gagner en productivité les équipes IT n'est plus une option, c'est un impératif.

Ce dispositif n'est pas la sortie d'un outil. Il est né d'une collaboration exigeante entre un professionnel de l'IT et un assistant IA avancé, Claude (Anthropic), sollicité sans détour pour proposer, coder, rédiger et explorer vite.

L'aide de l'IA a été réelle et précieuse, et il serait malhonnête de la masquer. Mais le cap, les arbitrages, la traque méthodique des incohérences et la conduite de la réflexion jusqu'à son terme sont restés humains. Ce sont l'exigence, les compétences et l'obstination à pousser chaque idée à bout qui ont transformé une ébauche en cette cible. Sans cette direction, on se serait arrêté bien avant. C'est, au fond, le principe même du dispositif : l'IA éclaire et propose, l'humain décide et en répond.

Reste une frontière à franchir pour être pleinement fidèle à la souveraineté visée. L'assistant qui a aidé à concevoir tout ceci est, lui, hébergé dans le cloud. La suite logique consiste à confier ce même rôle à un modèle open-weight souverain, assez capable pour rendre ce service mais hébergé entièrement en local. Alors, plus une seule ligne, même à la conception, ne quitterait la plateforme.