Cybersécurité & Audit

Le prestataire affirme que c'est sécurisé. Personne n'a de trace de ce qui a été testé, ni quand, ni par qui. Une assurance qui ne s'appuie sur aucune mesure n'est pas une assurance : c'est un espoir.

La sécurité ne se promet pas : elle se teste, se mesure et se corrige.

Exposition maîtrisée

Pourquoi un incident s'arrête au lieu de se répandre

Trois anneaux : les identités entrent, les services répondent, la donnée reste au centre. La scène allume d'abord tous les chemins concevables, puis ne garde que ceux qui ont une raison d'exister — c'est le moindre privilège, montré par soustraction. Une identité bascule, une onde part : le disjoncteur ouvre une brèche, l'onde s'arrête à l'anneau, un secteur s'éteint et le reste continue de servir. Sous la scène, la trace s'accumule, un événement par barre. Une forme et un mouvement — aucune donnée réelle, et aucun moyen d'attaque.

Cybersécurité & audit

Le rayon de souffle

Trois anneaux — identités, services, données — et des requêtes qui descendent vers le centre. La scène montre d'abord tous les chemins concevables, puis ne garde que ceux qui ont une raison d'exister. Une identité bascule, une onde part ; le disjoncteur ouvre une brèche et l'onde s'arrête à l'anneau. Un secteur s'éteint, le reste continue de répondre — et la trace s'accumule, un événement par barre.

Une direction à qui l'on a vendu de la sécurité en liste à puces, et qui voudrait voir ce que « moindre privilège » et « rayon de souffle » veulent dire une fois posés sur son propre système.

Regardez les chemins inutiles disparaître, puis l'onde s'arrêter net à l'anneau.

Three.js · WebGL · 3 anneaux instanciés · moindre privilège par soustraction · onde arrêtée au disjoncteur · trace immuable · récit en 5 chapitres · repli sans WebGL

Ce que nous surveillons, et ce que nous refusons de promettre

Le registre dirigeant est visible sans un clic ; le registre expert vit au volet, avec son garde-fou affiché — c'est ce qui distingue une démonstration honnête d'une plaquette.

DEV & TECHNOLOGIE · RUN

Rendre l’incident visible avant qu’il ne devienne une crise.

Identités, traces, budgets et alertes partagent le même contexte opérationnel.

Une plateforme crédible sait expliquer ce qu’elle a fait, pour qui et avec quelle limite.

SAIN · DÉGRADÉ · CIRCUIT OUVERT · INCIDENT

Méthode

Moindre privilège, journal d’audit immuable, traces distribuées et budgets de fiabilité.

RBAC / ABAC · séparation des rôles
Corrélation requête · utilisateur · tenant · version
SLO · budget d’erreur · taux de saturation
Circuit breaker · reprise · idempotency key
SBOM · dépendances · politique de correctifs
Runbook · escalade · post-mortem sans blâme

Quand nous qualifions un système de sécurisé, nous donnons le périmètre, la menace considérée, la date et les contrôles vérifiés.

Les quatre surfaces qu'un audit ouvre

La méthode dit comment on procède ; ceci dit ce qu'on ouvre. Quatre surfaces, et pour chacune le défaut qu'on y rencontre le plus souvent.

Ce qui est exposé

L'inventaire de ce qui répond depuis l'extérieur : services ouverts, environnements oubliés, interfaces de recette laissées joignables, dépendances publiées.

Le défaut le plus fréquent n'est pas une faille : c'est une machine que plus personne ne savait allumée.

Qui a le droit de quoi

Les identités, les rôles, les comptes de service et les secrets : qui accède, depuis où, avec quoi, et ce qui reste ouvert après un départ.

Les droits s'ajoutent et ne se retirent jamais — au bout de trois ans, tout le monde peut tout.

La chaîne qui livre

Du poste du développeur à la mise en production : provenance des bibliothèques, signature des artefacts, secrets dans les journaux de construction, droits des robots de déploiement.

On protège l'application et on laisse ouverte la porte qui la fabrique.

Ce qu'on verrait passer

La journalisation, sa conservation, ce qu'elle permet de reconstituer, et la procédure d'incident : détecter, contenir, reprendre, et savoir ce qui a été touché.

Un incident sans journal se raconte, il ne se prouve pas — et ce qui ne se prouve pas se rejoue.

Des contrôles qui rendent l'erreur impossible, racontés sans les noms

Un contrôle qui conserve la mesure d'hier et alerte sur l'écart, une frontière où rien de nominatif ne franchit le mur : ce que nous avons posé, ce que ça a produit, et ce qui était difficile. Noms retirés, volumes gardés.

RÉFÉRENCES · MISSIONS RÉELLES, NOMS CENSURÉS

