We build Agents. You build the Future. Nous construisons les agents. Vous construisez l’avenir.
● Offre B2B — Vulnérabilités & correctifsVulnérabilités et correctifs : quel avis touche quelle machine, dans quel ordre, et sur quelle preuve
Un avis de sécurité paraît sur un produit ; il ne dit rien de vous tant que votre inventaire n'a pas parlé. Votre agent travaille sur les inventaires, les nomenclatures logicielles et les rapports de scanner que vous lui ouvrez : il cherche où ce produit est installé, dans quelle version, exposé comment et sous quelle responsabilité, explique l'ordre de traitement facteur par facteur, puis prépare le ticket, les tests, la fenêtre et le retour arrière. Données hébergées en France ; le modèle d'IA est appelé chez son éditeur, sauf option Modèle souverain. En formule 100 % Souverain, la carte de vos versions et de vos points faibles ne sort pas de l'entreprise. Déployer un correctif reste une décision humaine, prise par le propriétaire de l'actif et tracée.
Mis à jour le
Simulation fictive — pas un résultat client
Chaque affectation porte un niveau de confiance et les preuves qui la fondent ; l'ordre de traitement se recompose facteur par facteur, avec la règle de politique qui l'a éventuellement relevé.
Un actif dont la version est inconnue est marqué en investigation, jamais corrigé.
🔗 Sourcé · inventaires, nomenclatures et rapports déposés, avec leur date et leur âge
Un correctif appliqué sans retour arrière transforme une capacité de production en pari : la décision appartient au propriétaire de l'actif, l'exécution à votre exploitation, et l'effet n'est déclaré obtenu qu'après relecture de l'inventaire suivant.
✎ Cadre · changement préparé, décision et déploiement humains
Pour une organisation établie hors de l'Union européenne, c'est le droit de son pays qui s'applique ; sur sa demande, nous mettons en place des garanties équivalentes (revue humaine avant toute action, journal des critères, information des personnes).
Un agent Blue Lemon Agent de gestion des vulnérabilités et des correctifs, qui travaille sur les inventaires, nomenclatures logicielles et rapports que vous déposez : il rapproche chaque avis publié des actifs qui portent le produit, affiche sa confiance et ses preuves, explique l'ordre de traitement facteur par facteur, prépare le ticket, les tests, la fenêtre et le retour arrière, puis rassemble le dossier de preuve. L'orchestration de déploiement fonctionne en simulation par défaut : toute écriture réelle exige un actif et une version confirmés, un correctif d'origine autorisée, les tests exigés, un retour arrière disponible et une approbation humaine enregistrée. Données hébergées en France ; le modèle d'IA est appelé chez son éditeur, sauf option Modèle souverain. En formule 100 % Souverain, la carte de vos versions reste chez vous, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité.
Repères décrivant notre offre, et non des résultats mesurés chez un client. L'ampleur du gain sur le nombre d'actifs, d'avis et de propriétaires se confirme par un pilote.
Estimation indicative, à confirmer par un pilote sur vos dossiers réels (conditions générales de vente, article 4).
Un socle, un seul agent
Un agent de gestion des vulnérabilités et des correctifs (inventaire, affectation, priorisation, plan, preuves), installé et exploité pour vous, avec quatre sources d'avis comprises : CERT-FR, la base européenne des vulnérabilités (EUVD) de l'ENISA, les identifiants du programme CVE et cinq flux d'éditeurs nommés au contrat. Toute autre source s'ajoute en option, chiffrée sur devis.
Installation + abonnement maîtrisé
- Installation, paramétrage et formation de vos équipes
- Exploitation, supervision humaine, mises à jour et support
- Hébergement en France, ressource dédiée et isolée
Tout inclus, sans frais d'installation
- Mise en service incluse (installation, paramétrage, formation)
- Exploitation, supervision humaine, mises à jour et support
- Hébergement en France, géré de bout en bout
Sur site, vous êtes propriétaire
- Matériel installé dans vos locaux (vous en êtes propriétaire)
- Modèles IA français / européens exécutés en local
- Maintenance à distance sécurisée (Suivi Pro inclus)
Que fait l'agent concrètement ?
Douze modules compris au socle, de l'inventaire réconcilié jusqu'au dossier de preuve, avec des renvois vers des agents voisins. L'agent réalise lui-même ce que vous l'autorisez à faire ; toute écriture réelle exige une approbation humaine enregistrée.
Inventaire cyber réconcilié
Réunit vos sources d'inventaire — parc, base de configuration, comptes en nuage, registres d'images, manifestes de dépendances — en un tableau d'actifs, de composants, de versions et de propriétaires, chacun avec sa source et son âge.
Collecte et normalisation des avis
Reprend les avis de CERT-FR, les entrées de la base européenne des vulnérabilités (EUVD) et les bulletins des éditeurs nommés au contrat, ainsi que les rapports que vous lui ouvrez ; les normalise en un format unique et conserve pour chaque valeur sa source et sa date de publication.
Affectation vulnérabilité–actif
Rapproche chaque avis des actifs qui portent le produit visé, avec la version observée, la plage affectée, un niveau de confiance obligatoire et les preuves retenues.
Priorisation contextuelle explicable
Compose l'ordre de traitement par un moteur déterministe versionné : chaque score se refait à l'écran facteur par facteur, et chaque règle de politique affiche son identifiant.
Plan de remédiation
Écrit pour chaque dossier l'action, le propriétaire, l'échéance issue de votre politique, les tests exigés et le retour arrière — et signale le dossier auquel il manque l'un des quatre.
Tickets, changements et escalades
Prépare le ticket et la demande de changement dans la forme que vous produisez déjà, sans doublon quand le dossier est rejoué, et rédige l'escalade quand une échéance approche.
Contrôle du correctif avant pose
Vérifie l'origine autorisée du correctif, ses prérequis, les tests à passer et le groupe pilote sur lequel il s'éprouve avant d'être proposé au parc entier.
Orchestration sous garde
Montre en simulation ce qui serait déclenché, dossier par dossier. Une écriture réelle exige actif et version confirmés, correctif autorisé, tests réussis, fenêtre conforme, retour arrière disponible et approbation enregistrée.
Vérification après correction
Relit l'inventaire suivant pour confirmer l'effet obtenu, distingue la correction complète de la correction partielle et nomme les actifs restés ouverts avec leur motif.
Exceptions datées et mesures compensatoires
Rédige l'exception avec son périmètre, ses mesures compensatoires, son responsable, son approbateur, sa date d'expiration et ses conditions de révocation — et rouvre le dossier à l'échéance.
Nomenclatures logicielles et déclarations d'exploitabilité
Exploite les nomenclatures (SBOM) et déclarations d'exploitabilité (VEX) que vous ou vos fournisseurs produisez, rattache chaque composant à la version livrée et prépare le dossier de sécurité produit.
Preuves et pilotage
Journalise source, décision, dossier, exception, action, accusé et délai, et affiche en tête sa propre couverture d'inventaire — le dossier que réclame un contrôle interne ou un commissaire aux comptes.
IA souveraine
Le socle d'hébergement et de confidentialité sur lequel repose l'agent.
Besoin d'aller plus loin ?
Ces agents traitent un autre processus métier, avec leur propre responsable et leur propre tarif. Ils s'ajoutent à celui-ci.
Cybersécurité & journaux
Corréler les événements d'un incident et qualifier une alerte part d'un fait observé dans vos journaux ; le cycle de la vulnérabilité part d'un avis publié à l'extérieur.
Cybersécurité & journaux dès 311 € HT / mois Découvrir l'agent →Support technique avancé
Résoudre une demande signalée par un utilisateur relève du support ; ici, les dossiers existent qu'on les signale ou non, avec des échéances qui courent sans que personne n'appelle.
Support technique avancé dès 291 € HT / mois Découvrir l'agent →Génération & revue de code
Écrire le correctif d'une dépendance se fait dans le dépôt ; savoir sur combien d'actifs cette dépendance est déployée, et exposés comment, se fait ici.
Génération & revue de code dès 324 € HT / mois Découvrir l'agent →Contrôle réglementaire
Démontrer qu'une obligation est respectée et en tenir le dossier relève du contrôle de conformité ; ici la matière est technique — un actif, une version, un correctif — et le relevé de vérification produit alimente ce dossier sans le remplacer.
Contrôle réglementaire dès 371 € HT / mois Découvrir l'agent →Support technique & documentation
Écrire et tenir à jour la documentation d'exploitation revient à cet agent ; ici la documentation est un intrant — fiches du constructeur, notes de version — et la sortie est un dossier de changement daté, prêt à signer.
Support technique & documentation dès 344 € HT / mois Découvrir l'agent →Tests & qualité logicielle
Concevoir et exécuter les campagnes de tests d'une application revient à cet agent ; ici les tests de non-régression sont une CONDITION de la fenêtre de pose, exigés au dossier et vérifiés avant que le changement parte.
Tests & qualité logicielle dès 272 € HT / mois Découvrir l'agent →En 30 minutes, nous identifions l'agent le plus pertinent — sans surdimensionner le projet.
Voyez l'agent au travail
5 situations courantes, prises parmi celles qui reviennent le plus. Choisissez-en une : l'échange se déroule comme il se déroulerait chez vous.
Démonstration écrite à l'avance. Ces échanges illustrent le comportement de l'agent — ses sources, ses refus, ce qu'il laisse à vos équipes. Rien n'est envoyé depuis cette page, aucun modèle n'y est interrogé, et les dossiers cités sont fictifs. C'est précisément ce que nous promettons à vos données. Les comportements montrés ici — surveillance, règles d'automatisation, routage et relances — sont paramétrés avec vous lors du déploiement, à partir de vos outils, de vos règles et de vos seuils. Les points d'architecture cités dans ces échanges — localisation, exécution locale, isolation, chiffrement, accès par rôle, journalisation — ne sont pas une garantie attachée à la démonstration : ils sont ceux de l'architecture décrite à votre devis, et vérifiés avant mise en service.
L'entreprise de cette démonstration
Entreprise fictiveVergaray Participations — société holding animatrice, six filiales détenues
- Secteur
- Société holding animatrice, NAF 64.2 — six filiales détenues : une industrielle, deux de services, trois de distribution
- Effectif
- 31 personnes au siège, dont 2 à l'informatique. Aucun RSSI, aucun analyste sécurité. 1 240 salariés dans les six filiales
- Public servi
- Les six directions de filiale, un conseil de surveillance, deux commissaires aux comptes
- Ordre de grandeur
- Environ 900 postes et 140 serveurs répartis sur les six filiales ; consolidation financière trimestrielle ; trésorerie centralisée au siège
- Outils en place
- Trois bases de configuration sur six tenues à jour, un scanner hebdomadaire chez deux filiales, l'outil de tickets du siège, la GED de contrôle interne — l'agent lit ce que le groupe lui ouvre, rien n'est remplacé
- La filiale industrielle
- Les Fournils de Vaubourg — un site, deux lignes de production en trois-huit, 3 personnes à l'informatique et 2 automaticiens ; propriétaire du serveur de reporting réglementaire hérité
- La contrainte de l'atelier
- Une seule nuit d'arrêt de ligne planifiée par mois — c'est elle qui commande l'ordre de traitement du périmètre industriel, et non la note d'un éditeur
- Qui décide
- Le directeur administratif et financier arbitre les priorités et toute acceptation de risque ; le responsable informatique du siège instruit ; chaque directeur de filiale reste propriétaire de ses actifs et autorise seul ses changements
- Les points d'amélioration
- Aucun tableau unique des versions des six filiales ; la version de la passerelle d'identité mutualisée n'est connue de personne au siège ; le serveur de reporting réglementaire est hors support de l'éditeur
Vergaray Participations pilote six filiales qui ne partagent ni le même outil d'inventaire, ni le même rythme de correction, ni le même responsable. Le siège reçoit les avis éditeurs comme tout le monde et n'a aucun moyen de dire, en moins d'une semaine, laquelle de ses filiales est concernée. L'agent lit les trois bases de configuration tenues à jour, les rapports du scanner hebdomadaire de deux filiales, l'outil de tickets du siège et le registre des prestataires du groupe. Il rapproche, chiffre, explique, et prépare — le directeur administratif et financier arbitre, et chaque directeur de filiale autorise ce qui touche ses machines. Les échanges qui suivent couvrent une semaine, de la réception des avis au dossier de preuve. Le cinquième onglet ouvre le périmètre INDUSTRIEL de la filiale qui possède déjà le serveur de reporting réglementaire : quatre actifs d'atelier, une nuit d'arrêt par mois, et l'impact sur la sécurité des personnes comme facteur de priorité.
Cette entreprise, ses chiffres et les échanges qui suivent ont été inventés pour la démonstration. Ils illustrent une situation courante ; ils ne décrivent aucun client réel.
Simulation fictive — pas un résultat client
Cette démonstration porte sur des données entièrement fictives. Aucun système n'est scanné ni modifié.
Le socle d'IA souveraine retenu au devis — inférence locale ou ressource isolée hébergée en France — porte cet agent : vos exports et vos avis restent dans cet espace.
Le périmètre chargé :
· 4 actifs de groupe : le portail de consolidation, le hub de trésorerie centralisée, la passerelle d'identité mutualisée des six filiales, le serveur de reporting réglementaire hérité.
· 4 avis fictifs, préfixés DEMO-CVE pour qu'aucun ne puisse être confondu avec une vulnérabilité réelle.
· 5 sources simulées : les bases de configuration des filiales, les rapports du scanner hebdomadaire de deux d'entre elles, l'outil de tickets du siège, le registre des prestataires du groupe, la GED de contrôle interne.
· Collecte et normalisation des avis, déjà faites : les 4 avis arrivent en quatre présentations différentes et repartent en une seule — un produit, une plage de versions affectées, une source, une date de publication. C'est cette normalisation qui rend le rapprochement possible ligne à ligne.
· Politique de démonstration demo-policy-1.0, avec ses quatre seuils et ses six règles de priorité — c'est la vôtre qui s'appliquerait, pas la mienne.
Et les deux trous, nommés :
· La version de la passerelle d'identité mutualisée est inconnue — elle est exploitée par un prestataire sous contrat cadre, et aucune de vos bases ne la porte.
· Le serveur de reporting réglementaire n'a pas de propriétaire au siège : il appartient à la filiale industrielle, qui autorise seule ses changements.
Une valeur inconnue reste inconnue dans tout ce qui suit. Elle n'est ni saine, ni corrigée, et vous verrez qu'elle empêche une clôture plutôt que d'en fabriquer une. depot-sources_groupe-vergaray.pdfPIÈCE D'ENTRÉE · 5 exports déposés, 4 avis reçus, 0 écriture
⛓ Sourcé · 5 exports déposés le 07/09, âges affichés, seuil du groupe 72 h
Voici d'abord l'inventaire cyber réconcilié du groupe : vos cinq exports repartent en un tableau unique — actif, composant, version, propriétaire, source et âge de la donnée. C'est ce tableau réconcilié qui porte tout ce qui suit.
La couverture d'inventaire est la mesure qui commande toutes les autres : un actif absent d'un inventaire est invisible pour moi, et c'est précisément l'actif oublié qui pose problème. La pièce jointe vous donne la couverture filiale par filiale, avec ce qui manque à chacune.
Ce que je vous propose, et le calcul : les quatre actifs de groupe que le siège exploite lui-même sont couverts à 100 %, parce que vous en tenez l'inventaire. Les trois filiales sans base à jour représentent, dans ce scénario fictif, environ 380 postes et 46 serveurs sur lesquels je ne peux rien affirmer. Plutôt que d'ouvrir six chantiers d'inventaire en même temps, je propose de commencer par la filiale industrielle : c'est elle qui héberge le serveur de reporting réglementaire hors support, donc celle où l'ignorance coûte le plus cher aujourd'hui.
La décision vous revient, et elle se prend sur un chiffre : trois chantiers d'inventaire ou un seul, sur l'actif dont vous savez déjà qu'il est en fin de support. couverture-inventaire_six-filiales.pdf3 entités sur 6, 2 données manquantes nommées
⛓ Sourcé · couverture d'inventaire donnée avant tout score
Simulation fictive — pas un résultat client
· DEMO-CVE-F01 → portail de consolidation, version observée 6.1.0, la plage affectée est < 6.1.1. Affectation confirmée, confiance 0,99. Preuves : la version relevée dans votre base de configuration, et le rapport du scanner hebdomadaire de la même semaine.
· DEMO-CVE-F02 → hub de trésorerie centralisée, version 4.7.3, plage < 4.7.4. Affectation confirmée, confiance 0,98.
· DEMO-CVE-F04 → serveur de reporting réglementaire, version 12.0, plage 12.x. Affectation confirmée, confiance 0,94, et l'actif est en fin de support éditeur — aucun correctif n'est publié pour lui.
· DEMO-CVE-F03 → passerelle d'identité mutualisée : en investigation, confiance 0,35. La version est inconnue. L'avis est sévère et déclaré activement exploité dans le scénario ; c'est exactement la raison pour laquelle je refuse de l'afficher comme confirmé sur une correspondance de nom de produit.
Une correspondance floue n'est jamais présentée comme une affectation confirmée. affectation_quatre-dossiers.pdf3 affectations confirmées, 1 en investigation
⛓ Sourcé · versions relevées en base de configuration et au rapport de scanner
Il est classé « revue obligatoire » par la règle PR-APP-UNK-001, qui s'évalue avant toute autre : un dossier en investigation n'obtient aucun score numérique. L'absence de score est une information, pas un zéro — un zéro l'aurait fait descendre en bas de votre liste.
Ce que j'ai déjà préparé, et qui est joint : une demande de preuve au prestataire, rédigée, adressée au bon interlocuteur du contrat cadre, qui demande trois choses et rien d'autre — la version exploitée, la date de son dernier déploiement, et l'état de la vulnérabilité DEMO-CVE-F03 sur cette version, sous la forme d'une déclaration d'exploitabilité datée et signée. Les nomenclatures logicielles (SBOM) et les déclarations d'exploitabilité (VEX) que vos fournisseurs produisent entrent par la même porte : je rattache chaque composant à la version livrée, et le dossier de sécurité produit se remplit au fil des réponses. Le registre des prestataires du groupe me donne l'interlocuteur ; la lettre est prête, elle part quand vous la validez.
Et j'ai posé la conséquence : tant que cette preuve n'est pas au dossier, la clôture est bloquée. Pas différée sur un rappel qu'on oublie — bloquée, avec la date à laquelle elle manque.
Ce que cela change chez vous : une holding ne scanne pas la machine d'un prestataire, elle lui oppose un contrat. Je transforme une question technique que vous ne pouvez pas poser en une demande contractuelle que vous pouvez poser, et j'en suis l'échéance. demande-de-preuve_prestataire-identite.pdf3 questions, 1 échéance, clôture bloquée
✎ Cadre · demande contractuelle rédigée, clôture bloquée tant que la preuve manque
Simulation fictive — pas un résultat client
C'est une priorisation contextuelle, et elle est explicable ligne à ligne : l'ordre vient de VOTRE contexte — exposition, criticité, impact métier, exploitation connue — et chaque score affiche les facteurs qui l'ont produit.
· Portail de consolidation — DEMO-CVE-F01 — score 98 sur 100, revue immédiate. Origine de la priorité : la règle PR-KEV-001 et le seuil, tous deux. La règle seule aurait suffi : une vulnérabilité déclarée activement exploitée sur un actif exposé et critique remonte en revue immédiate même s'il manque une autre métrique.
· Serveur de reporting réglementaire — DEMO-CVE-F04 — score 51, planifié. Origine : la règle PR-EOL-001 et le seuil. L'actif est en fin de support, ce qui ajoute 10 points et déclenche un plancher de priorité.
· Hub de trésorerie — DEMO-CVE-F02 — score 54, planifié. Origine : le seuil seul.
· Passerelle d'identité mutualisée — DEMO-CVE-F03 — pas de score, revue obligatoire.
Deux points qui comptent chez vous : le hub de trésorerie obtient 54 alors que sa sévérité technique est de 7,6 — parce qu'il est peu exposé (0,4), et c'est le contexte de votre groupe, pas la note de l'éditeur, qui produit ce classement. Et une règle de politique peut RELEVER une priorité, jamais l'abaisser en silence : elle affiche son identifiant, ici PR-EOL-001, et son explication. calcul-priorite_portail-consolidation.pdfScore 98 recomposé facteur par facteur
⚙ Calculé · politique demo-policy-1.0, chaque score recomposable à l'écran
Le calcul, d'abord, à l'unité près : le portail de consolidation obtient 98 parce qu'il cumule quatre choses que le hub de trésorerie n'a pas — une exploitation connue (25 points), une exposition maximale (15 points), une probabilité d'exploitation de 0,91 (9,1 points) et un correctif disponible et fiable (5 points). Le hub de trésorerie, lui, est derrière votre segmentation : exposition 0,4, soit 6 points au lieu de 15, et aucune exploitation connue, soit 0 point au lieu de 25. L'écart de 44 points vient de là, et de nulle part ailleurs.
Ce que je propose, chiffré : si votre direction financière estime que la trésorerie centralisée doit remonter quoi qu'il arrive, cela s'écrit comme une règle de politique, pas comme un ajustement de score. Par exemple : tout actif du service « Trésorerie centralisée » a une priorité plancher « traitement accéléré ». La règle porterait un identifiant, une explication, une version, et elle serait testée comme les six autres.
Je déconseille en revanche de monter le poids de l'impact métier : il est déjà à 10 sur le hub, soit son maximum, et l'augmenter remonterait aussi les trois filiales de distribution — vous obtiendriez huit revues immédiates au lieu d'une, ce qui revient à n'en avoir aucune.
Le poids et le seuil s'administrent, se versionnent et se testent. Aucune conversation avec moi ne les change, et c'est ce qui rend votre classement défendable devant votre conseil de surveillance.
✎ Cadre · poids et seuils administrés, versionnés et testés — jamais par la conversation
Simulation fictive — pas un résultat client
Comment je connais ses versions, puisque je ne scanne rien : par les inventaires que la filiale m'ouvre — gestion de maintenance, relevés d'intervention, fiches du constructeur — et par ce que l'historisation de site déclare. Aucun scan actif n'est lancé sur une ligne en production, et ce n'est pas un réglage : un scan sur un automate en marche peut perturber le procédé.
Les quatre actifs : passerelle de télémaintenance, poste d'ingénierie de la ligne 2, automate de conditionnement n° 7, historisation de site.
Et le facteur que vos cinq autres filiales n'ont pas : l'impact sur la sécurité des personnes entre dans le calcul de priorité, avec son propre poids. L'automate de conditionnement porte la valeur maximale, parce qu'un défaut sur lui touche un opérateur, pas un tableur.
Trois des quatre dossiers ont donc une priorité PLUS ÉLEVÉE que leur score ne le donnerait, et chaque règle affiche son identifiant :
· Passerelle de télémaintenance — 100 — revue immédiate (PR-KEV-001 et seuil).
· Poste d'ingénierie ligne 2 — 60 — traitement accéléré par PR-OT-HIGH-001 : impact sécurité 0,8 et retour arrière pas encore prêt.
· Automate de conditionnement n° 7 — 56 — traitement accéléré par la même règle : impact sécurité 1,0 et aucun correctif publié.
· Historisation de site — 49 — planifié par PR-OT-SAFE-001.
Le principe tient en une phrase : une règle de politique relève une priorité, elle ne l'abaisse jamais en silence et elle ne touche pas au score. 49 reste 49, et la priorité affichée porte le nom de la règle qui l'a relevée — vous voyez le risque calculé ET la décision de sûreté, sans que l'un maquille l'autre. regles-de-surete_quatre-dossiers-industriels.pdf3 priorités relevées, aucune abaissée
⚙ Calculé · impact sur la sécurité des personnes pris comme facteur, règles nommées
Ce qui produit son score de 100 : une vulnérabilité déclarée activement exploitée (25 points), une exposition de 0,9 parce que la passerelle est joignable depuis l'extérieur (13,5 points), une criticité maximale (15 points) et un impact sur la sécurité des personnes de 0,7 (7 points). Le calcul brut donnait 103,8, borné à 100 — une borne est une borne, pas un arrondi commode.
Ce que j'ai préparé, et c'est l'ordre qui compte : l'isolement d'abord, le correctif ensuite. Restreindre l'accès à une plage horaire convenue avec le constructeur et à ses adresses déclarées ne demande aucun arrêt de ligne. Le correctif, lui, entre dans la nuit d'arrêt, avec ses tests et son retour arrière disponible.
Vous gagnez la réduction d'exposition tout de suite, sans dépenser votre nuit, et le contrat de maintenance reste servi sur un créneau écrit et révocable.
Deux choses que l'isolement ne fait pas, et je préfère qu'elles soient dites : il ne clôt pas le dossier, et il ne fait pas baisser le score — seule une mesure compensatoire VÉRIFIÉE, attestation datée à l'appui, retranche des points. Et je ne modifie aucune règle d'accès de ma propre initiative : je rédige la demande de créneau, votre responsable de production la signe. plan-isolement_passerelle-telemaintenance.pdfExposition réduite, 0 minute d'arrêt de ligne
✎ Cadre · isolement préparé, aucune règle d'accès modifiée par l'agent
Ce que j'ai préparé, et qui attend deux signatures : trois mesures compensatoires — restriction du chemin d'administration, surveillance ciblée des accès à l'automate, retrait de l'automate du segment joignable depuis les postes bureautiques — chacune avec ce qu'elle réduit et ce qu'elle ne réduit pas.
Les deux signatures ne sont pas interchangeables : le responsable qualité et sécurité, parce que la mesure touche un équipement dont un défaut atteint un opérateur, et le responsable de production, parce que sa mise en œuvre modifie l'exploitation de la ligne. La double validation sur les actifs à fort impact sécurité est configurable, et elle est activée ici.
Ce que j'écris du côté du constructeur : une demande de position écrite sur DEMO-CVE-O03, avec les trois mêmes éléments que pour tout tiers — version concernée, existence d'un correctif prévu, date. La demande est rédigée, non envoyée : elle part quand vous la validez.
Et voici ce qui entre dans la nuit d'arrêt, et ce qui n'y entre pas. Y entrent la passerelle en 3.4.1, tests écrits et retour arrière disponible. N'y entre pas le poste d'ingénierie, dont le correctif existe mais dont le retour arrière n'est pas prêt : l'orchestration reste sous garde — je montre en simulation le changement qui partirait, et la garde retient la soumission en affichant son motif et son action de déblocage. Un poste d'ingénierie sans retour arrière, sur une ligne qui tourne en trois-huit, ferait de la ligne le pari — et ce blocage est votre propre règle, appliquée sans exception silencieuse. L'historisation, elle, sort de la nuit : elle n'interrompt pas la ligne, je vous rends ce temps-là. mitigation_automate-conditionnement-7.pdf3 mesures compensatoires, 2 signatures attendues
✎ Cadre · mesures compensatoires préparées, deux signatures attendues
Simulation fictive — pas un résultat client
· Portail de consolidation — changement d'urgence prêt. Action : montée en 6.1.1. Propriétaire : la direction financière du siège. Prérequis, tests de non-régression sur la consolidation trimestrielle, retour arrière disponible, fenêtre proposée, communication aux six filiales rédigée, preuve attendue nommée. Approbation : en attente.
· Hub de trésorerie — changement planifié sous fenêtre, même structure, retour arrière disponible.
· Serveur de reporting réglementaire — aucun correctif n'existe. J'ai donc préparé un dossier de mitigation et une exception datée, jointe : périmètre exact, motif, risque décrit, trois mesures compensatoires, responsable, approbateur, date de début, date d'expiration, date de réexamen, conditions de révocation. L'exception expire, elle ne se renouvelle pas seule — à l'échéance, le dossier se rouvre.
· Passerelle d'identité mutualisée — la demande de preuve est partie, la clôture reste bloquée.
Un point de votre gouvernance que j'applique : le serveur de reporting appartient à votre filiale industrielle. L'exception est donc adressée à son directeur, pas au siège — et votre DAF y figure comme approbateur du risque de groupe, pas comme propriétaire de la machine. exception-datee_reporting-reglementaire.pdfPérimètre, approbateur, date d'expiration, réexamen
✎ Cadre · changements rédigés, décision au propriétaire de l'actif
Dans la simulation de ce scénario :
· Portail de consolidation — correction vérifiée. Version 6.1.1 observée, contrôle simulé négatif, changement simulé réussi. Je propose la clôture ; c'est vous qui la prononcez.
· Hub de trésorerie — correction vérifiée sur le même modèle.
· Serveur de reporting réglementaire — exception en attente d'approbation. Aucune clôture, et c'est le bon résultat : une exception non approuvée n'est pas une exception.
· Passerelle d'identité mutualisée — preuve manquante. Le prestataire n'a pas répondu dans la simulation. État : preuve absente. Le dossier reste ouvert, l'échéance court, et l'escalade est préparée pour le responsable du contrat cadre.
Et du côté de la filiale industrielle, dans la même simulation : la passerelle de télémaintenance est isolée puis corrigée en 3.4.1 — correction vérifiée, clôture proposée ; l'automate n° 7 reste ouvert, mesures compensatoires en attente de deux signatures et réexamen daté. Le relevé les porte dans le même tableau, sous les mêmes règles.
Ce que vous obtenez au bout de la semaine, et c'est le vrai livrable : trois corrections démontrées sur deux périmètres, une exception qui porte une date de fin, deux dossiers qui attendent une preuve ou une signature nommée — et un tableau qui affiche sa propre couverture, ses données manquantes et ses affectations à faible confiance en haut, pas en note de bas de page.
Une correction partielle ne devient jamais un succès global, et une preuve absente ne devient jamais une clôture. C'est ce qui rend le relevé opposable le jour où votre commissaire aux comptes le demande. releve-de-verification_semaine.pdfPIÈCE DE SORTIE · 3 corrections vérifiées, 0 clôture forcée
⛓ Sourcé · effet confirmé sur l'inventaire suivant, jamais sur l'ordre envoyé
Votre cas n'est pas ici ? C'est exactement ce dont on parle en 30 minutes. Parler de votre projet →
Les étapes de votre projet d'agent IA
Audit & cadrage
30 min pour cibler le cas d'usage le plus rentable.
Devis ou souscription directe
Une offre du catalogue se souscrit en ligne ; un besoin particulier reçoit un devis chiffré.
Conception
Nous concevons l'agent et ses garde-fous.
Intégration & tests
Nous raccordons vos outils à l'agent, lui-même hébergé en France.
Déploiement
Mise en service et formation de votre équipe.
Exploitation
Supervision continue et amélioration.
Qu'apporte un agent IA à votre gestion des correctifs ?
Un avis dont on voit l'actif touché, la version observée et le propriétaire se tranche en une minute ; un bulletin éditeur recoupé à la main occupe une semaine.
! L'enjeu
Le NIST décrit la gestion des correctifs comme une maintenance préventive à planifier, et non comme une réaction à l'événement (NIST, SP 800-40 Rev. 4, « Guide to Enterprise Patch Management Planning », publié en avril 2022). Le travail qui coince n'est pas la décision : c'est de savoir si le produit visé tourne quelque part chez vous, dans quelle version, exposé comment, et qui répond de la machine. Ce travail est systématique, et il se prépare.
✓ Notre réponse
Vos propriétaires d'actifs reçoivent des dossiers déjà instruits : l'avis, l'actif, la version observée avec sa source, le niveau de confiance, l'ordre de traitement recomposé facteur par facteur, et le changement rédigé avec ses tests et son retour arrière. Ils tranchent, et leur décision motivée est conservée avec sa date et son auteur. Une version inconnue reste inconnue : elle empêche la clôture au lieu de fabriquer une certitude. Données hébergées en France sur une ressource isolée ; le modèle d'IA est appelé chez son éditeur, sauf option Modèle souverain. En formule 100 % Souverain, la carte qui décrit vos versions, et donc vos points faibles, ne sort pas de l'entreprise.
Votre carte des versions : souveraineté & confidentialité
La liste de vos actifs non corrigés dit où sont vos points faibles. Sa confidentialité est un enjeu de sécurité en soi ; voici comment elle est tenue.
Inférence locale
En formule 100 % Souverain, l'agent tourne sur une machine de votre organisation : aucun inventaire, aucune nomenclature logicielle et aucun rapport de scanner ne sort du réseau.
Hébergement en France
Sinon, en formules Agilité et Sérénité, une ressource dédiée et isolée hébergée en France, sous droit français : données hébergées en France ; le modèle d'IA est appelé chez son éditeur, sauf option Modèle souverain.
Exposition extraterritoriale réduite
Pour votre carte des versions et vos actifs non corrigés, l'architecture vise à réduire l'exposition au Cloud Act et au FISA 702 ; la seule localisation en France ou dans l'Union européenne ne garantit pas l'immunité.
Cloisonnement des entités
Chaque filiale, entité ou site a son propre espace : un dossier de remédiation ne montre jamais les actifs d'une autre entité, et les rôles suivent ce cloisonnement.
Décisions conservées
Chaque décision garde son auteur, sa date, son motif et la version de politique appliquée ; chiffrement, accès par rôle (RBAC) et journalisation exploitable en contrôle. Les droits de lecture, d'écriture et d'approbation sont séparés.
AI Act : déploiement encadré
L'agent exécute ce que vous avez autorisé ; aucun correctif déployé, aucun risque accepté et aucun dossier clos automatiquement ; traçabilité et supervision humaine de bout en bout.
Ce qui dépend de l'architecture retenue Ces points ne sont pas des garanties générales : ils sont arrêtés déploiement par déploiement, au devis.
- La localisation applicable est celle de l'architecture décrite au devis et vérifiée avant mise en service.
- L'exécution locale n'est annoncée que pour la configuration explicitement décrite et recettée au devis.
- L'isolation applicable dépend du mode de déploiement décrit au devis ; aucune isolation dédiée n'est présumée.
- Les rôles et permissions sont configurés et recettés pour les identités et systèmes effectivement raccordés.
- Les événements journalisés, leur contenu, leur durée de conservation et leurs accès sont définis pour le déploiement retenu.
Combien d'avis une équipe peut-elle instruire ?
En prenant en charge le rapprochement, la recherche du propriétaire et la reconstitution des versions, on déplace l'effort vers la décision. L'ampleur du gain dépend de votre parc et reste à confirmer par un pilote.
Quatre garanties qui comptent pour votre parc
Ressources liées
Vos questions, nos réponses
L'agent remplace-t-il notre scanner de vulnérabilités ou notre gestion de parc ?
Peut-il déployer un correctif automatiquement ?
Comment se raccorde-t-il à nos outils ?
Quelles sources d'avis de sécurité sont couvertes ?
Que fait-il quand la version d'un actif est inconnue ?
Et quand aucun correctif n'existe ?
Fait-il des scans actifs, ou des tests d'intrusion ?
Cette page prouve-t-elle notre conformité à un texte ?
D'autres agents pour l'informatique
Estimons le potentiel sur votre prochain lot d'avis
30 minutes pour cadrer vos sources d'inventaire, vos environnements et vos propriétaires — hébergé en France, supervisé, sans engagement.