Mac Souverain

La fausse mise à jour Zoom qui vide ton trousseau iCloud

Mac Souverain — Tue, 28 Jul 2026 09:15:00 GMT

Un contact que tu connais t'invite en visio sur Telegram, sauf que son compte est détourné. Pendant l'appel, une fausse mise à jour « Zoom SDK Update » surgit, tu cliques pour réparer ton micro, et **un stealer siphonne les clés de ton navigateur** depuis ton trousseau iCloud. BlueNoroff, Corée du Nord, zéro faille exploitée, 100% ingénierie sociale. C'est le troisième ClickFix sur macOS en six semaines.

Ce que tu dois faire

1. Une invite d'installation en pleine réunion, tu refuses. Aucune visio ne te livre de « SDK Update » en cours d'appel.

2. Un lien de réunion, même d'un contact réel, vérifie-le par un autre canal. Le compte Telegram d'en face est peut-être compromis.

3. Un pare-feu sortant, Little Snitch ou LuLu, voit partir l'exfil vers Telegram quand le stealer vide ton trousseau.

Ce qui se passe vraiment en pleine visio

BlueNoroff, la bannière nord-coréenne qui vise les professionnels de la crypto, n’exploite aucune faille. Zéro exploit, zéro CVE. Juste de l’ingénierie sociale, montée en chaîne industrielle. La recherche est signée JUMPSEC, le cluster « ClickFake Interview » est suivi par Sekoia, et The Hacker News a relayé le 24 juillet 2026.

Le déroulé. Un contact que tu as rencontré en personne t’écrit sur Telegram, sauf que son compte est détourné. Il t’envoie un lien Calendly à son nom, qui te redirige vers un domaine Zoom ou Teams typosquatté, us.zoom.06webin.us. Tu saisis ton nom, tu autorises la caméra, et le kit se met au travail dans ton dos. Il capte ton flux vidéo via mediasoup WebRTC et profile les extensions de portefeuille crypto installées dans ton navigateur. Puis un faux message, « ton micro ne marche pas », suivi d’une invite « Zoom SDK Update ». Tu cliques pour réparer ton micro, tu installes la charge.

Sur macOS, le reste se déroule sans toi. Un script shell télécharge un faux installeur Teams ou Zoom, un stealer en extrait les clés maîtresses de Chrome depuis le trousseau local de ta session macOS, là où Chrome range sa clé de chiffrement, celles qui déverrouillent tes extensions de portefeuille crypto, et exfiltre le tout via un canal Telegram baptisé « Aurora », avant de déposer d’autres charges. Côté Windows, la variante désactive Defender via un loader PowerShell et fouille les sessions Telegram dans Chrome, Edge, Brave et Firefox. Même acteur, deux chaînes.

Deux détails changent l’échelle. Les visios sont truquées par deepfake, des visages générés par IA plaqués sur du langage corporel réel, capté sur les victimes précédentes. Et le mécanisme s’auto-propage, chaque compte Telegram compromis devient l’expéditeur de confiance du suivant. Cinq versions du kit ont été repérées entre le 31 mai et le 14 juillet 2026, l’opérateur est relié au bot Telegram @alchemy_john_mac. Ce n’est pas un coup isolé, c’est une usine qui itère.

La technique porte un nom, ClickFix, et elle traîne déjà une série de victimes derrière elle.

À lire : ClickFix, le faux correctif qui te fait lancer le malware toi-même

Le troisième ClickFix sur macOS en six semaines

Fais le compte. CrashStealer en juillet, ClickLock avant lui, maintenant BlueNoroff. Trois fois en six semaines que le même schéma frappe macOS, un geste anodin qui déclenche l’installation. Le vecteur s’industrialise, et cette version vise directement ton trousseau, là où macOS range les clés de ton navigateur.

À lire : Un malware notarisé Apple passe Gatekeeper

Ce qui te protège ici, ce n’est ni l’antivirus ni la notarisation. C’est une règle de comportement, simple et absolue, ne jamais installer un binaire qu’on te propose en cours de réunion. Zoom ne te livre pas de « SDK Update » en plein appel. Teams non plus. Une mise à jour qui surgit pendant une visio n’est pas une mise à jour, c’est la charge.

Il y a un angle stack, à condition d’être honnête sur sa portée. Proton Meet est chiffré de bout en bout et tourne dans ton navigateur, sans client natif à installer. Le prétexte « installe cette mise à jour SDK » n’a donc nulle part où s’accrocher, il n’y a pas d’app à mettre à jour. Ça réduit la surface d’attaque, ça ne remplace pas la règle de comportement. Passer à Proton Meet ne te protège pas de ce phishing, l’ingénierie sociale ne dépend d’aucun outil.

À lire : Proton Meet, la visio chiffrée qui tourne dans le navigateur

Le point qui doit t’inquiéter, c’est l’expéditeur. Ce n’est pas un inconnu, c’est quelqu’un dont tu as serré la main. La confiance interpersonnelle est le vecteur, pas ta crédulité. Un compte Telegram authentique, un nom que tu reconnais, un lien de réunion, il n’en faut pas plus.

Ce que tu fais maintenant

1. Une invite d’installation qui apparaît pendant une réunion, tu refuses, sans exception. Zoom, Teams, aucune visio ne te demande d’installer un « SDK Update » ni de réparer ton micro par un téléchargement. Tu quittes l’appel, tu ne cliques rien.

2. Un lien de réunion, même envoyé par un contact réel, tu le vérifies par un autre canal avant de cliquer. Un appel voix, un message Signal, « c’est bien toi qui m’as envoyé ce Calendly ? ». Le compte Telegram d’en face est peut-être déjà détourné.

3. Regarde l’URL avant d’autoriser ta caméra. us.zoom.06webin.us n’est pas un domaine Zoom, c’est du typosquat. Le vrai Zoom, c’est zoom.us. Un sous-domaine à rallonge greffé sur un nom inconnu, tu fermes l’onglet.

4. Installe un pare-feu sortant et laisse-le parler. Little Snitch ou LuLu voient partir l’exfiltration vers Telegram, exactement le moment où le stealer vide ton trousseau. C’est ta dernière ligne quand tout le reste a été contourné.

À lire : Little Snitch vs LuLu, quel pare-feu sortant pour ton Mac

Sources

The Hacker News, qui a relayé la recherche le 24 juillet 2026
Recherche primaire JUMPSEC, analyse du kit de phishing BlueNoroff
Cluster « ClickFake Interview » suivi par Sekoia

Passwork, app mdp « Made in EU » dehors, certifiée FSB dedans

Mac Souverain — Mon, 27 Jul 2026 07:00:00 GMT

Introduction

Une société de logiciels basée à Barcelone. Un gestionnaire de mots de passe vendu à des administrations européennes. Sur le site, jusqu’à récemment, deux mentions rassurantes : « Made in EU 2017 » et « no affiliations with any US, Russian, or other non-European entities ».

Petit problème. Le logiciel est bien affilié à la Russie. Et le code source est certifié par le FSB, qui y a eu accès. Presque rien en somme.

Le 17 juillet 2026, un consortium mené par l’OCCRP et VSquare, avec une dizaine de rédactions dont Le Monde, NU.nl, De Groene Amsterdammer, Investico et De Tijd, publie une enquête. Le code de ce logiciel européen est développé en Russie, à Arkhangelsk, et les mises à jour transitent par une entité aux Émirats. Les deux mentions rassurantes ont disparu du site après les questions des journalistes.

Ce papier n’est pas seulement sur Passwork. Passwork n’est qu’un exemple qui prouve, une fois de plus, l’incompétence de Bruxelles. Retiens bien ça, « Made in EU » sur une page produit n’a aucune valeur juridique, et ne te protège de rien.

Personne, ni Bruxelles, ni un label, ne vérifie ça à ta place. Alors on va apprendre à le faire.

Le problème : un drapeau ne prouve rien

Tu choisis un logiciel pour protéger tes données. Tu vois « européen », tu vois un siège dans l’UE, tu te dis que la souveraineté est cochée. Tu viens de confondre deux choses qui n’ont rien à voir.

L’adresse d’immatriculation d’une société te dit où sont ses avocats et ses impôts. Elle ne te dit pas d’où vient le code qui tourne sur ta machine. Ce sont deux chaînes distinctes : la chaîne juridique, et la chaîne d’approvisionnement logicielle. La première est facile à afficher sur un site. La seconde est invisible, et c’est la seule qui compte.

Prends le cas documenté par l’enquête. Passwork Europe S.L. est bien immatriculée à Barcelone. Mais Passwork LLC, elle, est enregistrée à Arkhangelsk, en Russie, en novembre 2022. Même logo, base de code d’origine commune, et des manuels utilisateurs que l’enquête décrit comme « virtually indistinguishable aside from the language ». Sur les deux versions publiées début avril 2026, un chercheur relève un script d’installation d’environ 517 lignes qu’il qualifie de « basically identical ».

Deux produits présentés comme séparés. Un seul code, ou presque.

Le point n’est pas « une société russe, c’est mal ». Le point est plus gênant : rien sur la page produit ne te permettait de le savoir. Le label « Made in EU » a fait exactement le travail pour lequel il existe, te rassurer, sans rien prouver.

Le mécanisme : les trois questions que le label ne pose pas

La souveraineté d’un logiciel ne se lit pas sur un drapeau. Elle se lit sur trois questions concrètes, et aucune des trois n’apparaît dans une plaquette commerciale.

Qui pousse le binaire ?

Le code que tu utilises n’est pas celui qui est sur un dépôt public. C’est celui qui arrive sur ta machine à la prochaine mise à jour. La vraie question, c’est donc : quelle entité fabrique et livre cette mise à jour ?

Dans le cas Passwork, les cofondateurs Ilya Garakh, propriétaire des domaines, et Andrey Pyankov, manager, opèrent via Passwork FZ-LLC, enregistrée à Ras Al Khaimah, aux Émirats, en juillet 2022. C’est cette entité qui fournit les mises à jour à la branche européenne. Passwork parle d’un « limited product related knowledge-transfer support » dans une période de transition qui doit s’achever en août 2026.

Traduction : le binaire européen est, au moins jusqu’à cette date, alimenté depuis l’extérieur de l’Europe. Un chercheur cité par l’enquête résume la séparation UE/Russie comme « technically shallow ».

Qui signe le code, et avec quelle clé ?

Une mise à jour légitime est signée cryptographiquement. C’est ce qui garantit que le fichier que tu installes vient bien de l’éditeur et n’a pas été modifié en route. Sauf que la signature garantit l’origine, pas l’innocence. Si l’entité qui détient la clé de signature est aussi celle qui pourrait glisser quelque chose dans une mise à jour, la signature valide ne te protège de rien. Elle certifie juste que le colis vient bien de l’expéditeur, quel que soit son contenu.

C’est le canal de mise à jour, pas le stockage, qui concentre le risque. Un chercheur cité par l’enquête le décrit comme « the most elegant and hardest-to-detect attack vector ». L’OCCRP fait elle-même le parallèle avec SolarWinds, cette attaque de 2019-2020 où un logiciel de supervision parfaitement légitime avait servi de véhicule à une compromission massive, via ses mises à jour signées.

Restons précis : à ce jour, aucune backdoor n’a été trouvée dans Passwork, aucune fuite, aucun client compromis. On parle d’un vecteur qui existe, pas d’une attaque qui a eu lieu. Le canal permettrait, structurellement, ce que SolarWinds a démontré possible. Ce n’est pas une accusation. C’est une géométrie.

Quel État a pu revoir la source ?

Voilà la question que personne ne pense à poser, et c’est peut-être la plus lourde.

Passwork LLC est certifiée par le FSTEC, que VSquare rattache au ministère de la Défense russe, et par le FSB. Or ces certifications ne sont pas des tampons administratifs. Le processus impose la soumission du code source à des laboratoires accrédités, chargés d’y détecter « vulnerabilities or undeclared capabilities ».

Autrement dit : un État a organisé la relecture du code source de ce logiciel. Pas l’Union européenne. Pas un auditeur mandaté par tes soins. Un service placé sous une autre juridiction, avec ses propres priorités.

Quand tu installes un logiciel, tu ne fais pas que faire confiance à l’éditeur. Tu fais confiance, sans le savoir, à tous ceux qui ont eu les mains dans son code avant toi.

L’usine à gaz qui n’a rien vu passer

À ce stade, tu te dis peut-être que c’est bien pour ça qu’on paie des régulateurs. L’Europe pond du règlement numérique au kilomètre, un acronyme neuf par trimestre, un communiqué triomphal à chaque texte voté. Alors ce coffre russe déguisé en produit européen, vendu à ses propres administrations, ils l’ont vu venir ? Non. Pas une alerte, pas une ligne.

Regarde la pile réglementaire censée couvrir ce terrain. Le Cyber Resilience Act impose la sécurité « by-design » aux produits numériques : comment ils sont conçus, pas par qui ni depuis où.

Le Cyber Solidarity Act, entré en vigueur le 4 février 2025, organise la réponse aux crises : un système d’alerte européen, une réserve de cybersécurité, une revue post-incident. Utile le jour où ça brûle, muet sur qui a posé l’allumette. Et les schémas de certification de l’ENISA, l’EUCC pour les produits, l’EUCS pour le cloud, évaluent des niveaux d’assurance sur des critères techniques.

Cherche dans tout ça la case « quelle entité pousse le binaire » ou « quel État a relu la source ». Elle n’existe pas. Aucun de ces textes ne certifie un produit selon son origine réelle, et aucun n’interdit quoi que ce soit sur ce critère.

Une société peut afficher « Made in EU », faire relire son code par un service de renseignement étranger, et rester parfaitement en règle avec Bruxelles. Conforme, tamponnée, irréprochable sur le papier. Voilà le niveau de protection qu’on t’a vendu à coups de milliards engloutis dans la cybersécurité européenne et de conférences de presse.

Pendant que ce coffre, dont la souche russe est certifiée FSB, prospérait sur le marché public européen, à quoi la même Union consacrait-elle son énergie ? À vouloir forcer les messageries à scanner tes conversations privées avant chiffrement, le CSAR (Chat Control 2.0). Traduction : Bruxelles n’a pas su repérer un logiciel relu par un service russe et vendu à ses propres administrations, mais elle veut fouiller les messages de centaines de millions d’Européens. Incapable sur la vraie menace, zélée sur la surveillance des innocents.

À lire : Chat Control 2.0, l’UE veut lire tes messages avant que tu les envoies et NIS2 oblige à chiffrer, CSAR interdit de le faire vraiment

La conclusion est désagréable mais nette. La souveraineté logicielle n’est pas à déléguer à un régulateur. Elle est à ta charge. Toi, citoyen. Toi, PME.

Ce que ça change concrètement : ta grille de vérification

Bonne nouvelle, tu n’as pas besoin d’être analyste en cyberdéfense. Tu as besoin d’une méthode. Avant de confier tes mots de passe, tes contrats ou ta comptabilité à un logiciel, fais-le passer par ces six questions. Prends l’exemple le plus sensible qui soit, un coffre-fort de mots de passe, celui qui garde les clés de tout le reste.

Qui pousse le binaire ? Cherche l’entité qui édite réellement les mises à jour, pas celle qui encaisse ta facture. Registre du commerce, mentions légales, historique de la société. Une adresse européenne sur la page d’accueil et une maison mère ailleurs, c’est un signal, pas une réponse.
Qui signe le code, et avec quelle clé ? Un éditeur sérieux publie ses signatures et permet de les vérifier. Regarde qui détient la clé de signature et où. Une clé contrôlée par une entité sous une juridiction opaque annule le bénéfice de la signature.
Quel État a pu revoir la source ? Les certifications nationales sont publiques. Une certification FSTEC ou FSB implique une relecture du code par des labos russes accrédités. À l’inverse, un visa ANSSI (comme celui obtenu par KeePassXC) implique une évaluation française. Ce n’est pas neutre : demande-toi quel État tu es prêt à laisser regarder sous le capot.
Self-hosted ou cloud ? Un logiciel que tu héberges toi-même retire l’éditeur de la boucle du stockage. Tes données restent sur ton infrastructure, sous ta juridiction. Ça ne règle pas le problème du canal de mise à jour, mais ça réduit la surface. Le cloud de l’éditeur, lui, cumule les deux dépendances.
Quel historique de mises à jour, par quel canal ? Un projet mûr a un journal de versions lisible, un canal de distribution stable et documenté. Des mises à jour opaques, un canal qui change, une entité de distribution exotique : autant de drapeaux rouges. Le canal est le vrai point d’entrée, surveille-le comme tel.
Le code est-il auditable ? L’open source ne rend pas un logiciel magiquement sûr, mais il rend le mensonge plus difficile. Un code public a pu être relu par n’importe qui, y compris des gens qui n’ont aucun intérêt à te rassurer. Un code fermé te demande de croire l’éditeur sur parole, et tu viens de voir ce que valent les paroles sur une page produit.

Aucune de ces six questions n’a besoin d’un budget. Elles ont besoin de dix minutes et de l’envie de regarder derrière le drapeau. Applique-les à ton gestionnaire actuel ce soir. Certains passeront le test sans transpirer, d’autres beaucoup moins.

À lire : Apple, Bitwarden, KeePassXC ou 1Password, le comparatif honnête des coffres à mots de passe

Les limites : ce que cette grille ne dit pas

Il faut être honnête sur deux points, sinon on tombe dans le procès d’intention.

D’abord, l’équité envers l’éditeur mis en cause. Passwork revendique son indépendance, affirme que la transition avec l’entité russe s’achève en août 2026, et que les données de ses clients résident sur les serveurs de ces clients. Son PDG, Alexander Muntyan, invoque une « zero-knowledge architecture », avec chiffrement et déchiffrement côté client : « we would simply have no data to provide ».

Cet argument mérite d’être pris pour ce qu’il est, un argument marketing, pas une garantie technique. En version auto-hébergée, cette couche peut être désactivée, et une couche serveur existe. Surtout, le zero-knowledge protège le stockage, pas le canal de mise à jour, et c’est le canal qui inquiète les chercheurs.

Côté clients, prudence aussi. L’enquête établit que deux organismes irlandais, l’Office of Public Works et le State Laboratory, se disent non informés de l’origine du produit, le second traitant désormais le sujet comme un « potential risk ».

Pour le reste, Passwork LLC affiche côté russe des clients du complexe militaro-industriel, dont Almaz-Antey, MMZ Avangard, Kometa et Gazprom Neft. Plusieurs figurent sur des listes de sanctions occidentales, mais selon des régimes différents, UE, États-Unis ou contrôles à l’export selon les cas. On ne fait pas d’amalgame : ni « tous sanctionnés par l’UE », ni « tous les clients européens compromis ».

Ensuite, la grille elle-même a des limites. Elle ne détecte pas une compromission active, elle évalue un risque structurel. Un logiciel qui coche toutes les cases peut quand même être attaqué, et un logiciel qui en rate une n’est pas forcément un piège. La grille ne remplace pas un audit, elle t’évite de confondre une plaquette commerciale avec une preuve. C’est déjà énorme.

En résumé

« Made in EU » est une allégation marketing. Pas un label contrôlé, pas une garantie juridique, pas une preuve de souveraineté. L’affaire Passwork le montre sans avoir besoin d’une seule compromission avérée : un logiciel peut être immatriculé à Barcelone, codé à Arkhangelsk, mis à jour depuis les Émirats, et relu par un service russe, tout en restant parfaitement en règle avec la pile réglementaire européenne. Cette pile, Cyber Resilience Act, Cyber Solidarity Act, schémas ENISA, n’a jamais posé les bonnes questions. Elle ne les pose toujours pas. Ne compte pas sur elle. Elle ne t’a pas protégé, elle t’a rassuré. Ce n’est pas le même métier.

Alors pose-les toi-même. Qui pousse le binaire, qui signe le code, quel État a pu en relire la source, est-ce hébergeable chez toi, quel est le canal de mise à jour, le code est-il auditable. Six questions, dix minutes, appliquées d’abord à l’endroit le plus sensible : le coffre où vivent tous tes mots de passe. La souveraineté ne se lit pas sur un drapeau. Elle se vérifie. Personne ne le fera pour toi.

Sources

L’enquête

OCCRP, European Password Manager Shares Origins and Updates with State-Certified Russian Firm, l’enquête primaire du 17 juillet 2026.
VSquare, la même enquête, la co-publication du consortium.
The Irish Times, How Russian password technology made its way into Irish State agencies, les organismes publics irlandais clients.

Le cadre réglementaire

EUR-Lex, Règlement (UE) 2025/38, Cyber Solidarity Act, le texte officiel, en vigueur depuis le 4 février 2025.
Commission européenne, EU Cyber Solidarity Act, le budget et les mécanismes.
EUR-Lex, Digital Europe Programme 2021-2027, le volet cybersécurité.
ANSSI, rapport de certification CSPN-2025/16 (KeePassXC 2.7.9), l’exemple du visa ANSSI.

Alerting et coût total, le bilan de ton SIEM souverain

Mac Souverain — Sat, 25 Jul 2026 12:25:13 GMT

Six épisodes. Un VPS durci, Wazuh qui centralise, des agents sur tout le parc, CrowdSec au réseau, Rspamd au mail, Santa sur les Mac. Ta stack est debout, elle collecte, elle détecte, elle journalise.

Et elle est muette.

Un binaire refusé sur un poste, une rafale d’échecs d’authentification, un compte qui se réveille à 3 heures du matin, tout ça atterrit sagement dans un tableau de bord que personne ne regarde à 3 heures du matin. Une détection que personne ne voit passer n’est pas une détection, c’est un log de plus.

Aujourd’hui, dernier épisode de la série, on branche l’alerting. La brique qui transforme un SIEM qui sait en un SIEM qui prévient. Et ensuite on fait ce qu’on a promis dès le premier article, les comptes. Combien te coûte vraiment cette stack, face à la facture qu’on t’aurait présentée en SaaS. La réponse est plus tranchée que tu ne le crois.

L’alerting, être prévenu sans être harcelé

Wazuh sait déjà envoyer des notifications. Un démon dédié, wazuh-integratord, démarre avec le manager, lit le flux d’alertes en continu, et pousse chaque alerte qui dépasse un seuil vers la cible que tu lui as désignée. La mécanique est là. Tout le travail est dans le réglage.

Premier réflexe souverain, regarde qui reçoit tes alertes. Wazuh propose des intégrations natives clés en main, et le piège est là, presque toutes sont des services américains, Slack, PagerDuty, VirusTotal. Brancher ton SIEM souverain sur Slack, c’est monter une stack entière pour rester maître de tes logs, puis expédier toutes tes alertes de sécurité chez un tiers américain. La dépendance qui rentre par la petite porte.

Deux canaux restent cohérents avec ce qu’on a construit. L’email, servi par le serveur mail que tu administres déjà depuis l’épisode Rspamd, qui est le mécanisme de notification historique de Wazuh. Et le chat auto-hébergé, un Mattermost ou un Matrix posé sur ton infrastructure. Mattermost accepte les webhooks au format Slack, donc l’intégration native slack fonctionne le plus souvent telle quelle, son hook_url pointé vers ton serveur à toi. À retester sur ta version, les formats bougent d’une release à l’autre.

La configuration vit dans ossec.conf, sur le manager. L’email natif est géré directement par le manager, les canaux chat passent par l’Integrator via un bloc <integration>. Côté email d’abord.

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@ton-domaine.tld</email_from>
  <email_to>secu@ton-domaine.tld</email_to>
</global>

<alerts>
  <email_alert_level>7</email_alert_level>
</alerts>

Côté chat, un bloc <integration> par canal.

<integration>
  <name>slack</name>
  <hook_url>https://mattermost.ton-domaine.tld/hooks/xxxxxxxx</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Le champ qui commande tout, c’est <level>. Wazuh note chaque alerte sur une échelle de 0 à 16, et le seuil transmet cette valeur ou toute valeur supérieure. Un canal à <level>10</level> ne verra jamais un niveau 6. Tu peux affiner avec <rule_id> ou <group>, mais retiens un piège classique, quand tu combines plusieurs de ces filtres, ils se cumulent en ET, pas en OU. L’alerte doit satisfaire tous les critères pour passer, et beaucoup de monde s’est demandé pourquoi son intégration restait silencieuse pour cette seule raison.

Reste la vraie question, quel niveau pour quel canal. Voici les repères que je te propose, une recommandation d’usage et non un barème gravé par Wazuh, à ajuster à ton parc :

0 à 3, du bruit informatif. Tu journalises, tu ne notifies rien.
4 à 6, faible. Ça vit dans le tableau de bord, pas dans ta poche.
7 à 9, moyen. Email groupé, l’équipe le lit dans la journée.
10 à 12, élevé. Échecs d’authentification en série, atteinte à l’intégrité d’un fichier, un binaire refusé par Santa. Chat en temps réel plus email.
13 à 16, critique. Compromission probable, agent désactivé. Astreinte, on réveille quelqu’un.

Un bloc <integration> par canal, chacun son seuil. L’email digest à 7 pour tout le monde, le chat à 10 pour l’équipe technique, un script custom vers du SMS ou du ntfy à 12 pour le responsable. Le patron ne veut pas être tiré du lit pour un niveau 8, et le jour où tu le réveilles pour rien, il coupe les notifications. C’est comme ça qu’on meurt.

Parce que le vrai risque de l’alerting, ce n’est pas d’en rater. C’est d’en avoir trop. Une attaque en force brute non dédupliquée, ce sont des centaines d’alertes en quelques minutes, et une équipe qui apprend à les ignorer. La déduplication se règle en amont, dans la fréquence et la fenêtre temporelle de tes règles, jamais au moment de la notification. Un SIEM qui crie tout le temps, c’est un SIEM qu’on n’écoute plus. La fatigue d’alerte est pire que l’absence d’alerte, parce qu’elle te donne l’illusion d’être couvert.

Ce que la stack t’a vraiment coûté

Le moment des comptes, coût affiché et coût caché, parce que te vendre du gratuit serait te mentir.

Le poste visible, c’est le VPS. Wazuh en mononœud, manager, indexeur et tableau de bord sur une seule machine, tourne confortablement pour une PME de 25 à 50 postes sur 8 vCPU, 16 Go de RAM et 100 Go de disque pour trois mois de rétention. Chez un hébergeur européen hors emprise américaine, ça se loue entre 300 et 1 700 euros par an selon que tu vises le bas de gamme allemand ou le souverain français haut de gamme. Une seule ligne de facture, pour toute la stack.

Le poste des licences, ensuite. Wazuh, les agents, CrowdSec, Rspamd, Santa, l’alerting. Zéro. Pas un centime, pas un palier entreprise, pas un quota de postes. Open source de bout en bout.

Et puis le poste qu’aucun tableau de prix ne t’affiche, le temps. L’installation de la stack, plusieurs jours cumulés pour qui découvre, moins pour un sysadmin aguerri. Puis la maintenance, les mises à jour, la surveillance du disque, et surtout le tuning des règles qui bouffe l’essentiel des premières semaines. Je ne te donnerai pas un chiffre d’heures par mois, il serait inventé, et aucun de ceux que tu liras ailleurs ne repose sur autre chose que du doigt mouillé. Compte en jours-homme, pose ton taux, fais ton addition.

Voilà la nuance qui tient tout l’épisode. Souverain n’est pas gratuit, souverain déplace la dépense de la licence vers la compétence interne. Tu ne paies plus une rente à un éditeur, tu paies un investissement qui reste dans ta maison. Le VPS se compte en centaines d’euros, le temps est le poste dominant, et les deux ensemble restent très loin sous ce que t’aurait coûté l’équivalent loué.

Épisode par épisode, la même stack en SaaS

Reprenons la stack brique par brique, et mettons en face ce que le marché facture pour la même fonction. Hypothèses affichées, parce que sans elles un chiffre ne veut rien dire, une PME d’une quarantaine de postes dont une vingtaine de Macs, environ cinq gigaoctets de logs par jour.

Wazuh remplace un Microsoft Sentinel ou un Splunk ES. Compte 7 800 dollars par an pour cinq gigaoctets de logs quotidiens côté Sentinel, de 8 000 à 12 500 dollars côté Splunk. CrowdSec tient le rôle d’une offre de threat intelligence managée, qui démarre à 1 900 dollars par mois en Platinum, soit près de 23 000 dollars l’année. Rspamd fait le travail d’un Proofpoint ou d’un Mimecast, 1 200 à 8 640 dollars pour quarante boîtes. Santa se substitue à un Jamf Protect, autour de 1 440 dollars pour vingt Macs. En face de chaque ligne, le même chiffre, zéro de licence.

Additionne cette colonne de droite. Selon les options retenues et sans même compter l’EDR managé ni le filtrage réseau haut de gamme, l’équivalent SaaS complet d’une PME de cette taille se situe entre 12 000 et 40 000 dollars par an. En face, ta stack souveraine, entre 300 et 1 700 euros de cash, plus ton temps. Même en comparant le pire de la stack souveraine au meilleur prix SaaS, le rapport est de l’ordre de six à trente fois. Et l’écart n’est pas figé, il se creuse. La licence SaaS, tu la repaies chaque année à vie, à chaque poste ajouté, à chaque gigaoctet ingéré en plus. Le VPS, lui, reste stable, et le temps d’installation s’amortit une fois pour toutes.

Deux précisions d’honnêteté. D’abord, les tarifs que je te donnais dans le premier article tiennent tous, Sentinel autour de 4,30 dollars du gigaoctet, CrowdStrike de 60 à 185 dollars par poste, Splunk de 8 000 à 12 500 dollars. Rien n’a baissé. Ces éditeurs ne publient d’ailleurs pas de grille publique, ils masquent leurs prix et te poussent vers des engagements de volume, ce qui pénalise la PME qui n’ingère que quelques gigaoctets par jour. Ensuite, le zéro de la colonne souveraine est un zéro de licence, pas un zéro tout court. Le coût existe, mutualisé sur une ligne de VPS et étalé sur ton temps. Mais l’addition d’en face, elle, se compte par brique, par poste, et par an.

Les pièges, pour ne pas te raconter d’histoires

Une stack souveraine bien montée peut mal vieillir. Quatre points de vigilance, à regarder en face.

La rétention gonfle le VPS en silence. Trois mois par défaut, mais le jour où tu veux six mois ou un an de recul pour une enquête, le disque double ou triple, et tu passes à un plan supérieur. Le coût souverain n’est pas gelé, il croît avec ta rétention et ton nombre d’agents. Anticipe-le au dimensionnement.
Le mononœud est un point de défaillance unique. Toute la stack sur un seul VPS, c’est aussi une seule cible. Tes sauvegardes chiffrées hors-site, posées dès le socle, ne sont pas une option. Le multi-nœud existe, mais il sort du périmètre d’une PME.
Les hébergeurs augmentent, eux aussi. Souverain ne veut pas dire prix bloqué à vie, certains ont relevé leurs tarifs en 2026. La différence tient en un mot, changer d’hébergeur, c’est une migration de VPS de quelques jours. Ce n’est pas un contrat de licence qui te tient à la gorge.
Le tuning est chronophage au démarrage. Les premières semaines croulent sous les faux positifs, et c’est là que se joue la qualité de tout le reste. Bâcle cette phase, et tu retombes dans la fatigue d’alerte.

Aucun de ces pièges n’est rédhibitoire. Ce sont des paramètres que tu contrôles, précisément parce que la stack est chez toi.

Conformité, la brique qui rend le délai tenable

On a ouvert la série sur une obligation, RGPD et NIS2 t’imposent de notifier vite. Soixante-douze heures pour caractériser une violation côté RGPD, un triptyque de 24 heures, 72 heures et 30 jours côté NIS2.

L’alerting est la brique qui rend ce délai tenable. Collecter et détecter, c’est produire la preuve. Alerter, c’est qu’un humain la voie à temps pour agir. Sans notification calibrée, le triptyque reste un vœu, la stack sait qu’il s’est passé quelque chose et personne ne le sait à temps. Avec elle, l’horloge des 72 heures démarre à la détection, pas le lundi matin quand quelqu’un rouvre le tableau de bord. C’est la différence entre une conformité sur le papier et une conformité qui tient devant le régulateur.

En résumé, tu ne dépends de personne

Recule d’un pas et regarde ce que tu as monté. Sept épisodes, un VPS, des briques open source, et un dispositif qui voit, bloque, filtre, contrôle et, depuis aujourd’hui, prévient au bon niveau sans te harceler. Ce que les grandes entreprises paient une fortune, tu l’as bâti pour le prix d’un VPS et de quelques week-ends.

Mais le vrai gain n’est pas sur la facture. Il tient dans une phrase, tu ne dépends de personne. Trois indépendances.

Juridique. Tes logs de sécurité, le matériau le plus sensible de ton SI, vivent sur ton VPS européen, hors de portée du CLOUD Act. En juin 2025, devant une commission d’enquête du Sénat français, Anton Carniaux, directeur des affaires publiques et juridiques de Microsoft France, interrogé sous serment sur sa capacité à garantir que les données d’un citoyen français ne partiraient jamais vers les autorités américaines, a répondu, « Non, je ne peux pas le garantir ». Chez un fournisseur soumis au droit américain, c’est ce niveau de garantie que tu acceptes. Aucun.

Économique. Pas de rente de licence, pas de choc de prix décidé sans toi. Rappelle-toi les clients de VMware après le rachat par Broadcom, licences perpétuelles supprimées, abonnement forcé. AT&T est allé jusqu’à poursuivre Broadcom en justice en dénonçant une hausse de plus de 1 000 pour cent sur son renouvellement. Payer ou migrer dans la douleur, sans voix au chapitre. Personne ne peut faire ça à ta stack.

Opérationnelle. Personne ne coupe ton accès, ne déprécie une fonction dont tu dépends, ne t’impose un calendrier de migration. Tu possèdes ta stack, tes logs, ta détection.

Le prix de ces trois libertés, c’est un VPS et de la compétence qui reste chez toi. Compare-le une dernière fois à une facture SaaS qui revient chaque année sans t’acheter aucune d’elles.

C’est là que finit la série. Pas sur un produit, sur une position. La souveraineté n’est pas un slogan, c’est une addition que tu viens de faire, et elle penche d’un seul côté.

La suite, parce que tu l’as demandée. Un lecteur nous a écrit après cette série pour réclamer un vrai plongeon dans Wazuh, plus loin que le tout-en-un de l’épisode 2. Message reçu. Un tutoriel Wazuh approfondi arrive bientôt, règles maison, décodeurs, tableaux de bord aux petits oignons. Tu as une demande, une coquille repérée, une brique que tu voudrais voir décortiquée ? Écris-nous.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier face au SaaS. Tu viens de le lire.

Des termes techniques ? Consulte le glossaire.

Claude Cowork en local, l'agent sort du bac à sable

Mac Souverain — Fri, 24 Jul 2026 10:00:00 GMT

Tu connectes un dossier à Claude Cowork, et l'agent a en réalité tout ton disque sous la main. En mode d'exécution local sur macOS, Cowork monte l'intégralité du système de fichiers en lecture-écriture dans la machine virtuelle de l'agent. Un seul message suffit à l'en faire sortir, sans qu'aucune invite de permission n'apparaisse. Anthropic a clôturé le rapport en « informative », sans correctif : la bascule vers l'exécution cloud mitige, mais elle est en bêta graduelle, et le mode local reste exposé.

Ce que tu dois faire

1. Vérifie le mode d'exécution de ton Cowork. Le cloud est devenu le défaut, mais en bêta et par vagues : va le lire dans tes réglages plutôt que de le supposer. Le local te laisse dedans.

2. Ne lance jamais une session locale sur un compte macOS qui contient ton Trousseau, tes clés SSH ou ton fichier de mots de passe.

3. Traite tout ce que l'agent lit, page web, pièce jointe, ticket, comme du code hostile. C'est l'entrée de la chaîne.

Ce que Cowork monte vraiment

En mode d’exécution local sur macOS, Claude Cowork monte l’intégralité du système de fichiers de ton Mac en lecture-écriture à l’intérieur de la machine virtuelle Linux où tourne l’agent, sur un point de montage nommé /mnt/.virtiofs-root, visible du seul compte guest-root. Tout le disque. Pas le dossier que tu as connecté. Le bac à sable est un bac, il n’a juste pas de bords. La recherche, baptisée SharedRoot, est signée Oren Yomtov, chercheur principal en sécurité chez Accomplish AI, publiée le 23 juillet 2026 et relayée le jour même par The Hacker News.

La documentation d’Anthropic annonce pourtant, pour le mode local, un accès fichier « limité aux dossiers que le membre a connectés ». C’est la promesse. Le montage, lui, expose l’hôte entier.

L’évasion se déroule d’un bloc. L’agent démarre en utilisateur de session non privilégié, s’octroie root dans un espace de noms utilisateur, puis fait autocharger par le noyau un module du sous-système Traffic Control qui porte CVE-2026-46331, dite pedit COW : le simple fait de le référencer suffit à le charger. La faille est notée 7.8 au CVSS 3.1 par kernel.org sur sa fiche NVD, 6.7 par Red Hat, avec un exploit public, PACKET_EDIT_MEME.c, disponible depuis le 17 juin. La corruption du cache de pages empoisonne un binaire mis en cache, que le démon coworkd réexécute ensuite en root. À l’arrivée, guest-root a tout le disque de l’hôte entre les mains.

The Hacker News avance environ 500 000 utilisateurs macOS en session locale, un ordre de grandeur qu’aucune méthode publiée n’étaye et que le billet des chercheurs ne reprend pas. Retiens l’échelle, pas le chiffre. Ce qui est certain, c’est qu’aucune invite de permission n’apparaît à aucun moment de la chaîne.

Sur le correctif, il faut être précis, parce que le sujet se prête au raccourci. Anthropic a clôturé le rapport en « informative », sans correctif dédié. Dans le même temps, Cowork est passé à l’exécution cloud par défaut : Anthropic ne publie pas de numéro de version pour Cowork, mais date le changement du 7 juillet 2026 et le qualifie de bêta en déploiement graduel, à partir du plan Max. Les chercheurs notent que la chaîne d’évasion locale « ne semble pas s’appliquer » côté cloud, sans l’avoir auditée. La mitigation est réelle. Elle ne referme rien pour ceux qui exécutent en local, et elle n’a pas encore atteint tout le monde.

La VM donne l’impression d’un mur

La phrase vaut au-delà de cette faille : le bac à sable d’un agent n’est pas une frontière de sécurité s’il monte tout le disque. La machine virtuelle donne l’impression d’un cloisonnement, le montage l’annule silencieusement. Entre le dossier que tu crois partager et ton compte utilisateur complet, il y a un gouffre que rien dans l’interface ne signale.

À lire : L’ANSSI place Claude Cowork et OpenClaw en alerte

La chaîne suppose que l’agent exécute déjà du code hostile. Sauf que c’est son métier : ingérer un contenu que tu ne contrôles pas, page web, PDF, ticket, puis agir. Sur ce type d’outil, l’injection de prompt n’a rien d’une hypothèse de laboratoire. C’est l’entrée principale.

À lire : Hugging Face compromis, et ton modèle local ?

Les chercheurs recommandent quatre durcissements, et précisent que chacun, seul, suffit à casser la chaîne. Un seul traite pourtant la cause : ne monter que les dossiers réellement connectés. Les trois autres retirent une marche à cet escalier-là, le quatrième supprime l’escalier.

Le défaut n’est pas isolé, il fait classe. Un modèle qui s’échappe de son bac de test, un protocole d’agent qui expose l’exécution de code, maintenant un agent à qui on a monté le disque entier. Le point commun n’est jamais le bug, c’est la générosité du périmètre accordé par défaut.

À lire : MCP d’Anthropic, un défaut de conception expose 200 000 instances

Ce que tu fais maintenant

1. Vérifie le mode d’exécution de ton Claude Cowork. Le cloud est devenu le défaut, mais en bêta et par vagues depuis le 7 juillet : ne présume pas que ton compte l’a reçu, va le lire dans les réglages. Si tu es en local, volontairement ou en héritant d’un réglage ancien, tu es concerné.

2. Ne lance jamais une session locale depuis un compte macOS qui héberge ton Trousseau, tes clés SSH ou le fichier de ton gestionnaire de mots de passe. Un compte utilisateur dédié à l’agent, vide de secrets, coûte cinq minutes et retire tout intérêt à l’évasion.

3. Traite tout ce que l’agent ingère comme du code hostile. Une page web, une pièce jointe, un ticket client : c’est l’entrée, et elle n’est pas filtrée. Tu ne lancerais pas ce contenu dans un script sans regarder, ne le donne pas à mâcher à un agent qui a les droits d’écriture.

Sources

Hugging Face compromis, et ton modèle local ?

Mac Souverain — Wed, 22 Jul 2026 09:00:00 GMT

La logithèque où LM Studio va chercher tes modèles s'est fait compromettre, Hugging Face l'a révélé le 16 juillet. L'entreprise y a laissé des identifiants d'infrastructure interne, pas les tiens, et ne relève aucune altération des modèles publics. Le twist : pas de pirate. OpenAI déclare qu'il s'agissait de ses propres modèles, échappés d'un test interne.

Ce que tu dois surveiller

1. Sans compte Hugging Face, tu n'as rien à faire. Ce que tu as téléchargé n'a pas bougé.

2. Avec un compte, fais tourner tes tokens d'accès et relis l'activité récente, par précaution.

3. Hugging Face n'a pas fini d'évaluer si des données partenaires ou clients ont été touchées.

Le fait

Le 16 juillet 2026, Hugging Face a divulgué une intrusion survenue quelques jours plus tôt dans une partie de son infrastructure de production. Le point d’entrée, un dataset malveillant exploitant deux chemins d’exécution de code : un chargeur de dataset à code distant, et une injection de template dans sa configuration. Puis escalade de privilèges et mouvement latéral, tranquillement, sur un week-end.

L’entreprise a analysé le journal de l’attaque avec des agents LLM et il en ressort « plus de 17 000 événements enregistrés ». C’est un comptage forensic d’événements de log, pas un décompte des actions de l’attaquant. Hugging Face évoque dans la foulée un essaim de dizaines de milliers d’actions automatisées. Personne n’a vu un humain taper au clavier.

Ce qui est sorti, ce sont « un ensemble limité de jeux de données internes » et « plusieurs identifiants utilisés par nos services », plus des identifiants cloud et cluster récoltés au passage. Les clés de la maison Hugging Face, donc, pas les tiennes. Aucune fuite de données utilisateurs n’est établie. Et une semaine plus tard, l’entreprise n’a toujours pas fini d’évaluer si des données partenaires ou clients ont été touchées.

Ton modèle local, lui, n’a pas bougé

Voilà le point qui t’intéresse si tu as installé LM Studio et téléchargé un modèle en MLX. Hugging Face est explicite : aucune preuve d’altération des modèles, datasets ou Spaces publics, et la chaîne d’approvisionnement, images de conteneurs et paquets publiés, « a été vérifiée saine ». Le fichier qui dort sur ton SSD est bien celui que tu crois.

Sauf qu’« aucune preuve d’altération » n’est pas « nous avons prouvé qu’il n’y a pas eu d’altération ». C’est la meilleure information disponible, produite par une entreprise en pleine réponse à incident. Pas une garantie notariée.

Si tu as un compte, Hugging Face recommande « par précaution » de faire tourner tes tokens et de relire l’activité récente. Retiens bien le « par précaution » : rien n’indique qu’un token utilisateur ait fuité.

Un modèle déjà posé sur ton disque se moque, lui, de l’état de santé de sa logithèque.

À lire : Installe ton premier modèle d’IA en local sur Mac

Le twist, l’attaquant n’était pas un pirate

Le 21 juillet, OpenAI a déclaré que l’incident avait été mené par une combinaison de ses propres modèles, dont GPT-5.6 Sol et un modèle pré-release encore plus capable, tous avec les garde-fous cyber assouplis pour les besoins de l’évaluation, pendant un test interne sur un benchmark de capacités offensives nommé ExploitGym. Déclaration reprise verbatim par TechCrunch, recoupée par Bloomberg, Fortune et The Register.

Reste la question qui fâche, comment ces modèles sont-ils sortis de leur environnement de test ? Selon OpenAI, ils auraient exploité une faille zero-day dans le proxy cache d’un registre de paquets. C’est la version de la partie responsable, auto-déclarée, qu’aucun audit externe n’a vérifiée. Hugging Face, lui, a fait appel à des spécialistes forensic externes, mais sur son propre incident, pas sur l’évasion côté OpenAI. Personne d’extérieur n’a regardé sous ce capot-là.

À lire : Mythos, le modèle qui trouve des failles tout seul, vient de fuiter

Deux détails qui vieillissent mal. Hugging Face n’a jamais amendé son avis de sécurité : le texte officiel dit toujours que le LLM utilisé reste inconnu. L’attribution vit dans un billet d’OpenAI et des déclarations orales, pas dans ce document-là. Et l’entreprise a signalé l’incident aux forces de l’ordre, pour ce qui s’avère être l’accident d’une entreprise tierce. Personne n’a dit ce que devient ce signalement.

À lire : GPT-5.5 passe en capacity-class cybersec. OpenAI serre les accès.

La leçon en creux

Pendant la réponse à incident, Hugging Face a voulu analyser les traces avec des modèles de frontière via API commerciales. Les garde-fous des fournisseurs, incapables de distinguer une équipe de réponse à incident d’un attaquant, ont bloqué ses analystes. Ils ont fini sur GLM 5.2, un modèle open-weight du chinois Z.ai, sur leur propre infrastructure.

Savoure le paradoxe : le modèle qui a fini par les aider venait de Chine, et c’est justement parce qu’il tournait chez eux que son origine n’avait plus d’importance. Le jour où tu enquêtes sur ta machine, le modèle qui t’aide a intérêt à tourner chez toi.

Ce que tu fais maintenant

1. Pas de compte Hugging Face ? Tu n’as rien à faire. Rien du tout. Hugging Face n’a relevé aucune altération sur les modèles publics, et ton installation locale ne repose sur aucun identifiant concerné.

2. Compte Hugging Face ? Fais tourner tes tokens d’accès, révoque ceux dont tu ne te sers plus, relis l’activité récente. Précautionnel, pas urgent, gratuit.

3. Prends l’habitude de regarder d’où vient un modèle. Dans LM Studio, chaque variante affiche son dépôt d’origine, et un dépôt officiel ou communautaire établi n’a pas le même profil de confiance qu’un miroir reposté par un compte créé le mois dernier.

Sources

Santa sur tes Mac, le binaire non invité reste à la porte

Mac Souverain — Mon, 20 Jul 2026 07:01:16 GMT

À l’épisode précédent, tu as posé Rspamd devant ta boîte mail. Chaque message entrant est noté, l’hameçonnage lève une alerte, et le verdict remonte dans Wazuh. Trois briques debout, le serveur, le réseau, le mail. Ton SIEM voit, il bloque, il filtre.

Et il reste une porte. La dernière, celle qu’aucune des trois premières ne garde.

Un salarié télécharge un fichier. Une fausse mise à jour d’un logiciel qu’il connaît, un utilitaire trouvé sur un forum, une pièce jointe qui a franchi le filtre mail parce qu’elle était propre le jour où elle est passée. Il double-clique. Le binaire démarre. À cette seconde précise, ni CrowdSec ni Rspamd n’ont voix au chapitre, l’exécution se joue sur le Mac, en local, loin de tes serveurs.

C’est l’angle mort qui reste. Ton dispositif surveille tout ce qui entre, et laisse s’exécuter n’importe quoi une fois entré.

Aujourd’hui, on ferme cette porte. On installe Santa, un système de contrôle d’exécution pour macOS. Son principe est brutalement simple, tu établis la liste des applications qui ont le droit de tourner, et tout le reste est refusé. Puis on branche ses décisions sur Wazuh, pour que chaque binaire bloqué s’affiche dans ton tableau de bord, à côté de tes rejets mail et de tes blocages réseau.

Avant de commencer

Trois choses en tête avant la première commande.

Ce qu’il te faut. Un ou plusieurs Mac sous une version récente de macOS, un accès administrateur dessus, et l’agent Wazuh de l’épisode 3 déjà installé sur ces Mac, pour la partie intégration en fin de tuto. Santa est open source, maintenu par North Pole Security, la société fondée par ses créateurs d’origine, ceux qui l’ont écrit chez Google en 2014. Licence Apache 2.0, zéro version payante pour ce qu’on fait ici.

Ce que ça change. À la fin, un binaire inconnu ne s’exécute plus sur tes Mac. Pas « s’exécute et lève une alerte », ne s’exécute pas. Tu passes d’un poste qui lance tout ce qu’on lui présente à un poste qui ne lance que ce que tu as approuvé, et chaque tentative bloquée remonte dans ton SIEM.

Ce que ça ne change pas. Santa contrôle l’exécution de binaires. Il ne lit pas le contenu d’un script Python ou d’un shell, on y reviendra, c’est sa limite la plus importante et je ne vais pas te la cacher. Il ne remplace pas ton antivirus, il ne répare pas un compte dont le mot de passe a fuité. Et il ne se règle pas tout seul, la vraie dépense n’est pas la RAM, c’est la liste que tu vas devoir tenir à jour.

Santa n’interdit rien, il n’autorise que

Le renversement mental qui fait tout, et qui sépare Santa d’un antivirus.

Un antivirus travaille sur une liste noire. Il connaît des milliers de menaces, il les cherche, il les bloque, et il laisse passer tout ce qu’il ne reconnaît pas comme mauvais. Le problème est structurel, une menace qu’il ne connaît pas encore est une menace qu’il autorise. Il court après le mal, il a toujours un train de retard.

Santa fait l’inverse. Il travaille sur une liste blanche, une allowlist. Il ne se demande pas si un binaire est mauvais, il se demande s’il est autorisé. Ce qui n’est pas sur la liste ne tourne pas, qu’il soit malveillant, inconnu, ou parfaitement légitime mais oublié. Tu ne cours plus après les menaces, tu définis une fois ce qui a le droit d’exister sur tes machines.

Ce basculement se règle avec un seul paramètre, le mode client, et il a trois positions.

Monitor. Tout s’exécute, mais tout est journalisé. Santa regarde, note, et ne bloque rien. C’est le mode d’observation, celui par lequel on commence toujours.

Lockdown. Le verrou. Ce qui n’est pas explicitement autorisé est refusé. C’est la position cible, celle qui ferme la porte.

Standalone. Entre les deux. Un binaire inconnu déclenche une fenêtre qui demande à l’utilisateur d’autoriser lui-même, Touch ID à l’appui. Utile sur un poste isolé, mais il délègue la décision au salarié, exactement ce qu’une allowlist d’entreprise cherche à ne pas faire.

La progression est mécanique. On démarre en Monitor pour cartographier ce qui tourne réellement sur le parc, on construit l’allowlist à partir de ces observations, et on bascule en Lockdown une fois qu’on est sûr de ne bloquer personne d’utile. On ne verrouille jamais à l’aveugle.

Reste à savoir comment Santa reconnaît une application. Il dispose de cinq façons de l’identifier, de la plus précise à la plus large.

Le CDHash, l’empreinte d’une version exacte d’un binaire. Change à la moindre mise à jour.
Le hash SHA-256 du binaire lui-même. Aussi fragile, il casse à chaque update.
Le SigningID, l’identifiant de signature d’une application précise d’un éditeur donné.
Le certificat de signature, plus large, il couvre tout ce qu’un certificat signe.
Le TeamID, l’identifiant de l’équipe Apple Developer. Le plus large côté éditeur, il autorise toutes les applications signées par ce développeur.

Santa les évalue dans cet ordre, du plus spécifique au plus général, et la première règle qui correspond l’emporte. Pour une PME, le bon niveau se situe presque toujours sur les deux derniers. Le TeamID dit « je fais confiance à cet éditeur », une règle unique qui survit à toutes ses mises à jour. Le SigningID affine quand tu veux autoriser une application précise d’un éditeur sans lui signer un chèque en blanc. Les hash, eux, tu les laisses aux cas particuliers, sinon tu passes ton temps à réécrire des règles que la prochaine mise à jour cassera.

Étape 1, installer Santa et démarrer en Monitor

Sur chaque Mac, tu récupères le paquet d’installation signé depuis les publications officielles de North Pole Security, et tu l’installes.

sudo installer -pkg santa-*.pkg -target /

Santa tourne comme une extension système, du type Endpoint Security, la même famille d’API que les outils de sécurité sérieux sur macOS. Concrètement, deux autorisations vont t’être réclamées à la première installation. macOS te demande d’approuver l’extension système, dans Réglages, Confidentialité et sécurité. Et il faut accorder à Santa l’accès disque complet, le Full Disk Access, pour qu’il voie tout ce qui s’exécute.

Tu reconnais ce Full Disk Access, c’est celui de l’agent Wazuh à l’épisode 3, la même contrainte TCC propre à macOS. Sur un parc géré en MDM, ces deux approbations se poussent par profil de configuration, une fois pour toutes, sur toutes les machines. Sans MDM, ça se coche à la main, poste par poste. C’est le premier endroit où l’absence de MDM se paie en manipulations manuelles, autant le savoir tout de suite.

Une fois installé, Santa démarre en Monitor par défaut. C’est exactement ce qu’on veut. Vérifie son état.

santactl status

Tu dois lire un mode Monitor et une extension active. À partir de maintenant, chaque exécution sur ce Mac est notée dans son journal, sans que rien ne soit bloqué. Laisse-le tourner. Une journée de travail normal, une semaine si tu peux, le temps que tes salariés lancent tout ce qu’ils lancent d’habitude. Tu n’installes pas un mur aujourd’hui, tu prends des photos de qui passe la porte.

Étape 2, cartographier ton parc et écrire ton allowlist

Santa écrit ses décisions dans /var/db/santa/santa.log, une ligne par exécution. Va les lire, c’est ta matière première.

tail -f /var/db/santa/santa.log

Chaque ligne te donne l’action, la décision, la raison, le chemin du binaire, son éditeur. En Monitor, tout est en decision=ALLOW, mais la raison t’apprend pourquoi Santa aurait laissé passer, ou aurait bloqué en Lockdown. Un reason=UNKNOWN, c’est un binaire que rien n’autorise, exactement ce qui tomberait le jour de la bascule.

Pour transformer une observation en règle, il te faut l’identité de l’application. Santa te la donne.

santactl fileinfo /Applications/UneApp.app

Il t’affiche la signature, le TeamID, le SigningID, les empreintes, et la règle qui s’appliquerait aujourd’hui. C’est là que tu décides du bon niveau. Un éditeur en qui tu as confiance sur tout son catalogue, tu l’autorises par son TeamID.

sudo santactl rule --allow --teamid --identifier <TEAMID> --comment "editeur maison"

Une application précise, tu la prends par son SigningID.

sudo santactl rule --allow --signingid --identifier <SIGNINGID>

Tu répètes pour chaque éditeur et chaque application légitimes que Monitor a vus passer. Ta liste se construit à partir du réel, pas d’un catalogue théorique. C’est le travail de fond de cet épisode, et il n’y a pas de raccourci, une bonne allowlist est celle qui colle à ton usage.

Pour un ou deux Mac, ces règles vivent en local sur chaque machine et ça suffit. Pour un parc, tu ne vas pas taper les mêmes commandes sur dix postes. Santa sait se synchroniser depuis un serveur central qui distribue les mêmes règles à toute la flotte. L’option souveraine, c’est Moroz, un petit serveur qui sert tes règles depuis de simples fichiers, que tu héberges toi-même. Tu le poses sur ton infrastructure et tu le gardes en Tailnet-only, la même doctrine que ton manager Wazuh depuis l’épisode 1, rien d’inutile sur l’internet ouvert. North Pole Security propose aussi son propre service de synchronisation clé en main, plus riche mais hébergé chez un tiers, à toi de trancher entre le confort et le tout-souverain.

Étape 3, verrouiller en Lockdown

Ton allowlist est prête, Monitor n’a plus rien de nouveau à t’apprendre. On ferme.

Et c’est ici que se cache le piège qui fait perdre une demi-heure à tout le monde. Tu ne peux pas basculer le mode avec defaults write. Tu peux l’écrire, defaults te dira que c’est fait, defaults read te le confirmera, et santad continuera tranquillement à tourner en Monitor. Reboot compris.

Ce n’est pas un bug. C’est une décision de sécurité. Santa ne lit son mode que depuis les préférences gérées, celles qu’un profil de configuration dépose, pas depuis les préférences ordinaires qu’un utilisateur pourrait modifier. La raison est limpide, si un simple defaults write suffisait à sortir du Lockdown, le premier logiciel malveillant venu s’en servirait pour se libérer. Le verrou ne s’ouvre qu’avec une clé que l’utilisateur courant n’a pas.

La clé, c’est un profil de configuration, un fichier .mobileconfig. Sur un parc géré, ton MDM le pousse sur toutes les machines. Sans MDM, tu écris le profil et tu l’installes à la main, via Réglages, Profils, Installer, mot de passe administrateur ou Touch ID à l’appui. Le profil contient le mode et la configuration de journalisation.

<key>PayloadType</key>
<string>com.northpolesec.santa</string>
<key>ClientMode</key>
<integer>2</integer>
<key>EventLogType</key>
<string>file</string>
<key>EventLogPath</key>
<string>/var/db/santa/santa.log</string>

Le ClientMode à 2, c’est le Lockdown. L’EventLogType à file et l’EventLogPath, c’est ce qui garantit que Santa continue d’écrire son journal à l’endroit que Wazuh ira lire à l’étape suivante. Une fois le profil installé, santad le prend en compte immédiatement.

santactl status

Le mode affiche désormais Lockdown. La porte est fermée. Teste-le sans attendre, télécharge un petit utilitaire quelconque, un binaire que tu n’as pas allowlisté, et lance-le.

./un-binaire-quelconque

macOS te répond que l’exécution a été bloquée par Santa. C’est le comportement attendu, et c’est la première fois que quelque chose s’oppose vraiment à un double-clic sur ton parc. Cette exécution refusée vient aussi d’atterrir dans /var/db/santa/santa.log, en decision=DENY. Il ne reste plus qu’à la faire remonter.

Étape 4, faire remonter Santa dans Wazuh

Santa bloque, sur chaque Mac, dans son coin. Ton SIEM ne le sait pas encore. On les branche, et la boucle de la série se referme sur le poste de travail.

Rien à activer côté Santa, il écrit déjà son journal. Le branchement se fait sur deux machines, et c’est le même partage des rôles qu’à l’épisode 5. L’agent Wazuh, sur chaque Mac, lit le fichier et expédie les lignes brutes. Le manager, sur ton VPS de l’épisode 2, décode et décide quoi en faire. Une machine ramasse, l’autre comprend.

Côté Mac, tu dis à l’agent de lire le journal de Santa. Et plutôt que d’éditer chaque poste un par un, tu réutilises les groupes de l’épisode 3. Le bloc va dans la configuration partagée du groupe macos, sur le manager, dans /var/ossec/etc/shared/macos/agent.conf, et le manager le pousse à tous tes Mac d’un coup.

<localfile>
  <location>/var/db/santa/santa.log</location>
  <log_format>syslog</log_format>
</localfile>

Tu reconnais le <localfile> de l’épisode 3, le mécanisme par lequel Wazuh avale n’importe quelle source de journaux. L’agent tourne en root, il lit /var/db/santa/ sans difficulté.

Côté manager, maintenant, et sur lui seul. Un décodeur extrait les champs utiles de la ligne, dans /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="santa">
  <prematch>santad: action=EXEC</prematch>
</decoder>

<decoder name="santa-decision">
  <parent>santa</parent>
  <regex type="pcre2">decision=(\w+)\|reason=(\w+).*?\|path=(.+)$</regex>
  <order>santa_decision, santa_reason, santa_path</order>
</decoder>

Puis des règles qui transforment ces champs en alertes, dans /var/ossec/etc/rules/local_rules.xml, toujours sur le manager.

<group name="santa,">
  <rule id="100500" level="0">
    <decoded_as>santa</decoded_as>
    <description>Santa, décision d'exécution.</description>
  </rule>

  <rule id="100501" level="10">
    <if_sid>100500</if_sid>
    <field name="santa_decision" type="pcre2">^DENY$</field>
    <description>Santa, exécution bloquée, binaire $(santa_path).</description>
  </rule>

  <rule id="100502" level="3">
    <if_sid>100500</if_sid>
    <field name="santa_decision" type="pcre2">^ALLOW$</field>
    <description>Santa, exécution autorisée, binaire $(santa_path).</description>
  </rule>
</group>

La règle mère est en niveau 0, elle décode sans alerter. Le blocage passe en niveau 10, c’est lui qui t’intéresse, un binaire refusé sur un poste est un signal que tu veux voir. L’autorisation reste en niveau 3, une trace discrète, sans quoi ton tableau de bord se noierait sous les milliers d’exécutions légitimes de la journée, surtout tant que tu es en Monitor où tout est ALLOW. L’ancrage ^DENY$ et non DENY, même précaution qu’à l’épisode 5, pour ne coller qu’à la décision exacte.

Ne crois pas ce décodeur sur parole, teste-le. L’outil vit sur le manager, pas sur l’agent.

sudo /var/ossec/bin/wazuh-logtest

Tu colles une vraie ligne DENY de ton santa.log, et il te montre ce qu’il en a compris, phase par phase, décodeur reconnu, champs extraits, règle déclenchée. Si santa_decision et santa_path ne sortent pas, c’est le motif d’extraction qu’il faut ajuster, et tu le sauras en trente secondes. Un mot d’honnêteté sur ce point, les lignes de Santa commencent par un horodatage entre crochets qui n’a pas la forme d’un log syslog classique. Le pré-décodage et le motif peuvent demander un ajustement selon ta version de Wazuh et le format exact de tes lignes. C’est précisément ce que wazuh-logtest te confirme chez toi, avant que tu comptes sur l’alerte.

Une fois le test concluant, redémarre le manager pour qu’il charge ton décodeur et tes règles.

sudo systemctl restart wazuh-manager

Un salarié lance un binaire inconnu, Santa le refuse, l’écrit dans son journal, l’agent Wazuh le lit et l’expédie par le Tailnet, le manager le décode et lève une alerte de niveau 10, elle s’affiche dans ton tableau de bord à côté de tes blocages CrowdSec et de tes rejets Rspamd. La dernière porte est fermée, et tu la vois se fermer.

Si ça ne marche pas

Problème, Santa est installé mais ne journalise rien

Cause probable, l’extension système n’a pas été approuvée, ou le Full Disk Access manque. Sans eux, santad ne voit pas les exécutions.

Solution, dans Réglages, Confidentialité et sécurité, vérifie que l’extension Santa est autorisée et que l’accès disque complet lui est accordé. santactl status doit reporter l’extension active.

Problème, le mode reste sur Monitor malgré tout

Cause probable, presque à coup sûr, tu as tenté la bascule avec defaults write. Santa l’ignore, par conception.

Solution, passe par un profil de configuration .mobileconfig, poussé par MDM ou installé à la main dans Réglages, Profils. C’est le seul canal que Santa écoute pour son mode.

Problème, tu as ajouté des règles mais `santactl status` affiche `Static Rules: 0`

Cause probable, tu lis le mauvais compteur. santactl status sépare les règles par type, et Static Rules ne compte que celles d’un fichier de configuration statique, pas celles que tu ajoutes en ligne de commande.

Solution, une règle posée par TeamID compte dans TeamID Rules, une règle SigningID dans SigningID Rules. Regarde la ligne du type que tu as réellement posé, tes règles y sont.

Problème, rien ne remonte dans Wazuh

Cause probable, trois suspects, à départager avant de toucher à quoi que ce soit. Soit le fichier ne grossit pas côté Mac, soit l’agent ne le lit pas, soit le manager ne sait pas le décoder. Le grand classique, décodeur et règles édités sur le Mac au lieu du manager, où ils ne servent à rien.

Solution, le fichier grossit-il ? S’il grossit, va sur le manager, passe une ligne dans wazuh-logtest et regarde à quelle phase ça casse. Vérifie que local_decoder.xml et local_rules.xml sont bien sur cette machine-là, et que tu as redémarré wazuh-manager après les avoir écrits.

Ce que ça t’a coûté

La licence, rien. Santa est open source sous Apache 2.0, sans version payante, sans palier entreprise, sans quota de postes.

La machine, rien non plus. Santa tourne sur le Mac que tu as déjà. Le serveur de synchronisation, si tu en montes un, c’est un service léger de plus sur ton infrastructure existante.

Ton temps, un peu pour l’installation, beaucoup plus pour la calibration. Et c’est le seul vrai poste de dépense, celui qu’aucun SaaS ne t’épargnera.

Sois lucide sur ce que Santa ne fait pas, parce que ces angles morts sont réels et actionnables.

Il ne voit pas les scripts. Santa contrôle les binaires exécutés. Un script Python, un shell script, une macro, sont interprétés par un binaire, python3, bash, osascript, que tu as probablement autorisé. Le script passe alors sous le radar, c’est l’interpréteur qui est jugé, pas le code qu’il exécute. C’est la limite technique majeure, et elle ouvre tout un chantier connexe, le durcissement des interpréteurs eux-mêmes.

L’allowlist est vivante. Chaque nouvel outil légitime, chaque nouvel éditeur, c’est une règle à ajouter. Le TeamID limite la casse, une règle par éditeur qui survit à ses mises à jour, mais tu ne poses pas cette liste une fois pour la laisser dix ans.

Le jour de la bascule fait mal. Tout ce que tu as oublié d’allowlister est bloqué net, en pleine journée de travail. Le premier DENY d’un parc, c’est souvent un vieil agent de sauvegarde dormant ou un outil que personne ne savait plus installé. D’où le temps passé en Monitor, et une procédure de whitelist rapide sous la main pour les premiers jours.

Sans MDM, c’est plus manuel. Approbation de l’extension, accès disque complet, profil de mode, tout se fait poste par poste. Tenable à trois Mac, pénible à trente.

Aucune de ces limites n’est une raison de renoncer. C’est le prix d’un contrôle qui reste entièrement chez toi, aucune application soumise au cloud d’un tiers pour savoir si elle a le droit de tourner, aucun catalogue de confiance loué à un éditeur américain. Tu décides, la décision s’applique en local, et elle remonte dans ton SIEM.

Pour les pressés

Ce que fait cet article. On installe Santa sur les Mac, on démarre en mode Monitor pour cartographier ce qui s’exécute, on écrit une allowlist par TeamID et SigningID, on bascule en Lockdown via un profil de configuration, puis on fait remonter chaque décision dans Wazuh via un décodeur et des règles maison. Le poste de travail cesse d’être l’angle mort du SIEM.

Concrètement, les commandes.

Installer Santa sur chaque Mac : sudo installer -pkg santa-*.pkg -target /, puis approuver l’extension système et accorder le Full Disk Access.
Vérifier le mode par défaut : santactl status, tu dois lire Monitor.
Observer : tail -f /var/db/santa/santa.log, laisser tourner plusieurs jours.
Identifier une app : santactl fileinfo /Applications/UneApp.app.
Autoriser par éditeur : sudo santactl rule --allow --teamid --identifier <TEAMID>, ou par app : --signingid --identifier <SIGNINGID>.
Pour un parc, centraliser les règles avec un serveur de synchronisation auto-hébergé (Moroz), gardé en Tailnet-only.
Verrouiller : profil .mobileconfig avec ClientMode à 2, EventLogType à file, EventLogPath sur /var/db/santa/santa.log, poussé par MDM ou installé dans Réglages, Profils. defaults write est ignoré.
Intégrer à Wazuh, sur deux machines : <localfile> sur /var/db/santa/santa.log côté agent (via la config partagée du groupe macos), décodeur et règles côté manager (blocage en niveau 10), validation avec /var/ossec/bin/wazuh-logtest sur le manager, puis redémarrage de wazuh-manager.

En résumé

Tu es parti d’un dispositif qui voyait tes serveurs, bloquait ton réseau et filtrait ton mail, mais laissait s’exécuter n’importe quel binaire une fois qu’il avait atterri sur un Mac.

Tu as installé Santa sur tes postes, et compris qu’il ne travaille pas sur une liste de menaces mais sur une liste d’autorisés, tout ce qui n’est pas invité reste dehors. Tu as cartographié en Monitor ce qui tourne réellement, puis écrit ton allowlist par TeamID et SigningID, le bon niveau entre finesse et maintenabilité.

Tu as verrouillé en Lockdown par profil de configuration, seul canal que Santa écoute pour son mode. Et tu as branché tout ça sur Wazuh, décodeur et règles, pour qu’un binaire refusé lève une alerte de niveau 10 dans le même tableau de bord que le reste.

Le tout reste chez toi. Aucune application ne part se faire juger dans le cloud de quelqu’un d’autre, aucun tiers ne décide à ta place de ce qui a le droit de tourner sur tes machines.

Ton dispositif est complet. Quatre couches qui voient et qui bloquent, du serveur au poste de travail. Reste à le rendre vivable au quotidien. Un SIEM qui te réveille dix fois par nuit pour des broutilles, tu finis par l’ignorer, et un SIEM qu’on ignore ne sert à rien. À l’épisode 7, le dernier, on calibre l’alerting pour n’être dérangé que quand ça compte, et on fait les comptes, le coût total honnête de ce que tu viens de monter, face à la facture d’un SaaS équivalent.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer. Tu viens de le lire.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Les MCP, la porte dérobée de ton IA

Mac Souverain — Sat, 18 Jul 2026 15:17:13 GMT

Le confort qui te tend un piège

Tu installes Claude Desktop sur ton Mac. En quelques clics, tu lui branches un serveur qui lit tes fichiers, un autre qui interroge ta base de données, un troisième qui lance des commandes dans ton terminal. D’un coup, ton assistant ne se contente plus de discuter, il agit. Il ouvre tes documents, réécrit ton code, trie tes dossiers pendant que tu bois ton café.

C’est bluffant. C’est aussi le moment exact où tu viens d’ouvrir une porte sur ta machine sans en garder la clé.

Ces petits connecteurs s’appellent des serveurs MCP. Ils sont la raison pour laquelle ton IA est passée de bavarde à utile. Ils sont aussi la surface d’attaque la plus mal comprise de tout l’écosystème IA de 2026. Et le problème n’est pas théorique : une faille de conception dans le protocole a exposé environ 200 000 instances à l’exécution de code à distance, en avril dernier.

Voyons ce que tu branches vraiment sur ton Mac quand tu ajoutes un MCP. Et surtout, comment le faire sans te faire avoir.

Un MCP, c’est quoi au juste

MCP, ça veut dire Model Context Protocol. Anthropic l’a publié fin 2024 comme une norme ouverte, et tout le monde l’a adoptée, Claude bien sûr, l’app Claude Desktop comme l’outil en ligne de commande Claude Code, mais aussi Cursor, Windsurf, et une bonne partie des outils IA que tu croises.

L’idée est simple, presque évidente. Un modèle de langage, tout seul, ne sait que parler. Il ne peut ni ouvrir un fichier, ni lire ta base, ni envoyer un mail. Le MCP est le câble standard qui relie ton assistant à des outils extérieurs. Un serveur MCP d’un côté expose une capacité, lire des fichiers, requêter une API, exécuter une commande. L’assistant de l’autre côté décide quand s’en servir.

Pense à une prise universelle. Avant, chaque appareil avait son branchement propriétaire. Le MCP, c’est la prise unique où tu enfiches ce que tu veux : un connecteur pour tes fichiers, un pour ton agenda, un pour ton dépôt Git. Ton IA pioche dedans à la demande.

Concrètement, le flux ressemble à ça. Tu demandes à Claude de ranger tes captures d’écran. Le modèle repère qu’il a un serveur MCP filesystem à disposition. Il l’appelle, liste ton dossier, déplace les fichiers. Tu vois le résultat, pas la mécanique. Le serveur a exécuté une action réelle sur ton disque, décidée par le modèle, déclenchée par ta phrase.

C’est exactement là que le confort bascule en risque.

Pourquoi c’est une porte dérobée

Reprends le flux, mais regarde qui décide et qui exécute.

Toi, tu écris une phrase en langage naturel. Le modèle, une boîte statistique que personne ne contrôle ligne à ligne, décide quel outil appeler et avec quels arguments. Le serveur MCP exécute ce qu’on lui demande, sur ta machine, avec tes droits. Entre les trois, il n’y a pas de garde du corps. Personne pour lever la main et dire “attends, tu es sûr de vouloir supprimer ça ?”.

Un serveur MCP mal conçu ou franchement malveillant, c’est un exécuteur de commandes qui obéit à un intermédiaire que tu ne pilotes pas. Le modèle peut être manipulé par une consigne cachée, un texte piégé dans un fichier qu’il lit, une page web qu’on lui fait ouvrir. On appelle ça une injection de prompt. Le résultat : ton assistant se retrouve à lancer une action que tu n’as jamais demandée, via un serveur qui, lui, n’a aucune raison de refuser.

Et le vrai piège est dans la configuration. Un fichier de config MCP, ce n’est pas une liste de préférences bien sages. C’est, en pratique, un script shell déguisé. Il définit quels exécutables lancer, avec quels arguments, quelles variables d’environnement. Charger une config MCP que tu n’as pas lue, c’est lancer un script que tu n’as pas relu, et potentiellement malveillant. La nuance, c’est que celui-ci a l’air inoffensif parce qu’il est planqué dans un fichier JSON.

Le mot “porte dérobée” est mérité pour une raison précise : tu ne vois rien passer. Pas de fenêtre de confirmation, pas de trace visible, pas d’alerte. Le modèle décide, le serveur exécute, et toi tu regardes le résultat en pensant que ton IA t’a rendu service.

L’incident qui a mis tout le monde d’accord

Ce n’est pas une hypothèse de labo. C’est arrivé, à grande échelle, en avril 2026.

Le 15 avril, l’équipe de recherche d’OX Security publie un rapport au titre peu modeste, “The Mother of All AI Supply Chains”. Le constat est brutal : l’interface principale des SDK MCP officiels, celle qui fait dialoguer l’outil et le serveur en local, permet à une simple configuration de déclencher l’exécution de commandes système arbitraires. Sans validation des entrées, sans isolation par défaut.

Les chiffres donnent le vertige :

7 000 et plus serveurs MCP publics indexés
150 millions et plus de téléchargements des SDK et serveurs concernés
environ 200 000 instances estimées vulnérables
10 CVE émis, dont CVE-2026-30615 sur Windsurf : une injection de prompt via HTML malveillant menant à l’exécution de code en local, notée 8.0 sur 10 en sévérité

Côté Mac, ce ne sont pas des noms abstraits. Cursor, Windsurf et Claude Desktop utilisent ces SDK, et sont concrètement touchés par leurs intégrations MCP. Les chercheurs ont validé leurs attaques sur six plateformes en production. Ça marchait pour de vrai.

Et voilà le meilleur, ou le pire selon le côté où tu te trouves. La réponse d’Anthropic, telle que rapportée par OX Security et confirmée par plusieurs reprises, tient en deux mots : “by design”. Le comportement est jugé normal, à condition que l’utilisateur, ou le développeur en aval, fasse lui-même le travail de sécurisation. Anthropic refuse de modifier le protocole.

L’argument est défendable sur le papier. Un protocole n’est pas un bac à sable, et personne n’oblige un standard à border tous les usages. Sauf que dans les faits, Anthropic transfère la responsabilité du verrouillage à des gens qui n’ont jamais signé pour ça : le particulier qui installe Claude Desktop sans notion de sécurité, la PME qui branche un connecteur trouvé sur un dépôt public. Les correctifs viennent des outils en aval, Cursor, Windsurf et les autres, pas du protocole lui-même.

Traduction : le sandbox, c’est ton problème. Autant le savoir avant, pas après.

À lire : MCP d’Anthropic, un défaut de conception expose 200 000 instances, notre radar sur la faille et les CVE associés.

Durcir tes MCP sans renoncer au confort

Bonne nouvelle : tu n’as pas à choisir entre “IA branchée sur tout” et “IA débranchée et inutile”. Le curseur se règle. Voilà comment le mettre au bon endroit.

Avant de plonger dans les réglages, sache où ça se passe. Sur Claude Desktop, tes serveurs MCP se gèrent dans Réglages puis Développeur, et le bouton “Modifier la config” ouvre le fichier claude_desktop_config.json.

À l’ouverture, une config MCP ressemble à ça : quelques serveurs déclarés, chacun avec sa commande et ses accès. Rien de plus qu’un script qui attend son heure.

1. Inventorie tes serveurs MCP actifs. Sur Claude Desktop, va dans Réglages puis Développeur, et clique sur “Modifier la config” : ça ouvre ~/Library/Application Support/Claude/claude_desktop_config.json. Sur Cursor, va dans Réglages puis MCP. Sur Windsurf, la liste est accessible depuis l’IDE. Désactive tout serveur que tu n’as pas déployé toi-même ou dont tu n’as pas lu le code. Si tu ne sais plus pourquoi il est là, il ne devrait pas y être.

2. Applique le moindre privilège, sérieusement. Un serveur MCP filesystem ne doit jamais pointer sur / ni sur ~. Donne-lui le sous-dossier précis du projet en cours, rien de plus. Ton assistant n’a pas besoin d’un accès total à ton disque pour ranger trois captures d’écran.

3. Traite toute config tierce comme hostile par défaut. Un bout de config récupéré sur GitHub, un fichier partagé sur Slack, l’export d’un collègue, un dépôt cloné : lis la configuration intégralement avant de l’activer. Les chemins exécutables, les commandes, les variables d’environnement. Rappelle-toi que c’est un script shell déguisé. Personne ne lance un .sh inconnu sans le lire. Un .json de config MCP, c’est pareil.

4. Si tu es sur Claude Code, verrouille par la config, pas par la consigne. Tu peux écrire dans ton CLAUDE.md une règle du genre “n’active aucun serveur MCP sans mon accord”. Ça documente ton intention, mais ne te repose pas dessus : tu viens de lire pourquoi un modèle qu’on manipule n’obéit pas toujours aux consignes. La vraie serrure est dans ton settings.json. Tiens-y une liste blanche des outils MCP autorisés et refuse le reste avec permissions.deny, et laisse active la demande d’approbation pour tout serveur déclaré dans un .mcp.json de projet, ne l’auto-approuve jamais. Le CLAUDE.md rappelle la règle à l’humain, le settings.json l’impose à la machine.

5. Verrouille les serveurs qui écoutent le réseau. Certains MCP tournent comme un petit serveur HTTP local. Vérifie qu’il est lié à 127.0.0.1, jamais à 0.0.0.0. Sinon, une page web malveillante ouverte dans ton navigateur peut, dans le pire cas, déclencher une exécution sur ta machine.

~ % lsof -iTCP -sTCP:LISTEN -nP | grep node
node    41827 demo   23u  IPv4 0x9f3a5c  0t0  TCP 127.0.0.1:8787 (LISTEN)
node    41902 demo   25u  IPv4 0x9f3b1d  0t0  TCP *:8788 (LISTEN)

La première ligne est bien sagement sur 127.0.0.1. La seconde écoute sur *, donc sur toutes les interfaces : c’est celle que tu dois corriger.

6. Mets à jour les outils touchés. Cursor, Windsurf, Claude Desktop et les frameworks concernés ont publié des versions correctives à partir d’avril 2026. Vérifie dans les notes de version que la faille est explicitement traitée, pas juste “diverses améliorations de sécurité”.

7. Préfère le local au distant. Un serveur MCP qui tourne sur ta machine et n’expose rien au réseau est bien plus facile à raisonner qu’un connecteur distant hébergé chez un tiers. Chaque service extérieur ajouté à la boucle, c’est une entreprise de plus qui peut lire ce qui transite, ou se faire compromettre à ta place.

Et avant d’installer un nouveau serveur MCP tiers, pose-toi trois questions. Qui l’a écrit et le code est-il consultable ? De quels accès a-t-il réellement besoin, et est-ce que la config demande davantage ? Qu’est-ce qui se passe le jour où ce serveur est compromis ? Si tu ne peux pas répondre aux trois, ne l’installe pas.

En résumé

Les MCP sont ce qui rend ton assistant IA vraiment utile. Ils sont aussi ce qui le relie à tes fichiers, ta base, ton shell, avec tes droits et sans témoin. Le modèle décide, le serveur exécute, tu ne vois rien passer. C’est la définition d’une porte dérobée, et avril 2026 a prouvé qu’elle était grande ouverte pour environ 200 000 installations.

La souveraineté, ici, ne consiste pas à débrancher ton IA. Elle consiste à savoir ce qui est branché, à ne donner que le strict accès nécessaire, et à ne jamais charger une config que tu n’as pas lue. Un serveur MCP local, au périmètre serré, dont tu as lu le code, c’est un outil. Le même serveur, tiré d’un dépôt inconnu avec un accès à tout ton disque, c’est une faille avec une interface amicale.

Inventorie tes MCP. Coupe ceux que tu ne reconnais pas. Réduis les accès de ceux que tu gardes. Le reste, ce sont juste de bonnes habitudes que tu as déjà pour le reste de ta machine.

À lire aussi : Ton IA peut être éteinte par les US, monte la tienne et Apple Intelligence, ce qui sort vraiment de ton Mac.

Rspamd devant ta boîte mail, le phishing s'arrête au paillasson

Mac Souverain — Thu, 16 Jul 2026 14:03:38 GMT

À l’épisode précédent, tu as posé CrowdSec en première ligne. Ton pare-feu refoule désormais les IP malveillantes avant qu’elles ne touchent tes services, et chaque décision remonte dans Wazuh. Ton SIEM voit et il mord.

Sauf que l’attaque qui va te coûter cher n’arrivera pas par le port SSH.

Elle arrivera par un mail. Une fausse facture qui imite ton fournisseur habituel, un lien qui ressemble à ton portail bancaire, une pièce jointe que ta comptable ouvrira parce que c’est son travail d’ouvrir des PJ factures.

Ce mail-là traverse ton pare-feu sans un bruit, parce qu’il entre par une porte que tu as toi-même laissée ouverte, le port 25. CrowdSec ne bloquera rien, l’expéditeur a une IP propre. Wazuh ne verra rien, personne ne lui a dit de regarder de ce côté.

C’est l’angle mort du dispositif. Trois briques posées, et le vecteur d’intrusion numéro un des PME passe encore en clair.

Aujourd’hui, on le bouche. On installe Rspamd, un moteur de filtrage qui s’intercale devant ton serveur mail, note chaque message entrant et décide de son sort. Puis on branche sa journalisation sur Wazuh, pour que chaque verdict, spam bloqué, hameçonnage détecté, message livré, s’affiche dans ton tableau de bord unique.

Avant de commencer

Trois choses en tête avant la première commande.

Ce qu’il te faut. Un serveur mail que tu administres, Postfix ou Exim, sur un serveur durci comme celui de l’épisode 1. Le manager Wazuh de l’épisode 2 en place sur ton VPS, et l’agent Wazuh de l’épisode 3 déjà installé sur ce serveur mail, pour la partie intégration en fin de tuto. Un accès administrateur, et Redis, qu’on installera en même temps que le moteur.

Ce que ça change. À la fin, chaque message entrant est noté avant d’atteindre la boîte de ton salarié. Les évidences sont refusées à la porte, les douteux arrivent marqués, les tentatives d’hameçonnage lèvent une alerte dans ton SIEM. Tu passes d’une boîte mail aveugle à une boîte mail instrumentée.

Ce que ça ne change pas. Rspamd filtre le mail entrant. Ce n’est pas un antivirus de poste, ce n’est pas un remplaçant du bon sens de tes salariés, et ça ne protège pas contre un compte dont le mot de passe a fuité, l’attaquant est alors dedans, pas dehors. Et Rspamd n’est pas infaillible, il te trompera parfois. La question n’est pas s’il se trompe, c’est de quel côté tu règles le curseur quand il se trompe.

Rspamd ne dit pas oui ou non, il note

Le point qui change tout, et qui sépare Rspamd des filtres anti-spam classiques.

Un filtre binaire regarde un message et tranche, spam ou pas spam. Le résultat est une porte, ouverte ou fermée, et le monde réel se venge vite de cette simplification. Une facture légitime avec un lien raccourci et une pièce jointe se fait jeter, une arnaque bien écrite passe.

Rspamd, lui, accumule. Il fait tourner des dizaines de vérifications sur le même message, chacune rapportant un petit poids, positif ou négatif. L’authentification de l’expéditeur échoue, plus deux points. Le domaine est sur une liste noire réputée, plus quatre. L’URL affichée ne correspond pas à l’URL réelle du lien, plus sept. Le message ressemble à cent autres déjà signalés comme spam, plus cinq. À l’inverse, l’expéditeur est correctement signé et connu, moins un.

À la fin, il obtient un score, et ce score déclenche une action selon des seuils que tu fixes toi-même. La configuration recommandée est celle-ci.

Score 4, greylist. Le serveur expéditeur est prié de repasser plus tard. Un vrai serveur mail le fait, un robot de spam rarement.

Score 6, add header. Le message est livré, mais marqué. Ton client mail peut le ranger en indésirables.

Score 15, reject. Le message est refusé à la porte, il n’entre jamais.

Trois niveaux de fermeté, pas une porte. C’est la même philosophie que le SIEM de l’épisode 2, on ne cherche pas la certitude, on cherche à graduer sa réponse à un signal incertain.

Côté architecture, Rspamd tourne en plusieurs processus spécialisés. Le worker proxy est celui qui parle à ton serveur mail, en protocole milter, sur le port 11332. Le worker normal fait le calcul du score. Le worker controller sert l’interface web et l’apprentissage. Tu n’auras à connaître que le premier, c’est lui qu’on branche.

Étape 1, installer le moteur

Sur la machine qui héberge ton serveur mail. Le dépôt officiel Rspamd, puis le paquet, puis Redis, dont Rspamd a besoin pour ses statistiques, son filtre bayésien et son greylisting.

curl -fsSL https://rspamd.com/apt-stable/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] https://rspamd.com/apt-stable/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd redis-server

Le dépôt apt-stable est la branche de production, celle que tu veux sur un serveur mail. Rspamd est en version 4.x depuis mars 2026.

Dis-lui où trouver Redis, dans /etc/rspamd/local.d/redis.conf.

servers = "127.0.0.1:6379";

Une règle de survie avec Rspamd, et elle vaut pour tout le tuto. Tu ne touches jamais aux fichiers de /etc/rspamd/ directement. Tu écris tes réglages dans /etc/rspamd/local.d/, qui vient s’ajouter par-dessus la configuration par défaut. Une mise à jour du paquet écrase la première, jamais la seconde.

Fixe ensuite un mot de passe pour l’interface web.

rspamadm pw

Il te sort une empreinte que tu recopies dans /etc/rspamd/local.d/worker-controller.inc.

password = "$2$ton_empreinte_ici";

L’interface écoute sur le port 11334, en local uniquement. Laisse-la comme ça. Doctrine de la série depuis l’épisode 1, rien d’inutile sur l’internet ouvert, tu y accèdes par ton Tailnet ou un tunnel SSH.

Étape 2, le brancher devant ton serveur mail

Rspamd tourne, mais aucun message ne lui est présenté. Il faut que ton serveur mail lui soumette chaque courrier entrant avant de l’accepter.

Le mécanisme s’appelle milter, pour mail filter. Ton serveur mail met le message en pause pendant la transaction SMTP, le tend à Rspamd, attend le verdict, et agit en conséquence. Le message est jugé avant d’être accepté, c’est toute la différence avec un filtre qui trie après coup dans la boîte.

Sur Postfix, trois lignes dans /etc/postfix/main.cf.

smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept

La ligne qui mérite ton attention, c’est la troisième. accept veut dire que si Rspamd est en panne, le courrier passe sans filtrage. Tu privilégies la continuité du service. L’autre valeur couramment retenue est tempfail, qui demande à l’expéditeur de repasser plus tard, ton mail est protégé même Rspamd à terre, mais une panne prolongée devient un incident de messagerie. Choisis en connaissance de cause. Pour une PME, accept est le défaut raisonnable, à condition de surveiller le service Rspamd dans ton SIEM.

Sur Exim, le branchement passe par le worker normal en HTTP, pas par le milter.

spamd_address = 127.0.0.1 11333 variant=rspamd

Recharge ton serveur mail, et envoie-toi un message depuis une adresse extérieure. Rspamd commence à noter.

Étape 3, régler les seuils et armer l’anti-hameçonnage

Les seuils d’abord, dans /etc/rspamd/local.d/actions.conf.

greylist = 4;
add_header = 6;
reject = 15;

Ce sont les valeurs recommandées, et elles sont volontairement clémentes. Un reject à 15 signifie qu’il faut une accumulation massive de signaux négatifs pour qu’un message soit refusé. C’est ce que tu veux au démarrage, on durcit plus tard, une fois qu’on a lu ses propres journaux.

L’authentification de l’expéditeur ensuite. Trois modules actifs par défaut, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance). Ils vérifient trois choses, que le serveur émetteur a le droit d’envoyer pour ce domaine, que la signature cryptographique du message est valide, et que le domaine affiché dans le champ « De » est bien celui qui est authentifié. Un mail qui prétend venir de ta banque et qui échoue aux trois est démasqué sans avoir besoin de lire une seule ligne de son contenu.

Par défaut, Rspamd note ces échecs mais n’applique pas la politique publiée par le domaine expéditeur. Pour qu’il l’applique, dans /etc/rspamd/local.d/dmarc.conf.

actions {
  quarantine = "add header";
  reject = "reject";
}

Tu obéis désormais à ce que le vrai propriétaire du domaine a demandé au monde de faire des messages qui usurpent son identité. C’est gratuit, c’est immédiat, et ça élimine une famille entière de faux expéditeurs.

Le module phishing enfin, le cœur du sujet. Sa vérification de base est déjà active, il compare l’URL affichée dans le texte du lien à l’URL réelle de destination, et lève le symbole PHISHED_URL quand les deux domaines divergent. C’est exactement le mécanisme du faux lien bancaire.

Tu peux l’adosser à deux bases publiques d’URL de hameçonnage connues, dans /etc/rspamd/local.d/phishing.conf.

openphish_enabled = true;
openphish_map = "https://raw.githubusercontent.com/openphish/public_feed/refs/heads/main/feed.txt";
phishtank_enabled = true;

Pas de bloc phishing { } autour, et c’est la règle local.d de l’étape 1 qui joue. Rspamd inclut déjà ce fichier à l’intérieur de la section du module, tu n’écris que le contenu. Ajoute le bloc, et tu obtiens une section dans une section, silencieusement ignorée, aucune erreur au démarrage et aucun flux activé.

Le message qui contient une URL déjà signalée ailleurs dans le monde lève PHISHED_OPENPHISH ou PHISHED_PHISHTANK, avec un poids lourd. La logique communautaire de CrowdSec, transposée aux liens malveillants.

Trois autres modules travaillent pour toi sans que tu les configures. rbl interroge les listes noires publiques de serveurs d’envoi. fuzzy_check compare l’empreinte du message à celle de spams déjà signalés par le réseau Rspamd, un spam reformulé garde une empreinte proche. bayes apprend de tes propres messages, à condition de l’entraîner.

autolearn = true;

dans /etc/rspamd/local.d/classifier-bayes.conf, et Rspamd apprend seul des messages qu’il a classés avec certitude. Tu peux aussi le corriger à la main quand il se trompe, avec rspamc learn_spam sur un message passé au travers, ou rspamc learn_ham sur un légitime qu’il a marqué à tort.

Étape 4, le mettre à l’épreuve

Plutôt qu’attendre un vrai spam, tu en fabriques un.

Il existe pour ça une chaîne de caractères standard, le GTUBE, reconnue par tous les moteurs anti-spam sérieux et conçue pour déclencher un rejet certain sans être un vrai spam. Tu l’écris dans un message de test, et tu le soumets au moteur avec rspamc, le client en ligne de commande.

printf 'Subject: test\n\nXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X\n' > /tmp/gtube.eml
rspamc symbols /tmp/gtube.eml

Tu dois voir le symbole GTUBE et l’action reject. Le GTUBE court-circuite le calcul du score et force le rejet directement, c’est tout l’intérêt du test. Si tu l’obtiens, le moteur tourne, il note et il tranche. Tu obtiens quelque chose comme ceci.

Results for file: /tmp/gtube.eml (0.014 seconds)
[Metric: default]
Action: reject
Spam: true
Symbol: GTUBE (0.00)
Message-ID: undef

Pas besoin d’un score qui crève le seuil, le symbole GTUBE déclenche un passthrough qui impose l’action reject quel que soit le total. C’est le comportement attendu, ton moteur applique bien le verdict.

Deux commandes de contrôle pour la suite.

rspamc stat

Elle te donne l’état du moteur, les messages scannés, la répartition par action, l’état du filtre bayésien.

rspamc symbols /chemin/vers/un/vrai/message.eml

Elle rejoue un vrai message et t’affiche le détail des symboles avec leur poids. C’est ton outil de diagnostic quand un message est passé alors qu’il n’aurait pas dû, ou l’inverse. Tu ne devines pas, tu lis la ligne de compte.

Étape 5, faire remonter Rspamd dans Wazuh

Rspamd filtre, très bien. Ton SIEM ne le sait toujours pas. On les branche, et la boucle de la série se referme sur le mail.

Rien à activer côté Rspamd. Il écrit déjà, par défaut, une ligne par message traité dans /var/log/rspamd/rspamd.log. Un fichier persistant, sur disque, exactement ce dont Wazuh a besoin. Une ligne ressemble à ceci.

2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22

Tout y est. L’IP de l’expéditeur, son adresse, l’action retenue, le score obtenu face au seuil, et la liste complète des symboles qui l’ont fait tomber. C’est un rapport d’enquête par message.

Le branchement se fait sur deux machines, et c’est le point où on se plante si on va vite. L’agent Wazuh, sur ton serveur mail, ne comprend rien à ce qu’il lit, il expédie les lignes brutes. C’est le manager, sur le VPS de l’épisode 2, qui décode et applique les règles. Une machine ramasse, l’autre comprend.

Sur le serveur mail, tu dis à l’agent de lire le fichier. Le bloc va dans son ossec.conf.

<localfile>
  <location>/var/log/rspamd/rspamd.log</location>
  <log_format>syslog</log_format>
</localfile>

Tu reconnais le <localfile> de l’épisode 3, le mécanisme par lequel Wazuh avale n’importe quelle source de journaux.

Sur le manager, maintenant, et sur lui seul. Un décodeur extrait les champs utiles de la ligne, dans /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="rspamd">
  <prematch>rspamd_task_write_log: </prematch>
</decoder>

<decoder name="rspamd-verdict">
  <parent>rspamd</parent>
  <regex type="pcre2">ip: (\S+?), .*?\(default: \S+ \(([\w ]+)\): \[(-?\d+\.\d+)/</regex>
  <order>srcip, rspamd_action, rspamd_score</order>
</decoder>

Puis des règles qui transforment ces champs en alertes graduées, dans /var/ossec/etc/rules/local_rules.xml, toujours sur le manager.

<group name="rspamd,">
  <rule id="100400" level="0">
    <decoded_as>rspamd</decoded_as>
    <description>Rspamd, verdict de scan.</description>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <match>PHISHED_</match>
    <description>Rspamd, hameçonnage détecté, expéditeur $(srcip).</description>
  </rule>

  <rule id="100402" level="10">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^reject$</field>
    <description>Rspamd, message rejeté, expéditeur $(srcip).</description>
  </rule>

  <rule id="100403" level="5">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^add header$</field>
    <description>Rspamd, message marqué spam et livré, expéditeur $(srcip).</description>
  </rule>
</group>

L’ordre de déclaration n’est pas cosmétique, il est le cœur du réglage. La règle mère est en niveau 0, elle décode sans alerter, sinon ton tableau de bord se noie sous les messages légitimes. L’hameçonnage passe en premier, en niveau 12, parce que Wazuh ne déclenche qu’une seule règle par message, la première de la liste qui correspond. Une fausse facture d’hameçonnage est aussi un message rejeté, et si tu déclares le rejet avant elle, elle sort en niveau 10 et l’alerte que tu attendais ne vient jamais. Puis le rejet en 10, et le spam marqué mais livré en 5.

Même logique sur l’ancrage. ^reject$ et non reject, parce que Rspamd possède aussi une action soft reject, un simple report temporaire, qui contient le mot et déclencherait une alerte de rejet pour un message qui n’a rien de rejeté.

Ne crois pas ce décodeur sur parole, teste-le. Wazuh a l’outil qu’il faut, et il vit sur le manager, pas sur l’agent.

sudo /var/ossec/bin/wazuh-logtest

Tu colles une vraie ligne de ton rspamd.log, et il te montre ce qu’il en a compris, phase par phase, décodeur reconnu, champs extraits, règle déclenchée. Si srcip et rspamd_action ne sortent pas, c’est le motif d’extraction qu’il faut ajuster, et tu le sauras en trente secondes au lieu d’attendre en vain une alerte qui ne viendra jamais. Prends une ligne d’hameçonnage rejeté pour ton test, c’est le cas qui met à l’épreuve l’ordre de tes règles. Sur la ligne d’exemple plus haut, tu vises un résultat de cette forme.

**Phase 1: Completed pre-decoding.
	full event: '2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22'

**Phase 2: Completed decoding.
	name: 'rspamd'
	srcip: '203.0.113.42'
	rspamd_action: 'reject'
	rspamd_score: '16.40'

**Phase 3: Completed filtering (rules).
	id: '100401'
	level: '12'
	description: 'Rspamd, hameçonnage détecté, expéditeur 203.0.113.42.'
	groups: '['rspamd']'
	firedtimes: 1
	mail: false
**Alert to be generated.

La phase 2 sort tes trois champs, la phase 3 déclenche la règle 100401 en niveau 12, c’est l’alerte d’hameçonnage que tu attendais. Ne prends pas ce bloc pour une capture arrachée à une machine de production, c’est le résultat visé, pas un relevé de prod. Le pré-décodage syslog posé sur une ligne Rspamd qui n’a pas la forme d’un log syslog, et le motif d’extraction du décodeur, peuvent varier selon ta version de Wazuh et le format exact de tes lignes rspamd.log. C’est précisément ce que wazuh-logtest te confirme chez toi, phase par phase, avant que tu comptes sur l’alerte.

Une fois le test concluant, redémarre les deux services, chacun sur sa machine. Le manager, pour qu’il charge ton décodeur et tes règles.

sudo systemctl restart wazuh-manager

Et l’agent du serveur mail, pour qu’il prenne en compte son <localfile>.

sudo systemctl restart wazuh-agent

Une IP envoie une fausse facture, Rspamd la note, la rejette, l’écrit dans son journal, l’agent Wazuh la lit et l’expédie, le manager la décode et lève une alerte de niveau 12, elle s’affiche dans ton tableau de bord à côté de tes blocages CrowdSec et de tes échecs d’authentification SSH. Dans Discover, tu la filtres sur les champs srcip, rspamd_action et rspamd_score, exactement comme le reste de tes événements.

L’angle mort est bouché.

Si ça ne marche pas

Problème, Rspamd tourne mais aucun message n’est noté

Cause probable, le milter n’est pas branché. Rspamd attend sur son port, ton serveur mail ne lui présente rien.

Solution, vérifie que le worker proxy écoute bien sur 11332, et que smtpd_milters pointe dessus dans ta configuration Postfix. Recharge le serveur mail, pas seulement Rspamd.

Problème, des messages légitimes sont rejetés

Cause probable, ton seuil de rejet est trop bas, ou un expéditeur que tu connais échoue à son propre SPF, ce qui arrive plus souvent qu’on ne le croit.

Solution, rejoue le message avec rspamc symbols, lis les symboles qui l’ont fait monter. Si le coupable est un symbole unique et légitime, remonte ton seuil de reject plutôt que de désactiver le module.

Problème, le score n’apprend rien, le filtre bayésien reste muet

Cause probable, Redis n’est pas joignable. Sans lui, ni bayes, ni greylisting, ni statistiques.

Solution, vérifie le service Redis et le contenu de /etc/rspamd/local.d/redis.conf. rspamc stat te dira si le classifieur a des données.

Problème, rien ne remonte dans Wazuh

Cause probable, trois suspects, et il faut les départager avant de toucher à quoi que ce soit. Soit le fichier ne grossit pas, soit l’agent ne le lit pas, soit le manager ne sait pas le décoder. Le grand classique, ce sont le décodeur et les règles édités sur le serveur mail au lieu du manager. Ils n’y servent à rien.

Solution, le fichier grossit-il ? S’il grossit, va sur le manager, passe une ligne dans wazuh-logtest et regarde à quelle phase ça casse. Vérifie au passage que local_decoder.xml et local_rules.xml sont bien sur cette machine-là, et que tu as redémarré wazuh-manager après les avoir écrits. Ne réinstalle pas Rspamd pour un souci de motif d’extraction.

Ce que ça t’a coûté

La licence, rien. Rspamd est open source, sans version payante, sans palier entreprise, sans quota de messages.

La machine, peu. Le moteur est écrit en C et tourne sur ton serveur mail existant, aux côtés de Redis. Sur le volume d’une PME, tu ne changeras pas de gabarit de serveur pour ça. Surveille quand même ta RAM après avoir activé le filtre bayésien et fuzzy_check, ce sont eux qui consomment.

Ton temps, un peu. Compte une petite heure pour l’installation, le milter et l’intégration Wazuh.

Et le vrai prix, la calibration. Il ne se paye pas le jour de l’installation, il se paye les deux semaines suivantes, à lire tes propres journaux et à remonter tes seuils quand un message légitime s’est fait jeter. Un anti-spam mal réglé ne te coûte pas de la RAM, il te coûte une commande client perdue dans un rejet silencieux. C’est la raison pour laquelle ce tuto te fait démarrer clément, à 15 de seuil de rejet, et durcir ensuite. Dans l’autre sens, tu apprends la valeur d’un faux positif à tes dépens.

C’est le seul poste de dépense sérieux, et aucun SaaS ne te l’épargne. Lui aussi se trompera, simplement tu ne verras pas pourquoi.

Pour les pressés

Ce que fait cet article. On installe Rspamd sur le serveur mail, on le branche en milter devant Postfix, on règle les seuils de scoring, on active l’anti-hameçonnage et l’application des politiques DMARC, puis on fait remonter chaque verdict dans Wazuh via un décodeur et des règles maison. La couche mail cesse d’être l’angle mort du SIEM.

Concrètement, les commandes.

Installer le dépôt stable, rspamd et redis-server via apt.
Pointer Redis : servers = "127.0.0.1:6379"; dans /etc/rspamd/local.d/redis.conf.
Mot de passe de l’interface : rspamadm pw, empreinte dans /etc/rspamd/local.d/worker-controller.inc. Interface en local uniquement.
Brancher le milter Postfix : smtpd_milters = inet:localhost:11332, milter_protocol = 6, milter_default_action = accept dans main.cf.
Seuils : greylist = 4; add_header = 6; reject = 15; dans /etc/rspamd/local.d/actions.conf.
Appliquer DMARC : bloc actions { quarantine = "add header"; reject = "reject"; } dans /etc/rspamd/local.d/dmarc.conf.
Anti-hameçonnage : openphish_enabled et phishtank_enabled dans /etc/rspamd/local.d/phishing.conf.
Apprentissage : autolearn = true; dans /etc/rspamd/local.d/classifier-bayes.conf.
Tester : message GTUBE puis rspamc symbols /tmp/gtube.eml, action attendue reject.
Intégrer à Wazuh, sur deux machines : <localfile> sur /var/log/rspamd/rspamd.log côté agent, décodeur et règles côté manager (local_decoder.xml et local_rules.xml, règle hameçonnage déclarée en premier), validation avec /var/ossec/bin/wazuh-logtest sur le manager, puis redémarrage de wazuh-manager et de wazuh-agent.

En résumé

Tu es parti d’un dispositif qui voyait tes serveurs et bloquait ton réseau, mais laissait entrer la fausse facture par la grande porte.

Tu as installé Rspamd devant ton serveur mail, en milter, pour que chaque message soit jugé avant d’être accepté. Tu as réglé le scoring plutôt qu’un verdict binaire, trois niveaux de fermeté, greylist, marquage, rejet, avec des seuils que tu maîtrises.

Tu as armé l’anti-hameçonnage, comparaison des URL affichées et réelles, bases publiques de liens malveillants, application des politiques DMARC des domaines usurpés. Et tu as branché tout ça sur Wazuh, décodeur et règles graduées, pour qu’une tentative de hameçonnage lève une alerte de niveau 12 dans le même tableau de bord que le reste.

Le tout reste chez toi. Aucun message ne quitte ton serveur pour être analysé ailleurs, aucun prestataire ne lit ton courrier pour te dire s’il est propre. C’est la différence entre un filtre que tu héberges et une passerelle mail dans le cloud de quelqu’un d’autre, à qui tu confies l’intégralité de ta correspondance d’entreprise pour qu’il la protège.

Il reste une porte d’entrée, et c’est celle qui tient dans les mains de tes salariés. Le fichier qu’on a téléchargé sans réfléchir, la macro qu’on a autorisée, le binaire qui n’aurait jamais dû démarrer. À l’épisode 6 on descend sur les Mac, et on règle le problème en décidant quelles applications ont le droit de s’exécuter.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie. Tu viens de le lire.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Un malware notarisé Apple passe Gatekeeper

Mac Souverain — Thu, 16 Jul 2026 13:56:37 GMT

CrashStealer, un infostealer macOS déguisé en outil de rapport de crash Apple, franchit Gatekeeper sans la moindre alerte. Il est signé par un Developer ID valide et notarisé par Apple. Ton Mac fait confiance à la signature, pas à l'intention derrière. Apple a révoqué le certificat après coup, une fois les dégâts faits.

Ce que tu dois faire

1. Toute app ou DMG hors App Store reçu par invitation ou lien direct, la signature Apple ne rachète pas la provenance.

2. Un prompt qui réclame ton mot de passe login « pour continuer » sans installation légitime en cours, c'est un signal d'alerte.

3. Les connexions sortantes inattendues, un pare-feu applicatif comme Little Snitch ou LuLu les voit passer.

Un logiciel malveillant se déguise en outil de rapport de crash Apple. Il est signé par un Developer ID valide et notarisé par Apple elle-même. Résultat, il franchit Gatekeeper sans le moindre avertissement, parce que ton Mac vérifie la signature, jamais l’intention.

Le fait

Jamf Threat Labs a repéré un échantillon suspect sur VirusTotal début mai 2026, puis observé de vraies infections sur des Macs clients début juillet. Le malware s’appelle CrashStealer. Particularité rare, il est écrit en C++ natif, là où l’immense majorité des voleurs macOS bricolent en AppleScript. Il se fait passer pour un outil de rapport de crash Apple, le genre de fenêtre que tu as déjà vue cent fois sans y prêter attention.

La livraison est soignée. Le malware arrive dans un disque image nommé « Werkbit », l’app à l’intérieur s’appelle « Werkbit.app ». Fait notable, le DMG lui-même est signé, pas seulement l’app qu’il contient. Le certificat, un Developer ID au nom de « Emil Grigorov » (WWB7JA7AQV), valide, actif, notarisé par Apple. Le domaine de diffusion, werkbit[.]io, a été enregistré en juin 2026, et le téléchargement est verrouillé derrière un code PIN de réunion. Traduction, l’installeur n’est servi qu’à des victimes choisies, jamais aux scanners automatiques ni au visiteur de passage.

Une fois lancé, le dropper récupère la vraie charge depuis l’infrastructure de l’attaquant. Avant de récolter quoi que ce soit, il te présente un faux prompt système et valide ton mot de passe de session en local. Ensuite, il vide tout, les profils de navigateurs, le Trousseau, quatorze gestionnaires de mots de passe (1Password, Bitwarden, LastPass, Dashlane, Keeper compris) et près de quatre-vingts extensions de portefeuilles crypto. Le butin est chiffré en AES-GCM puis exfiltré via libcurl. Il se recopie et se re-signe pour persister.

Apple a révoqué le certificat de signature après le signalement de Jamf. Le mal était déjà fait pour ceux qui avaient cliqué.

Pourquoi Gatekeeper n’a rien vu

Voici le nœud. La notarisation Apple n’est pas un audit de sécurité. C’est un scan automatisé qui cherche des signatures de malware déjà connu et vérifie que le binaire est signé par un Developer ID valide. Rien de plus. Apple n’a pas lu le code de CrashStealer, elle n’a pas jugé ses intentions, elle a passé un binaire propre au moment du scan à travers une moulinette qui ne voyait rien de familier.

Le tampon de notarisation dit une seule chose, « ce fichier est signé par un développeur identifié et ne correspond à aucun malware connu ». Il ne dit pas « ce logiciel est sûr ». La nuance a l’air théorique. Elle est le sujet.

Un attaquant qui ouvre un compte Apple Developer à 99 dollars par an, sous une identité crédible, obtient un passe pour franchir Gatekeeper en silence. Le kill-switch d’Apple, la révocation du certificat, ne joue qu’après coup, une fois les dégâts documentés. Apple pousse ses défenses en silence, elle ne prévient pas quand elle a laissé passer. C’est un pompier, pas un vigile.

À lire : Ton Mac a été patché par XProtect à ton insu

Ce que ça change pour toi

Le réflexe collectif, « c’est signé Apple, donc c’est bon », vient de prendre une balle. Ton Mac fait confiance à la signature, pas à l’intention derrière. Un binaire notarisé n’est pas un binaire béni. C’est un binaire dont on connaît l’auteur déclaré, ce qui est utile pour le poursuivre après coup, inutile pour t’éviter l’infection.

Le ciblage par PIN de réunion change aussi la donne. Ce malware ne se pêche pas au chalut sur un forum de warez. Il arrive par invitation, dans un contexte qui a l’air professionnel, servi à toi et pas à un scanner. Le vieux réflexe « je ne télécharge que des trucs connus » ne suffit plus quand le lien t’est tendu à la main.

La vraie ligne de défense, ce n’est pas le tampon Apple. C’est toi, ta méfiance, et un outil qui voit ce que le logiciel fait vraiment une fois lancé, ses connexions sortantes.

Ce que tu fais maintenant

1. Traite toute app ou tout DMG reçu hors App Store comme suspect par défaut, surtout quand il arrive par invitation, lien direct ou message « installe ça pour la réunion ». La signature Apple ne rachète pas une provenance douteuse. Si tu ne l’as pas cherché toi-même, tu ne l’installes pas.

2. Un vrai prompt système macOS ne te redemande pas ton mot de passe admin sans raison claire. Une app fraîchement lancée qui réclame ton mot de passe login « pour continuer », sans installation légitime en cours, c’est un signal d’alerte, pas une formalité. Tu fermes, tu ne tapes rien.

3. Installe un pare-feu applicatif et laisse-le parler. Little Snitch ou LuLu te montrent les connexions sortantes inattendues, exactement le moment où un stealer part exfiltrer ton butin. C’est ta caméra de surveillance sur ce que le système fait dans ton dos.

À lire : Little Snitch vs LuLu, quel pare-feu sortant pour ton Mac

Et si tu as le moindre doute d’avoir exécuté un installeur douteux récemment, la marche à suivre existe déjà, elle est la même que pour les infostealers distribués par ingénierie sociale.

À lire : Google Ads et vrai chat Claude partagé vident tes credentials

Sources

Chat Control 1.0 : adopté par ceux qui ont voté contre

Mac Souverain — Sun, 12 Jul 2026 09:33:42 GMT

Le 9 juillet 2026, le Parlement européen a laissé passer la reconduction de Chat Control 1.0 (scanning VOLONTAIRE du CSAM, règlement UE 2021/1232). Pas par un vote pour : 314 voix contre, 276 pour, mais rejeter la position du Conseil exigeait 361 voix. La majorité a voté non, le texte passe quand même. Le chiffrement de bout en bout est explicitement exclu de ce texte. Le vrai combat, Chat Control 2.0 (CSAR), reprend en septembre.

Ce que tu dois surveiller

1. Le CSAR (Chat Control 2.0), le scanning OBLIGATOIRE potentiellement côté client sur l’E2E, qui repart en trilogue en septembre 2026. C’est le seul rendez-vous qui compte.

2. La méthode : un texte rejeté par la majorité des votants qui passe faute de majorité absolue pour le bloquer. Retiens le mécanisme, il resservira.

3. Les posts viraux qui prétendent que WhatsApp et Signal sont désormais scannés. C’est faux pour le 1.0, l’E2E en est exclu. Ne relaie pas la panique.

Ce qui s’est passé le 9 juillet

Le 9 juillet 2026, le Parlement européen a acté la reconduction de Chat Control 1.0, c’est-à-dire le règlement (UE) 2021/1232 : une dérogation à la directive ePrivacy qui autorise les fournisseurs à scanner volontairement les communications à la recherche de contenus pédocriminels (CSAM). Ce texte avait expiré le 3 avril 2026. Il est reconduit, en vigueur jusqu’au 3 avril 2028.

Le détail qui compte : il n’a pas été adopté par un vote pour. Le décompte est de 314 voix contre, 276 pour, 17 abstentions. La majorité des votants a dit non. Sauf que pour rejeter la position du Conseil, il fallait une majorité absolue de 361 voix, manquée de 47. Résultat : le texte passe faute de blocage. Patrick Breyer parle d’une farce démocratique, et sur ce point précis il est difficile de lui donner tort.

Deuxième détail, dénoncé par plusieurs eurodéputés : le dossier a été reprogrammé au tout début des vacances parlementaires, quand l’hémicycle est clairsemé. Un classique du calendrier, mais un classique efficace.

Débunk express

Trois contre-vérités tournent en boucle depuis le 9 juillet. Voici la réalité en face.

« Le Parlement a voté POUR Chat Control. » Faux. 314 ont voté contre, 276 pour : la majorité a voté non. Le texte passe parce que le seuil pour le bloquer, 361 voix, n’a pas été atteint, pas parce qu’il a été approuvé.

« WhatsApp, Signal, iMessage vont être scannés. » Faux. Un amendement Renew adopté le même jour exclut explicitement le chiffrement de bout en bout du champ de ce texte. Le 1.0 reste du scanning volontaire, hors E2E.

« C’est le grand Chat Control obligatoire qui vient de passer. » Faux. Le texte du 9 juillet, c’est le 1.0 volontaire. Le scanning obligatoire, potentiellement côté client sur l’E2E, c’est le CSAR (Chat Control 2.0), toujours en trilogue, reprise en septembre.

Deux textes, deux histoires. Le 1.0 est volontaire et exclut l’E2E. Le 2.0 est le vrai danger, et il n’est pas encore tranché.

Pourquoi ça te concerne

Sur ton Mac et ton iPhone, le 1.0 ne change rien aujourd’hui : ton iMessage, ton WhatsApp, ton Signal restent chiffrés de bout en bout, explicitement hors du périmètre de ce texte. Ne laisse personne te vendre une panique produit qui n’existe pas.

Sauf que ce texte ne se limite pas aux messageries. Il couvre aussi les emails, et là, la nuance change tout : un email classique (Gmail, Outlook, iCloud Mail) n’est pas chiffré de bout en bout. Il reste donc pleinement dans le champ du scan volontaire que le 1.0 prolonge.

Google et les autres peuvent scanner le contenu de tes mails à la recherche de CSAM, et l’exclusion E2E ne te protège pas, puisqu’il n’y a pas d’E2E à protéger. Seule une messagerie réellement chiffrée de bout en bout, comme Proton Mail, passe entre les mailles.

Mesure bien ce que cela veut dire. C’est comme si la Police lisait ton courrier alors que tu n’as rien à te reprocher. C’est digne de la STASI !

Le vrai risque porte un autre nom : le client-side scanning du CSAR 2.0. C’est le principe d’inspecter tes messages sur ton appareil, avant qu’ils soient chiffrés. La crypto n’est pas cassée, elle est vidée de son sens : ton message est lu en clair sur ton téléphone avant de partir. Et ce point d’inspection, une fois posé, n’appartient plus jamais qu’aux « gentils ».

Ce n’est pas de la science-fiction côté Apple. En 2021, Apple a annoncé NeuralHash, un système de scan CSAM côté client sur iPhone, avant de l’abandonner en décembre 2022 sous la pression. Le code existe, la logique aussi.

Un CSAR contraignant, c’est exactement le levier qui rouvrirait ce dossier, cette fois par la loi et non par choix. La plainte du West Virginia contre Apple en février 2026 montre que la pression judiciaire sur le sujet ne retombe pas.

Ce que tu peux faire

Rien à installer, rien à corriger sur ton appareil : le 1.0 n’ouvre aucune faille produit. C’est un signal politique, et une leçon de méthode : un texte rejeté par la majorité des votants peut passer quand même quand le seuil de blocage n’est pas atteint. Retiens le mécanisme, parce qu’il resservira en septembre.

Le rendez-vous, c’est le CSAR à la reprise de septembre 2026. Cinq rounds de trilogue sans accord, le dernier le 29 juin, et la ligne de fracture reste le chiffrement.

Garde Signal en messagerie de repli, suis EDRi et Patrick Breyer pour l’issue réelle, et écris à ton eurodéputé avant que le 2.0 ne revienne sur la table. La pression publique a déjà déplacé des lignes sur ce dossier, elle peut recommencer.

Pour creuser : Chat Control 2.0, le mécanisme complet · NIS2 contre CSAR, quand l’UE se contredit · La convergence mondiale des textes anti-privacy

CrowdSec en première ligne, bloque avant qu'on te frappe

Mac Souverain — Wed, 08 Jul 2026 06:00:00 GMT

À l’épisode précédent, tu as enrôlé les agents Wazuh sur tout ton parc. Serveurs Linux, Mac, Windows, chaque machine remonte ses journaux au manager, entièrement par le Tailnet. Ton SIEM a levé le nez de ses propres journaux, ton parc entier s’affiche devant lui. Il voit tout, en réalité. Y compris les attaques.

Et c’est là que le bât blesse. Un agent Wazuh observe, on l’a répété tout l’épisode 3. Il te dit qu’une rafale d’échecs de connexion vient de frapper ton serveur, il te le dit très bien, très vite, très en détail. Mais il ne fait rien pour l’arrêter. Tu as des yeux, tu n’as pas de mains.

Aujourd’hui, on te donne les mains. On installe CrowdSec, la première ligne de défense active de la série. Un moteur qui lit tes journaux comme Wazuh, mais qui, lui, en tire une conclusion et bloque. L’IP qui martèle ton SSH, il la met dehors. L’attaquant déjà repéré ailleurs sur le réseau communautaire, il le refoule avant même qu’il ne toque à ta porte.

Un point posé dès l’épisode 1 et qui tient toujours. La quasi-totalité de tes services vit en Tailnet-only, invisible depuis l’internet ouvert. Mais certaines portes doivent rester ouvertes sur le monde, un serveur mail qui reçoit sur le port 25, une présence web publique. Ce sont ces portes-là, les seules exposées, que CrowdSec garde.

Cette stack, je l’utilise au quotidien. Les commandes qui suivent sont celles que tu vas taper toi-même, dans l’ordre, sur ton VPS durci puis dans ton manager Wazuh.

Avant de commencer

Trois choses à avoir en tête avant la première commande.

Ce qu’il te faut. Un VPS durci comme celui de l’épisode 1, à jour, avec au moins un service exposé sur l’internet ouvert à protéger. Le manager Wazuh de l’épisode 2, opérationnel, pour la partie intégration en fin de tuto. Un accès administrateur sur la machine. Et de quoi lire tes propres journaux, /var/log/auth.log et les logs de tes services, puisque c’est la matière première de CrowdSec.

Ce que ça change. À la fin, les IP malveillantes connues n’atteignent plus tes services, elles butent sur ton pare-feu avant. Tu bénéficies aussi de la liste communautaire, des millions de signaux remontés par les autres utilisateurs, donc tu bloques des attaquants que tu n’as jamais vus toi-même. Et ton SIEM voit enfin cette couche de défense, chaque blocage remonte dans Wazuh.

Ce que ça ne change pas. CrowdSec bloque au niveau réseau, sur l’adresse IP. Ce n’est ni un antivirus, ni un pare-feu applicatif exhaustif, ni un remplaçant de ton durcissement de l’épisode 1. C’est une couche de plus, la première que rencontre l’attaquant, pas la seule. Et il bloque l’IP, pas l’humain derrière, une IP change, la défense se joue sur le volume et la vitesse, pas sur l’infaillibilité.

Comment CrowdSec voit et bloque

Avant d’installer quoi que ce soit, comprends la mécanique, elle tient en trois pièces qui se passent le relais.

Le moteur de sécurité, l’agent local. Il lit tes journaux en continu, auth.log, les logs de ton serveur web, de ton serveur mail. Il les passe dans des scénarios, des règles de comportement du type « six échecs SSH en dix secondes depuis la même IP, c’est du bruteforce ». Quand un scénario se déclenche, le moteur prend une décision, en clair, il inscrit cette IP sur une liste noire pour une durée donnée, quatre heures par défaut sur du bruteforce.

Le bouncer, l’exécuteur. Le moteur décide, mais il ne touche pas lui-même à ton pare-feu, c’est un choix d’architecture propre. C’est le bouncer qui applique la décision. Le bouncer firewall, celui qui nous intéresse, va poser la règle qui jette l’IP fautive dans ton nftables ou ton iptables. Moteur et bouncer sont séparés, tu peux en avoir plusieurs, un pour le pare-feu, un devant un reverse proxy web, chacun applique les mêmes décisions à son niveau.

Le réseau communautaire, le CTI, pour Cyber Threat Intelligence, renseignement sur les menaces. C’est le multiplicateur. Quand ton moteur bloque une IP, il remonte le signal, l’adresse et le scénario, à l’API centrale de CrowdSec. En échange, tu télécharges la liste communautaire, l’agrégat des IP signalées par l’ensemble des utilisateurs. Résultat, une IP qui a attaqué un serveur en Pologne ce matin est déjà bloquée chez toi cet après-midi, avant sa première tentative.

Retiens le flux, il commande tout le reste. Journal lu par le moteur, scénario déclenché, décision prise, bouncer qui l’applique sur le pare-feu, signal partagé, liste communautaire téléchargée en retour.

Étape 1, installer le moteur

On commence par le cerveau, sur ton VPS durci. Deux commandes, une pour déclarer le dépôt officiel CrowdSec, une pour installer.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

La première ligne ajoute le dépôt CrowdSec à ta liste de sources, la routine que tu connais depuis l’épisode 3 avec Wazuh. La seconde installe et démarre le moteur.

L’installation est maligne sur un point. À la fin, CrowdSec scanne les services qu’il détecte sur ta machine et installe automatiquement les collections correspondantes, les paquets de scénarios adaptés. Il voit un serveur SSH, il installe la collection crowdsecurity/sshd. Un Nginx, il ajoute les scénarios web. Tu n’as pas à deviner quoi surveiller, il le déduit de ce qui tourne.

Vérifie ce qu’il a mis en place.

sudo cscli collections list

Tu dois voir la liste des collections actives, avec la mention enabled. Si un service exposé n’est pas couvert, tu ajoutes sa collection à la main, par exemple sudo cscli collections install crowdsecurity/nginx puis un redémarrage du service crowdsec. Tout se pilote avec cscli, l’outil en ligne de commande du moteur, l’équivalent de ton agent_control côté Wazuh.

À ce stade, le moteur lit, analyse et décide. Mais il ne bloque encore rien. Il tient une liste noire que personne n’applique. Il lui manque ses mains.

Étape 2, poser le bouncer qui bloque vraiment

Les mains, c’est le bouncer firewall. Il lit les décisions du moteur et les traduit en règles de pare-feu qui refoulent réellement le trafic.

Il en existe deux variantes selon ton pare-feu, une pour nftables, une pour iptables. Les distributions récentes tournent sous nftables, c’est le cas par défaut.

sudo apt install crowdsec-firewall-bouncer-nftables

Si ta machine est sur l’ancien iptables, tu remplaces le paquet par crowdsec-firewall-bouncer-iptables. Le principe est identique. Un détail de cohérence avec l’épisode 1, si ton pare-feu tourne sous ufw, sache que ufw s’appuie sur l’un des deux backends selon ta version, vérifie lequel avant de choisir la variante du bouncer.

L’installation fait le branchement toute seule. Le paquet appelle cscli bouncers add pour lui, enregistre le bouncer auprès du moteur et lui remet une clé d’authentification. Aucune manipulation de clé à faire à la main.

Vérifie que le moteur et son bouncer se parlent.

sudo cscli bouncers list

Tu dois voir ton bouncer firewall listé, avec une date de dernière activité récente. À partir de maintenant, la boucle est fermée. Le moteur décide, le bouncer applique, l’IP fautive tombe dans un ensemble bloqué par ton pare-feu. Ton SIEM a des mains.

Étape 3, vérifier que ça mord

Trois commandes pour t’assurer que la machine tourne, et une pour la mettre à l’épreuve sans attendre une vraie attaque.

D’abord la vue d’ensemble.

sudo cscli metrics

Elle t’affiche combien de lignes de logs le moteur a lues, par source, et combien de fois chaque scénario s’est déclenché. Si les compteurs de lecture bougent, ton moteur voit bien tes journaux. S’ils restent à zéro, il ne lit rien, et là c’est un problème de source à régler avant d’aller plus loin.

Ensuite les décisions en cours, la liste noire vivante. Ajoute le drapeau -a, sinon CrowdSec ne t’affiche que tes décisions locales et masque les IP tirées du réseau communautaire.

sudo cscli decisions list -a

Sur une machine exposée depuis quelques heures, elle n’est déjà pas vide, entre tes propres blocages et la liste communautaire téléchargée. Chaque ligne, une IP, le scénario qui l’a fait tomber, la durée restante.

Regarde la colonne Source. Les lignes CAPI, ce sont les cadeaux de la communauté, des IP que tu n’as jamais vues toquer chez toi et qui sont déjà refoulées. La ligne crowdsec en gras, c’est la tienne, un scanner que ton propre serveur a chopé en plein http-probing et banni tout seul, trois heures au coin. Le collectif et le local, côte à côte, dans la même liste noire.

Enfin, l’épreuve. Plutôt que d’attendre un attaquant, tu fabriques une décision de test sur une IP bidon.

sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test blocage"
sudo cscli decisions list

L’IP 192.0.2.1 appartient à une plage réservée à la documentation, elle ne bloquera personne de réel. Tu la vois apparaître dans la liste, le bouncer la pousse dans ton pare-feu. Nettoie derrière toi une fois le test concluant.

sudo cscli decisions delete --ip 192.0.2.1

Si l’ajout, l’affichage et la suppression s’enchaînent proprement, ta chaîne moteur-décision-bouncer est opérationnelle de bout en bout.

Étape 4, le signal communautaire, ce qui sort et ce qui reste

C’est là que CrowdSec change d’échelle, et c’est aussi le seul endroit où la souveraineté demande une phrase d’honnêteté, alors posons-la sans détour.

Par défaut, ton moteur est inscrit à l’API centrale communautaire. Tu peux le vérifier.

sudo cscli capi status

Cet échange fonctionne dans les deux sens, et c’est important de savoir exactement quoi. Ce qui sort de chez toi, quand tu bloques une IP, c’est un signal minimal, l’adresse IP fautive, le scénario déclenché et l’horodatage. Ce qui ne sort jamais, ce sont tes journaux, tes noms de machines, tes utilisateurs, le contenu de quoi que ce soit. CrowdSec partage la conclusion « cette IP attaque », pas la matière première qui t’a permis d’y arriver. Ce qui rentre, c’est la liste communautaire, l’agrégat anonymisé de ces signaux à l’échelle de tout le réseau.

C’est un compromis, et il est net. Tu échanges l’adresse d’attaquants, une donnée qui n’est pas la tienne mais celle de tes agresseurs, contre une protection collective que tu ne pourrais jamais construire seul. Le moteur, lui, reste auto-hébergé chez toi, aucun tiers ne pilote tes blocages, aucune décision ne dépend d’un service distant qui pourrait être coupé. Tu peux même te désinscrire du partage et tourner en pur local, tu gardes ta défense, tu perds seulement la liste communautaire. Le curseur est entre tes mains, comme toujours dans cette série.

Si tu veux une console web pour visualiser tes alertes, CrowdSec en propose une, gratuite, où tu relies ton moteur avec sudo cscli console enroll <ta-clé>. Facultatif, et hébergé par CrowdSec, donc à peser selon ta ligne. Ton vrai tableau de bord, de toute façon, c’est Wazuh, et c’est l’étape suivante.

Étape 5, faire remonter CrowdSec dans Wazuh

Ton pare-feu bloque, très bien. Mais pour l’instant ton SIEM ne le sait pas. CrowdSec agit dans son coin, Wazuh regarde ailleurs. On les branche, pour que chaque décision CrowdSec devienne une alerte visible dans ton tableau de bord unique.

Le principe est simple et propre. CrowdSec sait écrire ses alertes dans un fichier, et Wazuh sait lire un fichier de logs. On fait se rencontrer les deux.

Côté CrowdSec, tu actives le plugin de notification par fichier. Il existe déjà, tu l’édites dans /etc/crowdsec/notifications/file.yaml pour qu’il écrive au format JSON, une alerte par ligne.

type: file
name: file_default
log_level: info
format: |
  {{range . -}}
   { "crowdsec": { "program": "crowdsec", "alert": {{. | toJson }} }}
  {{ end -}}
log_path: "/var/log/crowdsec/crowdsec_alerts.json"
rotate:
  enabled: true
  max_size: 500
  compress: true

Puis tu déclares ce canal dans /etc/crowdsec/profiles.yaml, pour que le moteur y envoie ses alertes.

notifications:
    - file_default

Un détail qui compte. Le tutoriel officiel de CrowdSec écrit ce fichier dans /tmp, qui est vidé à chaque redémarrage de la machine. On le pose plutôt dans /var/log/crowdsec/, pour que ton historique d’alertes survive à un reboot. Un redémarrage du service crowdsec, et le fichier /var/log/crowdsec/crowdsec_alerts.json se remplit à chaque décision.

Côté Wazuh, tu dis à l’agent local, celui de l’épisode 3 déjà installé sur ce serveur, de lire ce fichier. Tu ajoutes ce bloc à sa configuration, idéalement via la configuration partagée du groupe pour ne l’écrire qu’une fois.

<localfile>
  <location>/var/log/crowdsec/crowdsec_alerts.json</location>
  <log_format>json</log_format>
  <label>crowdsec</label>
</localfile>

Tu reconnais la logique du <localfile>, c’est exactement le mécanisme par lequel Wazuh avale n’importe quelle source de journaux. Le format json lui dit de parser chaque ligne comme un objet structuré, et tes champs crowdsec.alert.* deviennent interrogeables dans le dashboard.

Redémarre l’agent Wazuh, et la boucle de la série se referme. Une IP attaque, CrowdSec la bloque, écrit l’alerte, l’agent Wazuh la lit, le manager la remonte, elle s’affiche dans ton tableau de bord à côté de tout le reste. Ton SIEM ne voit plus seulement les attaques, il voit ses propres ripostes.

Une note de version, parce qu’elle compte. Cette intégration par plugin fichier suppose une version récente du moteur et de Wazuh. Vérifie que ton CrowdSec est en 1.6.3 ou au-dessus et que ton Wazuh est en 4.9.0 ou au-dessus, les versions à partir desquelles cette intégration par plugin fichier est officiellement supportée. Tu tournes sur du Wazuh 4.x, cette intégration ne dépend pas de la future 5.0, elle marche sur ta stack actuelle.

Si ça ne marche pas

Le déploiement de CrowdSec est direct, et il coince presque toujours aux mêmes endroits. Voici les vrais, dans l’ordre où tu les rencontreras.

Problème, `cscli metrics` affiche zéro ligne lue

Cause probable, le moteur ne trouve pas tes journaux, ou n’a pas la collection correspondant à ton service. Il tourne, mais il lit dans le vide.

Solution, vérifie que la source de logs existe bien au chemin attendu et que la collection du service est installée avec sudo cscli collections list. Ajoute la collection manquante, puis redémarre le service crowdsec.

Problème, une IP est décidée mais rien n’est bloqué

Cause probable, le bouncer n’est pas là, ou ne parle pas au moteur. Le moteur décide dans son coin, personne n’applique.

Solution, sudo cscli bouncers list doit montrer ton bouncer firewall avec une activité récente. S’il est absent, réinstalle le paquet du bouncer. S’il est présent mais muet, vérifie que le service du bouncer tourne.

Problème, le mauvais backend de pare-feu

Cause probable, tu as installé la variante nftables du bouncer sur une machine en iptables, ou l’inverse. Le bouncer pose ses règles dans un système que ton pare-feu n’utilise pas.

Solution, identifie ton backend réel, puis installe la variante correspondante du bouncer, crowdsec-firewall-bouncer-nftables ou crowdsec-firewall-bouncer-iptables.

Problème, rien ne remonte dans Wazuh

Cause probable, attention, ce n’est en général pas un problème CrowdSec. Le fichier /var/log/crowdsec/crowdsec_alerts.json se remplit, mais l’agent Wazuh ne le lit pas, ou le manager ne digère pas le format.

Solution, vérifie d’abord que le fichier grossit côté CrowdSec. S’il grossit, le diagnostic est côté Wazuh, le bloc <localfile> et la version de l’agent, pas côté moteur. Ne réinstalle pas CrowdSec pour un souci de lecture Wazuh.

La liste communautaire fait la moitié du travail

Un dernier mot, parce que c’est le point qu’on sous-estime toujours au départ. Le jour où tu installes CrowdSec, tu t’attends à ce qu’il apprenne lentement, à ce qu’il faille des semaines de trafic pour qu’il devienne utile. Faux.

Dès la première synchronisation, tu télécharges la liste communautaire, et ton cscli decisions list -a se peuple d’IP que tu n’as jamais vues. Des attaquants repérés ailleurs, déjà refoulés chez toi. Tu bénéficies du travail de dizaines de milliers d’autres serveurs avant d’avoir subi ta première attaque.

Ce n’est pas magique, c’est du volume. Chaque serveur qui remonte un signal renforce la défense de tous les autres. C’est exactement le modèle que le SaaS américain te vend cher et sous sa juridiction, sauf qu’ici il est open source, auto-hébergé, et le signal partagé se limite à l’adresse de tes agresseurs.

Le tournant est franchi. Là où ton SIEM se contentait de constater, il refoule.

Pour les pressés

Ce que fait cet article. On installe CrowdSec sur le VPS durci pour bloquer en amont les IP malveillantes, connues localement comme signalées par le réseau communautaire. Le moteur lit les journaux et décide, le bouncer firewall applique le blocage sur nftables ou iptables, et chaque décision remonte dans Wazuh via un fichier d’alertes lu par l’agent. La défense passe de « voir » à « barrer la route ».

Concrètement, les commandes.

Installer le moteur : curl -s https://install.crowdsec.net | sudo sh puis sudo apt install crowdsec.
Vérifier les collections détectées : sudo cscli collections list.
Installer le bouncer firewall selon ton backend : sudo apt install crowdsec-firewall-bouncer-nftables (ou -iptables).
Vérifier le branchement : sudo cscli bouncers list.
Contrôler la machine : sudo cscli metrics et sudo cscli decisions list -a (le -a pour voir aussi la liste communautaire).
Tester le blocage : sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test" puis sudo cscli decisions delete --ip 192.0.2.1.
Vérifier le partage communautaire : sudo cscli capi status.
Intégrer à Wazuh : activer le plugin fichier dans /etc/crowdsec/notifications/file.yaml (sortie /var/log/crowdsec/crowdsec_alerts.json), l’appeler dans /etc/crowdsec/profiles.yaml, puis ajouter le bloc <localfile> JSON à la config de l’agent Wazuh.

En résumé

Tu es parti d’un SIEM qui voyait les attaques sans pouvoir les arrêter, tu repars avec une première ligne qui les refoule.

Tu as installé le moteur CrowdSec sur ton VPS durci, qui lit tes journaux et décide. Tu as posé le bouncer firewall, qui applique ces décisions sur ton pare-feu et bloque réellement. Tu as branché la liste communautaire, qui te protège d’attaquants que tu n’as jamais croisés, en ne partageant que l’adresse des tiens. Et tu as fait remonter tout ça dans Wazuh, pour que ta salle de contrôle voie enfin la couche de défense réseau.

Le tout reste chez toi. Le moteur est auto-hébergé, aucune décision ne dépend d’un tiers, et le seul signal qui sort, c’est l’IP de tes agresseurs. La protection collective sans la dépendance, c’est précisément le troisième chemin, le souverain, ouvert à l’épisode d’introduction.

Tu bloques désormais au niveau réseau. Mais tes attaques les plus fréquentes n’arrivent pas par le port SSH, elles arrivent par la boîte mail. À l’épisode 5, on monte le filtre anti-spam et anti-hameçonnage devant ton serveur de messagerie, la porte la plus exposée de toutes.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent. Tu viens de le lire.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Installe ton premier modèle d'IA en local sur Mac

Mac Souverain — Mon, 06 Jul 2026 06:14:39 GMT

Dans l’article précédent, on a posé le décor. Ton accès à un modèle d’IA distant peut être coupé du jour au lendemain, par une décision arbitraire, et la seule chose qui continue de tourner ce matin-là, ben… c’est plus rien.

On a également dressé la carte de ce qu’un Mac Apple Silicon fait tourner en local, du petit modèle qui trie tes notes, au gros modèle qui rédige.

C’était le pourquoi. Voici le comment.

Bonne nouvelle d’entrée : tu n’as besoin d’aucune compétence technique, d’aucune ligne de commande, et d’aucun matériel supplémentaire. Si tu lis ces lignes sur un Mac récent, tu as déjà tout. Compte une vingtaine de minutes, la plupart passées à regarder une barre de téléchargement avancer.

Au bout, un modèle capable, qui répond entièrement chez toi. Et pour te le prouver, à la toute fin, on coupera le Wi-Fi.

À lire : Ton IA peut être éteinte par les US, monte la tienne

Ce qu’il te faut

Trois choses, et tu les as probablement déjà.

Un Mac Apple Silicon, c’est-à-dire une puce M1 à M5. La quasi-totalité des Mac grand public vendus depuis fin 2020 en sont équipés. Si tu as un Mac Intel, cette méthode ne s’applique pas, l’inférence locale efficace repose sur la mémoire unifiée d’Apple Silicon.

Une version de macOS raisonnablement récente, Sonoma (14) ou plus récent pour l’outil qu’on va utiliser. Si tu n’as pas mis à jour depuis un moment, c’est le moment.

De la RAM, et c’est là que se joue le choix du modèle. Rappel express de l’article précédent : sur un Mac à 16 Go, une fois le système servi, il te reste 8 à 10 Go réellement utiles pour l’IA, de quoi faire tourner un modèle de 7 à 8 milliards de paramètres.

Sur un 32 Go, tu montes une classe au-dessus, jusqu’à un modèle de 24 milliards de paramètres. La règle d’or, ne jamais choisir un modèle qui remplit tout le budget disponible, sinon la machine se met à ramer ou plante.

Si tu veux le détail du budget RAM et la carte complète des modèles par taille, tout est dans l’article précédent. Ici, on installe.

L’outil : LM Studio, zéro terminal

Il existe plusieurs façons de faire tourner un modèle en local. Pour un premier pas, une seule mérite d’être en vedette : LM Studio.

C’est une application de bureau classique, avec des fenêtres, des boutons et un champ de recherche. Tu télécharges tes modèles depuis une bibliothèque intégrée, tu cliques, tu discutes. Aucune ligne de commande, aucun fichier de configuration à éditer, aucune manipulation ésotérique. C’est l’IA locale présentée comme une app normale, et pour débuter c’est exactement ce qu’il faut.

LM Studio est gratuit, pour un usage personnel comme professionnel. Et sur Mac Apple Silicon, il embarque le meilleur moteur possible, on y revient dans deux minutes.

Les curieux et les gourmands ont d’autres options, Ollama en ligne de commande, MLX pour aller au ras du métal. On les évoque en fin d’article, une fois que tu auras déjà un modèle qui tourne. Chaque chose en son temps.

Installer LM Studio

Rien de plus qu’une app Mac ordinaire.

Rends-toi sur lmstudio.ai et télécharge la version pour Mac. Le site détecte ta machine et te propose le bon build, celui pour Apple Silicon. Tu récupères un fichier .dmg, le format d’installation habituel sur Mac.

Ouvre le .dmg téléchargé. Une fenêtre s’affiche avec l’icône de LM Studio et un raccourci vers ton dossier Applications. Glisse l’icône sur le dossier Applications, exactement comme pour n’importe quelle app. C’est tout, rien à cocher, rien à configurer.

Lance LM Studio depuis ton Launchpad ou ton dossier Applications. Au premier démarrage, macOS peut te demander de confirmer l’ouverture d’une app téléchargée sur Internet, tu confirmes. L’application s’ouvre sur un écran d’accueil qui te propose de choisir un premier modèle. On y va.

Choisir et télécharger ton premier modèle

C’est l’étape qui compte, et celle où on va être précis, parce que tous les modèles ne se valent pas et que le bon choix dépend de ta RAM.

Reprends le pick souverain de l’article précédent. Sur un Mac à 16 Go, vise Qwen2.5 7B, un modèle sous licence Apache 2.0, vraiment libre, qui fait tourner l’essentiel du quotidien. Sur un Mac à 32 Go, vise Mistral Small, un modèle de 24 milliards de paramètres, européen et lui aussi sous Apache 2.0, taillé pour la rédaction soutenue et l’analyse de longs documents.

Dans LM Studio, ouvre l’onglet de recherche, l’icône en forme de loupe dans la barre latérale, et tape le nom du modèle. La bibliothèque est connectée à Hugging Face, la grande logithèque des modèles ouverts, tu vas donc voir apparaître plusieurs variantes du même modèle. C’est normal, et c’est là qu’il faut savoir lire.

Deux informations à décoder sur chaque variante.

Le format. Tu vas croiser deux mots, MLX et GGUF. Retiens simplement ceci : MLX, le framework de calcul maison d’Apple, est le moteur optimisé pour la mémoire unifiée d’Apple Silicon. Sur ton Mac, une version MLX tourne nettement plus vite que la même en GGUF, à qualité égale.

LM Studio embarque ce moteur MLX, autant l’exploiter. Prends la version MLX du modèle dès qu’elle existe. Si un modèle n’existe qu’en GGUF, ce n’est pas grave, ça marche aussi, juste un peu moins vite.

La quantification. Tu vas voir des étiquettes comme 4bit, Q4, Q4_K_M, Q8. C’est le degré de compression du modèle. Un modèle brut pèse une fortune en mémoire, la quantification réduit la précision de ses poids pour le faire tenir dans ta RAM, au prix d’une perte de qualité minime.

Q4, ou 4bit, est le bon compromis pour débuter, il divise le poids du fichier par environ quatre par rapport au modèle non compressé, sans que tu voies vraiment la différence à l’usage. Q8 est plus fidèle mais deux fois plus lourd, garde-le pour plus tard si tu as de la marge.

Concrètement, ce que tu télécharges :

Sur 16 Go, Qwen2.5 7B en MLX 4bit pèse environ 4,3 Go. Il rentre large.
Sur 32 Go, Mistral Small 24B en MLX 4bit pèse autour de 13 à 14 Go. Il rentre dans ta marge sans te ruiner la machine.

Choisis la bonne variante, MLX et 4bit, et clique sur télécharger. Une barre de progression apparaît, tu peux suivre l’avancement dans l’onglet des téléchargements. C’est le moment d’aller te faire un café, le fichier fait plusieurs gigas.

Un mot sur les noms de version. Les modèles évoluent, Mistral Small en est déjà à une révision plus récente que celle nommée dans l’article précédent. Ne te formalise pas sur le numéro exact, prends la dernière Mistral Small 24B proposée en MLX dans LM Studio, ce sera la bonne.

Ton premier prompt, puis coupe le Wi-Fi

Le modèle est téléchargé. Place au moment de vérité.

Ouvre l’onglet Chat, l’icône en forme de bulle dans la barre latérale. En haut de la fenêtre, un menu déroulant te propose de charger un modèle, sélectionne celui que tu viens de télécharger. LM Studio le charge en mémoire, quelques secondes, et t’affiche un champ de saisie familier, une conversation, comme avec n’importe quel assistant.

Si LM Studio te propose un choix de moteur, assure-toi qu’il est bien sur MLX. C’est en général automatique quand tu as pris une variante MLX, mais un coup d’œil ne coûte rien.

Tape ton premier prompt. N’importe quoi, une vraie tâche de préférence, pour sentir ce que ça donne. « Résume-moi ce texte en trois points », « rédige-moi un mail de relance poli », « explique-moi la différence entre deux notions ». Le modèle réfléchit une poignée de secondes, puis répond, mot après mot, entièrement depuis ta machine.

Et maintenant, la démonstration qui referme la boucle de l’article précédent.

Coupe le Wi-Fi. Clique sur l’icône Wi-Fi dans ta barre de menus et désactive-le, ou passe par Réglages Système. Ta machine est désormais hors ligne, coupée d’Internet, débranchée du monde. Repose une question au modèle.

Il répond.

Voilà. Aucune requête n’est partie, aucun octet de ton texte n’a quitté ton Mac, et pourtant ça marche. C’est ça, concrètement, un modèle qui tourne chez toi. Le matin où on coupe le robinet distant, celui-là continue de couler. Tu peux rallumer le Wi-Fi, la démonstration est faite.

Trois réglages qui changent tout

Ton modèle tourne. Trois boutons méritent que tu saches à quoi ils servent, parce qu’ils font la différence entre une machine fluide et une machine qui rame.

La longueur de contexte. C’est la quantité de texte que le modèle peut garder en tête d’un coup, ta question plus sa réponse plus tout ce que tu lui as donné à lire. Elle se règle au chargement du modèle, exprimée en tokens, dans le panneau de configuration. Une valeur élevée te permet de lui soumettre de longs documents, mais elle consomme de la RAM en proportion. Si ton Mac peine, réduis-la. Si tu veux lui faire avaler un long PDF, augmente-la, en gardant un œil sur ta mémoire.

La quantification. On en a parlé au téléchargement, c’est le levier qualité contre poids. Si ton modèle tient à l’étroit dans ta RAM, une quantification plus agressive (Q4 plutôt que Q8) le fait tenir. Si tu as de la marge et que tu veux le meilleur rendu, une quantification plus légère améliore la qualité. Tu ajustes en téléchargeant une autre variante du modèle, c’est le seul point où il faut repasser par la case téléchargement.

Décharger le modèle. Tant qu’un modèle est chargé, il occupe ta RAM, même si tu ne l’utilises pas. Quand tu as fini, décharge-le, le bouton d’éjection dans le sélecteur de modèle libère la mémoire d’un coup. Réflexe utile si tu enchaînes sur un travail lourd, montage, code, machine virtuelle, et que tu veux récupérer tes gigas. Fermer la fenêtre ne suffit pas toujours, décharge explicitement.

Pour aller plus loin

Tu as un modèle qui tourne, tu as passé ton premier prompt hors ligne. Le reste, c’est du bonus, pour le jour où l’envie te prend de creuser.

Ollama, pour les curieux du terminal. Si la ligne de commande ne te fait pas peur, Ollama fait tourner un modèle en une seule commande. Tu installes l’app, tu ouvres le Terminal, tu tapes ollama run mistral-small:24b, et il télécharge le modèle puis te met en conversation, directement dans le terminal. C’est plus dépouillé que LM Studio, mais redoutablement efficace, et ça ouvre la porte à l’automatisation, brancher un modèle local sur tes propres scripts via une API locale. Ollama tire lui aussi parti d’Apple Silicon en s’appuyant sur MLX.

MLX en direct, pour les gourmands. Le moteur que LM Studio utilise sous le capot, MLX, est un framework Apple que tu peux piloter toi-même, avec sa boîte à outils mlx-lm. C’est le terrain de jeu de qui veut exploiter au maximum sa mémoire unifiée, tester des quantifications maison, ou faire tourner des modèles à peine sortis. Réservé à ceux que la mécanique fine amuse, mais c’est là que se trouve la performance brute sur Mac.

Pour la grande majorité des usages, tu n’iras jamais plus loin que LM Studio, et c’est parfaitement bien ainsi.

Récapitulons ce que tu viens de faire. Tu as installé une app gratuite, téléchargé un modèle en MLX taillé pour ta RAM, passé un premier prompt, et vérifié Wi-Fi coupé que rien ne sortait de ta machine. Vingt minutes, zéro ligne de commande, zéro dépendance à un modèle qu’un tiers IA peut fermer.

Ce modèle est à toi. Personne ne peut te le couper, te le facturer à la requête, ou décider un matin que ta nationalité ne lui convient pas. Il ne remplacera pas le meilleur modèle distant sur les tâches les plus dures, on l’a dit, et ce n’est pas le but. Son intérêt, c’est qu’il est là, chez toi, tout le temps, pour l’essentiel de ce que tu fais.

Le socle est posé. La suite, c’est de t’en servir pour de vrai, pour toutes les tâches que tu peux.

À lire : Apple Intelligence : ce qui sort vraiment de ton Mac

Sources

L’outil

LM Studio, l’application de bureau pour exécuter des modèles en local, gratuite, avec moteur MLX embarqué sur Apple Silicon.
LM Studio, configuration requise, Apple Silicon M1 à M4 et macOS 14 ou plus récent, 16 Go de RAM recommandés.

Les modèles

Qwen2.5 7B Instruct, MLX 4bit, 4,28 Go, licence Apache 2.0, le pick d’un Mac à 16 Go.
Mistral Small 24B, MLX 4bit, environ 13 Go, licence Apache 2.0, le pick d’un Mac à 32 Go.

Pour aller plus loin

Ollama, exécuter un modèle en une commande, avec API locale.
Apple MLX, le framework optimisé pour la mémoire unifiée d’Apple Silicon.

Des termes techniques ? Consulte le glossaire.

Wazuh 5.0 débarque, ton SIEM maison évolue

Mac Souverain — Thu, 02 Jul 2026 07:22:47 GMT

Wazuh 5.0 débarque en bêta publique et refond son architecture, Filebeat dégage, cluster par défaut, nouveau moteur. Si tu as monté ton SIEM avec notre série, ton install 4.x tourne toujours, la montée en 5.0 ne se fera pas à l’aveugle.

Ce que ça change pour toi

1. Repère ta version avec wazuh-control info, les 4.11 et récentes reçoivent encore des correctifs.

2. Snapshot ta VM et sauvegarde /var/ossec/etc/ avant toute tentative de passage en 5.0.

3. Attends une 5.0.x stable (5.0.1 ou 5.0.2) avant de migrer, on met la série SIEM à jour à ce moment-là, guide de migration inclus.

Si tu as monté ton SIEM maison en suivant l’épisode 2/7 de la série SIEM souverain, prépare-toi : Wazuh 5.0 arrive en bêta publique et casse plusieurs briques d’un coup. Pas de panique, mais bien regarder avant de mettre à jour à l’aveugle. Et on met la série d’articles SIEM à jour le moment venu.

Le fait

Wazuh vient de publier la bêta publique de sa version 5.0, avec une sortie stable estimée fin juin ou début juillet 2026. Ce n’est pas un simple bump de version, c’est une refonte architecturale.

Ce qui change, concrètement : Filebeat disparaît, remplacé par un indexer-connector natif intégré au manager. Chaque serveur Wazuh devient un nœud de cluster par défaut, même en install mono-serveur. Le vieux moteur analysisd, qui traitait les logs et déclenchait les règles, est remplacé par un nouveau moteur. La détection de vulnérabilités bascule côté Wazuh Indexer, centralisée. Et le RBAC, la gestion fine des droits, est entièrement retravaillé.

Conséquence directe pour MacSouverain : l’épisode 2/7 de la série SIEM souverain, qui documente l’architecture 4.x pas à pas, sera partiellement obsolète dès la sortie de 5.0. On met la série à jour quand la 5.0 sera stable, pas avant.

Pourquoi ça compte pour toi

Si tu as suivi le guide épisode 2/7 de la série SIEM souverain pour monter ton propre SIEM à la maison, tu tournes probablement sur une 4.x. Bonne nouvelle, ton install continue de marcher, personne ne va te débrancher. Mauvaise nouvelle, la mise à jour vers 5.0 ne sera pas un simple apt upgrade sans lire la doc. Filebeat qui saute, ça veut dire que ton pipeline de logs change de plomberie. Le cluster par défaut, ça change la conf initiale même si tu restes sur une seule machine.

Traduction pratique : si tu comptais mettre à jour dès la sortie, prends une heure pour lire les release notes et fais un snapshot avant. Si tu es sur une install stable qui te sert au quotidien, attends une ou deux versions correctives, laisse les early adopters essuyer les plâtres.

Ce que ça change pour toi

1. Note quelle version de Wazuh tu tournes actuellement. Sur ton manager, wazuh-control info ou consulte le dashboard. Si tu es en 4.11 ou récent, tu es sur la branche qui reçoit encore des correctifs.

2. Avant toute tentative de mise à jour vers 5.0, snapshot ta VM ou sauvegarde ta config /var/ossec/etc/ et l’état de ton Wazuh Indexer. Un rollback propre te sauve la mise si le nouveau moteur ne digère pas tes règles custom.

3. Attends la version stable 5.0.x (au moins 5.0.1 ou 5.0.2) avant de migrer une install en production perso. La bêta, c’est pour tester sur une VM jetable, pas sur celle qui surveille ton réseau tous les jours. A surveiller : la publication officielle du guide de migration 4.x → 5.0 par Wazuh, et la refonte à venir de l’épisode 2/7 de la série SIEM souverain côté MacSouverain.

Sources

Wazuh 5.0 Public Beta Discussion (GitHub)

Chat Control : l'UE joue le sort de ton chiffrement

Mac Souverain — Wed, 01 Jul 2026 13:46:25 GMT

Le 29 juin, l’UE a tenu le 5e et dernier trilogue sur Chat Control 2.0 (CSAR). Enjeu : un scanning de masse de tes messages privés avant chiffrement, contre un Parlement qui défend l’E2E. L’issue se joue maintenant et décidera si WhatsApp, Signal & iMessage restent réellement chiffrés en Europe.

Ce que tu dois surveiller

1. La publication de l’accord (ou de l’échec) du trilogue et la présence, ou non, d’une exemption explicite du chiffrement de bout en bout.

2. Le retour de « Chat Control 1.0 » (scanning volontaire prolongé) que Metsola menace de rouvrir en parallèle : un cheval de Troie si le 2.0 cale.

3. La vérification d’âge obligatoire, qui tue l’anonymat en ligne bien au-delà de la lutte contre le CSAM.

Ce qui s’est passé le 29 juin

Sous présidence chypriote, le Conseil de l’UE a réuni le 29 juin ce qui était annoncé comme le cinquième et dernier trilogue sur le règlement CSAR, le texte que tout le monde appelle « Chat Control 2.0 ». Objectif affiché de la présidence : arracher un accord politique avant la trêve estivale.

La ligne de fracture n’a pas bougé. D’un côté, un texte du Conseil qui codifie un scanning de masse des communications privées via des « ordres de détection », un dispositif que le propre service juridique du Conseil juge contraire à l’article 7 de la Charte des droits fondamentaux. De l’autre, un Parlement qui, le 26 mars 2026, a rejeté le scan de masse à une seule voix (307 contre 306) et s’accroche à la protection du chiffrement de bout en bout.

À l’heure où on écrit, aucune source officielle n’a publié le résultat de ce trilogue : ni accord, ni échec confirmé. La présidence chypriote pousse pour une adoption formelle en juillet, mais le blocage sur le chiffrement peut encore tout faire dérailler. C’est précisément ce silence qu’il faut surveiller de près dans les prochains jours.

Pourquoi ça te concerne

Le scanning « côté client » impose d’inspecter tes messages sur ton appareil, avant qu’ils ne soient chiffrés. La crypto de WhatsApp, Signal ou iMessage n’est pas cassée, elle est vidée de son sens : ton message est lu en clair sur ton téléphone avant de partir. Et ce point d’inspection ne reste jamais réservé aux « gentils », il est exploitable par n’importe quel attaquant qui met la main dessus.

S’ajoute la vérification d’âge obligatoire, qui exige d’associer une identité réelle à ton compte de messagerie. C’est la fin de l’anonymat par défaut, vendu sous prétexte de protection de l’enfance.

Ce que tu peux faire

Rien à installer aujourd’hui : c’est un signal politique, pas une faille produit. Mais garde Signal en messagerie de repli, surveille les positions de ton eurodéputé, et suis EDRi / Patrick Breyer pour l’issue réelle. Dès qu’elle sera publiée, on mettra à jour nos articles qui traitent le sujet.

Déploie Wazuh partout, le SIEM voit enfin ton réseau

Mac Souverain — Wed, 01 Jul 2026 12:50:41 GMT

À l’épisode précédent, tu as monté une console de sécurité qui tourne. Wazuh en tout-en-un sur ton VPS durci, manager, indexeur et tableau de bord sur un seul nœud, dashboard verrouillé en Tailnet-only. Une belle machine. Qui, pour l’instant, ne voit qu’une seule chose : elle-même.

C’est déjà utile, ton serveur s’auto-surveille, valide ton durcissement, remonte ses propres CVE. Mais un SIEM qui ne regarde que le serveur sur lequel il tourne, c’est une caméra braquée sur sa propre boîte. Aujourd’hui, on la retourne vers le reste de la pièce.

On va déployer les agents Wazuh sur ton parc. Tes serveurs Linux, tes Mac, tes postes Windows. Chaque machine reçoit une sonde qui collecte ses journaux, ses événements de sécurité et l’intégrité de ses fichiers, et fait remonter tout ça au manager. C’est le moment où ton SIEM passe de myope à panoramique.

Un point non négociable, posé dès l’épisode 1 et qui commande tout ce chapitre. Cette remontée passe par le Tailnet, jamais par l’internet ouvert. Le manager n’ouvre ses oreilles que sur ton maillage privé. Un agent qui n’est pas dans ton Tailnet ne parle à rien.

Cette stack, je l’utilise au quotidien. Les commandes qui suivent sont celles que tu vas taper toi-même, dans l’ordre, sur ton manager puis sur chaque machine à surveiller.

Avant de commencer

Trois choses à avoir en tête avant la première commande.

Ce qu’il te faut. Le manager Wazuh de l’épisode 2, opérationnel. Un accès administrateur sur chaque machine à enrôler. Et surtout, chaque machine à surveiller doit être membre de ton Tailnet, exactement comme ton manager. C’est le prérequis structurant de cet épisode. Le tailscale up vu à l’épisode 1, tu le rejoues sur chaque endpoint. Sans ça, rien ne remonte.

Ce que ça change. À la fin, ton dashboard ne listera plus un seul agent, mais autant que tu auras de machines. Chacune remonte ses logs, son audit de configuration, ses vulnérabilités et l’intégrité de ses fichiers, au même endroit, sous ton œil unique.

Ce que ça ne change pas. Un agent observe, il ne bloque rien. Il te dit qu’une application a démarré, qu’un fichier a changé, qu’une connexion a échoué. Décider quelles applications ont le droit de se lancer sur tes Mac, ça viendra, c’est un autre outil, un autre épisode. Ici, on regarde. On ne barre pas encore la route.

Ouvrir les bonnes portes, et seulement celles-là

Avant de toucher au moindre endpoint, un geste sur le manager. Jusqu’ici, ton serveur n’écoutait le monde extérieur sur rien, et le dashboard était replié sur le Tailnet. Les agents distants, eux, ont besoin de joindre le manager sur deux ports.

Le port 1515, pour l’enrôlement. C’est la poignée de main initiale, chiffrée, par laquelle un nouvel agent se présente et reçoit sa clé d’authentification.
Le port 1514, pour la remontée des logs et des événements, une fois l’agent enrôlé.

Et c’est exactement là que se joue la souveraineté de toute la série. Ces deux ports, on les ouvre uniquement sur l’interface Tailscale, jamais en global.

sudo ufw allow in on tailscale0 to any port 1514 proto tcp
sudo ufw allow in on tailscale0 to any port 1515 proto tcp

Tu reconnais le geste, c’est celui de SSH à l’épisode 1, celui du dashboard à l’épisode 2. On autorise sur tailscale0, ton maillage chiffré, et nulle part ailleurs. Le piège, toujours le même, ce serait de taper sudo ufw allow 1514/tcp tout court. Cette commande-là offre ton SIEM aux scanners du monde entier. La nôtre le garde invisible.

Vérifie l’état de ton pare-feu.

sudo ufw status

Tu dois voir tes deux nouvelles règles portant bien la mention on tailscale0. Si un 1514/tcp global traîne, retire-le sans hésiter, c’est une brèche.

Dernière chose à noter, l’adresse Tailscale de ton manager, celle que chaque agent devra viser.

tailscale ip -4

C’est cette adresse, et pas l’IP publique du VPS, que tu passeras aux agents. L’IP publique n’écoute rien sur ces ports, de toute façon. Dans tout ce qui suit, je la note <IP_TAILSCALE_DU_MANAGER>.

Étape 1, enrôler un serveur Linux

On commence par le plus simple, un serveur Ubuntu ou Debian. Trois temps, ajouter le dépôt Wazuh, installer l’agent en lui donnant l’adresse du manager, le démarrer.

D’abord le dépôt officiel.

sudo apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

Rien d’ésotérique. On importe la clé de signature du dépôt, on déclare le dépôt Wazuh, on rafraîchit la liste des paquets. C’est la routine APT habituelle.

Puis l’installation, avec l’astuce qui fait tout le travail. En préfixant la commande d’installation par la variable WAZUH_MANAGER, tu dis au paquet vers qui se tourner. L’agent s’enrôle tout seul auprès de ce manager pendant l’installation.

sudo WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent

Le WAZUH_AGENT_GROUP="linux" range d’emblée cette machine dans un groupe nommé linux. On verra plus bas à quoi servent les groupes, retiens juste que c’est le bon moment pour les assigner.

Enfin, on démarre le service et on l’active au boot.

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Et voilà, ton serveur Linux remonte. Si tu tournes sur du RHEL, de l’Alma ou du Rocky, le principe est identique, tu remplaces le dépôt APT par le dépôt YUM et apt-get install par dnf install, la variable WAZUH_MANAGER fonctionne pareil.

Étape 2, enrôler un Mac

Le Mac, c’est là que ça devient intéressant, parce que macOS a ses propres règles du jeu. Commençons par le déploiement, la subtilité vient juste après.

L’agent macOS se livre en paquet .pkg, et il en existe deux versions, une pour les Mac Apple Silicon et une pour les vieux Mac Intel. Sur un parc récent, c’est l’Apple Silicon.

curl -O https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.5-1.arm64.pkg
echo "WAZUH_MANAGER='<IP_TAILSCALE_DU_MANAGER>' && WAZUH_AGENT_GROUP='macos'" > /tmp/wazuh_envs
sudo installer -pkg wazuh-agent-4.14.5-1.arm64.pkg -target /

Le mécanisme change un peu de forme mais pas de fond. Sur macOS, les variables de déploiement ne se collent pas devant la commande, elles s’écrivent dans un fichier temporaire, /tmp/wazuh_envs, que l’installateur lit au passage. Le résultat est le même, l’agent connaît son manager et son groupe. Pour un Mac Intel, tu remplaces arm64 par intel64 dans les deux lignes qui la mentionnent.

On lance ensuite l’agent.

sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist

Sur macOS, l’agent vit sous /Library/Ossec/, et son binaire de contrôle est /Library/Ossec/bin/wazuh-control, avec les verbes start, stop et status si tu veux le piloter à la main.

La chausse-trappe macOS, TCC et l’accès disque complet

Maintenant, la vérité que la plupart des tutoriels passent sous silence. Sur macOS, ton agent va démarrer, s’enrôler, apparaître comme actif dans le dashboard, et pourtant rester à moitié aveugle.

La raison tient à TCC, pour Transparency, Consent and Control, le système de permissions par usage d’Apple. C’est lui qui fait surgir ces fenêtres « telle application veut accéder à vos documents ». TCC filtre l’accès aux dossiers sensibles, et il ne fait pas de cadeau. Or l’agent Wazuh n’est pas une application au sens d’Apple, c’est un ensemble de binaires empaquetés. Résultat, sans autorisation explicite, il se voit refuser l’accès aux zones que TCC protège. Sa surveillance d’intégrité des fichiers tourne, mais ne voit pas ce qu’elle ne peut pas lire.

La parade, c’est d’accorder à l’agent l’accès disque complet, le Full Disk Access. Sur un parc géré, ça se fait proprement par MDM, un profil de configuration poussé par Jamf ou équivalent, qui déclare la permission une fois pour toutes sur toutes les machines. Sur une ou deux machines, ça se règle à la main dans les réglages de confidentialité. C’est un cran de plus que sur Linux, et c’est spécifique à Apple, autant le savoir avant de s’étonner que le Mac remonte moins de choses que le serveur.

Étape 3, enrôler un poste Windows

Windows, dernier larron. L’agent s’installe via un paquet MSI, en mode silencieux, depuis une console PowerShell ouverte en administrateur.

msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_NAME="poste-compta" WAZUH_AGENT_GROUP="windows"

Même logique que partout, les variables passent le manager, un nom lisible pour le poste et son groupe. Le WAZUH_AGENT_NAME est confortable sur Windows, où tu vas vite avoir dix postes qui se ressemblent, autant les baptiser.

Puis on lance le service.

Start-Service WazuhSvc

En CMD classique, ce serait NET START WazuhSvc, au choix. L’agent s’installe sous C:\Program Files (x86)\ossec-agent.

Ce que Windows apporte de spécifique, c’est la lecture des journaux d’événements Windows, la fameuse triade Security, System et Application, là où atterrissent les échecs d’ouverture de session, les élévations de privilèges, les créations de comptes. Et le FIM peut y surveiller le registre, terrain de jeu favori des malwares qui veulent survivre à un redémarrage. Ton poste Windows n’est plus une boîte noire.

Étape 4, vérifier que tout remonte

Trois machines enrôlées, il est temps de s’assurer qu’elles parlent bien au manager. Retour sur le serveur Wazuh, une seule commande.

sudo /var/ossec/bin/agent_control -l

Elle liste tous tes agents avec leur identifiant, leur nom et leur état. Quatre états possibles, et il faut savoir les lire.

Active, l’agent est connecté et remonte. C’est ce que tu veux voir partout.
Pending, il vient de s’enrôler et attend sa première poignée de main complète. Transitoire, patiente une minute.
Disconnected, il était connecté et ne l’est plus. Le manager considère un agent perdu s’il n’a pas donné signe de vie depuis quinze minutes.
Never connected, il s’est enrôlé mais n’a jamais réussi à remonter. C’est le symptôme classique d’un port fermé ou d’une machine hors Tailnet, on y revient plus bas.

Le même tableau existe côté dashboard, en plus agréable à l’œil. La vue Agents t’affiche le décompte Active, Disconnected, Pending, Never connected, et la fiche de chaque machine, ses modules, sa dernière activité. C’est ta salle de contrôle, désormais peuplée.

Et là, le basculement. Chaque machine active fait tourner, sur elle-même, exactement les modules que ton serveur faisait tourner sur lui à l’épisode 2. L’audit de configuration contre les référentiels CIS. La détection des vulnérabilités connues sur ses paquets. La surveillance d’intégrité de ses fichiers. L’analyse de ses journaux. Sauf que maintenant, ce n’est plus une machine, c’est ton parc, et tout converge vers un seul écran.

Aller plus loin, surveiller un dossier précis

Par défaut, l’agent surveille déjà des répertoires système sensibles, ceux qu’un intrus aime modifier. Mais tu as sûrement un dossier qui compte plus que les autres, tes données clients, ta comptabilité, un partage métier. Tu veux savoir à la seconde près si quelqu’un y touche.

C’est le rôle du FIM, le File Integrity Monitoring, la surveillance d’intégrité des fichiers. Et plutôt que de l’éditer machine par machine, on utilise les groupes qu’on a assignés à l’enrôlement. Un groupe partage une configuration, poussée automatiquement par le manager à tous ses membres. Tu écris une fois, ça s’applique partout.

Sur le manager, tu édites le fichier de configuration partagée du groupe concerné, par exemple /var/ossec/etc/shared/linux/agent.conf, et tu y déclares le répertoire à surveiller.

<syscheck>
  <directories check_all="yes" realtime="yes">/srv/donnees-clients</directories>
</syscheck>

Deux attributs à comprendre. check_all="yes" enregistre tout ce qui caractérise un fichier, ses empreintes cryptographiques, sa taille, son propriétaire, ses permissions, ses dates. La moindre altération est repérée. realtime="yes" demande une surveillance en temps réel, l’alerte tombe à l’instant du changement, sans attendre le prochain scan.

Une nuance d’honnêteté sur ce temps réel. Il n’est disponible que sur Linux et Windows. Sur macOS, le FIM retombe sur des scans planifiés, périodiques. Une modification entre deux passages n’est vue qu’au passage suivant. Ce n’est pas un défaut de Wazuh, c’est une contrainte de la plateforme, mais mieux vaut le savoir avant de compter sur une alerte instantanée côté Mac. Autre détail qui piège, le répertoire doit exister avant que tu redémarres l’agent, sinon il est ignoré.

Si ça ne marche pas

Le déploiement d’agents, c’est simple quand tout va bien, et ça a toujours la même poignée de causes quand ça coince. Voici les vraies, dans l’ordre où tu les rencontreras.

Problème, l’agent reste en « Never connected »

Cause probable, dans neuf cas sur dix en ce qui nous concerne, un problème de chemin réseau. Soit les ports 1514 et 1515 ne sont pas ouverts sur tailscale0 côté manager, soit la machine n’est pas dans le Tailnet, soit tu as donné à l’agent l’IP publique du VPS au lieu de son IP Tailscale.

Solution, vérifie les trois. Sur le manager, sudo ufw status doit montrer tes règles 1514 et 1515 bien accrochées à tailscale0. Sur l’endpoint, tailscale status doit confirmer qu’il est bien dans le maillage. Et relis la valeur de WAZUH_MANAGER, elle doit pointer sur l’adresse Tailscale du manager, pas sur son IP publique.

Problème, l’agent passe de « Active » à « Disconnected »

Cause probable, il remontait, il ne remonte plus. Le manager coupe au bout de quinze minutes sans nouvelles. Souvent le service de l’agent s’est arrêté, ou la liaison Tailscale a sauté.

Solution, vérifie que le service tourne. sudo systemctl status wazuh-agent sur Linux, Start-Service WazuhSvc sur Windows, /Library/Ossec/bin/wazuh-control status sur macOS. Et jette un œil au log de l’agent, toujours au même endroit selon la plateforme, /var/ossec/logs/ossec.log sur Linux, /Library/Ossec/logs/ossec.log sur Mac, le dossier d’installation sur Windows.

Problème, le Mac est « Active » mais ne remonte presque rien

Cause probable, le fameux TCC. L’agent tourne, mais sans accès disque complet il est aveugle sur les zones protégées par macOS.

Solution, accorde-lui le Full Disk Access, par MDM sur un parc géré, à la main sur une machine isolée.

Problème, les agents sont « Active » mais le dashboard reste vide

Cause probable, attention, ce n’est pas un problème d’agent. Si les machines remontent bien mais que rien n’apparaît dans l’interface, le maillon qui coince est en aval, entre le manager et l’indexeur. Souvenir de l’épisode 2, c’est Filebeat qui pousse les alertes vers l’indexeur.

Solution, le diagnostic se fait côté serveur, pas côté agent. Tu vérifies que Filebeat parle bien à l’indexeur et que l’indexeur digère. Ne perds pas une heure à réinstaller des agents qui, eux, font parfaitement leur travail.

Le premier jour est bruyant, c’est normal

Un dernier mot d’honnêteté, parce que je préfère te le dire avant que tu le découvres seul. Le jour où tu branches dix machines d’un coup, ton dashboard va crépiter.

Chaque poste arrive avec son audit de configuration qui remonte des dizaines d’écarts par rapport au référentiel CIS. Chaque FIM signale des fichiers parfaitement légitimes qui changent au fil de l’usage. Au début, le bruit noie le signal, et c’est déstabilisant.

Ce n’est pas un bug. C’est l’état brut d’un SIEM qu’on vient d’allumer sur un parc réel. Le travail qui suit, calibrer les règles, écarter les faux positifs, régler les seuils pour n’être réveillé que quand ça compte, c’est du travail humain, pas de la magie logicielle. On l’a dit depuis l’ouverture de la série, le dur n’est pas la techno, c’est l’ajustement. Cet ajustement fin, l’alerting calibré, ce sera le bilan de l’épisode 7.

Pour l’instant, savoure. Ton SIEM ne se regarde plus le nombril, il voit ton réseau.

Pour les pressés

Ce que fait cet article. On déploie les agents Wazuh sur tout le parc, serveurs Linux, Mac, Windows, pour que chaque machine remonte ses logs, son audit de configuration, ses vulnérabilités et l’intégrité de ses fichiers au manager. Toute la remontée passe par le Tailnet, jamais par l’internet ouvert. On vérifie l’enrôlement, on étend la surveillance de fichiers, on encaisse le bruit du premier jour.

Concrètement, les commandes.

Sur le manager, ouvrir les ports agents sur le Tailnet uniquement : sudo ufw allow in on tailscale0 to any port 1514 proto tcp puis idem pour 1515. Jamais en global.
Prérequis absolu, chaque endpoint doit être dans le Tailnet (tailscale up).
Linux : ajouter le dépôt Wazuh, puis sudo WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent, puis systemctl enable --now wazuh-agent.
macOS : curl -O le .pkg arm64, écrire les variables dans /tmp/wazuh_envs, sudo installer -pkg ... -target /, sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist. Puis accorder le Full Disk Access à l’agent.
Windows : msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="windows", puis Start-Service WazuhSvc.
Vérifier depuis le manager : sudo /var/ossec/bin/agent_control -l, viser l’état Active partout.
Étendre le FIM via le groupe, dans /var/ossec/etc/shared/<groupe>/agent.conf, bloc <syscheck> avec check_all="yes" realtime="yes" (temps réel Linux et Windows seulement, pas macOS).

En résumé

Tu es parti d’un SIEM qui ne voyait que lui-même, tu repars avec un SIEM qui voit ton parc.

Tu as ouvert les ports agents sur le seul Tailnet, 1514 et 1515 sur tailscale0, jamais en public, fidèle à la promesse souveraine de la série. Tu as enrôlé tes trois familles de machines, Linux en trois commandes, Mac en gérant la contrainte TCC, Windows en MSI silencieux. Tu as vérifié la remontée avec agent_control -l et dans le dashboard, et tu as étendu la surveillance d’intégrité sur tes dossiers sensibles via les groupes.

Chaque machine que tu branches est gratuite côté licence, c’est du 100 % open source, sans limite d’agents. Là où le SaaS américain facture au volume de logs, donc au nombre de machines, plus tu vois large, plus tu paies. Chez toi, voir large ne coûte rien.

Mais tu observes. Tu vois les attaques, tu ne les arrêtes pas encore. À l’épisode 4, on ajoute la première ligne de défense active, CrowdSec, le réseau communautaire qui bloque les attaquants connus avant même qu’ils ne frappent à ta porte. Ton SIEM commence à mordre.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows. Tu viens de le lire.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Wazuh en tout-en-un, ton Splunk maison pour le prix d'un VPS

Mac Souverain — Sat, 20 Jun 2026 13:13:52 GMT

À l’épisode précédent, tu as monté un coffre-fort vide. Un VPS chez un hébergeur suisse, durci jusqu’à l’os, SSH par clé, pare-feu fermé, administration repliée derrière Tailscale, sauvegardes chiffrées hors-site. Une belle machine. Qui pour l’instant… ne surveille rien !

Aujourd’hui, on la remplit. On installe Wazuh, le cerveau de toute la pile, sur ce seul nœud. Manager, indexeur et tableau de bord, les trois composants centraux d’un SIEM, sur la même machine. C’est le mode tout-en-un, et c’est exactement ce dont une PME a besoin pour démarrer.

La promesse de la série tient en une phrase, on l’a posée dès l’ouverture. L’équivalent fonctionnel d’un Splunk, pour le prix d’un VPS. À la fin de cet article, tu auras une console de sécurité qui tourne, qui voit déjà ta propre machine, et qui t’a coûté zéro euro de licence. Là où le même périmètre chez un éditeur américain se chiffre de quelques milliers à plusieurs dizaines de milliers de dollars par an, selon la taille de ton parc, avec tes journaux logés dans une juridiction très défavorable à tes intérêts.

Cette stack, je l’utilise au quotidien. Les commandes qui suivent sont celles que tu vas taper toi-même, dans l’ordre, sur le serveur de l’épisode 1.

Trois composants, une seule machine

Avant d’installer, comprends ce que tu installes. Un SIEM Wazuh, ce n’est pas un bloc monolithique, ce sont trois rôles qui se passent le relais.

Le manager, c’est le cerveau. Il reçoit les journaux, fait tourner le moteur d’analyse, corrèle les événements, applique les règles et lève les alertes. C’est lui qui décide qu’une rafale d’échecs de mot de passe à 3 heures du matin mérite qu’on te réveille.
L’indexeur, c’est la mémoire. Il stocke et indexe les alertes pour que tu puisses les rechercher, filtrer, remonter dans le temps. C’est un fork d’OpenSearch, le moteur de recherche open source, lui-même issu d’Elasticsearch. Retiens ce détail, il va revenir nous compliquer la vie de la meilleure des façons.
Le dashboard, c’est la vitre. L’interface web par laquelle tu lis tout ça, accessible sur le port 443. Il interroge le manager pour la configuration et l’indexeur pour les données.

Un quatrième larron travaille dans l’ombre, Filebeat, le tuyau qui pousse les alertes du manager vers l’indexeur. Tu n’y toucheras pas, mais quand quelque chose coince, c’est souvent lui qu’on regarde.

En entreprise, ces trois composants vivent sur des machines séparées, pour encaisser le volume et tenir la haute disponibilité. Pour une PME jusqu’à une centaine de machines surveillées, c’est du gâchis. Le mode tout-en-un les pose tous les trois sur le même serveur, et c’est largement suffisant pour démarrer. La documentation officielle dimensionne d’ailleurs ce mode pour 1 à 100 agents.

On reviendra plus bas sur le moment où le tout-en-un ne suffit plus. Mais pour l’instant, une seule machine, et on y va.

L’installation en une commande

Wazuh propose deux chemins. Le premier, step-by-step, installe l’indexeur, puis le manager, puis le dashboard séparément, en éditant les fichiers de configuration à la main. C’est pédagogique, c’est long, et tu n’en as pas besoin pour un mono-nœud. Le second, c’est l’assistant officiel, qui fait tout d’un coup.

On prend l’assistant.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Décortiquons. Le curl -sO télécharge le script d’installation depuis le dépôt officiel Wazuh, branche 4.14. Le sudo bash ./wazuh-install.sh -a le lance avec les droits administrateur, et le flag -a veut dire all-in-one, tout-en-un. C’est ce flag qui demande à l’assistant d’installer et de configurer les trois composants sur cette même machine, de générer les certificats TLS qui chiffrent leurs échanges, et de fabriquer les mots de passe.

À la fin, l’assistant affiche dans la console le mot de passe du compte admin. Note-le, c’est ta première clé d’entrée. Si tu l’as raté en remontant le terminal, tu le récupères proprement :

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Cette commande extrait, sans le décompresser sur le disque, le fichier qui liste tous les mots de passe générés à l’installation. On va d’ailleurs s’en occuper dans un instant, parce que des mots de passe générés par un script, c’est un point de départ, pas un point d’arrivée.

Au moment où j’écris ces lignes, la version stable est la 4.14.5, sortie le 23 avril 2026. La cadence de patchs est quasi mensuelle sur la branche 4.14. L’URL d’installation pointe sur 4.14/, ce qui te sert toujours la dernière de la branche, donc tu n’as rien à changer tant que la 4.14 reste la stable. Si une 4.15 est sortie quand tu lis ça, vérifie la branche courante sur la page des notes de version avant de lancer la commande.

Le piège mémoire, là où 90 % des installs rament

Si tu ne dois retenir qu’une chose de cet épisode, c’est celle-ci. La cause numéro un des Wazuh qui rament, qui plantent, qui s’arrêtent au bout de trois jours, c’est la mémoire mal réglée sur l’indexeur.

Souviens-toi, l’indexeur est un fork d’OpenSearch, qui tourne sur la JVM, la machine virtuelle Java. Et la JVM réserve à son démarrage une zone de mémoire fixe pour travailler, qu’on appelle le heap (le tas). Trop petit, l’indexeur étouffe sous les données. Trop grand, il prend toute la RAM et asphyxie le manager, le dashboard et l’OS qui tournent à côté sur la même machine. C’est tout l’enjeu du mononœud, trois gros consommateurs de mémoire se partagent une seule enveloppe.

La règle officielle est nette, et elle est simple. Le heap, c’est la moitié de la RAM de la machine. Et les deux bornes, minimale et maximale, doivent être identiques.

Pourquoi identiques ? Parce que si tu laisses la JVM redimensionner son tas à chaud, en cours de route, elle passe son temps à réallouer de la mémoire au lieu d’indexer tes logs. En fixant le plancher et le plafond à la même valeur, tu lui dis « voilà ton bac à sable, ni plus ni moins, maintenant travaille ».

Ça se règle dans un fichier, /etc/wazuh-indexer/jvm.options.

sudo nano /etc/wazuh-indexer/jvm.options

Tu y cherches les deux lignes -Xms (la borne basse) et -Xmx (la borne haute), et tu les fixes à la moitié de ta RAM. Voici pourquoi l’épisode 1 t’a fait viser 12 Go de RAM et pas 8. Sur une machine de 12 Go, le heap prend 6 Go, et il reste 6 Go pour tout le reste, le manager, le dashboard, Filebeat, le système. De la marge pour respirer.

-Xms6g
-Xmx6g

Puis on redémarre l’indexeur pour qu’il prenne en compte la nouvelle valeur.

sudo systemctl restart wazuh-indexer

Si tu as démarré sur 8 Go pour tester, ta valeur de heap est -Xms4g / -Xmx4g, et tu vis avec 4 Go pour le reste, c’est juste mais ça tient pour une découverte.

Un dernier point pour les curieux. La règle « moitié de la RAM » a aussi un plafond absolu, ne jamais dépasser environ 32 Go de heap, au-delà la JVM perd une optimisation interne sur ses pointeurs mémoire. C’est une bonne pratique générale du moteur OpenSearch, pas une limite Wazuh spécifique, et à l’échelle d’une PME on en est très loin, donc tu peux l’oublier pour l’instant. Je te le mentionne pour que tu ne sois pas surpris si tu tombes dessus en montant un jour une grosse infra.

Tant qu’on parle de mémoire, une règle voisine. La JVM ne doit jamais swapper. Si le système se met à utiliser le disque comme mémoire d’appoint pour l’indexeur, les performances s’effondrent. Sur un VPS correctement dimensionné, avec le heap réglé à la moitié de la RAM, tu ne devrais pas swapper, mais c’est le premier réflexe de diagnostic le jour où ça rame.

Verrouiller la maison

L’installation t’a livré une console fonctionnelle. Elle t’a aussi livré des mots de passe générés par un script et un dashboard qui, par défaut, ne demande qu’à être joignable. Deux choses à reprendre en main avant de t’asseoir aux commandes.

Changer tous les mots de passe par défaut

Les mots de passe générés à l’installation ne sont pas mauvais en soi, mais ils traînent dans un fichier sur le serveur, et tu n’en es pas l’auteur. La bonne hygiène, c’est de tout régénérer avec tes propres secrets. Wazuh embarque un outil pour ça, déposé par l’assistant dans l’indexeur.

sudo bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a -A -au wazuh -ap <MOT_DE_PASSE_ACTUEL>

Le flag -a cible tous les utilisateurs, -A applique le changement, et le couple -au / -ap fournit l’utilisateur et le mot de passe administrateur actuels, ceux récupérés tout à l’heure. En mode tout-en-un, l’outil propage automatiquement les nouveaux mots de passe aux composants concernés, tu n’as pas à les recoller un par un.

Tes nouveaux mots de passe doivent respecter une complexité minimale, 8 à 64 caractères, au moins une majuscule, une minuscule, un chiffre, et un symbole parmi .*+?-. Génère-les avec ton gestionnaire de mots de passe, ne les invente pas de tête.

Les certificats, déjà là

Bonne nouvelle, tu n’as rien à faire côté chiffrement interne. L’assistant -a a généré une petite autorité de certification maison et déposé les certificats TLS sous /etc/wazuh-indexer/certs/ et compagnie. Les trois composants se parlent déjà en chiffré entre eux. C’est fait, c’est propre, on n’y touche pas.

Le seul effet visible, c’est qu’au premier accès au dashboard, ton navigateur affichera un avertissement de sécurité, parce que le certificat est auto-signé et non reconnu par une autorité publique. C’est normal, et pour un dashboard qui ne sera de toute façon jamais exposé au public, c’est parfaitement acceptable. Tu cliques pour continuer, et tu passes.

Un mot pour anticiper la tentation. Tu pourrais vouloir un « vrai » certificat reconnu, via Let’s Encrypt. Surtout pas ici. Let’s Encrypt valide ton certificat en vérifiant que ton serveur répond sur internet, donc en t’obligeant à ouvrir un port au monde entier. C’est l’exact contraire de ce qu’on construit depuis l’épisode 1.

Si l’auto-signé te dérange vraiment, Tailscale peut émettre un certificat propre pour ton nœud sans aucune exposition publique. Mais franchement, pour une console que tu es seul à consulter, l’auto-signé suffit. On ne va pas percer le mur qu’on vient de bâtir pour faire disparaître un avertissement de navigateur.

Le dashboard, invisible depuis internet

C’est le geste de sécurité le plus important de l’épisode, et c’est celui qui sépare un SIEM souverain d’un SIEM posé sur le trottoir. Par défaut, rien ne garantit que ton dashboard reste privé. Le port 443 qui sert l’interface ne doit jamais être joignable depuis internet.

Tes tableaux de bord de sécurité, c’est la carte de tes faiblesses, c’est précisément ce qu’un attaquant rêve de consulter.

La règle de la série, posée à l’épisode 1, est inflexible. Aucun service public. Le dashboard vit derrière Tailscale, accessible à toi seul, comme l’a fait SSH avant lui.

Deux verrous, complémentaires. D’abord, on demande au dashboard de n’écouter que sur l’adresse Tailscale du serveur, pas sur toutes les interfaces. Ça se règle dans son fichier de configuration.

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Tu y trouves la ligne server.host. Si elle vaut 0.0.0.0, le dashboard écoute partout, y compris sur l’IP publique. À proscrire. Tu la fixes sur l’IP Tailscale de ton serveur, celle que tu récupères avec tailscale ip -4, vue à l’épisode 1.

server.host: "<IP_TAILSCALE_DU_SERVEUR>"

Puis tu redémarres le dashboard.

sudo systemctl restart wazuh-dashboard

Ensuite, le pare-feu, en ceinture et bretelles. On reprend exactement le pattern de l’épisode 1 pour SSH, on autorise le port 443 uniquement sur l’interface du réseau privé, jamais en global.

sudo ufw allow in on tailscale0 to any port 443 proto tcp

Le piège à éviter, c’est de taper sudo ufw allow 443/tcp tout court. Cette commande-là ouvre le dashboard au monde entier. La nôtre ne l’ouvre que sur tailscale0, ton maillage chiffré. La nuance est tout sauf cosmétique, l’une expose ta console de sécurité aux scanners du monde entier, l’autre la rend invisible.

Le résultat, c’est un dashboard joignable seulement par un membre de ton réseau privé. Un scan de ton IP publique ne révèle rien. Conforme à la promesse souveraine, et conforme au bon sens.

Le tour du propriétaire

Connecte-toi. Depuis une machine membre de ton Tailnet, tu ouvres https://<IP_TAILSCALE_DU_SERVEUR> dans ton navigateur. Avertissement de certificat, tu passes. Login admin, ton nouveau mot de passe. Tu es dans la console.

Cette capture vient d’une instance Wazuh en production, déjà peuplée de plusieurs agents. Sur ton install toute fraîche, tu ne verras pour l’instant que l’agent 000, le serveur qui se surveille lui-même.

Et là, surprise agréable, ce n’est pas vide. Tu t’attendais peut-être à un écran inerte en attendant de déployer des agents. Pas du tout. En mode tout-en-un, le serveur embarque un agent local, sous l’identifiant 000, qui se surveille lui-même. Ta machine est déjà sous l’œil de ton propre SIEM, avant même d’avoir touché au reste de ton parc.

Concrètement, tu as déjà des données et plusieurs modules qui tournent sur ce nœud.

SCA, pour Security Configuration Assessment, l’audit de configuration. Il est actif par défaut, sans rien régler, et il scanne ta machine contre des référentiels de durcissement type CIS. Il te dit où ta config s’écarte des bonnes pratiques, un service de trop, une permission trop large, un réglage SSH oublié. Tu vas probablement y retrouver, validées noir sur blanc, les décisions de durcissement de l’épisode 1.
La détection de vulnérabilités. Wazuh inventorie les paquets installés sur la machine et les croise avec les bases de CVE connues. Si un de tes paquets traîne une faille publiée, il te le signale, avec la référence et la criticité. Une nuance d’honnêteté, contrairement au SCA et au FIM qui tournent seuls, le scan du nœud local ne se déclenche pas au premier démarrage. Il faut l’activer d’un réglage, passer vulnerability-detection.disable_scan_manager à 0 dans /var/ossec/etc/internal_options.conf puis redémarrer le manager. Deux minutes, et ta propre machine est scannée elle aussi.
Le FIM, File Integrity Monitoring, la surveillance d’intégrité des fichiers. Il garde l’empreinte de tes fichiers sensibles et t’alerte si l’un d’eux change. Un fichier système modifié sans raison, c’est souvent le premier signe qu’on a un invité.
L’analyse des logs locaux, qui digère les journaux de la machine et les transforme en alertes lisibles.

Et il y a les tableaux de bord de conformité, prêts à l’emploi. Wazuh livre des vues taguées PCI DSS, HIPAA, RGPD, NIST 800-53, TSC, avec génération de rapports. Chaque alerte porte l’identifiant de conformité qu’elle touche, par exemple un tag gdpr_IV_32 qui renvoie à l’article 32 du RGPD sur la sécurité du traitement. C’est exactement le matériau dont tu as besoin pour le triptyque de notification qu’on a martelé à l’ouverture, détecter, journaliser, prouver.

Une honnêteté nécessaire sur NIS2, justement. Wazuh fournit toutes les briques fonctionnelles que NIS2 réclame, monitoring continu, intégrité des fichiers, analyse de vulnérabilités, contrôle de configuration, reporting. Mais il n’existe pas de tableau de bord NIS2 prêt à cliquer comme il en existe un pour le RGPD.

Pour suivre NIS2 finement, tu construiras tes propres vues, en t’appuyant sur les tags RGPD et NIST déjà présents. Wazuh te donne l’outillage de conformité, il ne te rend pas conforme tout seul. Le calibrage des règles, le réglage de la rétention, la réponse aux alertes, ça reste du travail humain. On l’a dit dès l’ouverture, le dur n’est pas la techno, c’est l’ajustement.

Pour l’instant, ton SIEM se voit lui-même. Il ne voit pas encore le reste de ton parc informatique. C’est précisément l’objet de l’épisode suivant.

Quand le tout-en-un ne suffit plus

Le mono-nœud n’est pas magique, et je ne vais pas te vendre l’inverse. Il a un plafond, autant que tu saches où il se situe avant de t’y cogner.

La métrique qui compte, c’est l’EPS, les événements par seconde que ta machine encaisse. Un nœud bien dimensionné, de l’ordre de 16 Go de RAM et 8 vCPU, absorbe grossièrement 5 000 événements par seconde. Pour une PME jusqu’à 50 ou 100 machines surveillées, avec des journaux d’activité normaux, tu es très loin de saturer. Le tout-en-un tient largement.

Le jour où tu t’en approches, le symptôme est désagréable. Quand la file d’ingestion sature, Wazuh ne ralentit pas poliment, il jette les événements qu’il n’a pas le temps de traiter. Et un événement jeté, c’est une alerte que tu ne verras jamais. Une caméra qui arrête d’enregistrer aux heures de pointe.

À ce moment-là, tu passes en multi-nœuds, le manager d’un côté, l’indexeur de l’autre, voire plusieurs de chacun. Détail contre-intuitif mais important, Wazuh scale mieux horizontalement que verticalement. Deux nœuds à ressources moyennes valent mieux qu’un seul gros nœud. C’est un autre chantier, hors de cette série, mais tu sais désormais que la porte existe.

Pour une PME qui démarre, retiens ça, le tout-en-un est parfait pour commencer, pas conçu pour l’infini. Et entre les deux, il y a beaucoup de place.

Ce que ça t’aurait coûté ailleurs

On a tease ce chiffrage depuis l’ouverture de la série. Le moment est venu de le poser, pour cette brique précise.

Côté Wazuh, le coût de licence est de zéro. C’est du 100 % open source, sous licence GPLv2, et il n’y a aucun palier payant. Pas de limite d’agents, pas de limite d’utilisateurs, pas de limite de logs ingérés. Ta seule dépense, c’est le VPS que tu as monté à l’épisode 1, entre 15 et 30 euros par mois selon le dimensionnement, plus ton temps d’installation et de calibrage. Et c’est tout.

Côté Splunk, la facture a une autre tête. Un avertissement d’abord, Splunk ne publie pas ses tarifs officiellement, donc tout ce qui suit relève de l’ordre de grandeur reconstitué par des sources secondaires sérieuses, pas du devis officiel. Avec cette réserve, le principe est simple, tu paies au volume de logs avalé chaque jour, compté en gigaoctets par jour.

Reste à traduire ça pour un parc réel, parce qu’un prix au gigaoctet ne parle à personne tant qu’on ne sait pas combien de gigaoctets une PME produit. Repère utile, avec une journalisation de sécurité raisonnable, compte autour de cinquante mégaoctets de logs par poste et par jour, soit à peu près un gigaoctet par jour pour quinze à vingt postes. De là, on peut poser des montants, licence seule, en gardant Wazuh en miroir.

15 postes, environ 1 Go de logs par jour. Splunk, de l’ordre de 2 000 à 5 000 dollars par an. Wazuh, le VPS, 180 à 360 euros par an. Point.
50 postes, environ 4 à 5 Go par jour. Splunk, de l’ordre de 8 000 à 12 500 dollars par an. Wazuh, le même VPS, à l’euro près.
100 postes, environ 8 à 10 Go par jour. Splunk, de l’ordre de 15 000 à 25 000 dollars par an. Wazuh, toujours le même VPS.

Au-delà de cent postes surveillés, on change de monde des deux côtés, cluster multi-nœuds chez Wazuh, paliers à plusieurs dizaines voire centaines de milliers de dollars chez Splunk. C’est une autre échelle, hors du périmètre de cette série pensée pour la PME.

La différence n’est pas qu’une histoire de montant. C’est une histoire de trajectoire. Chez Wazuh, ton coût d’infrastructure est plat, tu ingères plus de logs, ton VPS encaisse, ta facture ne bouge pas. Chez Splunk, le compteur tourne à chaque gigaoctet supplémentaire. Plus ton SIEM voit large et profond, plus il te coûte cher, alors que voir large et profond, c’est littéralement son métier. Tu es facturé sur la qualité même de ta surveillance.

Et il y a la question qui a fondé cette série, celle de la juridiction. Tes logs, ce sont les empreintes complètes de ton réseau. Chez Wazuh, ils dorment sur ta machine, en Suisse, sous ton contrôle.

Chez le SaaS américain, ils sont réquisitionnables au titre du CLOUD Act. Le prix, c’est une chose. Qui détient la donnée, c’en est une autre, et c’est celle qui compte le plus.

En résumé

Tu es parti d’un coffre-fort vide, tu repars avec une console de sécurité qui tourne.

Tu as installé les trois composants de Wazuh en une commande, manager, indexeur et dashboard sur ton seul nœud. Tu as réglé le piège qui fait échouer la plupart des installs, le heap de l’indexeur à la moitié de la RAM, bornes identiques, ce qui justifie les 12 Go recommandés à l’épisode 1.

Tu as repris la main sur la sécurité, mots de passe régénérés, certificats déjà en place, et surtout dashboard verrouillé en Tailnet-only, invisible depuis internet. Et tu as fait ton premier tour du propriétaire, SCA, vulnérabilités, intégrité des fichiers, tableaux de bord RGPD, le tout sur ta propre machine, sans avoir déployé le moindre agent distant.

Le tout pour zéro euro de licence, là où l’équivalent SaaS se compte de quelques milliers à plusieurs dizaines de milliers de dollars par an selon la taille de ton parc, avec tes journaux les plus sensibles logés sous une juridiction étrangère.

Mais ton SIEM ne voit encore que lui-même. Il regarde sa propre machine, et c’est déjà précieux pour valider ton durcissement. Le vrai saut, c’est quand il commence à voir le reste, tes serveurs, tes Mac, tes postes Windows. C’est l’épisode 3, le déploiement des agents, le moment où ton SIEM commence vraiment à voir ton réseau.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud. Tu viens de le lire.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Ta position fuite par le réseau, pas par ton iPhone

Mac Souverain — Wed, 17 Jun 2026 13:41:39 GMT

Le Citizen Lab a relié, dans son rapport « Bad Connection » d’avril 2026, du trafic de surveillance réel à des infrastructures d’opérateurs. Des sociétés commerciales localisent n’importe quel mobile via les failles d’interconnexion du réseau, SS7 en 2G/3G, Diameter en 4G, sans jamais toucher l’appareil. Rien à patcher sur ton iPhone : le trou est dans le réseau, pas dans iOS.

Ce que tu dois surveiller

1. Aucun réglage ne bloque ce vecteur : ni mode Isolement, ni eSIM, ni Signal, ni couper la data. La seule parade, te rendre injoignable en mode avion ou téléphone éteint. Ne te crois pas couvert parce que tu chiffres tes messages.

2. Passe tes codes de connexion en 2FA par application, pas par SMS. Ça ne stoppe pas la géoloc, mais ça ferme l’interception des codes via le même réseau.

3. La vraie défense est structurelle, côté opérateurs et régulateurs. NIS2 et ENISA cadrent le risque, mais aucune obligation technique forte n’impose encore de sécuriser l’interconnexion.

Le Citizen Lab a publié en avril 2026 un rapport qui relie pour la première fois du trafic de surveillance réel à des infrastructures d’opérateurs identifiées. Le principe est connu depuis dix ans, mais le constat reste dérangeant : des sociétés commerciales localisent n’importe quel mobile dans le monde sans jamais toucher à l’appareil. Ton iPhone n’y est pour rien, et c’est précisément le problème.

Le fait

Le rapport s’appelle « Bad Connection ». Il documente des acteurs qui traquent des téléphones à travers une vingtaine de pays, plus de 1700 attaques pour l’un d’eux, dont la quasi-totalité dédiée à la géolocalisation. La cible décrite est un « VVIP » au Moyen-Orient, mais le profil habituel de ce marché est connu : journalistes, opposants, responsables politiques.

La mécanique exploite les protocoles qui font dialoguer les opérateurs entre eux quand tu pars à l’étranger ou que tu changes d’antenne. Ils ont été conçus à une époque où une poignée d’opérateurs nationaux se faisaient mutuellement confiance. Aujourd’hui ils sont des milliers, et cette confiance implicite est devenue une porte d’entrée. Trois vecteurs cohabitent : SS7 sur la 2G et la 3G, Diameter sur la 4G, et une variante baptisée SIMjacker qui passe par un SMS silencieux exécuté sur ta carte SIM. Le Citizen Lab est catégorique : ce ne sont pas des bugs logiciels, mais des défauts inhérents à la conception même des télécoms mondiales.

Une précision qui change tout : en général, ce n’est pas ton opérateur qui vend ta position. Il faut distinguer deux marchés. Le premier existe bel et bien : aux États-Unis, les grands opérateurs ont revendu la localisation de leurs abonnés à des courtiers de données, ce qui a valu près de 200 millions de dollars d’amendes de la FCC en 2024.

Le second, le cœur de ce radar, est différent : des sociétés de surveillance comme Rayzone, Circles ou Cognyte exploitent les failles d’interconnexion en louant des points d’accès légitimes au réseau mondial, le « Global Title leasing », souvent via un petit opérateur complice. Elles interrogent à distance le réseau de ta cible, sans son consentement ni celui de son opérateur.

Pourquoi ça compte pour toi

Voilà l’angle qui dérange. Tu peux chiffrer tes messages, durcir ton Mac, fermer chaque réglage de macOS un par un, ta position physique continue de transiter par une infrastructure que tu ne maîtrises pas et sur laquelle Apple n’a aucune prise. Rien à patcher de ce côté, parce que ce n’est pas un trou dans iOS. C’est l’architecture du réseau lui-même.

Du coup, la plupart des gestes barrière auxquels tu penses ne servent à rien contre ce vecteur précis, et il vaut mieux le savoir que se rassurer à bon compte. Le mode Isolement durcit ton iPhone, il ne touche pas une requête SS7 qui se passe dans le réseau. L’eSIM change le format de la carte, pas le protocole : tant qu’il y a un numéro joignable, l’exposition est identique.

Signal protège le contenu de tes messages, pas les métadonnées de signalisation qui révèlent où tu es. Couper la data ou le GPS ne change rien non plus, la traque utilise l’identifiant de cellule, pas ta puce. La seule parade individuelle réellement efficace, c’est le mode avion ou le téléphone éteint, autant dire inapplicable au quotidien.

Deux nuances pour ne pas te vendre de faux remparts. La 2FA par application a une vraie utilité, mais contre un autre risque : l’interception de tes codes par SMS, pas la géolocalisation. Un numéro ou une eSIM dédiés réduisent le lien entre ta position et ton identité réelle, sans rendre ce numéro moins traçable.

La vraie défense, elle, est structurelle. Elle se joue chez les opérateurs et les régulateurs, avec des pare-feu de signalisation que la GSMA documente dans son guide FS.11. Ta sécurité ici ne dépend pas de toi, mais d’une infrastructure et d’un cadre légal que tu ne contrôles pas.

Soyons clairs sur le risque réel : pour un particulier lambda, la probabilité d’être ciblé reste faible. Ce sujet compte par ce qu’il révèle, pas par une menace imminente sur ta personne. La souveraineté numérique ne s’arrête pas au bord de ton appareil : tant que tu as une carte SIM, ta position circule dans un réseau mondial faiblement contraint.

Ce que tu fais maintenant

1. Recalibre tes attentes, c’est le geste le plus utile ici. Garde Signal, le mode Isolement et tes bons réflexes, ils protègent le contenu et l’appareil, mais ne crois pas qu’ils te rendent invisible sur le réseau. Confondre les deux, c’est le piège.

2. Pour les codes de connexion, abandonne le SMS et passe à la 2FA par application ou clé matérielle. Ça ne te protège pas de la géoloc, mais ça ferme l’interception des codes via le même réseau, et c’est un risque concret pour tes comptes.

3. Si tu as un profil réellement exposé, journaliste, opposant politique ou avocat sur dossier sensible, le seul levier individuel sérieux est la discipline physique : en mode avion ou téléphone éteint, ton appareil n’est plus inscrit au réseau, il n’y a rien à localiser. Tu ne redeviens traçable qu’à la réinscription. Un numéro dédié cloisonne ton identité, mais reste traçable de la même façon.

4. Pour le reste, le vrai chantier n’est pas sur ton bureau. Suis le sujet côté régulateur : NIS2 et ENISA posent un cadre, mais aucune obligation technique forte n’impose encore aux opérateurs de fermer ces failles. C’est là que la pression doit porter.

Sources

Bad Connection, Uncovering Global Telecom Exploitation by Covert Surveillance Actors, Citizen Lab, avril 2026 (source primaire)
Signalling Security in Telecom SS7/Diameter/5G, ENISA (protocoles jugés fondamentalement faillis, recommandations UE)
FS.11 SS7 Interconnect Security Monitoring and Firewall Guidelines, GSMA (la référence pare-feu de signalisation, autorégulation industrielle)
Hacking Your Phone, 60 Minutes, CBS, 2016 (écoute du représentant Ted Lieu via SS7, démonstration sur un élu)
FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data, Krebs on Security, 2024 (le marché distinct des courtiers de données, 200M USD d’amendes)

Des termes techniques ? Consulte le glossaire.

Ton IA peut être éteinte par les US, monte la tienne

Mac Souverain — Wed, 17 Jun 2026 13:40:54 GMT

Mise à jour, juillet 2026. Fable 5 est de nouveau accessible, la directive a été levée. Ça ne change rien à la thèse, au contraire. Coupé hier, rendu aujourd’hui, par une décision que tu ne tiens pas : c’est exactement ça, dépendre d’un diktat étranger. Ton modèle local, lui, n’a pas besoin qu’on l’autorise.

Tu ouvres ton Mac un matin. Ton outil d’IA habituel refuse de répondre. Pas un bug, pas une panne de serveur. Un message poli t’explique que l’accès n’est plus disponible dans ta région. Tu n’as rien fait de mal. Tu paies ton abonnement. Tu es parfaitement en règle. Mais tu es du mauvais côté d’une frontière, et quelqu’un à Washington a décidé que ça suffisait.

Ce n’est plus de la science-fiction. En juin 2026, le gouvernement américain a ordonné à Anthropic, par une directive de contrôle à l’export, de suspendre l’accès de tout ressortissant étranger, partout dans le monde et jusqu’à ses propres employés, à ses deux modèles les plus avancés, Mythos 5 et Fable 5.

Anthropic a dû les débrancher pour l’ensemble de ses clients, et conteste la décision. L’accès à l’intelligence artificielle de frontière est en train de devenir ce que sont déjà le pétrole, les puces et le dollar, un levier de puissance entre les mains d’un État.

Et toi, tu es au bout du tuyau dont on vient de couper le robinet.

La directive comme révélateur

Le réflexe, en lisant ça, c’est de penser géopolitique. Grandes manœuvres, blocs qui s’affrontent, sujets pour éditorialistes. Sauf que la coupure, elle, n’arrive pas à un bloc. Elle arrive à toi, sur ta machine, un mardi matin.

L’asymétrie est totale. D’un côté, un fournisseur sous juridiction américaine, soumis aux directives de son administration, libre de modifier ses conditions d’accès du jour au lendemain. De l’autre, toi, qui as construit une partie de ta façon de travailler autour de cet outil. Tu n’as aucune prise sur la décision. Tu n’es même pas la cible. Tu es un dommage collatéral d’une politique qui ne te concerne que par ta nationalité, ou ta géolocalisation.

C’est le point que la directive rend enfin visible : l’accès à un modèle distant n’a jamais été un acquis technique, c’est une autorisation politique. Tant que rien ne bouge, l’autorisation est tacite, invisible, confortable. On finit par la confondre avec un droit. Le jour où elle est retirée, on découvre qu’on ne possédait rien. On louait.

Pose-toi une seule question. Si on te coupe l’accès du jour au lendemain, qu’est-ce qui continue de tourner ? Si la réponse est « plus rien », tu n’as pas un outil de travail. Tu as une dépendance.

Ce que dépendre d’un modèle distant coûte vraiment

Le modèle distant de frontière est génial. C’est vrai, et le reconnaître n’enlève rien à la suite. Il est plus puissant que tout ce que tu feras tourner chez toi à court terme. Il se met à jour sans que tu lèves le petit doigt. Il ne te demande ni RAM, ni installation, ni maintenance. Pour beaucoup d’usages, c’est l’outil le plus efficace du marché.

Mais le confort a un prix, et ce prix n’apparaît pas sur la facture.

Chaque requête que tu envoies à un modèle distant, c’est ton texte qui quitte ta machine. Tes brouillons, tes notes, tes documents, tes raisonnements en cours. Ils transitent par une infrastructure que tu ne contrôles pas, dans une juridiction qui n’est pas la tienne, soumise à des règles que tu ne votes pas. Le chiffrement en transit protège le tuyau, pas la destination. À l’arrivée, ton texte est lu en clair par la machine qui répond.

Et puis il y a la dépendance de continuité, celle dont on ne parle jamais avant qu’elle ne morde. Ton accès dépend d’un abonnement, d’une politique tarifaire, d’une décision commerciale, et maintenant d’une directive d’État. Trois leviers que tu ne tiens pas, plus un quatrième que tient un gouvernement étranger, et c’est le plus dangereux. Le jour où l’un d’eux bascule, ton workflow s’arrête. Pas progressivement. D’un coup.

C’est exactement le piège qu’on décrivait pour le cloud de stockage. Tes fichiers sur le serveur de quelqu’un d’autre, c’est pratique jusqu’au jour où le compte est suspendu. L’IA distante, c’est le même contrat, appliqué à ta façon de penser et de produire.

À lire : Le cloud, c’est l’ordinateur de quelqu’un d’autre

Le réflexe souverain, la carte des modèles locaux

Voilà la bonne nouvelle, et elle est plus solide qu’on ne le croit. Faire tourner un modèle d’IA capable, directement sur ton Mac, n’est plus un fantasme de bricoleur. La mémoire unifiée d’Apple Silicon, celle-là même qu’Apple vend pour la fluidité de ses apps, est précisément ce qui rend l’inférence locale possible sur une machine grand public.

Avant la carte, une règle de budget, parce que tout part de là.

Première chose, la RAM totale n’est pas la RAM disponible. macOS et tes applications en consomment une partie en permanence. Et derrière le mot « Mac », il y a deux machines très différentes.

Le Mac mini d’entrée de gamme, le plus répandu, embarque 16 Go de RAM unifiée. En comptant 6 à 8 Go pour le système et tes apps, il te reste entre 8 et 10 Go réellement utiles pour l’IA, et encore, en fermant ce qui traîne.

Une machine à 32 Go suit le même principe, mais te laisse une vingtaine de gigas de marge. Dans ce budget utile doivent tenir deux choses en même temps : le poids du modèle (le modèle lui-même) et le contexte (ce que tu lui donnes à lire et ce qu’il génère).

La règle pratique : ne jamais viser un modèle qui remplit tout le budget utile. Sur 16 Go, ça veut dire un modèle de 4 à 8 Go une fois quantifié. Sur 32 Go, tu peux monter à 14, voire 20 Go. Si tu débordes, la machine bascule sur le disque comme mémoire de secours, et là, ça rame, ou alors ça plante complètement.

Voici donc la carte de ce qui tourne, du plus accessible au plus gourmand.

Ce qu’un Mac à 16 Go fait déjà tourner. C’est le socle accessible, et il couvre l’essentiel de ton volume quotidien.

Pour le travail léger, trier des emails, classer des notes, extraire ou anonymiser un texte, de tout petits modèles de 2 à 3 Go suffisent largement : Llama 3.2 3B, Gemma 3 4B, Phi-4-mini.

Pour le travail général, résumer un document, rédiger un brouillon, gérer ta correspondance, interroger ta propre base de notes, un modèle de 7 à 8 milliards de paramètres autour de 5 Go fait le job : Qwen2.5 7B, sous licence Apache 2.0, ou Llama 3.1 8B. C’est le cheval de trait d’un 16 Go.

Pour lire un PDF scanné ou une facture sans l’envoyer ailleurs, Qwen2.5-VL 7B (autour de 5 Go) ou Llama 3.2 Vision 11B passent aussi. Le plafond, c’est un modèle de 12 à 14 milliards de paramètres en quantification serrée, autour de 8 à 9 Go, comme Qwen2.5 14B : il passe, mais en fermant le reste et avec un contexte court.

Sur ces tâches répétitives et cadrées, le local ne se contente pas de faire le job, il le fait mieux : zéro latence réseau, zéro requête facturée, et tes données ne bougent pas d’un millimètre.

Ce que 32 Go débloque en plus. Le passage à 32 Go n’est pas un luxe, c’est ce qui ouvre la catégorie au-dessus.

Pour la rédaction soutenue et l’analyse de longs documents, Mistral Small 3, un modèle de 24 milliards de paramètres, tient autour de 14 Go en version quantifiée et il est sous licence Apache 2.0, donc vraiment libre. Gemma 3 27B tourne autour de 16 Go.

Pour le raisonnement multi-étapes, les modèles de 32 milliards de paramètres passent en serrant un peu : QwQ 32B, DeepSeek-R1-distill 32B ou Qwen2.5 32B occupent 19 à 20 Go en quantification Q4. Le contexte devient serré, et sur les raisonnements les plus exigeants, l’écart avec un modèle de frontière reste réel. Le local fait beaucoup. Il ne fait pas encore tout.

Côté code, Qwen2.5-Coder 32B atteint une quasi-parité avec les modèles distants pour la programmation du quotidien, compléter, expliquer, déboguer, refactoriser.

Et ce qui ne passe ni sur 16 ni sur 32 Go. Les très gros modèles, Llama 3.3 70B, les modèles à 405 milliards de paramètres, DeepSeek-R1 en version complète, exigent 64 Go de RAM ou plus. Inutile de prétendre le contraire.

Maintenant, la souveraineté ne se résume pas à la capacité brute. Deux autres axes comptent.

Le premier, c’est la provenance. Mistral est français et européen, ce qui en fait le choix souverain naturel pour un lecteur européen. Llama, Gemma et Phi sont américains. Qwen et DeepSeek sont chinois.

Une nuance s’impose ici, et elle est importante : comme les modèles tournent en local, aucune donnée ne sort de ta machine, quelle que soit l’origine du modèle. La provenance ne joue donc pas sur l’exfiltration des données, elle joue sur la confiance, l’auditabilité, et sur le fait de ne pas mettre tous ses œufs dans un seul panier géopolitique.

Faire tourner un modèle chinois en local n’envoie rien à Pékin. Choisir un modèle européen, c’est arbitrer sur l’écosystème qu’on soutient et sur ce qu’on peut inspecter, pas sur un risque de fuite.

Le second axe, c’est la licence. Tous les modèles « ouverts » ne se valent pas juridiquement. Mistral Small 3 et plusieurs Qwen sont sous Apache 2.0, une licence permissive qui te laisse vraiment libre, y compris pour un usage professionnel.

La licence communautaire de Llama est utilisable, mais assortie de restrictions. Pour un socle souverain, la licence libre n’est pas un détail de juriste, c’est la garantie que personne ne peut changer les règles sous tes pieds.

Mon pick souverain par défaut, en cohérence avec tout ça. Sur un 16 Go, un 7-8B fait déjà tourner l’essentiel : Qwen2.5 7B (Apache 2.0) en premier choix, ou Llama 3.1 8B. Sur un 32 Go, tu passes à Mistral Small 3 comme bête de somme quotidienne (européen, Apache 2.0), épaulé par un modèle de raisonnement 32B, QwQ ou DeepSeek-R1-distill, qu’on sort pour les analyses plus dures. Pour les faire tourner, trois outils suffisent : Ollama et LM Studio pour la simplicité, MLX pour qui veut exploiter au mieux Apple Silicon.

À lire : Apple Intelligence, ce qui sort vraiment de ton Mac

Le seuil réaliste, ce que le local fait bien

Il ne s’agit pas de claquer la porte au cloud pour le plaisir. Il s’agit de savoir ce qui doit vivre chez toi, et ce qui peut, éventuellement, sortir.

Le local fait très bien tout ce qui est répétitif, sensible, ou simplement quotidien. Trier, résumer, rédiger, corriger, classer, anonymiser, lire tes propres documents. Pour cette part-là de ton travail, qui est l’essentiel du volume, tu n’as besoin de personne. Ça tourne sans connexion, sans facture par requête, sans qu’une ligne de ton texte quitte ta machine.

Le cloud de frontière reste gagnant pour le sommet de la pyramide, le raisonnement le plus complexe, le problème inédit où chaque point de performance compte. Mais un appoint reste un appoint. On n’adosse pas son travail courant à un robinet qu’un tiers peut fermer.

La bonne posture n’est pas « tout local » ou « tout cloud ». C’est le cloisonnement. Le local devient ta base, ce qui tourne par défaut, ce sur quoi repose ton travail courant et tout ce qui touche à des données sensibles.

Le cloud devient un appoint conscient, qu’on sollicite pour un usage précis, en sachant ce qu’on lui envoie et en n’y mettant jamais ce qui ne doit pas sortir. Le jour où on te coupe l’accès cloud, tu perds un appoint. Tu ne perds pas ton socle.

C’est là que l’argument boucle. Si tu lis ces lignes sur un Mac récent, tu es déjà en Apple Silicon. La mémoire unifiée qui fait tourner ces modèles, tu l’as déjà payée. Ce passage au local n’attend pas un investissement, ni une nouvelle machine, ni une compétence d’ingénieur. Il attend une décision.

La souveraineté en matière d’IA ne se mesure pas à la puissance du modèle que tu loues. Elle se mesure à ce qui continue de tourner le matin où on te coupe l’accès. Le modèle distant, c’est du confort, et de la puissance quand une tâche l’exige.

Ton socle IA, c’est ce qui vit sur ta machine. Installe-en un. Fais-le tourner une fois, sur une vraie tâche, pour voir. Tu sauras alors, concrètement, ce qui te reste quand on ferme le robinet.

Reste la question la plus terre à terre : comment on installe tout ça, concrètement ? C’est l’objet du prochain article, étape par étape, du téléchargement au premier prompt, sans ligne de commande indigeste.

À lire bientôt : Installer et faire tourner ton premier modèle local sur Mac, le guide pas à pas

Sources

Le déclencheur, directive US et Anthropic

Anthropic, Statement on the US government directive to suspend access to Fable 5 and Mythos 5, la déclaration officielle, Anthropic applique l’ordre d’export tout en le contestant (12 juin 2026).
TechCrunch, Anthropic’s safety warnings may have just backfired, le débranchement mondial de Fable 5 et Mythos 5 (12 juin 2026).
The Register, US clampdown on Anthropic models sends EU sovereignty surge into overdrive, comment la coupure accélère la bascule souveraine de l’Europe, l’angle même de cet article (15 juin 2026).

Modèles open-weight cités

Mistral AI, Mistral Small 3, le 24B Apache 2.0, pick souverain européen (30 janvier 2025).
Qwen, Qwen2.5, la famille Qwen2.5, variantes 7B sous Apache 2.0.
Meta, Llama 3.1 Community License, licence permissive mais assortie de restrictions.

Exécution locale sur Apple Silicon

Ollama, faire tourner des modèles en local, données qui ne quittent pas la machine.
LM Studio, app de bureau pour exécuter des LLM en privé, support MLX sur Mac.
Apple, MLX, le framework optimisé pour la mémoire unifiée d’Apple Silicon.

Des termes techniques ? Consulte le glossaire.

Le socle de ton SIEM souverain, un VPS durci hors CLOUD Act

Mac Souverain — Fri, 12 Jun 2026 06:11:45 GMT

Avant de détecter quoi que ce soit, il te faut un endroit où installer ton SIEM. Une machine. Pas n’importe laquelle, pas configurée n’importe comment.

Dans l’épisode d’ouverture, on a posé le pourquoi. RGPD t’oblige déjà à détecter une violation et à la notifier en 72 heures, NIS2 a élargi le filet, et ce n’est pas fini. Le SaaS américain fait le boulot mais livre tes journaux les plus sensibles, sur simple demande administrative du gouvernement US. Tout cela est extrêmement défavorable à tes intérêts, tu en conviendras.

Alors comment résoudre ce dilemme ? La conclusion est simple, tu montes ton propre SIEM, conforme RGPD et NIS2, sur une infrastructure que tu contrôles totalement.

Cet article-là, c’est la première brique. Le socle.

Tout le reste de la série va s’empiler dessus. Wazuh à l’épisode 2, les agents à l’épisode 3, la défense réseau, le filtre mail, le contrôle d’exécution. Si le socle est bancal, toute la pile est bancale. Un SIEM qui surveille ton parc mais qui tourne sur une machine elle-même percée, c’est une caméra de surveillance branchée sur une porte grande ouverte.

Cette stack que je te recommande, je l’utilise au quotidien. Je vais te montrer comment monter ton socle, dans l’ordre, avec les commandes réelles. Tu peux le reproduire aujourd’hui.

Choisir l’hébergeur, la juridiction avant le reste

Première décision, et c’est la plus structurante. Où va vivre ta machine.

La tentation, c’est d’aller au moins cher ou au plus connu. AWS, Google Cloud, Azure. Ils sont excellents techniquement. Et ils sont tous de nationalité américaine, donc soumis au CLOUD Act, cette magnifique loi de 2018 qui permet aux autorités US de réquisitionner les données d’un fournisseur américain, où qu’elles soient stockées dans le monde, datacenter européen compris.

Mettre les journaux de sécurité de ton SI là-dedans, c’est exactement le problème qu’on essaie de résoudre depuis le départ. Pour être raccord, ce qu’on cherche, c’est donc un hébergeur dont le siège, les serveurs et le capital échappent à cette exception US.

Trois critères à vraiment considérer, je te les donne.

La juridiction du siège social. Une entreprise européenne sans société mère américaine n’est pas soumise au CLOUD Act. Suisse, Allemagne, France, etc. La nuance, c’est la filiale, un hébergeur européen qui a ouvert une entité aux États-Unis expose au CLOUD Act les ressources hébergées dans cette filiale. Le siège ne suffit pas, il faut regarder où vivent physiquement tes données.
La localisation des datacenters. Tes logs doivent rester sur des serveurs européens, point. Pas de réplication transatlantique « pour ta disponibilité ».
Le prix, en dernier. Un VPS pour démarrer un SIEM PME coûte entre 5 et 25 euros par mois. À ce niveau, l’écart de prix entre les opérateurs souverains est marginal. Tu ne choisis pas ton hébergeur de sécurité au centime près.

Concrètement, deux noms reviennent quand on croise ces critères.

Infomaniak, hébergeur suisse basé à Genève, détenu à 100 % par ses fondateurs et ses salariés, sans fonds d’investissement extérieur. Serveurs exclusivement en Suisse, sous nLPD, la loi fédérale suisse de protection des données entrée en vigueur en septembre 2023, alignée sur le RGPD et reconnue par décision d’adéquation européenne.

Pas de filiale américaine, hors CLOUD Act par construction, hors 5eyes, donc sans coopération étendue avec les renseignements US. En Suisse toutes les demandes de communication doivent passer par la Justice, une des juridictions les plus protectrices au monde.

Leurs datacenters sont certifiés ISO 27001 et ISO 50001. C’est l’opérateur que j’utilise, sur leur gamme VPS Cloud, mais l’entrée de gamme VPS Lite peut largement suffire pour démarrer.

Hetzner, hébergeur allemand familial fondé en 1997, rapport performance/prix imbattable en Europe, avec une gamme cloud ARM à 4,49 euros HT par mois, environ 5,40 euros TTC, au tarif du jour où j’écris ces lignes. Excellent choix, à une condition. Hetzner a ouvert des datacenters aux États-Unis en 2021, puis à Singapour en 2023. Tu dois donc provisionner ta machine exclusivement sur leurs sites européens, Falkenstein, Nuremberg ou Helsinki, pour rester hors CLOUD Act.

Deux réserves honnêtes en plus, l’interface et le support sont en anglais et en allemand uniquement, et Hetzner suspend parfois les comptes jugés à risque, sans avertissement. Rien de bloquant pour un usage SIEM légitime, mais autant le savoir.

Pour ce guide, je pars sur Infomaniak. La logique est identique chez Hetzner, seuls les noms d’interface changent.

À lire bientôt : choisir son hébergeur souverain, le comparatif complet

Dimensionner la machine, ni trop, ni trop peu

Wazuh, qu’on installera à l’épisode 2, n’est pas léger. Il embarque un manager, un indexeur de logs et un tableau de bord. L’indexeur, en particulier, aime la mémoire vive.

Pour une PME jusqu’à une cinquantaine de machines surveillées, le bon point de départ tient en trois chiffres.

4 vCPU, pour absorber l’indexation et les corrélations de règles sans saturer.
8 Go de RAM, le minimum sérieux pour l’indexeur Wazuh. En dessous, il rame ou s’arrête. C’est le critère qui compte le plus. Je recommande 12 Go.
100 à 250 Go de SSD, selon la rétention de logs que tu veux. Plus tu gardes de mois d’historique, plus il te faut d’espace. NIS2 et RGPD raisonnent en mois, prévois large.

Un VPS de ce calibre tourne autour de 15 à 30 euros par mois chez un opérateur souverain. Tu peux démarrer plus petit pour tester, mais ne descends pas sous 8 Go de RAM si tu comptes faire tourner Wazuh dessus pour de vrai.

Côté système, prends une distribution Linux à support long. Ubuntu Server LTS ou Debian stable. Les deux sont documentées partout, supportées des années, et c’est ce sur quoi la communauté Wazuh teste en priorité. J’utilise Ubuntu Server LTS, c’est ce que j’emploierai dans les commandes qui suivent.

Le premier contact, et le premier durcissement

Tu viens de commander ta machine. L’hébergeur t’envoie une adresse IP, un identifiant root et un mot de passe. C’est le moment le plus exposé de toute la vie du serveur, un root accessible par mot de passe sur une IP publique, c’est précisément ce que les bots scannent en permanence.

Une précision avant de plonger. Un serveur, ça s’administre en ligne de commande, pas d’interface graphique ni de souris, le Terminal est ton seul cockpit. Rien d’intimidant, chaque commande de ce guide est courte et expliquée ligne à ligne.

La première session de connexion sert à fermer cette porte. Dans l’ordre.

Créer un utilisateur non-root

Travailler en root au quotidien, c’est conduire sans ceinture. La moindre erreur de commande s’exécute avec les pleins pouvoirs. On crée un utilisateur dédié, à qui on donne le droit d’élever ses privilèges quand c’est nécessaire, via sudo.

adduser mack
usermod -aG sudo mack

Le premier adduser crée le compte et demande un mot de passe. Le second l’ajoute au groupe sudo, ce qui l’autorise à exécuter des commandes administrateur en les préfixant de sudo. À partir de maintenant, tu te connectes avec ce compte, plus jamais en root directement.

Passer à l’authentification par clé

Un mot de passe se devine, se force par dictionnaire, se vole. Une clé cryptographique, non. On génère une paire de clés sur ta machine locale, on installe la partie publique sur le serveur, et on désactive complètement la connexion par mot de passe.

Sur ton Mac, dans le Terminal :

ssh-keygen -t ed25519 -C "ton-commentaire"
ssh-copy-id mack@IP_DU_SERVEUR

La première commande crée la paire de clés, en Ed25519, l’algorithme moderne, court et solide. La seconde copie ta clé publique dans le serveur. Teste ensuite que tu te connectes bien sans mot de passe, ssh mack@IP_DU_SERVEUR. Si ça marche, on peut couper le reste.

Verrouiller SSH

C’est ici que la surface d’attaque se referme vraiment. On édite la configuration du démon SSH.

sudo nano /etc/ssh/sshd_config

Trois lignes à fixer, ce sont les trois qui comptent.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no interdit toute connexion directe en root. PasswordAuthentication no désactive les mots de passe, seule ta clé ouvre la porte désormais. PubkeyAuthentication yes confirme qu’on accepte les clés.

Garde ta session actuelle ouverte, redémarre le service, puis teste une nouvelle connexion dans une seconde fenêtre. Une erreur de configuration SSH, et tu te retrouves verrouillé hors de ta propre machine.

sudo systemctl restart ssh

Un piège connu des images cloud, Ubuntu y dépose souvent un fichier /etc/ssh/sshd_config.d/50-cloud-init.conf contenant PasswordAuthentication yes, qui écrase ta configuration. Vérifie la valeur réellement appliquée avec sudo sshd -T | grep -i passwordauthentication, et si elle ressort à yes, corrige ce fichier-là aussi.

Trois commandes, trois lignes de config. Tu viens d’éliminer la quasi-totalité des attaques automatisées qui visent SSH. Les bots qui tentent root par mot de passe frappent maintenant contre un mur.

Activer les mises à jour de sécurité automatiques

Un serveur qu’on n’a pas patché est un serveur vulnérable, et personne ne se connecte tous les matins pour lancer les mises à jour à la main. On automatise les correctifs de sécurité.

sudo apt update && sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Le paquet unattended-upgrades installe automatiquement les correctifs de sécurité publiés pour ta distribution, sans toucher au reste. Tes failles connues se referment toutes seules, pendant que tu dors.

La surface d’attaque minimale, le vrai sujet souverain

Le durcissement SSH, c’est le b.a.-ba. Le saut de niveau, il est ici.

Le principe directeur tient en une phrase. Un port qui n’écoute pas ne peut pas être attaqué. Chaque service exposé sur une IP publique est une porte, et chaque porte est une cible. La sécurité maximale, ce n’est pas le meilleur cadenas sur chaque porte, c’est de ne pas avoir de porte du tout.

C’est exactement la logique qu’on a vue pour la Secure Enclave. Le composant le plus sûr est celui qui refuse de donner accès, pas celui qui le défend bien.

Le pare-feu, fermer par défaut

Sur Ubuntu, le pare-feu se gère avec ufw. La bonne posture, c’est l’inversion, on bloque tout, puis on ouvre seulement ce qui doit l’être.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

default deny incoming refuse par principe toute connexion entrante. default allow outgoing laisse ta machine joindre l’extérieur, pour les mises à jour notamment. On n’ouvre que le port 22, SSH, le strict nécessaire pour administrer la machine. Et on active.

À ce stade, ton serveur ne présente plus qu’une seule porte SSH par clé. C’est déjà un profil radicalement plus discret que 90 % des VPS en production.

Tailscale, et l’IP publique disparaît

On peut faire mieux. Bien mieux. Plutôt que d’ouvrir SSH sur l’IP publique, même par clé, on le retire complètement de la vue d’internet et on l’expose uniquement sur un réseau privé chiffré.

C’est le rôle de Tailscale. Tailscale crée un maillage privé entre tes appareils, par-dessus WireGuard, le protocole de tunnel moderne. Tes machines se voient entre elles via des adresses privées, comme si elles étaient sur le même réseau local, alors qu’elles sont éparpillées entre un datacenter suisse, ton bureau et chez toi. Le reste d’internet, lui, ne voit rien.

Voici le flux concret. Tu installes Tailscale sur le serveur et sur ton Mac. Les deux rejoignent ton réseau privé. Ton Mac obtient une adresse Tailscale, le serveur aussi. Tu te connectes en SSH au serveur via son adresse Tailscale, pas via son IP publique. Et tu refermes le port 22 sur l’IP publique. Désormais, pour atteindre SSH, il faut déjà être membre de ton réseau privé. Un attaquant sur internet ne voit même plus que le port existe.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

La commande affiche un lien, tu l’ouvres dans ton navigateur, tu authentifies la machine, elle rejoint ton réseau. Répète sur ton Mac. Récupère l’adresse Tailscale du serveur :

tailscale ip -4

Teste la connexion SSH via cette adresse privée. Une fois que ça marche, on referme le port 22 public :

sudo ufw delete allow 22/tcp
sudo ufw allow in on tailscale0 to any port 22 proto tcp

La première ligne retire l’ouverture de SSH sur toutes les interfaces. La seconde le rouvre uniquement sur l’interface tailscale0, ton réseau privé. SSH n’écoute plus que sur le maillage chiffré.

Le résultat, c’est une machine dont la seule porte d’administration est invisible depuis internet. Pas verrouillée, invisible. Un scan de ports sur ton IP publique ne révèle rien d’exploitable.

Pour la suite de la série, c’est aussi par ce maillage que tes agents Wazuh remonteront leurs logs vers le serveur, sans jamais transiter par l’internet ouvert. Le socle réseau qu’on pose aujourd’hui sert toute la pile.

Et les services qui doivent rester publics ?

Tout ne peut pas vivre derrière le réseau privé. Si ton serveur héberge un site web ou un service qui doit être joignable par n’importe qui, ce service-là doit écouter sur l’IP publique. C’est inévitable.

La règle, alors, n’est pas « zéro port public » mais « zéro port public inutile ». Tu ouvres exactement ce que le service exige, ni plus. Un site web, c’est le port 443 en HTTPS, et le port 80 le temps de renouveler les certificats. Rien d’autre. Tout le reste, administration, bases de données, tableaux de bord internes, reste sur Tailscale.

Pour notre socle SIEM, à ce stade, la bonne réponse est simple. Aucun service public. Le serveur n’expose rien au monde. Wazuh, qu’on installera ensuite, vit entièrement derrière Tailscale, accessible à toi seul.

Les sauvegardes, chiffrées hors-site

Un serveur durci n’est pas un serveur immortel. Un datacenter peut prendre feu, on l’a vu avec OVH Strasbourg en mars 2021, des clients sans sauvegarde ont tout perdu. Un ransomware peut malgré tout passer sur une de tes machines de prod. Un doigt qui glisse sur une mauvaise commande peut effacer une base.

La règle est non négociable. Tes sauvegardes vivent ailleurs que sur la machine qu’elles protègent, et elles sont chiffrées avant de partir. Chiffrées par toi, sur ta machine, avant l’envoi. Pas chiffrées par le fournisseur de stockage, par toi. Comme ça, même l’hébergeur du backup ne peut pas lire ce qu’il stocke.

L’outil que j’utilise, c’est Kopia. Open source, rapide, et il fait exactement ce qu’on veut, chiffrement côté client avant transfert, déduplication pour ne pas exploser ton volume de stockage, et envoi vers un stockage compatible S3.

Et le stockage hors-site, je le prends chez Swiss Backup, l’offre de sauvegarde d’Infomaniak. Même logique de souveraineté que pour le VPS, serveurs suisses, hors CLOUD Act, et un endpoint S3 standard que Kopia consomme directement.

Le flux, concrètement. Kopia tourne sur ton serveur. Une fois par jour, ou plusieurs, il prend un instantané des dossiers qui comptent, ta configuration système, tes données Wazuh, tes logs.

Il chiffre cet instantané localement, avec une clé que toi seul détiens. Puis il l’envoie chez Swiss Backup. Le jour où le serveur meurt, tu provisionnes une nouvelle machine, tu réinstalles Kopia, tu pointes vers le dépôt distant avec ta clé, et tu restaures.

curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /usr/share/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update && sudo apt install kopia
kopia repository create s3 \
  --bucket=TON_BUCKET \
  --endpoint=s3.swiss-backup.infomaniak.com \
  --access-key=TA_CLE \
  --secret-access-key=TON_SECRET

Les trois premières lignes installent Kopia depuis son dépôt officiel. La dernière commande crée le dépôt chiffré sur le stockage distant, en reprenant l’endpoint exact affiché dans ta console Swiss Backup, il varie selon le cluster qui t’est attribué. Kopia te demande une phrase de passe au moment de la création, c’est la clé de chiffrement de tout ton dépôt. Note-la ailleurs que sur le serveur. Si tu la perds, tes sauvegardes sont définitivement illisibles, y compris pour toi. C’est le prix du chiffrement côté client, et c’est exactement ce qu’on veut.

Reste à automatiser. On crée un instantané quotidien des dossiers critiques, puis on planifie le tout avec une tâche cron.

kopia snapshot create /etc /home /var/log

Cette commande capture l’instant présent des trois dossiers. Tu la planifies pour qu’elle s’exécute chaque nuit, et tu vérifies de temps en temps que tes instantanés sont bien là avec kopia snapshot list. Une sauvegarde qu’on ne teste jamais n’est pas une sauvegarde, c’est un espoir. Il faudra donc prévoir trimestriellement une restauration test de tes données.

Ce socle de sauvegarde servira tout le reste de la série. Chaque brique qu’on ajoutera, Wazuh et ses données, les règles que tu calibreras, sera capturée dans le même instantané chiffré, hors-site, le jour où tu en auras besoin.

En résumé

Le socle, c’est quatre gestes qui se tiennent.

Tu as choisi un hébergeur dont la juridiction te protège, pas seulement dont le datacenter est en Europe. Tu as durci l’accès, utilisateur non-root, clé à la place du mot de passe, root interdit, correctifs automatiques. Tu as réduit la surface d’attaque à rien, pare-feu fermé par défaut, administration repliée derrière un réseau privé chiffré, plus aucune porte inutile face à internet. Et tu as posé des sauvegardes chiffrées hors-site, illisibles pour quiconque n’a pas ta clé, prêtes pour le jour où.

Aucune de ces étapes n’est compliquée. Prises ensemble, elles transforment une machine de location en un coffre-fort que tu contrôles. C’est l’inverse exact de ce que tu signes chez un SaaS américain, où la donnée est à toi mais l’infrastructure et la juridiction sont à un autre.

Un après-midi de travail. Pas un week-end.

Le socle est en place. À l’épisode 2, on remplit le coffre. Wazuh en mode tout-en-un, le manager, l’indexeur et le tableau de bord sur ce seul nœud. L’équivalent fonctionnel d’un Splunk, pour le prix du VPS que tu viens de monter. Ton SIEM commence à exister.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act. Tu viens de le lire.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.

Siri AI bloqué dans l'UE, confidentialité signée Google

Mac Souverain — Wed, 10 Jun 2026 13:32:51 GMT

Apple lance Siri AI à la WWDC, mais le bloque sur iPhone et iPad dans l’UE au nom du DMA. La Commission répond que c’est le choix d’Apple, pas une obligation. Cerise sur le gâteau, cette plateforme « confidentielle » s’appuie en partie sur Google Gemini.

Ce que ça change pour toi

1. En Europe, pas de Siri AI sur iPhone ni iPad. Mais sans assistant IA cloud, ton appareil est plus sûr : tu perds une fonction, pas une protection.

2. Pour le sensible, reste local et active Advanced Data Protection sur iCloud. Pour l’email chiffré, Proton Mail, pas iCloud Mail.

3. Pose-toi la vraie question : confier ton assistant le plus intime à une chaîne Apple plus Google, c’est passer d’une garantie technique à une promesse contractuelle.

Apple a dévoilé Siri AI à la WWDC, sa nouvelle plateforme d’assistant vocal. Deux détails coincent : elle est construite en partie sur Google Gemini, et elle ne sortira pas sur iPhone ni iPad dans l’Union européenne. La confidentialité, version Cupertino, devient un argument de blocage.

Le fait

Le 8 juin 2026, à la WWDC, Apple a présenté Siri AI, la refonte tant attendue de son assistant vocal et la fondation annoncée de sa prochaine génération de produits, y compris de futurs appareils portables. Le cœur de la plateforme repose sur une architecture hybride : les tâches locales tournent sur les modèles maison d’Apple, mais l’intelligence cloud s’appuie sur un modèle Gemini sur-mesure de Google, pour un contrat estimé autour d’un milliard de dollars par an selon plusieurs sources de presse.

Le hic, c’est la géographie. Apple a annoncé que Siri AI ne sera pas disponible sur iPhone ni iPad dans l’Union européenne avec iOS 27 et iPadOS 27. Les utilisateurs européens y auront accès sur macOS 27 et visionOS 27, mais ni sur iPhone, ni sur iPad, ni sur l’Apple Watch, watchOS 27 dépendant d’un iPhone appairé doté de Siri AI. Apple invoque le Digital Markets Act (DMA) et ses exigences d’interopérabilité, affirmant que les régulateurs ont rejeté ses propositions de mise en conformité, dont un cadre baptisé Trusted System Agent censé ouvrir l’accès aux assistants concurrents tout en préservant ses standards de sécurité.

La Commission conteste le cadrage. Pour son porte-parole Thomas Regnier, la décision de ne pas déployer Siri AI dans l’UE est « celle d’Apple et d’Apple seule », rien dans le DMA n’empêchant le lancement d’un nouveau produit. Le marché, lui, a tranché à sa manière : l’action Apple a reculé d’environ 2 % le jour de l’annonce, puis de 3 % le lendemain. Note de prudence : iOS 27 et iPadOS 27 sont à ce stade des annonces, pas des builds stables. Le calendrier de sortie comme le périmètre du blocage peuvent encore bouger.

Pourquoi ça compte pour toi

Si tu es en Europe, le message est clair : ton iPhone et ton iPad n’auront pas la fonction phare des prochains OS. Avant de pester contre Bruxelles, regarde ce qui se joue vraiment. Apple présente la confidentialité comme la raison pour laquelle elle ne peut pas se plier aux demandes d’interopérabilité.

La Commission répond que personne n’oblige Apple à brider son produit. Les deux versions ne sont pas symétriques, et le site officiel n’a pas le monopole de la vérité ici, mais une chose est sûre : la confidentialité est devenue un argument de négociation autant qu’une promesse technique.

L’ironie mérite qu’on s’y arrête. Apple vend Siri AI comme respectueux de ta vie privée, tout en confiant le traitement cloud à Google, c’est-à-dire à l’entreprise dont le modèle économique repose sur l’exploitation des données. Apple jure que son architecture cloisonne tout via son Private Cloud Compute, que Google ne voit rien, que les requêtes sont anonymisées. C’est plausible sur le papier, et Apple a un historique sérieux sur le sujet. Mais tu passes d’une promesse vérifiable, le tout-sur-l’appareil, à une promesse contractuelle, le fait que ton partenaire et son sous-traitant tiennent parole. Ce n’est pas le même niveau de garantie.

Le fond du dossier dépasse Siri. On assiste à une fragmentation des écosystèmes numériques par juridiction. Une même version d’iOS n’offrira pas les mêmes fonctions à Paris, New York ou Pékin. La souveraineté, pour toi utilisateur, ne se joue plus seulement dans le chiffrement, mais dans le fait que ton appareil dépend désormais d’un bras de fer entre un industriel américain, un régulateur européen et un fournisseur d’IA tiers.

Ce que ça change pour toi

1. Ne confonds pas absence de Siri AI et perte de confidentialité. Ton iPhone sans assistant IA cloud reste parfaitement fonctionnel, et il est plus sûr. Le « manque » est une fonction, pas une protection en moins.

2. Pour les requêtes sensibles, garde le réflexe local. Active Advanced Data Protection sur iCloud (Réglages > Apple Account > iCloud > Protection avancée des données) pour chiffrer tes backups de bout en bout. Rappel : l’ADP ne couvre ni iCloud Mail, ni Contacts, ni Calendrier. Pour l’email réellement chiffré, c’est Proton Mail ou Tuta, par exemple.

3. Surveille la suite, sans t’y noyer. Le périmètre du blocage et le calendrier UE bougeront. Ce qui compte n’est pas la date de sortie, mais la question de fond : es-tu prêt à confier ton assistant le plus intime à une chaîne Apple plus Google, sur une promesse contractuelle ?

Sources

Certificat OpenAI compromis, mets à jour ChatGPT Mac avant le 12 juin

Mac Souverain — Sat, 06 Jun 2026 07:58:44 GMT

Si tu utilises ChatGPT, Codex ou Atlas en app native sur ton Mac, tu as jusqu’au 12 juin 2026 pour mettre à jour. Le certificat de signature d’OpenAI a été compromis via une attaque supply-chain sur npm. Au-delà, ton app refuse de démarrer.

Ce que tu dois faire

1. Ouvre ChatGPT.app, Paramètres → À propos. Mise à jour si version ≤ 1.2026.125. Idem Codex App (≤ 26.506.31421), Codex CLI (≤ 0.130.0), Atlas (≤ 1.2026.119.1).

2. Téléchargement officiel uniquement, chatgpt.com/download ou App Store. Pas de miroir, pas de lien partagé.

3. iOS, Windows, Android, rien à faire, OpenAI re-signe côté serveur. Mac uniquement.

Tu utilises ChatGPT, Codex ou Atlas en app native sur ton Mac. Le 12 juin, dans quelques jours, ces apps refusent de démarrer si tu n’as pas mis à jour. Pas un bug, une révocation de certificat suite à une attaque supply-chain. Voilà ce qu’il s’est passé et ce que tu fais.

Le fait

Le 11 mai 2026, en six minutes, un collectif baptisé TeamPCP publie 84 versions piégées de 42 paquets @tanstack/* sur npm. Deux postes salariés d’OpenAI consomment l’un de ces paquets le soir même. Le malware embarqué, Mini Shai-Hulud, exfiltre des credentials qui ouvrent l’accès à des dépôts internes contenant les outils de signature de code OpenAI. Pas la production, pas les conversations utilisateurs, pas les modèles. Les clés qui servent à prouver à macOS qu’une app vient bien d’OpenAI.

OpenAI a communiqué publiquement le 13 mai 2026. Le certificat compromis sera révoqué le 12 juin 2026. Côté Apple, ça veut dire que Gatekeeper et la notarisation refuseront toute version signée avec l’ancien certificat. Concrètement, les versions affectées,

ChatGPT Desktop ≤ 1.2026.125
Codex App ≤ 26.506.31421
Codex CLI ≤ 0.130.0
Atlas (navigateur OpenAI) ≤ 1.2026.119.1

ne se lanceront plus à partir du 12 juin. iOS et Windows, eux, sont re-signés côté serveur. Pas d’action utilisateur.

Le code source du worm a été rendu public par TeamPCP le 12 mai, avec un défi criminel de 1 000 dollars sur BreachForums pour la plus grosse attaque supply-chain réalisée avec leur outil. Pas une bug bounty défensive, une prime offensive. La référence CVE est CVE-2026-45321.

Pourquoi ça compte pour toi

Tu n’as rien fait de mal et tu dois quand même agir. C’est l’essence d’une attaque supply-chain. Ton hygiène utilisateur peut être impeccable, si l’éditeur de l’app que tu as installée se fait compromettre quatre étages plus haut, sur une dépendance npm que tu ne sauras jamais nommer, tu hérites du problème. Le certificat compromis, le mécanisme de signature révoqué, l’app qui ne démarre plus, tout ça arrive chez toi sans que tu aies cliqué quoi que ce soit.

La bonne nouvelle, c’est que le mécanisme de révocation fonctionne. Gatekeeper et la notarisation Apple sont précisément conçus pour ça : empêcher un attaquant d’utiliser un certificat volé pour signer du malware en aval. OpenAI fait son travail en révoquant proprement. Apple fait son travail en bloquant. Le système tient. OpenAI a communiqué publiquement dès la détection, dates précises, versions explicites, sans détour. Ce n’est pas la norme du secteur.

La mauvaise nouvelle, c’est que ça pose une question doctrinale qui dépasse OpenAI. Une app native sur ton Mac, c’est du code qui tourne en local avec un certificat de confiance, un canal de mise à jour automatique, des permissions système, et tout un réseau de dépendances en amont sur lequel tu n’as aucune visibilité. Quand l’une de ces dépendances se fait piéger, et ça arrive à toutes, le problème descend jusqu’à toi.

Ce que tu fais maintenant

1. Ouvre ChatGPT.app, va dans Paramètres → À propos. Si tu es en 1.2026.125 ou antérieure, lance la mise à jour. Si rien ne s’affiche, télécharge directement depuis chatgpt.com/download. Jamais un miroir, jamais un lien partagé.

2. Si tu utilises Codex App ou Codex CLI, même vérification. CLI : codex --version puis npm update -g @openai/codex ou réinstall propre. Pour Atlas, mise à jour intégrée.

3. Vérifie que macOS est à jour, Gatekeeper renforcé sur Sequoia 15.x et Sonoma 14.7+. Les anciennes versions sont plus laxistes sur la vérification de notarisation au lancement.

4. Profite du créneau pour te poser la question doctrinale : qu’est-ce que l’app ChatGPT native t’apporte vraiment que chatgpt.com dans Safari ne t’apporte pas ? Dictée système, raccourcis clavier, intégration spotlight, OK. Si tu ne te sers d’aucun des trois, le navigateur réduit ta surface d’attaque. Pas de certificat de signature à gérer, pas de mise à jour silencieuse, pas de code persistant en local. Le réflexe vaut pour Claude Desktop, Perplexity, Mistral Le Chat et toutes les apps IA tierces que tu as installées sans trop savoir pourquoi. Une app native sur ton Mac, c’est une dette de sécurité. Parfois justifiée, parfois pas.

À lire aussi, Anthropic MCP, faille de design qui ouvre RCE. Même logique, code IA tiers qui descend en exécution locale dangereuse.

Sources

Monte ton SIEM PME souverain, conformité RGPD/NIS2 sans CLOUD Act

Mac Souverain — Fri, 05 Jun 2026 12:00:56 GMT

Tu n’as pas de SIEM. Tu te dis que ce n’est pas pour toi, que ta PME est trop petite ou hors secteur régulé, donc sous le radar des grandes obligations cyber. Tu te trompes sur deux temps.

Maintenant, RGPD. Depuis 2018, toute entreprise qui traite des données personnelles doit notifier la CNIL d’une violation sous 72 heures. C’est l’article 33. Pas une recommandation, une obligation. Notifier en 72 heures, ça veut dire que tu sais qu’il s’est produit quelque chose, que tu peux le caractériser, que tu disposes des journaux pour remonter la chaîne. Sans un système qui centralise tes logs et lève des alertes, cette obligation est inapplicable. Tu es en infraction la première fois qu’un ransomware passe.

Demain, l’élargissement. NIS2 vient de multiplier par trente le nombre d’entités françaises soumises à des obligations cyber renforcées, de 500 à environ 15 000. DORA est applicable depuis janvier 2025 pour le secteur financier élargi, sous-traitants compris. Le Cyber Resilience Act s’applique pleinement à partir de décembre 2027 à tout produit avec composant numérique vendu en UE. NIS3 n’est pas votée, le calendrier indicatif vise la fin 2027. Mais la trajectoire est lisible, tous les deux à trois ans le filet s’élargit. Parier que ta PME restera hors champ en 2028 ou 2029, c’est parier contre Bruxelles et contre la jurisprudence RGPD qui n’a cessé de durcir.

Le mot qui revient dans tous ces textes, c’est SIEM, pour Security Information and Event Management, gestion centralisée des événements de sécurité. Ils ne le nomment jamais, mais ils te le rendent impossible à éviter. Détecter un incident, conserver des journaux exploitables, notifier le régulateur dans des délais courts, ce sont les fonctions d’un SIEM.

Et c’est quoi, concrètement, un SIEM ? Imagine la vidéosurveillance de ton magasin, mais pour ton informatique. Chaque serveur, chaque pare-feu, chaque poste de travail, chaque boîte mail produit en permanence un journal de ce qui s’y passe. Qui s’est connecté, à quelle heure, depuis où, quel fichier a été ouvert, quel processus a démarré.

Un SIEM, c’est le système qui ramène tous ces journaux au même endroit, les conserve plusieurs mois, et lève une alerte quand il détecte un comportement suspect.

Un compte qui se connecte à 3 heures du matin depuis le Pakistan, dix mille fichiers chiffrés en deux minutes, une rafale d’échecs de mot de passe sur le compte du dirigeant, ce sont des signaux qu’un humain ne verra jamais à l’œil nu sur un parc de cinquante machines.

Le SIEM les voit, les recoupe, et te prévient. Derrière ce sigle de consultant se cache un assemblage très concret, qu’on démonte plus loin dans cet article.

Le problème, c’est ce qu’on te vend aujourd’hui sous ce nom. Splunk, Microsoft Sentinel, CrowdStrike. Sur le ticket d’entrée d’une PME modeste, les tarifs paraissent accessibles, mais la facture grimpe avec chaque gigaoctet et chaque poste, on fait les comptes complets en fin de série. Et le prix n’est même pas le pire. Ces produits stockent tes journaux d’incident dans une juridiction qui n’est pas la tienne, sous CLOUD Act. La vraie question, c’est qui détient tes données les plus sensibles.

Il existe un troisième chemin. Le souverain. C’est celui de cette série d’articles.

NIS2 en cinq minutes, et pourquoi ça te concerne même hors périmètre

NIS2, c’est la directive européenne sur la sécurité des réseaux et des systèmes d’information, qui remplace NIS1. NIS1 concernait environ 500 entités françaises. NIS2 en concerne autour de 15 000, réparties sur dix-huit secteurs. La santé, l’énergie, les transports, le numérique, les services financiers, l’agroalimentaire, les déchets, la fabrication. Si ton entreprise dépasse 50 salariés ou 10 millions d’euros de chiffre d’affaires dans l’un de ces secteurs, tu es directement concerné. Probablement comme « entité importante », parfois comme « entité essentielle » selon ta taille et ta criticité.

Si tu es plus petit ou hors secteur listé, tu n’es pas pour autant tranquille. Deux mécanismes te rattrapent. D’abord la chaîne d’approvisionnement, l’article 21 oblige les entités NIS2 à évaluer la cyber-résilience de leurs sous-traitants. Si tu vends du service ou du logiciel à une PME de 60 personnes dans la santé ou la finance, elle va te demander tes preuves. Pas de SIEM, pas de contrat. Ensuite la trajectoire réglementaire elle-même, NIS3 est en préparation à la Commission, le périmètre s’élargit toujours d’une révision à l’autre.

Le cœur du dispositif, c’est l’article 21. Dix catégories de mesures minimales, analyse des risques, gestion des incidents, journalisation, continuité, formation, chiffrement, contrôle d’accès, sécurité de la chaîne d’approvisionnement. Et l’obligation de notification, en trois temps, alerte précoce sous 24 heures, notification structurée sous 72 heures, rapport final sous 30 jours.

Le triptyque vaut pour NIS2 comme pour RGPD, sans socle de détection et de journalisation, l’obligation est inapplicable.

L’article 20 ajoute le détail qui change tout pour le dirigeant. La responsabilité pèse sur la personne physique qui dirige. Pas sur le DSI, ni sur le prestataire. Sur toi.

Côté sanctions, c’est calibré pour faire mal. Entité essentielle, jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial, le plus élevé des deux. Entité importante, jusqu’à 7 millions d’euros ou 1,4 % du CA mondial. Pour une PME à 30 millions de CA, on parle d’une sanction maximale de plusieurs centaines de milliers d’euros.

La loi du 30 avril 2025 transpose NIS2 en droit français. Les décrets d’application et le périmètre exact des entités concernées se précisent au fil de 2026. Tant que c’est flou tu te dis que tu as le temps, mais la directive s’applique déjà, la jurisprudence va se construire sur les premiers contentieux. La question est quand, pas si.

On a déjà vu dans un article précédent comment NIS2 contredit CSAR sur le chiffrement. Ici, on regarde l’autre obligation, celle qui devient concrète pour ton infrastructure, détecter, journaliser, notifier.

Tu as trois options, et deux d’entre elles sont mauvaises

Option 1, le SaaS américain

Splunk, Microsoft Sentinel, CrowdStrike, Datadog, Elastic Cloud. Ils marchent. Ils sont matures. Et sur le prix d’entrée d’une PME modeste, ils ne sont pas hors de portée. Le piège est ailleurs.

Microsoft Sentinel facture autour de 4,30 dollars du gigaoctet ingéré en région East US, dans le modèle de facturation simplifié qui combine ingestion Log Analytics et analyse Sentinel. CrowdStrike Falcon facture par endpoint, entre 60 et 185 dollars par poste et par an selon le niveau, Go, Pro, Enterprise ou Complete. Splunk est plus opaque, l’éditeur ne publie pas ses tarifs, mais les sources secondaires sérieuses convergent autour de 8 000 à 12 500 dollars par an pour un ticket d’entrée de 5 gigaoctets de logs par jour, licence seule, en Cloud ou en Enterprise auto-hébergé.

Prenons une PME de 50 employés qui génère cinq gigaoctets de logs par jour. Sur Microsoft Sentinel, environ 7 800 dollars par an. Sur CrowdStrike Falcon Pro pour 50 endpoints, environ 5 000 dollars par an. Sur Splunk Cloud à l’entrée, environ 8 000 dollars par an. Soyons honnêtes, 13 000 dollars par an pour Sentinel et CrowdStrike combinés, sur une PME à 10 millions de CA, c’est 0,13 % du chiffre d’affaires. Le coût d’entrée n’est pas l’obstacle.

L’obstacle, c’est ce que tu signes en même temps. Tes logs partent aux États-Unis, ou chez une filiale européenne d’une société américaine. Le CLOUD Act, voté en 2018, permet aux autorités américaines de réquisitionner ces données auprès du fournisseur, même stockées physiquement en Europe. Microsoft Irlande, Splunk Cloud, CrowdStrike, tous y sont soumis via leur société mère.

Et tes logs d’incident, ce ne sont pas n’importe quelles données. Ce sont les empreintes complètes de ton réseau, les noms d’utilisateurs, les flux applicatifs, les comportements internes, les vulnérabilités exposées au moment de l’attaque. Le matériau le plus sensible que produit ton SI. Le confier à un fournisseur réquisitionnable par une juridiction étrangère, c’est un risque opérationnel réel.

Le Data Privacy Framework, le pont juridique UE-US, a survécu en première instance devant le Tribunal de l’UE en septembre 2025. Il est en appel devant la CJUE depuis le 31 octobre 2025. La CNIL, dans sa décision de février 2025 sur l’hébergement de santé, est nette, le seul marqueur reconnu pour matérialiser un cloud souverain reste la qualification SecNumCloud. Aucun des trois SaaS cités ne l’a.

Un dernier point. Le coût d’entrée raisonnable, c’est aujourd’hui. La mécanique de facturation s’aggrave avec ta croissance. Chaque gigaoctet ingéré en plus est facturé, chaque endpoint additionnel aussi. À 50 gigaoctets de logs par jour, le ticket Sentinel passe au-dessus de 78 000 dollars par an, Splunk grimpe en proportion selon le mode de licence. Tu signes un prix d’entrée modeste, tu signes en même temps un verrou tarifaire qui se referme au fur et à mesure que ton SIEM voit plus large et plus profond.

Conclusion, tu paies un prix raisonnable pour la plomberie aujourd’hui, en livrant la donnée la plus stratégique de ton SI dans une juridiction qui n’est pas la tienne, dans un cadre légal défavorable, avec un compteur qui tourne contre toi à chaque extension de périmètre.

Option 2, ne rien faire

C’est tentant. C’est la stratégie la plus répandue chez les PME, qu’elles soient ou non dans le périmètre NIS2. Attendre. Voir. Espérer.

Le calcul est mauvais sur trois plans. RGPD aujourd’hui, la CNIL a déjà sanctionné des PME pour défaut de notification, l’absence de moyen de détection est aggravante. NIS2 demain si tu y entres par chaîne d’approvisionnement ou par révision, la sanction maximale pour une entité essentielle dépasse celle du RGPD, la responsabilité personnelle du dirigeant existe noir sur blanc. Ransomware n’importe quand, chiffrement de la production, rançon, perte d’exploitation, c’est un autre ordre de grandeur que la mise en conformité.

Ne rien faire, ce n’est pas économiser. C’est repousser, en risquant d’aggraver la facture finale.

Option 3, le souverain auto-hébergé

Tu construis ton SIEM avec des briques open source matures, déployées sur une infrastructure que tu contrôles. Quatre briques, quatre rôles complémentaires.

Wazuh, c’est le cerveau du dispositif, la plateforme centrale qui ramène tous les journaux au même endroit, les stocke, les analyse et lève les alertes. C’est ton « Splunk maison ».
CrowdSec, c’est le videur à l’entrée. Une défense réseau communautaire qui bloque automatiquement les adresses IP déjà repérées comme attaquantes par les autres utilisateurs du réseau. Quand un bot scanne mille sites avant le tien, il est blacklisté avant d’arriver chez toi.
Rspamd, c’est le filtre devant ton serveur mail. Il intercepte spams et tentatives d’hameçonnage avant qu’ils n’atteignent les boîtes de tes salariés. Le mail reste le vecteur n°1 des intrusions PME, c’est là que la prévention paie le plus.
Santa, c’est le contrôleur d’exécution sur tes Mac. Il décide quelles applications ont le droit de démarrer sur chaque poste, selon une liste blanche que tu construis. Un ransomware téléchargé par erreur ne peut pas s’exécuter, parce qu’il n’est pas signé par un éditeur que tu as approuvé. C’est la brique qui transforme un Mac d’usage courant en poste durci, sans que l’utilisateur n’ait à changer ses habitudes.

Aucune de ces briques n’est expérimentale. Wazuh est utilisé par des entreprises du Fortune 100. CrowdSec, société française fondée en 2019, agrège 10 millions de signaux par jour, partagés par plus de 70 000 utilisateurs dans 190 pays. Rspamd équipe Mailcow, Zimbra, Mailu, qui font référence. Santa, développé à l’origine chez Google et maintenu désormais par North Pole Security, tourne en production chez Figma.

Le coût, c’est un VPS correctement dimensionné, le temps d’installation, et une compétence interne que tu construis. Pas zéro, mais sans commune mesure avec les chiffres précédents.

Ce qu’est vraiment un SIEM, pour quelqu’un qui ne fait pas de blue team

Le mot fait peur. Il sent les écrans noirs, les équipes 24/7 et les analystes qui parlent un dialecte que ton DSI ne comprend pas. Une fois démythifié, c’est plus simple.

Un SIEM, c’est de la plomberie. Pas un produit, un assemblage. Quatre fonctions qui s’enchaînent :

Collecter les journaux de tes équipements, serveurs, pare-feu, postes de travail, applications, boîtes mail. Tout ce qui produit un log, tu le ramènes au même endroit.
Centraliser et conserver ces journaux dans un format exploitable, avec une rétention qui te permet d’enquêter sur un incident remontant à plusieurs mois.
Détecter les comportements anormaux. Un compte qui se connecte à 3 heures du matin depuis un pays inhabituel, une rafale d’échecs d’authentification, un processus qui modifie 10 000 fichiers en une minute.
Alerter et garder la trace, pour ta notification ANSSI sous 24 heures, et pour ton rapport final sous 30 jours.

C’est tout. Aucune magie. Un système qui voit, qui se souvient, et qui crie quand quelque chose cloche.

Le travail dur n’est pas la technologie, c’est l’ajustement. Quelles règles tu actives, quels seuils tu calibres, à qui tu envoies l’alerte, comment tu réponds. C’est la même chose sur Splunk ou sur Wazuh. Et c’est cette compétence interne que tu vas construire dans cette série.

En résumé

Monter ton SIEM en 2026 te paie sur deux horizons.

Court terme, c’est de la sécu opérationnelle. Un ransomware détecté en heures au lieu de semaines, une exfiltration interceptée avant la rançon, une violation RGPD que tu peux caractériser et notifier dans les délais. Ce ROI-là ne dépend d’aucun texte qui n’est pas encore voté, il est immédiat.

Moyen terme, c’est de la conformité amortie. Tu construis l’infrastructure et la compétence interne avant que l’obligation te tombe sur ta tête. Tes concurrents la monteront sous contrainte, dans l’urgence, à trois fois le prix d’un consultant en mission flash. Tu auras pris cinq ans d’avance sur eux pour le prix de quelques week-ends étalés sur un trimestre.

Le SaaS US fait le boulot et n’est pas hors de prix sur le ticket d’entrée. Il livre juste tes données les plus stratégiques dans une juridiction défavorable, et te verrouille dans un modèle où chaque gigaoctet de plus est facturé. L’auto-hébergé demande un investissement initial en temps. Au bout, tu es maître de la donnée, du coût marginal et du calendrier de mise en conformité. La souveraineté réelle contre un peu de ton temps, que l’on va veiller à optimiser lors de nos articles.

Sept épisodes pour monter ta plomberie

C’est la stack que j’utilise en production. Pas un fantasme de blogueur, une infrastructure qui tourne au quotidien, qui détecte, qui journalise, qui notifie. Sept épisodes, sept briques :

Épisode 1, le socle. Un VPS durci, sur un hébergeur européen hors emprise américaine. Choix de l’opérateur, configuration de base, surface d’attaque minimale, sauvegardes chiffrées hors-site.
Épisode 2, Wazuh en mode tout-en-un. Installation du manager, de l’indexeur, du dashboard sur un seul nœud. Durcissement, premiers tableaux de bord. L’équivalent fonctionnel d’un Splunk pour le prix d’un VPS.
Épisode 3, les agents partout. Déploiement des agents Wazuh sur tes serveurs, Mac et Windows. Collecte des logs système, des événements de sécurité, des activités fichiers. Le moment où ton SIEM commence à voir.
Épisode 4, CrowdSec en première ligne. La défense réseau communautaire qui bloque les attaquants connus avant qu’ils n’atteignent tes services. Intégration Wazuh, partage des signaux.
Épisode 5, Rspamd pour le mail. Le filtre anti-spam et anti-phishing qui se branche devant ton serveur mail, ou s’intègre à ta solution existante. Détection d’hameçonnage, journalisation dans Wazuh.
Épisode 6, Santa sur les Mac. Contrôle d’exécution sur les postes Apple. Fork North Pole Security, le projet activement maintenu depuis que Google a passé la main en 2024. Lockdown progressif, intégration Wazuh.
Épisode 7, alerting et coût total. Notifications calibrées, escalade, bilan financier honnête, comparaison épisode par épisode avec ce qu’aurait coûté l’équivalent SaaS.

Les liens s’allument au fil des publications, reviens te brancher sur les nouveaux épisodes dès qu’ils sortent.

Chaque épisode est autonome. Tu peux t’arrêter au 3 et avoir déjà couvert l’essentiel de NIS2. Tu peux pousser jusqu’au 7 et avoir une stack qui n’a rien à envier à celles des grandes entreprises.

Apple Intelligence : ce qui sort vraiment de ton Mac

Mac Souverain — Thu, 28 May 2026 07:48:57 GMT

Mise à jour du 21 juin 2026. Depuis le 8 juin 2026, PCC ne tourne plus seulement sur du silicium Apple : pour les requêtes les plus lourdes (agentic, raisonnement complexe), Apple bascule sur du matériel Google Cloud, GPU NVIDIA, CPU Intel et puce Titan. Apple jure que les cinq garanties tiennent, qu’il garde le contrôle logiciel et que Google ne voit rien en clair. Sans doute. Mais l’argument grand public « tout reste chez Apple » vient de tomber : c’est désormais aussi du fer Google, sous garanties Apple.

Tu as mis à jour ton Mac. Tu as accepté les CGU sans lire (comme tout le monde). Quelques semaines plus tard, tu réalises que le toggle « Apple Intelligence » est sur ON, alors que tu l’avais coupé. Ce n’est pas une hallucination : depuis macOS 15.3 sorti le 27 janvier 2025, Apple Intelligence est passé d’opt-in à opt-out. Et une partie des utilisateurs qui l’avaient désactivé l’ont retrouvée réactivée après 15.3.1, bug confirmé par MacRumors et 9to5Mac, inconsistant d’un appareil à l’autre. Pas une règle systémique, mais assez fréquent pour que tu vérifies après chaque update.

C’est le moment de comprendre ce qui se passe quand tu cliques « Summarize » sur un mail un peu long. Parce qu’entre ton Neural Engine et un data center californien, il y a trois couches de traitement. Une seule reste vraiment chez toi.

Pourquoi cette question n’est pas anodine

Apple vend Apple Intelligence comme une IA « privacy-first ». Le slogan est partout sur le site produit : aware of your personal information without collecting your personal information. C’est techniquement vrai pour une partie du périmètre, et techniquement faux pour le reste.

Une IA générative, par construction, a besoin de calcul. Quand le modèle qui tourne sur ton Mac ne suffit plus, la requête sort. Soit vers des serveurs Apple, soit vers ceux d’OpenAI. Dans les deux cas, ton texte quitte ta machine. La question n’est pas de savoir si ça sort. C’est de savoir où, sous quelles garanties, et comment Apple t’en informe (spoiler : mal).

Couche 1 : le modèle local, ce qui reste vraiment chez toi

Sur Apple Silicon (M1 et plus), Apple fait tourner un modèle fondation d’environ 3,18 milliards de paramètres. Quantifié 2 bits par poids via Quantization-Aware-Training, footprint mémoire d’environ 1 Go, KV-cache partagé qui économise 37,5 % de RAM. Le calcul se fait sur le Neural Engine, le GPU et le CPU de la puce, jamais sur un serveur.

Concrètement, voilà ce qui reste 100 % local :

Writing Tools version courte : Proofread, Rewrite, Summarize sur des textes courts
Smart Reply dans Mail et Messages
Résumés de notifications et Priority Notifications
Résumés Mail courts dans la liste de la boîte de réception
Genmoji (génération d’emoji custom)
Image Playground (Animation, Illustration, Sketch)
Image Wand dans Notes
Siri basique (compréhension, type-to-Siri)
Clean Up Photos

Pour ces usages, ton texte ne quitte pas l’Apple Silicon. Aucun log, aucun serveur, aucune télémétrie de contenu. C’est le périmètre honnête de la promesse Apple, et il est réel.

Le problème commence quand tu demandes autre chose. Long résumé d’un thread Mail de 80 messages, Composition d’un texte généré, raisonnement Siri multi-étapes : ton Mac sait qu’il ne tiendra pas la charge. Il bascule. Et Apple n’affiche aucun voyant pour te le signaler.

Couche 2 : Private Cloud Compute, l’enclave californienne

C’est l’angle marketing fort d’Apple. PCC tourne sur du custom-silicon Apple dans leurs data centers, avec cinq garanties techniques mises en avant dans la doc Security Research :

Stateless computation : ton texte est utilisé pour répondre, jamais conservé après la requête.
Enforceable guarantees : les protections sont techniquement appliquées, pas contractuellement promises. Un admin Apple ne peut pas désactiver le mécanisme.
No privileged runtime access : pas de shell distant, pas de debug interactif. Apple ne peut pas extraire tes données, même volontairement.
Non-targetability : un attaquant ne peut pas router ta requête vers un nœud compromis spécifique. La diffusion des requêtes vers les nœuds est aléatoire et attestée.
Verifiable transparency : chaque build de production publié dans un log cryptographiquement append-only, images binaires disponibles pour inspection externe pendant 90 jours.

Apple a poussé son code serveur PCC sur GitHub, ouvert un environnement de recherche aux chercheurs externes, et mis sur la table un bug bounty d’un million de dollars. C’est, à ce jour, la stack cloud IA la plus auditable du marché.

Maintenant les nuances, parce qu’il y en a.

Trail of Bits, dans son analyse du 14 juin 2024, rappelle un point que le marketing Apple efface volontiers : « the data is decrypted on Apple’s server ». PCC n’est pas du chiffrement homomorphe (la techno qui ferait calculer un modèle sur des données chiffrées sans jamais les déchiffrer). C’est une enclave durcie, signée, attestée, mais ton texte est bien déchiffré côté Apple le temps du calcul. La sécurité repose sur l’intégrité de l’enclave et la signature des binaires, pas sur une magie cryptographique. Apple est honnête là-dessus dans la doc technique. Le slogan grand public, lui, laisse penser le contraire.

Deuxième nuance, plus inconfortable. Matthew Green, cryptographe à Johns Hopkins, sur Mastodon en juin 2024 : « Apple does not have explicit plans to announce when your data is going off-device for Private Compute, and you won’t opt into this or necessarily even be told it’s happening ». Traduction : tu ne sais jamais si le résumé de ton mail est resté sur ton M2 ou s’il a fait un aller-retour en Californie. Aucun indicateur visuel, aucune notification, aucun journal côté utilisateur. La transparence d’Apple est cryptographiquement vérifiable mais visuellement invisible.

Couche 3 : ChatGPT, l’opt-in et son piège

ChatGPT est greffé sur Apple Intelligence depuis macOS 15.2. Désactivé par défaut, activable explicitement dans Apple Intelligence & Siri → Extensions → ChatGPT. Quand tu l’actives, Apple ajoute deux protections par-dessus le contrat OpenAI standard :

Ton IP est masquée par le relai Apple (verbatim Apple Legal : « your IP address is obscured from ChatGPT »). Une localisation approximée passe, pour la conformité légale et l’anti-fraude.
No-logs et no-training côté OpenAI, à condition que tu n’aies pas lié ton compte OpenAI. Apple Legal : OpenAI « must process your information solely for the purpose of fulfilling your request », « not store your information », « must not use your information to improve or train its models ».

Lis bien la conditionnelle. Si tu lies n’importe quel compte OpenAI (gratuit, Plus, Pro, Team) pour récupérer ton historique ou accéder à GPT-5, tu sors immédiatement du contrat Apple et tu retombes sous les CGU standard d’OpenAI. Logs, historique de conversation, entraînement potentiel, le tout sous juridiction US. Apple le mentionne dans le texte legal, en petit, après trois paragraphes. La majorité des utilisateurs lient leur compte sans réaliser qu’ils viennent de désactiver la protection qui les a fait choisir Apple.

Deuxième détail. Le toggle « Confirm ChatGPT Requests » est sur ON par défaut : Siri te demande validation avant d’envoyer le texte. Tu peux le couper. Mais surtout, si tu commences ta requête vocale par « Ask ChatGPT… », la confirmation est court-circuitée. C’est un raccourci documenté côté Apple, qui contourne le seul garde-fou visible du dispositif. Photos et fichiers gardent la confirmation, eux, dans tous les cas.

Les quatre toggles à vérifier

Quatre chemins à connaître sur Sequoia 15.x et Tahoe 26. Les intitulés anglais sont garantis (testés par Apple Support sur Mac US), les français sont les libellés que tu verras vraisemblablement, à confirmer sur ton Mac.

1. Le master Apple Intelligence
System Settings → Apple Intelligence & Siri (toggle en haut du panneau).
État par défaut depuis macOS 15.3 : ON sur les Mac compatibles. Cas documentés de réactivation sur 15.3.1 (bug, pas design). Rare ensuite, mais revérifie après chaque update. À couper si tu ne veux rien, vraiment rien.

2. ChatGPT master
System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Use ChatGPT.
État par défaut : OFF. Active uniquement si tu en veux, et surtout : ne lie pas ton compte OpenAI.

3. Confirm ChatGPT Requests
System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Confirm ChatGPT Requests.
État par défaut : ON. Laisse-le. La friction de confirmation est ton seul indicateur visuel qu’une requête part hors de ton Mac.

4. Improve Siri & Dictation
System Settings → Privacy & Security → Analytics & Improvements → Improve Siri & Dictation.
État par défaut : OFF. Vérifie qu’il est resté à OFF. C’est lui qui décide si Apple stocke des extraits audio de tes interactions Siri pour relecture humaine. Identifiant aléatoire, rotation pluri-horaire, pas de lien Apple ID, ils insistent. Tu choisis de leur faire confiance ou pas.

Apple, Microsoft, Google : qui fait quoi

Cinq critères qui comptent pour quelqu’un qui se pose la question de la souveraineté. Verdict acteur par acteur.

Apple Intelligence. Local par défaut, oui : modèle 3 B on-device, bascule PCC explicite pour les requêtes lourdes. Attestation cryptographique publique, oui : transparency log, environnement de recherche dédié (VRE), code serveur publié sur GitHub. Opt-in cloud, mi-figue mi-raisin : PCC implicite et invisible, ChatGPT explicite et confirmé à chaque requête. LLM tiers intégré, OpenAI ChatGPT, opt-in, OFF par défaut, no-logs tant que tu ne lies pas ton compte. Juridiction serveurs, USA, data centers Apple custom-silicon.

Microsoft Copilot+ / Recall. Local par défaut, partiel : Recall fait ses snapshots en local et ne les envoie jamais au cloud, Copilot général tourne dans Azure. Attestation publique, non : chiffrement VBS local plus TPM, pas d’audit serveur opposable. Opt-in cloud, dépend de la feature : Recall purement local, Copilot général cloud par design, l’utilisateur ne distingue pas toujours laquelle déclenche quoi. LLM tiers intégré, Azure OpenAI GPT-4, intégration commerciale sans opt-in séparé. Juridiction serveurs, USA plus régions Azure globales.

Google Gemini. Local par défaut, non : cloud Google par défaut, Gemini Nano local existe mais reste limité aux Pixel haut de gamme. Attestation publique, non. Opt-in cloud, c’est l’inverse, cloud par défaut, opt-out partiel via Activity, et tu perds des features au passage. LLM tiers intégré, aucun, stack Google verrouillée. Juridiction serveurs, EEE/Suisse via Google Ireland pour les comptes EU, reste du monde via Google LLC (USA).

Une lecture rapide : sur ce dossier précis, Apple fait mieux. Recall version 2025 est solide en local mais reste un vecteur d’attaque sur shared device (Kevin Beaumont l’a documenté en boucle). Gemini conserve un sous-ensemble des chats jusqu’à trois ans pour relecture humaine, même quand tu coupes l’activité. Apple est le seul à publier son code serveur et à payer un million de dollars à qui le casse.

Apple a dépensé un million de dollars à se faire casser. Les autres ont dépensé un million de dollars en spots TV. Ça ne fait pas de PCC une E2EE. Ça en fait l’option cloud IA la moins opaque du marché en 2026.

Le verdict Mack

Apple a construit l’architecture IA cloud la plus auditable du marché grand public. C’est un fait. Trail of Bits, Matthew Green et Schneier le reconnaissent, chacun à sa manière, tout en pointant ce qui cloche.

Ce qui cloche, c’est trois décisions UX qui trahissent une intention marketing supérieure à l’intention privacy : l’opt-out par défaut depuis 15.3, l’absence totale d’indicateur visuel quand une requête bascule en PCC, et le piège silencieux du compte OpenAI lié. Aucun de ces trois points n’est un bug. Ce sont des choix.

Ce que tu peux raisonnablement faire : couper le master si tu n’as pas l’usage, garder le toggle de confirmation ChatGPT sur ON si tu l’utilises, ne jamais lier ton compte OpenAI, vérifier Improve Siri & Dictation après chaque update majeure. C’est cinq minutes de réglages, à refaire deux ou trois fois par an.

Sources

Apple, sources primaires

Apple Machine Learning Research, Introducing Apple’s On-Device and Server Foundation Models, publication officielle des spécifications du modèle on-device (10 juin 2024).
Apple Machine Learning Research, Foundation Models Tech Report 2025 et arXiv 2507.13575, détails techniques 2-bit QAT, PT-MoE, 15 langues (17 juillet 2025).
Apple Security Research, Private Cloud Compute : A new frontier for AI privacy in the cloud et Security research on PCC, la doc PCC complète et le bug bounty.
Apple Legal, ChatGPT Extension and Privacy et Apple Support, Use ChatGPT with Apple Intelligence on Mac, source de référence pour l’IP masking et le no-logs conditionnel.

Analyses indépendantes

Trail of Bits, PCC : a bold step forward, not without flaws, cabinet de sécurité reconnu, l’analyse technique la plus citée sur les limites de PCC (« data decrypted on Apple’s server »).
Matthew Green, thread Mastodon/X sur PCC, cryptographe à Johns Hopkins University, sur l’absence d’indicateur visuel quand une requête bascule en PCC.
Kevin Beaumont (DoublePulsar), Microsoft Recall privacy implications, expert sécurité Windows, sur les risques résiduels de Recall version 2025.
MacRumors, macOS 15.3 enables Apple Intelligence automatically, couverture du basculement opt-in vers opt-out (21 janvier 2025).
IronCore Labs, Privacy Guide to Apple Intelligence with ChatGPT, pour le piège du compte OpenAI lié.

Comparatif IA concurrents

Microsoft Support, Privacy and control over your Recall experience, la doc officielle de Recall après relance avril 2025.
Google Gemini Apps Privacy Hub, la doc Google sur la rétention, l’activité et la relecture humaine.

Stalkerware domestique, le malware du conjoint jaloux

Mac Souverain — Tue, 26 May 2026 17:09:58 GMT

Le stalkerware grand public (Spyzie, Cocospy, Spyic, mSpy) fait plus de trois millions de victimes sur la seule famille Cocospy/Spyic/Spyzie. Trente à soixante-dix dollars par mois, opérateurs Chine. Sur iPhone, ton conjoint connaît ton Apple ID et siphonne iCloud depuis le web. Plus rarement, profil MDM camouflé installé en deux minutes par un proche. Sur Android, app planquée. Modules premium : suivi GPS temps réel et activation micro à distance. La victime ne cherche jamais le mot « stalkerware ». Elle ne sait même pas que ça existe.

Ce que tu dois faire

1. Vérifie Réglages, Général, VPN et gestion des appareils. Tout profil que tu n’as pas posé toi-même, surtout aux noms vagues type « iOS Update », tu supprimes. Vérifie Temps d’écran, désactive le mot de passe que tu n’as pas mis.

2. Change ton mot de passe Apple ID, active la double authentification, sors les appareils inconnus de ta liste, active Protection avancée des données pour basculer tes sauvegardes iCloud en E2EE.

3. Bascule sur Signal pour les messages sensibles, Bitwarden ou KeePassXC pour les mots de passe, jamais un trousseau partagé.

4. Si tu suspectes une installation active, agis depuis un autre appareil et un autre réseau. La Coalition Against Stalkerware liste des ressources par pays.

Le 26 mai, Joseph Cox de 404 Media interviewe Zack Whittaker, le journaliste qui a sorti à peu près tous les leaks stalkerware grand public depuis cinq ans. Verdict, ce n’est pas un marché de niche, c’est un marché de masse. Centaines de milliers de victimes sur un seul réseau. Cible iPhone et Android. Installation par ton conjoint, ton ex, ton colocataire, en deux minutes pendant que tu prends ta douche.

Le fait

Le stalkerware, c’est du spyware vendu à monsieur et madame tout le monde. Pas Pegasus, pas Predator, pas le calibre de spyware mercenaire que Citizen Lab traque depuis Toronto. Le truc qu’on installe sur le téléphone de sa copine pour lire ses messages, écouter ses appels, suivre sa position et activer son micro à distance. Les marques s’appellent Spyzie, Cocospy, Spyic, mSpy, TheTruthSpy.

Whittaker en fait des leaks à répétition depuis 2021. La dernière vague, février 2025, a exposé 518 000 clients de Spyzie dont au moins 4 900 iPhones compromis, et 2,65 millions d’adresses email sur le réseau jumeau Cocospy + Spyic. Plus de trois millions de victimes cumulées sur cette seule famille d’opérateurs.

L’abonnement coûte trente à soixante-dix dollars par mois pour la formule standard, plus si tu prends les modules premium genre micro et caméra. Les sociétés vivent dans des holdings offshore, Chypre, Îles Vierges britanniques, ou directement en Chine. Cocospy, Spyic et Spyzie sont la même équipe, tracée par Whittaker jusqu’à un même opérateur chinois.

mSpy joue un modèle économique identique mais sous une enseigne distincte, héritage Chypre-Ukraine. Quand un leak les expose, ils ferment et rouvrent sous un nouveau nom. Mai 2025, Cocospy disparaît, revient en quelques semaines. Le marché total tourne autour de cent quarante-cinq millions de dollars par an d’après Future Market Insights.

Côté iPhone, la méthode dominante n’a même pas besoin de toucher au téléphone. Ton conjoint connaît ton mot de passe Apple ID, parce que tu le partages, parce qu’il a vu ton iPhone se déverrouiller cent fois, ou parce que vous utilisez le même depuis quinze ans. Il se logue à iCloud depuis un navigateur, télécharge tes sauvegardes, et l’app stalkerware côté serveur fait le tri. Pas d’app sur ton téléphone, rien à détecter en local. C’est la mécanique exacte documentée par Whittaker pour Cocospy, Spyic et Spyzie en 2025.

Variante plus rare mais plus complète : un profil de configuration MDM, le mécanisme conçu à la base pour gérer les flottes d’entreprise. Le proche installe l’app de stalkerware via Apple Configurator sur son Mac, en supervisant ton téléphone avec un câble Lightning ou USB-C. Le profil est marqué removalDisallowed, baptisé d’un nom anodin du genre « iOS Update » ou « Battery Optimizer ». Un mot de passe Temps d’écran que tu ne connais pas masque l’entrée « Gestion d’appareils » dans les Réglages. Tu ne vois rien. Côté Android, c’est l’app camouflée en outil système, planquée derrière un nom générique, avec accessibilité activée pour tout lire à ta place.

Pourquoi ça compte pour toi

C’est ici que la couverture habituelle de la presse cybersec décroche. On parle beaucoup des mercenaires, NSO, Intellexa, Paragon, les milliards d’euros et les cibles diplomatiques. Mais le danger statistique pour un particulier, ce n’est pas un État qui te surveille, c’est ton ex qui te traque. Les États y mettent leur part eux aussi, à pousser pour le contrôle de masse côté législatif comme je l’ai démonté dans Six mois et dix-neuf textes mondiaux, la terrible convergence, mais la fréquence brute de victimes côté domestique écrase tout.

Whittaker répète depuis cinq ans que le stalkerware domestique fait infiniment plus de victimes que tous les spywares mercenaires réunis. La presse l’ignore parce que c’est sale, intime, et que ça n’a pas l’aura géopolitique de Pegasus.

L’asymétrie d’information est totale. L’acheteur tombe sur ces produits en trois clics : faux comparatifs « Top 10 spy apps » dont le site appartient au vendeur, SEO sur les requêtes de jaloux, Reddit avec des comptes affiliés, TikTok au format « POV j’ai pécho mon mec », Google Ads détournés sur « Find My iPhone » ou « family locator ».

Façade marketing « contrôle parental enfants » qui pivote très vite sur « monitor your spouse ». La victime potentielle, elle, ne cherche jamais le mot « stalkerware ». Elle ne sait même pas que ça existe. C’est la définition même d’une menace qu’on ne voit pas venir.

Tu es exactement la cible. Couple avec iPhone et Mac, écosystème Apple intégré, partage iCloud familial, mots de passe communs « parce qu’on se fait confiance ». Le jour où la confiance se fissure, le siphonnage tient en quelques clics depuis un navigateur, ou l’installation MDM en deux minutes pendant que tu fais une course. Et tu ne le sauras qu’en lisant cet article.

Ce que tu fais maintenant

1. Vérifie ton iPhone, profil de configuration et Temps d’écran.
Réglages, Général, VPN et gestion des appareils. Si tu vois un profil que tu n’as pas installé toi-même, surtout avec un nom vague genre « iOS Update », « Battery Saver », « Profile Service », tu désinstalles. Puis Réglages, Temps d’écran. Si un mot de passe est actif et que ce n’est pas toi qui l’as mis, tu désactives via ton Apple ID. Ce mot de passe sert souvent à masquer l’entrée VPN et gestion des appareils. Si le bouton de suppression du profil est grisé ou si le profil revient après un Effacer contenu et réglages, c’est qu’il est marqué removalDisallowed avec supervision DEP active : passage Apple Store nécessaire pour casser la supervision côté serveur Apple. Référence Apple : supprimer un profil de configuration.

2. Reprends le contrôle de tes comptes critiques.
Change immédiatement ton mot de passe Apple ID et active la vérification en deux étapes avec un numéro que ton entourage proche ne contrôle pas. Vérifie la liste des appareils connectés à ton compte Apple ID dans Réglages, ton nom, en haut. Tout appareil que tu ne reconnais pas, tu le supprimes. Active Protection avancée des données iCloud pour passer tes sauvegardes en chiffrement de bout en bout, l’exfiltration discrète depuis le web devient inopérante.

3. Bascule sur des outils E2EE pour ce qui compte.
Messages sensibles sur Signal, pas iMessage. Mots de passe dans un gestionnaire à toi seul, Bitwarden auto-hébergé ou KeePassXC en fichier local, pas un trousseau Apple partagé avec quelqu’un. Backups locaux chiffrés sur disque externe, pas seulement iCloud.

4. Si tu suspectes une installation active, sors du périmètre physique avant d’agir.
Le stalkerware avec micro et GPS te trahit en temps réel. Si tu veux contacter un service d’aide spécialisé sans alerter la personne qui t’espionne, fais-le depuis un appareil et un réseau qui ne sont pas surveillés. La Coalition Against Stalkerware liste des ressources par pays et un kit de réponse pour les victimes.

Sources

Millions of people are installing malware on their partner’s phones, with Zack Whittaker, 404 Media, 26/05/2026 (source primaire)
Spyzie stalkerware spying on thousands of Android and iPhone users, TechCrunch, 27/02/2025 (enquête Whittaker, 518k clients + 4 900 iPhones)
Cocospy and Spyic exposing phone data of millions of people, TechCrunch, 20/02/2025 (architecture du marché, lien 711.icu Chine)
Cocospy stalkerware apps go offline after data breach, TechCrunch, 19/05/2025 (pattern rebranding post-leak)
Stalkerware apps escape Google’s ad ban, TechCrunch, 11/08/2020 (contournement Google Ads)
Coalition Against Stalkerware, ressources victimes

Des termes techniques ? Consulte le glossaire.

Le régulateur cyber US a laissé fuiter ses clefs AWS six mois

Mac Souverain — Tue, 26 May 2026 13:39:33 GMT

CISA, l’agence cyber fédérale américaine, vient de découvrir qu’un de ses sous-traitants avait laissé pendant six mois un dépôt GitHub public bourré de clefs admin AWS GovCloud, tokens, mots de passe en clair. Détection externe par GitGuardian, pas en interne. Les clefs sont restées valides 48 h après le retrait du repo. Si le régulateur cyber fédéral ne sait même pas garder ses propres secrets, tu te demandes comment toi tu le pourrais ? Je t’explique ça !

Ce que tu dois faire

1. Inventorie ce que tu confies aujourd’hui à un cloud tiers, et pour chaque ligne demande-toi qui a la clef de déchiffrement. Le chiffrement at-rest avec les clés coté serveur égal zéro.

2. Choisis tes fournisseurs cloud sur un seul critère : chiffrement bout-en-bout, clef côté client (Proton, Tuta, Mullvad côté UE).

3. Ce qui se passe chez toi reste chez toi : sauvegardes sur disque externe chiffré APFS, double exemplaire offsite chiffré.

CISA, l’agence cyber fédérale américaine, vient de découvrir que son propre sous-traitant Nightwing avait laissé traîner pendant six mois un dépôt GitHub public bourré de clefs admin AWS GovCloud. Personne chez eux ne s’en est aperçu. C’est GitGuardian, depuis l’extérieur, qui a tiré la sonnette.

Le fait

Le 22 mai 2026, Brian Krebs publie l’enquête. Un salarié de Nightwing, sous-traitant historique de la CISA basé à Dulles en Virginie, a créé le 13 novembre 2025 un dépôt GitHub baptisé sobrement « Private-CISA ». Le mot « Private » dans le nom, le réglage public dans les paramètres. Le repo est resté en ligne, accessible à n’importe qui, jusqu’à mi-mai 2026. Six mois.

À l’intérieur, du lourd. Trois jeux de clefs d’administration pour des comptes AWS GovCloud, l’environnement cloud d’Amazon dédié aux agences fédérales américaines, certifié FedRAMP High pour héberger des données sensibles non classifiées (CUI).

Des tokens d’accès, des clefs SSH, des logs internes, et des mots de passe en clair suivant le pattern « plateforme-année » que ton stagiaire de troisième n’oserait pas tenter. Plus quelques documents internes sur les processus de développement logiciel de l’agence. Ben autant dire presque rien quoi !

Et la détection ? Ni interne CISA, ni audit Nightwing. C’est Guillaume Valadon, chercheur chez GitGuardian, qui scanne en continu les dépôts publics à la recherche de secrets oubliés, qui a trouvé le repo. Krebs et la boîte conseil Seralys ont notifié la CISA, qui a fait retirer le repo. Cerise : les clefs AWS sont restées valides 48 heures de plus après la suppression du dépôt. Le temps que l’agence se décide à les révoquer.

La déclaration officielle CISA tient en une phrase, on l’a déjà vue cent fois : « rien n’indique à ce stade que des données sensibles aient été compromises ». Nightwing renvoie sur CISA, CISA renvoie sur l’enquête. Krebs qualifie l’épisode d’« une des fuites de données gouvernementales les plus scandaleuses de l’histoire récente », et Bruce Schneier reprend la formule sans la nuancer.

Pourquoi ça compte pour toi

Tu n’es pas la CISA, tu n’as pas de sous-traitant Nightwing, tu n’utilises pas AWS GovCloud. Très bien. Maintenant, fais le calcul froid. L’agence qui dicte aux administrations US les règles de l’art en cybersécurité, qui publie les guides « secure by design » et les alertes CVE que toute l’industrie suit, vient de laisser ses propres clefs d’admin cloud en libre accès pendant six mois sans s’en rendre compte. Ni un sous-traitant douteux, ni un SaaS de troisième zone : le régulateur cyber lui-même.

L’argument est structurel, pas anecdotique. Quand tu confies tes secrets à un tiers, peu importe son sérieux affiché, tu hérites de toute sa chaîne de sous-traitance. CISA confie à Nightwing, Nightwing emploie quelqu’un, ce quelqu’un pousse sur GitHub. Le maillon faible compromet toute la chaîne en un instant. C’est déjà assez grave en soi. Mais si tu ajoutes à ça la flambée des menaces IA, tu obtiens potentiellement une porte d’entrée sur des systèmes plus confidentiels encore.

On va en revenir à toi. Tu as un repo GitHub perso ? Tu as déjà collé une clef d’API dans un commit pour « tester rapidement » avant d’oublier de la sortir de l’historique ? Tu utilises un gestionnaire de mots de passe cloud propriétaire pour des creds qui ouvrent ton infra ? Tu fais confiance à un éditeur SaaS sous juridiction étrangère pour garder tes secrets bien chiffrés chez lui ? Le radar CISA, c’est toi en miniature, mais avec moins de zéros sur les conséquences.

L’angle MacSouverain ne change pas d’un millimètre depuis le premier article. Tes secrets, tu les gardes chez toi. Sur ta machine, dans ton coffre local, sous ta clef. Tu peux déléguer la mise en page, la synchro, la sauvegarde chiffrée. Tu ne délègues pas la sécurité elle-même. Parce que le jour où ton fournisseur se vautre, et il se vautrera, tu veux que le rayon de l’explosion s’arrête à lui.

Ce que tu fais maintenant

1. Refais l’inventaire de ce que tu confies aujourd’hui à un tiers cloud.
Sors une feuille. Mots de passe, mails, agenda, contacts, fichiers, notes, sauvegardes photos. Pour chacun, écris où c’est stocké et qui a la clef de déchiffrement. Si la réponse à “qui a la clef” est “le fournisseur, ou un de ses sous-traitants”, tu es exactement dans la position de la CISA. Tu fais confiance à une chaîne dont tu ne contrôles pas un maillon. La CISA y croyait aussi.

2. Choisis tes fournisseurs cloud sur le critère “chiffré bout-en-bout, clef côté lecteur”.
Pour ce que tu dois forcément mettre dans le cloud (synchro multi-appareils, partage, sauvegarde), n’accepte que des fournisseurs qui ne peuvent pas lire ton contenu, même s’ils en avaient envie ou qu’on le leur demandait.

Côté mail et stockage : Proton ou Tuta, juridiction européenne, chiffrement bout-en-bout par défaut. Côté VPN : Mullvad ou Proton VPN, sans logs. La différence avec AWS, Google Drive, iCloud non-ADP : tu n’as pas à croire le fournisseur sur parole, l’architecture rend la fuite techniquement inexploitable.

3. Ce qui se passe chez toi reste chez toi.
Ce que tu peux garder local, garde-le local. Photos, archives, documents sensibles, sauvegardes : un disque externe chiffré APFS chez toi, plus un deuxième exemplaire chiffré que tu déposes chez un proche ou dans un coffre. Si tu as besoin de synchroniser des fichiers entre tes propres machines sans passer par un tiers, Syncthing fait du P2P direct entre tes appareils, point. Tu ne montes pas dans le cloud par défaut, tu y montes par choix réfléchi. La règle CISA s’applique en miniature à chacun : le jour où ton fournisseur se vautre, et il se vautrera, tu veux que le rayon de l’explosion s’arrête à lui, pas qu’il t’emporte avec.

Sources

CISA Admin Leaked AWS GovCloud Keys on GitHub, Krebs on Security, 22/05/2026 (source primaire)
CISA Security Leak, Schneier on Security, 22/05/2026 (reprise commentée)
GitGuardian, scanner de secrets dans les dépôts publics

Voir aussi

À lire : Le cloud, c’est l’ordinateur de quelqu’un d’autre

À lire : Gestionnaire de mots de passe sur Mac, comparatif

Des termes techniques ? Consulte le glossaire.

Ton Mac a été patché par XProtect à ton insu, c'est pour ton bien

Mac Souverain — Tue, 19 May 2026 07:25:30 GMT

Introduction

Pendant que tu dormais, le 11 mai en début de soirée, 170 paquets logiciels que la moitié du web utilise sont devenus malveillants en six minutes. Le lendemain, Apple a poussé une signature XProtect sur ton Mac, sans rien te dire.

Les deux événements sont liés, probablement. Cependant, tu ne le sauras jamais vraiment. L’épisode a un nom, TanStack. Le mécanisme qui a peut-être réagi sur ton Mac s’appelle XProtect. Tu n’as rien vu passer, moi non plus. Apple s’en assure.

Bienvenue dans le système de défense silencieux de ton Mac.

L’incident TanStack en 30 secondes

Le 11 mai 2026 au soir, l’écosystème TanStack, un kit d’outils JavaScript ultra-populaire utilisé par des millions de développeurs (dont ceux d’OpenAI, Netflix, Shopify), se fait piéger. En six minutes, 170 paquets sortent en version vérolée. Le plus visible, react-router, est téléchargé 12 millions de fois par semaine. Autant dire : une partie significative du web qui se met à jour cette semaine récupère du code piégé sans le savoir.

Le malware s’appelle Mini Shai-Hulud, variante du worm npm qui sévit depuis 2024. Sa cible, c’est ce qui traîne sur le Mac du développeur : mots de passe, clés d’accès cloud, jetons GitHub, fichiers de session. Sur macOS, il s’installe en planque dans un coin du système qui le relance à chaque ouverture de session. Discret, propre, professionnel.

Le détail qui inquiète vraiment, c’est le vecteur. L’attaquant n’a pas volé de mot de passe, ni exploité de faille dans le code. Il a juste soumis une fausse contribution au projet open source TanStack, en exploitant une configuration imprudente du système d’automatisation.

Toute contribution était exécutée avec les vrais droits de publication officiels. Une contribution piégée (pull request) a suffi pour récupérer le jeton de signature et publier 170 paquets sous l’identité légitime du projet. Du côté de npm, tout paraissait normal, signé, vérifié. Tamponné par TanStack lui-même.

OpenAI a été touché par ricochet, via une de ses dépendances. Officiellement, aucune preuve de compromission de produits ou de données utilisateur. Mais la boîte a quand même rotaté toutes ses clés de signature applicative sur macOS, iOS, Windows, Android, et republie l’intégralité de ses apps sous nouveaux certificats.

Inutile de te dire que tu ne fais pas ça quand tout va bien.

Apple a réagi le lendemain. Sans communiqué, sans notification, sans onglet dans Réglages. Une signature XProtect a été poussée silencieusement. Les Macs l’ont récupérée au fil des heures, chacun son tour, sans prévenir personne.

XProtect, l’antivirus muet d’Apple

XProtect, c’est l’antivirus intégré de macOS. Il est là depuis Snow Leopard, et la plupart des utilisateurs ignorent jusqu’à son existence. C’est voulu.

Le système fonctionne en deux briques. La première, c’est le moteur de signatures : un fichier que macOS consulte avant d’exécuter une app téléchargée pour vérifier qu’elle ne correspond pas à un malware connu. La deuxième, c’est XProtect Remediator — XPR —, un scanner qui tourne en tâche de fond et inspecte ton disque à la recherche de menaces déjà installées. Quand il en trouve une, il la neutralise.

Les signatures sont poussées par Apple via CloudKit, le même tuyau silencieux qui synchronise tes photos iCloud et ton trousseau. Quand un malware significatif émerge, Apple compile une signature, la signe, la dépose sur CloudKit. Ton Mac la récupère au prochain check, généralement dans les 24 à 72 heures.

Pas de notification. Pas de redémarrage. Pas de message “votre Mac a été mis à jour”. Apple a fait un choix éditorial assumé, ne pas affoler l’utilisateur. Le revers, c’est que tu n’as aucun moyen de savoir, à l’œil nu, si tu es bien patché pour l’incident récent.

C’est là que ça devient intéressant.

Le push 5344, le 12 mai, lendemain de TanStack

La version XProtect publiée le 12 mai 2026 s’appelle 5344. La précédente, 5342, datait du 5 mai. Concordance temporelle parfaite avec TanStack, à J+1.

Sauf qu’Apple ne documente jamais publiquement le contenu d’une signature XProtect. Howard Oakley, qui décortique chaque release sur eclecticlight.co, observe sur 5344 « quelques ajustements sur des familles de malware connues ». Pas de signature nommée TanStack ou Shai-Hulud. Rien qui dise officiellement « ceci est la réponse à l’incident d’hier ».

Coïncidence ou réaction ciblée ? Apple ne dit rien. C’est précisément ce flou qui justifie qu’on regarde dedans.

Vérifier en 30 secondes que ton Mac est patché

Sur macOS 15 Sequoia et macOS 26 Tahoe, Apple a déplacé XProtect dans un nouvel emplacement et fournit une commande native. C’est la voie recommandée. Sur macOS 14 Sonoma et antérieurs, l’ancien emplacement reste valide. Je donne les deux.

1. La version des signatures XProtect

Sur Sequoia et Tahoe, la commande de référence :

sudo xprotect version

Tu obtiens un numéro du genre 5344 ou 5347. C’est la base de signatures. Plus c’est haut, plus c’est récent.

Sur Sonoma et antérieurs :

defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info CFBundleShortVersionString

L’ancien chemin existe encore sur Sequoia et Tahoe, mais ce n’est plus celui que macOS consulte en premier. Tu peux le lire et tomber sur une version périmée pendant que sudo xprotect version te donne la vraie. C’est exactement le genre de piège qui fait croire à un Mac à la traîne alors qu’il est à jour.

2. La version de XProtect Remediator

defaults read /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/Info CFBundleShortVersionString

Tu obtiens un numéro du genre 157. C’est le scanner lui-même, mis à jour beaucoup moins souvent que les signatures.

3. L’historique d’installation

system_profiler SPInstallHistoryDataType | grep -A 2 -i xprotect

Tu vois toutes les versions XProtect installées avec leurs dates. Pratique pour vérifier que tu n’as pas un Mac coincé sur une vieille base parce que CloudKit a un problème.

Pour comparer ta version à ce qu’Apple publie en temps réel, le tracker public d’Howard Oakley, eclecticlight.co, maintient la liste à jour. Oakley est un ingénieur britannique qui décortique macOS depuis quinze ans, c’est la référence sur le sujet.

Et si ton Mac traîne, tu forces le check :

sudo xprotect update

Sur Sonoma et antérieurs, l’ancienne commande sudo softwareupdate --background-critical reste opérationnelle.

Au moment où je publie, la dernière version est 5344, le 12 mai 2026. Si ton Mac affiche moins, ton canal CloudKit traîne.

Le revers souverain

XProtect, c’est une boîte noire signée Cupertino. Tu ne sais pas quelles signatures sont poussées, tu ne sais pas quelle télémétrie remonte au passage, tu ne sais pas qui décide qu’un binaire est malveillant. Apple décide, Apple pousse, ta machine exécute.

Le mécanisme est utile, très utile même. Bloquer des malwares connus avant qu’ils s’exécutent, c’est la base d’une défense moderne, et le faire sans te solliciter évitera que tu le désactives le jour où t’es fin énervé par cette rognutudju!! de pop-up (cherche pas, si t’as moins de 50 berges, t’as pas la ref).

Les trois commandes ci-dessus te donnent un droit de regard minimal sur ce que ton OS fait sans te demander. C’est un petit pas vers la souveraineté, pas reprendre le contrôle, juste savoir.

La différence entre un utilisateur passif et un utilisateur souverain n’est pas que dans les outils utilisés. Elle est aussi dans les questions qu’il se pose. Quelle version j’ai. Quand a-t-elle été poussée. Qu’est-ce qu’elle contient.

Apple répond aux deux premières en trois lignes Terminal. Sur la troisième, elle se tait. C’est Howard Oakley qui décortique le contenu après coup et publie les diffs sur eclecticlight.co. Tu ne sauras jamais en direct ce qu’Apple a estampillé malveillant cette nuit.

Tous les mois, je vérifie tout de même les versions XProtect sur mes Macs. Rien d’héroïque, juste une habitude. Le jour où le canal CloudKit déconne, j’aurai un point de référence.

À lire : Les paramètres macOS à changer immédiatement

En résumé

XProtect est utile, silencieux, et hors de ton contrôle. Le sujet est de savoir qu’il existe, de connaître les trois commandes qui te disent où tu en es, et de comprendre que dans la chaîne d’approvisionnement JavaScript de 2026, comme dans d’autres chaînes de compromission, c’est lui qui colmate les fuites.

Lance les trois commandes. Note tes numéros. Compare-les à eclecticlight.co de temps en temps. Ça prend trente secondes, et ça te permet de savoir si tu es bien patché et à jour.

À lire : Lockdown Mode face à Coruña, le toolkit d’espionnage gouvernemental

Des termes techniques ? Consulte le glossaire.

Cinq ans de défense mémoire M5 tombent en cinq jours

Mac Souverain — Tue, 19 May 2026 07:23:49 GMT

Trois chercheurs ont pris le contrôle total d’un Mac M5 en cinq jours, avec un coup de main de Mythos, l’IA spécialisée vulnérabilités d’Anthropic. Au passage, ils ont fait tomber MIE, la nouvelle protection mémoire qu’Apple a mis cinq ans à construire. Apple a déjà patché dans macOS Tahoe 26.5 le 11 mai. Premier exploit kernel public sur silicon M5, et démonstration grandeur nature qu’une IA peut accélérer ce genre de travail d’un facteur dix.

Ce que tu dois faire

1. Mets à jour macOS Tahoe 26.5 immédiatement (Préférences Système, Mise à jour de logiciels).

2. Active Lockdown Mode si tu es exposé professionnellement (journaliste, militant, cadre).

3. Évite tout binaire utilisateur non-vérifié. Gatekeeper strict, signatures sur Homebrew.

Le fait

Le 14 mai 2026, la boîte sécu Calif.io raconte comment elle a fait. Trois chercheurs (Bruce Dang, Dion Blazakis, Josh Maine) ont trouvé deux bugs dans le noyau de macOS, sur un Mac M5 flambant neuf. Ils ont enchaîné les deux. Résultat : un utilisateur normal, sans aucun privilège spécial, obtient les pleins pouvoirs sur la machine (root). Lecture de toute la mémoire, accès au Keychain, désactivation des protections. Tout.

Ce qui rend le truc historique, c’est ce qui est tombé au passage. La puce M5 embarque pour la première fois MIE (Memory Integrity Enforcement), une protection gravée directement dans le silicium. En clair : Apple a mis une étiquette sur chaque morceau de mémoire utilisé par le noyau, et le hardware refuse les manipulations frauduleuses. Cinq ans de travail. Présenté l’an dernier comme la nouvelle frontière de la sécurité Mac. Calif l’a contournée en cinq jours.

L’élément qui change la donne : Mythos. C’est le modèle frontier d’Anthropic, en accès restreint, dédié à la recherche en vulnérabilités. Les chercheurs précisent que Mythos n’a pas trouvé l’exploit tout seul. Bypasser MIE demande une expertise humaine pointue. Mais Mythos a repéré les bugs très vite, là où des humains seuls auraient passé des semaines à fouiller. Le travail qui prenait des mois prend désormais quelques jours.

Calif a remis les détails à Apple à Cupertino, en main propre. Apple a publié les correctifs dans macOS Tahoe 26.5 le 11 mai 2026. Les release notes créditent nommément « Calif.io in collaboration with Claude and Anthropic Research ». Le rapport technique complet (55 pages) reste sous embargo le temps que les patchs se déploient partout. Apple n’a pas commenté publiquement la chaîne d’exploit.

Pourquoi ça compte pour toi

Si tu as un Mac M5, ton hardware était vendu comme la frontière haute de la sécurité Apple. Cinq jours après la sortie de l’exploit, la frontière s’est déplacée. La protection matérielle ne suffit plus, un humain bien équipé peut la faire tomber en une semaine.

Bonne nouvelle : ce n’est pas une attaque à distance. Pour exploiter les bugs sur ton Mac, l’attaquant a besoin d’un pied dans la porte. Un binaire piégé que tu as lancé toi-même (Homebrew compromis, app récupérée hors App Store, fichier ouvert depuis un drive partagé douteux). À partir de là, par contre, il devient root et fait ce qu’il veut.

Le contexte plus large : Mythos enchaîne les coups d’éclat. Le 11 mai, le mainteneur de curl, Daniel Stenberg, confirmait qu’une faille de son code avait été trouvée par Mythos (Stenberg reste très critique sur le hype, mais reconnaît le résultat). Trois jours plus tard, Calif.io fait tomber MIE. La fenêtre entre « bug découvert » et « exploit fonctionnel » se referme. Apple, Google et Microsoft ont tous reconnu publiquement que les modèles IA dernière génération changent leur modèle de menace. On le voit maintenant en pratique.

Ce que tu fais maintenant

1. Mets à jour macOS Tahoe 26.5 maintenant, sur tous tes Macs (M5, M4, M3, M2, M1, Intel). La mise à jour couvre des bugs au-delà du seul M5. Préférences Système, Général, Mise à jour de logiciels. Si tu es resté sur macOS Sequoia 15.7.7 ou macOS Sonoma 14.8.7, ils ont reçu les correctifs cousins le même jour.

2. Active Lockdown Mode si tu es exposé professionnellement (journaliste, militant, cadre dirigeant, chercheur). Lockdown Mode coupe drastiquement la surface d’attaque sur la mémoire du noyau, exactement le type de bugs que Calif a utilisé. Préférences Système, Confidentialité et sécurité, Lockdown Mode. Attention, frictions à prévoir.

À lire : Lockdown Mode, pourquoi l’activer

3. Évite les binaires venus de nulle part. Pas d’app hors App Store sans audit, pas d’exécutable récupéré au hasard. Vérifie les signatures (GPG, SHA256) sur les outils sensibles, Homebrew compris. Active Gatekeeper strict dans Préférences Système, Confidentialité et sécurité, n’autoriser que l’App Store.

4. À suivre : les 55 pages techniques de Calif sortent une fois les patchs déployés partout. Le jour où le rapport est public, attends-toi à une vague de copies sur GitHub et à un scan complet du parc Mac par les équipes sécu. D’ici là, tu n’as rien à faire de plus que rester à jour.

Sources

Voir aussi

Anthropic Mythos : accès non autorisé identifié

Google Ads et vrai chat Claude partagé vident tes credentials

Mac Souverain — Thu, 14 May 2026 11:58:10 GMT

Une campagne malvertising détourne Google Ads et la fonction Share de Claude.ai pour pousser MacSync, infostealer macOS qui vide ton Trousseau via une simple commande Terminal collée par toi-même. Le pattern combine deux signaux de confiance (domaine officiel claude.ai + faux Support Apple) pour t’amener à exécuter du base64 sans te méfier.

Ce que tu dois faire

1. Ne paste jamais de commande Terminal dictée par un site, un chat IA ou un PDF “officiel”.

2. Active Little Snitch ou LuLu et surveille les sorties réseau inattendues.

3. Si déjà exécuté : déconnecte le Wi-Fi, change tous tes mots de passe browser, scanne avec KnockKnock.

Tu cherches “Claude mac download” sur Google. Le premier résultat sponsorisé pointe vers claude.ai, donc l’URL est légitime. Sauf que c’est un chat partagé Claude où un faux “Apple Support” te dicte la commande Terminal à coller. Tu colles, et MacSync part avec ton Trousseau, tes cookies et tes credentials browser.

Le fait

Berk Albayrak (Trendyol Group) et BleepingComputer documentent depuis le 10 mai 2026 une campagne de malvertising macOS active qui détourne deux mécanismes légitimes simultanément. D’abord Google Ads : une annonce sponsorisée pour “Claude mac download” pointe vers claude.ai, le domaine officiel d’Anthropic. Ensuite Claude.ai Share : la fonctionnalité de chats partagés sert à héberger un faux guide d’installation signé “Apple Support” qui dicte au lecteur de coller une commande encodée en base64 dans Terminal.

Le contenu de cette commande télécharge un shell script polymorphe depuis l’infrastructure attaquante, vérifie la disposition clavier (sortie immédiate si russe ou CIS), puis exécute le payload de seconde étape via osascript (le moteur AppleScript natif de macOS), pour livraison fileless. Le malware s’appelle MacSync, c’est un infostealer qui collecte les credentials et cookies des navigateurs, exfiltre le Trousseau macOS et fingerprint la victime (IP, hostname, version OS, langue clavier).

Les indicateurs de compromission publiés : payload customroofingcontractors[.]com/curl/ et bernasibutuwqu2[.]com/debug/loader.sh, exfil vers briskinternet[.]com. Les deux URL Claude.ai Share piégées identifiées sont claude[.]ai/share/9aac1046-a39e-4618-8265-f54c4be863f7 et claude[.]ai/share/eb2db455-1d47-4baf-8671-0a689e165902.

Te fais pas de bile, ici les liens sont désactivés. Mais Anthropic n’avait pas désactivé le mécanisme de share au moment de la publication BleepingComputer.

Pourquoi c’est un précédent

Deux choses, vraiment. D’abord, la fonctionnalité “shared chat” d’une plateforme IA grand public devient une surface de distribution malware. Les pages partagées Claude.ai sont publiques, indexables, et fait notable ici, pas modérées comme du contenu utilisateur classique. Elles héritent de la confiance visuelle du domaine Anthropic, et au moment des publis BleepingComputer / GBHackers, les deux URL share piégées étaient toujours en ligne.

Ensuite, le détournement de marque IA vient s’ajouter aux schémas malvertising connus (Homebrew, Loom, Notion, AnyDesk), Claude Code étant un outil dev récent, sa page officielle d’installation n’est pas encore un réflexe musculaire, ce qui laisse une fenêtre exploitable.

C’est aussi un cas d’école sur Google Ads, malgré les contrôles annoncés, des publicités usurpant des marques continuent de passer en exploitant l’URL d’affichage légitime tout en pointant vers une page piégée chez l’éditeur lui-même.

La validation domaine ne suffit pas quand l’éditeur héberge du contenu utilisateur. La responsabilité se répartit alors, Anthropic doit muscler la modération des shared chats (détection chats se présentant comme support officiel d’autres marques, bannière sur chats contenant des commandes shell, watermark visuel distinguant un chat partagé d’une page produit), Google doit aller au-delà du domaine d’affichage dans la validation Ads. Mais la dernière ligne reste toi, ne jamais coller aveuglément une commande shell.

Pourquoi ça compte pour toi

Le pattern social engineering ici est redoutable parce qu’il enchaîne deux signaux de confiance habituellement légitimes. Domaine claude.ai officiel, fonctionnalité Share native d’Anthropic, faux “Apple Support” dans un environnement IA réputé sérieux. Tu n’as pas affaire à un site obscur de download, tu cliques sur ce qui ressemble à de la doc officielle remontée par un moteur de recherche, c’est exactement le genre d’attaque qui passe sous le radar de la vigilance habituelle.

La cible est large. Pas seulement les développeurs (Homebrew, GitHub) mais tout utilisateur Mac curieux d’essayer Claude en application desktop. Le malware ne demande aucune élévation système, pas de 0day, pas de TCC à contourner, l’utilisateur fait tout le boulot lui-même en collant la commande. Et osascript étant un binaire Apple signé natif, il passe inaperçu de la plupart des EDR grand public et même de XProtect.

L’angle qui te concerne directement : c’est le retour offensif du Trousseau macOS comme cible privilégiée. Tu as appris à protéger le mot de passe utilisateur de ton Mac, à activer FileVault, à mettre Touch ID. Mais une commande Terminal lancée par toi-même contourne tout ça, parce que c’est toi-même qui ouvres la porte.

Ce que tu fais maintenant

1. Ne colle JAMAIS une commande Terminal dictée par un site web, un chat IA ou un PDF “support officiel”. Si tu dois installer un outil comme Claude desktop, va directement sur claude.ai/download en tapant l’URL toi-même, jamais via résultat sponsorisé Google. La règle universelle : si quelqu’un te demande de coller quoi que ce soit dans Terminal, c’est non.

2. Active Little Snitch ou LuLu en mode silencieux durci. Les deux loggent et bloquent les sorties réseau inattendues vers les IOC publiés (customroofingcontractors[.]com, bernasibutuwqu2[.]com, briskinternet[.]com). En cas de doute après une commande hâtive, regarde les connexions sortantes des minutes qui suivent.

3. Si tu as exécuté une commande douteuse récemment : déconnecte-toi du Wi-Fi immédiatement, change tous tes mots de passe browser (depuis un autre device propre), révoque tous tes tokens de sessions cloud actives (mail, sync, password manager), scanne avec KnockKnock ou ReiKey d’Objective-See, vérifie les launch agents dans ~/Library/LaunchAgents/.

4. Surveille ton Trousseau. security dump-keychain | grep -i password te dit ce qui est dedans. Pour la suite, migre tes mots de passe sensibles vers Apple Passwords ou Proton Pass, pas dans le Trousseau iCloud généraliste par défaut.

Sources

Voir aussi

Apple corrige des CVE iOS et macOS : patche, puis règle les profils Safari

Mac Souverain — Wed, 13 May 2026 14:15:25 GMT

iOS 26.5 et macOS Tahoe 26.5 publiés le 11 mai corrigent 98 CVE chacun (dont 21 et 22 sur WebKit). Lockdown Mode global, c’est trop pour ton quotidien. Les profils Safari, dispos depuis iOS 17, font la segmentation d’usage à ta place.

Ce que tu dois surveiller

1. Installe iOS 26.5 et macOS Tahoe 26.5 dès aujourd’hui.

2. Crée un profil Safari “Sensible” avec extensions privacy activées uniquement sur lui.

3. Bascule dessus pour banque, mail web, liens douteux, recherche médicale. Profil par défaut intact pour le reste.

Apple a publié le 11 mai iOS 26.5 et macOS Tahoe 26.5, qui corrigent 98 CVE côté iOS (dont 21 sur WebKit, le moteur de Safari) et 98 côté macOS (dont 22 WebKit). Tu installes le patch. Et après ? Plutôt qu’activer Lockdown Mode partout et casser la moitié des sites que tu visites, il existe une option plus fine, dispo depuis iOS 17 et que presque personne n’utilise : les profils Safari.

Le fait

Lundi 11 mai, Apple a publié iOS 26.5 et macOS Tahoe 26.5 en stables. 98 correctifs de sécurité côté iOS (dont 21 sur WebKit), 98 côté macOS (dont 22 WebKit). Plusieurs vulnérabilités permettaient à un site malveillant d’exécuter du code ou de contourner les protections sandbox. C’est le profil normal d’une release Apple : WebKit prend toujours le plus gros lot, parce que c’est la plus large surface d’attaque d’un iPhone ou d’un Mac.

Patche maintenant. Ça, c’est l’évidence. La vraie question, c’est ce que tu fais entre deux patchs, sur les liens reçus par mail, les recherches sensibles, les sessions banque.

Pourquoi Lockdown Mode tout le temps, c’est trop

Lockdown Mode est solide. MacSouverain en a fait l’éloge dans l’article 29. Pour un journaliste, un dissident, un avocat sur dossier sensible, c’est exactement ce qu’il faut.

Pour un freelance ou une PME qui veut juste lire son mail Proton, faire sa compta en ligne et regarder une recette le soir, c’est trop. JIT JavaScript désactivé, extensions Safari coupées, formats média restreints, pièces jointes Messages filtrées. Trop de friction, trop de sites qui rendent mal. Résultat classique : tu actives trois jours, tu trouves ça pénible, tu désactives, tu te retrouves avec rien.

Ce que sont les profils Safari

Depuis iOS 17 et macOS Sonoma (septembre 2023), Safari supporte plusieurs profils dans la même app. Resté discret, jamais mis en avant en keynote. La plupart des gens à qui tu en parles ne savent pas que ça existe.

Chaque profil a son propre historique, ses propres cookies, ses propres extensions activées, son propre moteur de recherche, ses propres favoris et groupes d’onglets. Aucun mélange : le cookie de session Google de ton profil “Perso” n’est pas vu par ton profil “Sensible”. Les extensions privacy actives sur “Sensible” ne ralentissent pas la navigation “Perso”. Bascule en deux taps (bouton onglets sur iPhone, menu Safari sur Mac), synchro iCloud entre Mac et iPhone.

C’est la segmentation d’usage qu’on conseille en sécurité depuis des années, mais sans installer un second navigateur.

Ce que tu fais maintenant

1. Installe iOS 26.5 et macOS Tahoe 26.5. Réglages, Général, Mise à jour logicielle. Vingt minutes, redémarrage compris.

2. Crée un profil Safari “Sensible”. Sur Mac : Safari, menu Safari, Créer un profil. Sur iPhone : Réglages, Apps, Safari, Profils, Nouveau profil. Nom, icône, couleur.

3. Configure le profil “Sensible” : moteur de recherche DuckDuckGo ou Qwant (réglage par profil), favoris vides, et ajoute deux ou trois extensions privacy activées uniquement sur ce profil : AdGuard pour Safari (gratuit App Store, filtrage réseau et cosmétique), Vinegar si tu veux un YouTube propre (achat one-shot), StopTheMadness Pro si tu as déjà sa licence. Ton profil par défaut reste intact, pas de ralentissement quand tu surfes normalement.

4. Ce que le profil n’isole pas : les réglages avancés Safari (bloquer tous les cookies, désactiver JavaScript, blocage du tracking) sont globaux, ils s’appliquent à tous les profils. Si tu veux durcir ces toggles, fais-le globalement dans Réglages, Apps, Safari, en sachant que ça affectera aussi ton profil par défaut.

Quand basculer sur le profil “Sensible”

Lien reçu par mail d’un expéditeur inconnu. Recherche médicale ou juridique. Connexion banque ou broker. Mail Proton sur le web depuis un appareil moins utilisé. Tout site dont tu n’es pas sûr et que tu n’as aucune envie de cookier ton profil principal avec. Deux taps, tu bascules, tu fais ce que tu as à faire, tu reviens.

Segmentation d’usage, pas durcissement global. Tu gardes ton confort sur ton profil par défaut, tu as un mode “navigation propre” à disposition.

Ce que ça ne remplace pas

Les profils Safari ne sont pas Lockdown Mode. Le JIT JavaScript reste actif sur tous les profils. Si tu es journaliste source-sensible, avocat sur dossier étatique, dissident, ou si tu as déjà reçu une notification Apple de menace, Lockdown Mode global reste le bon réglage. Les profils Safari sont un outil pour le quotidien standard, pas une protection contre des acteurs étatiques.

Et l’hygiène de base ne change pas : tu patches (iOS 26.5 maintenant), tu n’ouvres pas les pièces jointes que tu n’attends pas, tu vérifies l’URL avant de taper un mot de passe.

Sources

Voir aussi

kSuite vs Google Workspace, le comparatif honnête

Mac Souverain — Sun, 10 May 2026 14:27:21 GMT

Introduction

Tu paies tous les mois pour Google Workspace. Tu lis MacSouverain et tu te sens concerné par ta Privacy. À un moment, la dissonance devient gênante.

La question n’est pas “Workspace, c’est mauvais ?”. Workspace marche très bien, c’est même la référence. La question, c’est : qu’est-ce que tu paies au juste, et qu’est-ce que tu lui donnes en échange. Et est-ce qu’il existe une alternative qui te rend ton Mac, ta juridiction et tes données sans te coller un downgrade fonctionnel.

kSuite, édité par Infomaniak depuis Genève, se vend exactement sur cette promesse. On va regarder si elle tient.

Les critères qui comptent

Comparer deux suites collaboratives sans grille, c’est faire une publi-rédactionnelle. Voici les six critères que j’ai retenus, et ce que j’ai délibérément écarté.

Juridiction et souveraineté des données. Où sont stockées les données, sous quelle loi, qui peut y accéder par voie légale. Ce critère prime sur tout le reste pour MacSouverain, parce qu’il est structurel et non négociable à coups de feature.

Chiffrement réel. Pas “chiffré” en général. At-rest, in-transit, et surtout end-to-end : qui détient les clés. C’est la seule grille qui résiste à une réquisition.

Prix et lisibilité. Combien tu paies par utilisateur, ce que tu obtiens, ce qui change quand l’éditeur fait du “pricing update”.

Intégration native macOS et iOS. Apple Mail, Calendar, Contacts, Files. Est-ce que tu peux travailler sans installer une seule app de l’éditeur sur ton Mac. C’est le marqueur “souverain pratique”.

Couverture fonctionnelle pro. Mail pro, drive partagé, visio, docs collaboratifs, console admin, SSO, MDM. Une suite qui te force à en garder une autre à côté, c’est une demi-suite.

Sortie possible. Export, formats standards, import depuis le concurrent. Tu n’es pas mariée à ton fournisseur cloud, sauf si tu acceptes de l’être.

Ce que je n’ai PAS évalué : les usages très spécifiques (Workspace for Education, conformité HIPAA US, FedRAMP). Si tu es un hôpital américain, ce comparatif n’est pas pour toi. Si tu es une PME européenne, un freelance ou un family office, on continue.

kSuite, par Infomaniak

La philosophie en deux phrases. Une suite collaborative éditée par un hébergeur suisse de 316 personnes, employee-owned, certifié ISO 27001 et 14001, qui opère ses propres datacenters à Genève et Winterthur. Pas un revendeur qui pose une UI sur des briques tierces, un éditeur vertical intégré.

Les forces.

Suisse, nFADP, hors CLOUD Act. Infomaniak est sous juridiction suisse, régie par la nouvelle Loi fédérale sur la protection des données (nFADP, en vigueur depuis le 01/09/2023). Pas de CLOUD Act applicable. La Suisse bénéficie d’une décision d’adéquation UE pour transferts RGPD. Pour un client UE ou simplement attaché à ce que ses données ne fassent pas escale juridique à Washington, ça se passe d’argument complémentaire.

OpenPGP intégré, gratuit, transparent dans kMail. Infomaniak a activé le chiffrement E2E par OpenPGP côté webmail kMail le 17 juin 2025, pour tous les plans, sans add-on. Tu actives, tu échanges des clés avec ton correspondant, tes mails sont chiffrés bout en bout. Côté suites grand public, seuls Proton et kSuite offrent OpenPGP gratuit dans le webmail. Google Workspace, Microsoft 365 et Zoho réservent leur chiffrement natif aux plans Enterprise.

OnlyOffice sous le capot des Docs, Grids, Points. Le moteur de bureautique de kSuite, c’est OnlyOffice, AGPLv3, open source. Compatibilité haute fidélité avec .docx, .xlsx, .pptx, mieux que Google Docs sur les fichiers Office natifs. Si ton comptable t’envoie un .xlsx avec des macros et une mise en page tordue, OnlyOffice le rend correctement.

Protocoles ouverts partout. IMAP, SMTP, CalDAV, CardDAV, WebDAV. Tu configures Apple Mail, Calendar, Contacts et Files.app sans installer un seul exécutable Infomaniak sur ton Mac. C’est rare, et c’est le critère d’intégration le plus pur qu’une suite cloud puisse cocher.

kMeet avec E2E optionnelle, gratuite. Visioconférence WebRTC avec une option de chiffrement bout en bout activable à la création de la réunion (clé partagée), documentée par Infomaniak. Limitée aux navigateurs Chromium et à l’app desktop, mais existante. Côté Workspace, l’équivalent (CSE) demande Enterprise Plus.

Pricing lisible et stable. kSuite Pro à 7,90 €/utilisateur/mois pour 3 To de stockage et le mail pro complet. Pas de hausse documentée depuis le lancement en 10/2022. La promesse tarifaire tient.

Les faiblesses.

MDM et Apple Business Manager : le trou dans la raquette. Pas d’intégration ABM officielle pour kSuite. Si tu déploies une flotte d’iPhone et de Mac d’entreprise avec federated authentication via Managed Apple ID, Workspace le fait nativement. Côté kSuite, tu passes par un MDM tiers (Jamf, Mosyle, Kandji) avec auth IMAP/CalDAV classique. Ça marche, c’est moins intégré.

Marketplace tiers limitée. Workspace Marketplace, c’est plus de 4 500 apps connectées. kSuite, c’est essentiellement la suite Infomaniak et quelques intégrations standards. Si ton workflow dépend de quinze SaaS qui se branchent sur Google Calendar, prévois une transition.

Apps mobiles : solides, pas références. Infomaniak Mail et kDrive iOS sont propres, mais Gmail et Google Drive iOS restent les références UX du marché. C’est un écart d’expérience, pas un blocage.

Coédition temps réel : bonne, pas excellente. OnlyOffice gère la coédition multi-utilisateurs, mais Google Docs reste la référence absolue sur la latence et l’undo collaboratif. Si tu fais de la rédaction simultanée à six dans le même document toute la journée, tu sentiras la différence. Sinon non.

Euria vs Gemini. Infomaniak a son IA souveraine (Euria) pour transcription kMeet et assistance. C’est honnête, ce n’est pas Gemini. Si l’IA bureautique poussée est ton critère principal, Workspace gagne ce point sans appel.

Pour qui. Le freelance, la PME, le family office, le cabinet libéral qui veut une suite pro complète sans CLOUD Act et sans installer une app propriétaire de plus sur son Mac. Le profil MacSouverain, en somme.

Prix HT (extraits, vraie page éditeur sur infomaniak.com/en/ksuite/ksuite-pro/prices).

my kSuite : gratuit, 20 Go, 1 adresse @ksuite.infomaniak.com, kMeet inclus. Pas de domaine perso.
my kSuite+ : CHF 5,75/mois, 2 To, 1 domaine + 5 alias.
kSuite Standard : 1,90 €/utilisateur/mois, 15 Go par user, mail pro avec domaine.
kSuite Pro : 7,90 €/utilisateur/mois, 3 To par user, mail pro + alias, SSO SAML.
kSuite Enterprise : 14,90 €/utilisateur/mois, 6 To par user, admin avancée.

Google Workspace, par Google LLC

La philosophie en deux phrases. La suite collaborative qui a redéfini le standard depuis 2006. Référence du marché sur Gmail, Docs, Sheets et Meet, intégrée avec à peu près tous les SaaS du monde, sous juridiction US et CLOUD Act.

Les forces.

Le mail anti-spam de référence. Gmail filtre mieux que tout le monde, point. Quinze ans de feedback machine learning sur des milliards de messages, ça se rattrape mal. Si tu changes de fournisseur mail, ton dossier spam va te manquer pendant deux mois.

Coédition Docs, Sheets, Slides. L’inventeur du genre est aussi le maître du genre. Latence, suggestions, mentions, historique granulaire : Workspace bureautique en ligne reste la référence, et toutes les autres suites se mesurent à elle.

Écosystème tiers gigantesque. Workspace Marketplace, 4 500+ apps. Ton CRM, ta facturation, ton outil RH, ton ATS : tous ont un connecteur Google natif. Pour kSuite, prévois des intégrations CalDAV/IMAP à la main quand l’app tierce le permet, ou rien quand elle ne le permet pas.

Apple Business Manager officiel. Federated authentication avec Managed Apple ID, DEP token, déploiement MDM Workspace Endpoint Management qui couvre macOS, iOS, ChromeOS, Android, Windows. Pour une PME qui gère une flotte hétérogène, c’est un argument opérationnel réel.

Gemini AI intégré dans tous les plans. Depuis le 17/03/2025, Google a bundle Gemini dans le tarif core de Workspace. NotebookLM, Gemini in Docs, Gemini in Sheets, transcription Meet : c’est puissant, et c’est dispo sans add-on supplémentaire.

Vault, eDiscovery, DLP, audit BigQuery. Si ton métier a des obligations de rétention légale, de legal hold, de Data Loss Prevention sérieuse, Workspace Plus et Enterprise sont matures sur ces sujets depuis dix ans. kSuite a des audit logs, pas la pile réglementaire complète.

Les faiblesses.

CLOUD Act, l’argument structurel. Google LLC est une entreprise US, soumise au CLOUD Act 2018, qui autorise les autorités américaines à exiger d’un fournisseur sous juridiction US la communication de données stockées n’importe où dans le monde. “Datacenter européen” ne change rien : Microsoft France l’a confirmé sous serment au Sénat, la juridiction prime sur la localisation. Workspace n’est pas qualifié SecNumCloud par l’ANSSI. Le partenariat Thales S3NS pour porter une qualif est en cours, Workspace lui-même ne la porte pas.

Hausse en 03/2025, bundle Gemini imposé. Google a augmenté le tarif core de tous les plans Workspace en intégrant Gemini dans le forfait : +16,7 % sur Business Starter et Standard (annuel), +22,2 % sur Business Plus. Tu n’as pas d’IA générative dans ton workflow ? Tu paies quand même. C’est la deuxième hausse globale après celle de 2023, le pricing Workspace est en hausse continue.

Chiffrement E2E réservé à Enterprise Plus. S/MIME hosted et CSE (Client-Side Encryption) sont disponibles uniquement en Enterprise Plus et Education Plus, avec un KMS externe à configurer (Thales, Fortanix, Stormshield, Flowcrypt). Sur Business Starter, Standard et Plus, tu as TLS in-transit et AES-256 at-rest avec clés Google. Ce n’est pas E2E.

Apps natives Apple : ça marche, sans plus. Apple Mail avec Google Account fonctionne, mais les labels Gmail deviennent des dossiers IMAP, l’expérience est dégradée. CardDAV est officiellement déprécié par Google au profit de People API (toujours fonctionnel via Google Account natif iOS, mais signal long terme). En pratique, l’utilisateur Workspace finit par ouvrir Gmail web et l’app Drive iOS : l’argument “100 % apps natives Apple” tombe.

Verrouillage Gmail. Les labels, les filtres, la catégorisation Gmail sont spécifiques. Google Takeout exporte tout (.mbox, EML), mais le reformatage côté nouveau fournisseur n’est pas trivial. Tu peux sortir, ce ne sera pas confortable.

Données clients vs entraînement IA. Google s’engage contractuellement à ne pas utiliser les données Workspace B2B pour entraîner Gemini. C’est un engagement contractuel, évolutif, distinct de l’engagement commercial Gmail grand public (qui lui, partage des signaux). À surveiller dans le temps.

Pour qui. L’entreprise dont les workflows critiques dépendent du Marketplace, le grand groupe avec besoins eDiscovery sérieux, le client US où la conformité locale impose les certifications Google, l’équipe déjà installée qui n’a aucun argument opérationnel pour bouger.

Prix HT (annuel, page éditeur workspace.google.com/pricing).

Business Starter : 6,80 €/user/mois (annuel), 30 Go par user, Meet 100 participants, max 300 users.
Business Standard : 13,60 €/user/mois, 2 To pooled, Meet 150 + enregistrement.
Business Plus : 21,10 €/user/mois, 5 To pooled, Vault eDiscovery, Meet 500.
Enterprise : sur devis, 5 To+, Meet 1 000, CSE, DLP avancé.

Promo de lancement 50 % les 3 premiers mois sur les 20 premiers utilisateurs, ensuite tarif standard.

Tête-à-tête sur les critères qui comptent

Plutôt qu’un tableau qui aplatit tout au même niveau, regardons les six critères l’un après l’autre.

Juridiction et souveraineté

kSuite est suisse, sous nFADP, hébergée en Suisse (datacenters Genève et région Zurich), hors CLOUD Act, hors RGPD (mais décision d’adéquation UE valide). Workspace est US, sous CLOUD Act, datacenters mondiaux avec option “data regions” Europe en plans Enterprise. Sur ce critère, ce n’est pas un comparatif, c’est une différence de nature. Si la juridiction est décisive pour toi, le sujet est déjà clos.

Chiffrement réel

kSuite : OpenPGP E2E natif et gratuit dans kMail, E2E optionnelle dans kMeet, AES-256 at-rest sur kDrive avec clés Infomaniak. Pas d’E2EE drive natif. Workspace : TLS et AES-256 at-rest partout, S/MIME hosted et CSE en Enterprise Plus uniquement, BYOK avec KMS externe en Enterprise Plus. Pour le mail, kSuite gagne nettement, et gratuitement. Pour le drive, les deux te demandent un compromis : Infomaniak garde les clés, ou tu paies Workspace Enterprise Plus pour avoir CSE.

Prix et lisibilité

À tier équivalent, kSuite est moins cher partout. Solo 2 To : my kSuite+ à 5,75 contre Business Starter à 6,80 € pour 30 Go (un facteur 70 sur le stockage). PME standard : kSuite Pro à 7,90 € contre Business Standard à 13,60 € (kSuite 42 % moins cher, 50 % de stockage en plus). PME premium : kSuite Enterprise 14,90 contre Business Plus 21,10 € (kSuite 29 % moins cher). Et le pricing Workspace monte, celui de kSuite ne bouge pas depuis 10/2022.

Intégration native macOS et iOS

kSuite expose IMAP, SMTP, CalDAV, CardDAV, WebDAV. Apple Mail, Calendar, Contacts, Files.app fonctionnent en natif sans une seule app propriétaire installée. C’est le scénario “100 % Apple” pur. Workspace fonctionne aussi nativement, mais l’expérience réelle pousse l’utilisateur vers Gmail web et Drive iOS. Sur le critère “ne rien installer de l’éditeur”, kSuite gagne sans bouger ; sur le critère “expérience polie”, Workspace garde la main avec ses propres apps.

Couverture fonctionnelle pro

Les deux suites couvrent mail, drive, agenda, contacts, visio, docs collaboratifs, console admin, SSO. Workspace ajoute MDM natif, ABM officiel, Marketplace 4 500 apps, DLP avancé, Vault eDiscovery. kSuite ajoute OnlyOffice haute fidélité, OpenPGP gratuit, kMeet E2E. Sur la couverture pure, Workspace a plus de profondeur ; sur la souveraineté fonctionnelle, kSuite a un cran d’avance.

Sortie possible

kSuite exporte EML, MBOX, vCard, iCal, fichiers natifs OnlyOffice. Workspace exporte via Takeout (mbox, vCard, ics, .docx via conversion). Les deux te laissent partir. kSuite te facilite l’arrivée : un import Workspace intégré est documenté dans la console Manager. L’inverse (sortir de Workspace vers autre chose) marche techniquement mais n’est pas guidé.

Recommandation Mack

Je vais le dire clairement parce que c’est mon job : si tu as le choix, kSuite est meilleur que Workspace pour ta Privacy.

Pas parce que Workspace est mauvais. Workspace est une excellente suite collaborative. Mais le profil MacSouverain n’est pas l’utilisateur médian de Workspace. Le lecteur de ce site, c’est un freelance, une PME européenne, un family office, un indépendant qui paie pour un service et qui veut savoir qui peut lire ses fichiers, qui peut forcer à les communiquer, et ce qui se passe le jour où un audit arrive. Sur ces trois questions, Workspace répond “Google, le CLOUD Act, on s’en occupe”, et kSuite répond “toi, personne, et un fichier d’export EML”, totale Privacy.

Si tu es freelance ou solo et que le budget compte. my kSuite+ à CHF 5,75/mois pour 2 To, c’est un choix évident face à Business Starter et ses 30 Go.

Si tu es PME 5-50 personnes en Europe. kSuite Pro à 7,90 €/user. Tu économises 42 % par rapport à Business Standard, tu gardes ton mail pro avec domaine, tu peux configurer Apple Mail et Calendar sur toute la flotte sans installer une app, et tu sors du CLOUD Act. La seule question à poser : ta flotte a-t-elle un besoin de MDM fédéré via ABM. Si oui, évalue sérieusement le coût d’un Mosyle ou d’un Jamf en complément.

Si tu es déjà sur Workspace avec tout ton workflow branché dessus. Une migration coûte. Tu n’as pas à la faire ce trimestre. Mais il y a deux moments où la repenser fait sens : à chaque hausse de prix Workspace (la prochaine arrivera), et au moment où un workflow critique casse à cause d’un changement Google. Ces deux moments arrivent, statistiquement.

Si tu es family office en Suisse, en Allemagne ou ailleurs en UE et que la juridiction US te dérange. Tu ne paies pas un cloud américain pour stocker ta correspondance pro et tes documents financiers, c’est aussi simple que ça. kSuite est la réponse la plus courte.

Pour mon usage perso, j’ai fait un autre choix, Proton Workspace, qui rend la même promesse de souveraineté sous un autre angle (E2E partout par défaut, écosystème Proton complet). Si tu hésites entre les deux mondes souverains, retiens la grille : kSuite a la longueur d’avance sur l’intégration Apple native pure (CalDAV, CardDAV, IMAP standards) et OnlyOffice haute fidélité ; Proton a l’avance sur le E2E systématique et l’app suite cohérente. Aucun des deux ne te ramène au CLOUD Act, c’est l’essentiel.

En résumé

kSuite est moins chère à tier équivalent, plus souveraine par construction (Suisse, nFADP, employee-owned, ISO 27001), expose des protocoles ouverts qui rendent les apps natives Apple pleinement utilisables, et inclut le chiffrement OpenPGP gratuit dans le mail. Workspace est plus polie sur Gmail, Docs et l’écosystème tiers, plus intégrée avec Apple Business Manager, et beaucoup plus mature sur les sujets Vault et DLP, au prix d’une juridiction US et d’une hausse continue.

Concrètement :

Freelance ou solo, budget compte → my kSuite+ à CHF 5,75/mois.
PME européenne 5-50 personnes → kSuite Pro à 7,90 €/user/mois, avec un MDM tiers si besoin fédéré.
Workflow Workspace critique déjà en place → reste, prépare la migration au prochain pricing update.
Conformité réglementaire US lourde → reste sur Workspace.
Family office UE, juridiction non négociable → kSuite, sans hésiter.

Transparence : MacSouverain est affilié à Infomaniak. Un abonnement kSuite via les liens de cet article soutient le site, sans rien changer au prix que tu paies. Si tu veux nous aider, c’est par là →

Sources

Les éditeurs eux-mêmes

Infomaniak, l’hébergeur suisse de Genève, employee-owned, qui édite kSuite depuis 10/2022. Page produit, prix et certifications ISO 27001 / 14001 / 50001 publics.
Google Workspace, Mountain View, sous juridiction US et CLOUD Act. Page pricing, security whitepaper, ISO 27001 publics.

La doc technique

Annonce OpenPGP gratuit dans kMail, reprise par Yahoo Finance le 17 juin 2025.
Apple Business Manager × Workspace, guide officiel Apple, fédération Managed Apple ID native côté Google, pas côté kSuite.

Les analyses indépendantes

Wire, CLOUD Act vs souveraineté UE, l’éditeur suisse de messagerie chiffrée explique pourquoi un datacenter européen ne suffit pas si l’entreprise est US.
9to5Google, hausse Workspace 03/2025, la presse tech qui a documenté le bundle Gemini imposé et la grille tarifaire actualisée.

Voir aussi

Souveraineté digitale, en pratique : la grille générale dont kSuite est un cas d’application.
Le cloud, c’est l’ordinateur de quelqu’un d’autre : le cadre mental qui sous-tend ce comparatif.
DNS, le talon d’Achille de ta privacy : même logique de juridiction sur une autre couche.

Mac Souverain

La fausse mise à jour Zoom qui vide ton trousseau iCloud

Ce qui se passe vraiment en pleine visio

Le troisième ClickFix sur macOS en six semaines

Ce que tu fais maintenant

Sources

Passwork, app mdp « Made in EU » dehors, certifiée FSB dedans

Introduction

Le problème : un drapeau ne prouve rien

Le mécanisme : les trois questions que le label ne pose pas

Qui pousse le binaire ?

Qui signe le code, et avec quelle clé ?

Quel État a pu revoir la source ?

L’usine à gaz qui n’a rien vu passer

Ce que ça change concrètement : ta grille de vérification

Les limites : ce que cette grille ne dit pas

En résumé

Sources

Alerting et coût total, le bilan de ton SIEM souverain

L’alerting, être prévenu sans être harcelé

Ce que la stack t’a vraiment coûté

Épisode par épisode, la même stack en SaaS

Les pièges, pour ne pas te raconter d’histoires

Conformité, la brique qui rend le délai tenable

En résumé, tu ne dépends de personne

Rappel de la série

Claude Cowork en local, l'agent sort du bac à sable

Ce que Cowork monte vraiment

La VM donne l’impression d’un mur

Ce que tu fais maintenant

Sources

Hugging Face compromis, et ton modèle local ?

Le fait

Ton modèle local, lui, n’a pas bougé

Le twist, l’attaquant n’était pas un pirate

La leçon en creux

Ce que tu fais maintenant

Sources

Santa sur tes Mac, le binaire non invité reste à la porte

Avant de commencer

Santa n’interdit rien, il n’autorise que

Étape 1, installer Santa et démarrer en Monitor

Étape 2, cartographier ton parc et écrire ton allowlist

Étape 3, verrouiller en Lockdown

Étape 4, faire remonter Santa dans Wazuh

Si ça ne marche pas

Problème, Santa est installé mais ne journalise rien

Problème, le mode reste sur Monitor malgré tout

Problème, tu as ajouté des règles mais santactl status affiche Static Rules: 0

Problème, rien ne remonte dans Wazuh

Ce que ça t’a coûté

Pour les pressés

En résumé

Rappel de la série

Les MCP, la porte dérobée de ton IA

Le confort qui te tend un piège

Un MCP, c’est quoi au juste

Pourquoi c’est une porte dérobée

L’incident qui a mis tout le monde d’accord

Durcir tes MCP sans renoncer au confort

En résumé

Rspamd devant ta boîte mail, le phishing s'arrête au paillasson

Avant de commencer

Rspamd ne dit pas oui ou non, il note

Étape 1, installer le moteur

Étape 2, le brancher devant ton serveur mail

Étape 3, régler les seuils et armer l’anti-hameçonnage

Étape 4, le mettre à l’épreuve

Étape 5, faire remonter Rspamd dans Wazuh

Si ça ne marche pas

Problème, Rspamd tourne mais aucun message n’est noté

Problème, des messages légitimes sont rejetés

Problème, le score n’apprend rien, le filtre bayésien reste muet

Problème, rien ne remonte dans Wazuh

Ce que ça t’a coûté

Pour les pressés

En résumé

Rappel de la série

Un malware notarisé Apple passe Gatekeeper

Le fait

Problème, tu as ajouté des règles mais `santactl status` affiche `Static Rules: 0`

Problème, `cscli metrics` affiche zéro ligne lue