01
Une équipe qui exploite sa propre plateforme et découvre ses incidents par ses utilisateurs plutôt que par ses écrans.
Quand · Posé en août 2026, exécuté chaque soir depuis.
Ce que nous avons fait
Nous avons remplacé la mesure qui s'écrase par une mesure qui se conserve : la valeur de la veille est datée et gardée, l'écart est calculé et inscrit dans le verdict lui-même, et une baisse déclenche une alerte qui pose la seule question qui tranche — est-ce de la donnée, ou un objet reconstructible ?
Ce que ça a produit
Un historique daté par source, un écart calculé à chaque exécution, et un contrôle quotidien qui rouvre la base pour lire la date de la donnée réellement présente — ni le journal du traitement, ni la date du fichier : la donnée.
Ce qui était difficile
Avant ce contrôle, une base a fondu de près de la moitié de son volume en une nuit. Les traitements ont tourné, tous les contrôles sont passés au vert, et c'est un humain qui l'a vu, en rapprochant à la main la carte de la veille et la mesure du soir. Une valeur seule ne peut pas être fausse ; deux valeurs, si.
02
Une structure qui doit ouvrir une partie de son analyse à l'extérieur sans que rien de nominatif ne franchisse le mur.
Quand · Septembre 2026, en service.
Ce que nous avons fait
Nous avons relié une interface publique à un service d'analyse interne : écoute fermée sur la boucle locale, débit borné par appelant, secret de machine lu côté serveur — jamais tapé sur une ligne de commande, où il resterait dans l'historique et dans la table des processus — et une purge du nominatif exécutée avant tout affichage.
Ce que ça a produit
Une épreuve du pont qui rejoue les quatre décisions (adresse acceptée, débit, mode servi, texte libre) et un banc qui injecte des noms fabriqués dans la chaîne pour vérifier qu'ils en ressortent purgés. Les deux tournent sans qu'aucun serveur soit allumé, donc ils tournent vraiment.
Ce qui était difficile
« Interne » se lisait dans un en-tête que tout client non-navigateur choisit librement : depuis le réseau local, un appel pouvait se déclarer interne et obtenir le mode complet. On ne vérifie pas mieux qui frappe à la porte — on ferme la porte qui donne sur la rue.

Aucun nom de client n'est publié, avec ou sans son accord. Nous ne publions pas de taux de réussite : il n'est pas mesuré, et un chiffre non mesuré n'est pas une référence.

Ce que nous faisons

Audit technique : configuration, dépendances, droits, exposition réelle.
Tests d'intrusion cadrés et autorisés, avec une restitution exploitable.
Revue de code et de chaîne de livraison.
Protection des données : cloisonnement, chiffrement, journalisation.
Plan de remédiation priorisé par risque exploitable, pas par confort.
Revue des dépendances et de la chaîne de livraison : une faille peut dormir des mois parce que personne n'a ouvert l'outil qui la révèle — et on ne corrige jamais en forçant des versions majeures, qui cassent en silence.
Recherche des trois dangers dans les extensions et les automatisations installées : téléchargement suivi d'exécution, destruction irréversible, exfiltration. Chaque signalement porte sa preuve ligne par ligne, et le contrôle compte ce qu'il a écarté.
Revue des secrets et des messages d'erreur : rien d'écrit en dur dans le code, rien de sensible dans les journaux, et une erreur qui n'apprend rien à celui qui la provoque.
Revue des droits ligne par ligne après les départs et les changements de poste — les droits s'empilent, ils ne se retirent jamais tout seuls.

Ce que nous livrons

Rapport d'audit hiérarchisé par criticité

Compte rendu de test d'intrusion

Plan de remédiation daté & priorisé

Inventaire des secrets, de leur emplacement et de leur date de rotation

Politique de droits & de journalisation

Journal des signalements écartés, avec leur motif

Procédure d'incident & de restauration

Contre-audit après correction

La méthode

Délimiter

Un périmètre écrit et autorisé : rien ne se teste hors cadre.

Éprouver

On cherche l'entrée réelle, pas la liste théorique des vulnérabilités.

Prioriser

Ce qui est exploitable d'abord ; le reste est daté, pas oublié. Et un contrôle mal calibré est pire qu'aucun contrôle : trois alertes par nuit dont une vraie, et plus personne pour la lire.

Contrôler

On repasse après correction — un rapport sans contre-audit ne prouve rien. Retirer un dossier n'est pas désinstaller : tant que la déclaration existe, l'outil se réinstalle.

CE QUE VOUS AUREZ EN MAIN · Le chemin d’attaque qui se ferme

Appliquez une correction : le maillon coupé, les chemins encore ouverts et la preuve de retest apparaissent.

Tous les chemins mènent au même point de clôture.

Nous transformons une liste de constats en chemins compréhensibles : actif, exposition, technique, impact, contrôle et preuve. La priorité vient de ce qui est réellement exploitable dans le périmètre autorisé, pas de la seule gravité théorique d’un catalogue.

Le dirigeant voit le chemin à fermer, l’action, le propriétaire et le test qui établira la fermeture. Après correction, le statut ne passe pas au vert par déclaration : il attend la preuve du retest.

Ouvrir le chemin

Actif → exposition → technique → contrôle → retest

Règles d’engagement, autorisation écrite, périmètre, horaires, données de test, limites, arrêt d’urgence et chaîne de contact.

Inventaire d’actifs, identités, secrets, dépendances, exposition Internet et propriétaires.

Modèle de menace : actifs critiques, frontières de confiance, scénarios d’abus, ATT&CK v19.1, contrôles et hypothèses.

OWASP ASVS 5.0 et WSTG versionné pour dériver exigences et cas de vérification applicative.

CVSS v4.0 Base, Threat, Environmental et Supplemental, sans réduire la priorité au seul score de base.

CISA KEV, exploitabilité observée, reachability, impact métier, blast radius et SSVC pour prioriser la réponse.

RBAC/ABAC, séparation des tâches, PAM, JIT/JEA, MFA résistante au phishing et revue des comptes de service.

Gestion de secrets et de clés : coffre, rotation, portée, chiffrement au repos/en transit et journal d’usage.

SAST, DAST, SCA, IaC/container scanning, SBOM, VEX, signature et provenance dans la chaîne de livraison.

Télémétrie de sécurité : logs structurés, horodatage, corrélation, détection, couverture ATT&CK et rétention.

Réponse à incident alignée CSF 2.0 / SP 800-61r3 : préparation, détection, analyse, confinement, éradication, reprise et apprentissage intégrés au risque.

Plan de remédiation avec propriétaire, échéance, dépendance, contrôle compensatoire, exception acceptée, preuve et contre-audit.

D'où ça vient

CISA · Known Exploited Vulnerabilities (cisa.gov)Catalogue public des vulnérabilités exploitéesconsulté le 2026-08-01établi
MITRE ATT&CK (attack.mitre.org)Techniques et tactiques publiquesconsulté le 2026-08-01établi

Le chemin d’attaque priorise la correction dans le périmètre autorisé ; il ne remplace ni la décision de la gouvernance sur l’exposition résiduelle, ni une revendication de qualification ou d’homologation, qui relèvent d’un périmètre et d’une preuve séparés. Aucun test ne prouve une absence absolue de vulnérabilité, et un actif, un contrôle ou un retest non fourni reste N.F., jamais un succès implicite.

LES QUESTIONS QUI FONT LE PRIX

Ce que nous vous demanderons avant de commencer.

Quatre questions que nous posons à chaque dossier de ce domaine. Chacune vient d'un incident payé — par nous, ou par un maître d'ouvrage avant nous.

Quand l'audit de dépendances a-t-il été lancé pour la dernière fois ?

Une faille peut dormir des mois parce que personne n'a ouvert l'outil qui la révèle. Nous auditons après toute installation et avant de déclarer un outil sûr — et nous ne corrigeons jamais en forçant des versions majeures, qui cassent en silence.

Si personne ne la pose — Dix-sept vulnérabilités, dont une exécution de code à distance, découvertes par hasard.

Qu'est-ce qui télécharge et exécute du code que personne n'a lu ?

Nous scannons chaque extension, chaque script, chaque automatisation pour trois dangers : téléchargement suivi d'exécution, destruction irréversible, exfiltration. Chaque signalement porte sa preuve ligne par ligne, et le contrôle compte ce qu'il a écarté.

Si personne ne la pose — Une capacité installée en cinq minutes qui réinstalle ce qu'on vient de supprimer.

Supprimer un dossier est-il désinstaller ?

Non. Tant que la déclaration existe, le gestionnaire réinstalle — en boucle. On retire la déclaration avant le dossier, et l'on contrôle chaque nuit la signature de la boucle.

Si personne ne la pose — Vingt-deux copies temporaires en quinze minutes, un disque plein en une heure quarante.

Un garde-fou qui accuse à tort est-il pire qu'aucun garde-fou ?

Oui : un contrôle qui crie au loup finit par n'être plus lu. Nous calibrons trois statuts — échec, réussi avec réserves, réussi — et nous comptons les faux positifs comme des défauts du contrôle lui-même.

Si personne ne la pose — Trois alertes par nuit, dont une vraie, et plus personne pour la lire.

SCÉNARIO DE CAPACITÉ — PAS UNE RÉFÉRENCE CLIENT

Quand on nous appelle

Une plateforme en production n'a jamais été auditée et ses droits se sont empilés au fil des départs. Nous relevons l'exposition réelle, testons les chemins d'accès dans un périmètre écrit, puis hiérarchisons les corrections par risque exploitable. Un contre-audit vérifie ce qui a été refermé.

Domaines croisés

Un dossier mobilise rarement un seul domaine.

Systèmes d'information & Cloud

Système opérable

Data & Intelligence artificielle

Décision outillée

Tous les domaines du pôle

Un projet Cybersécurité & Audit ?

Écrivez-nous. Nous répondons avec une lecture, pas une plaquette.

Nous écrire