Mac Souverain

Le traité ONU qui peut blanchir la preuve spyware

Mac Souverain — Mon, 17 Aug 2026 10:00:00 GMT

Le 16 juillet 2026, le Canada a signé la Convention ONU contre la cybercriminalité, le traité qu'il avait juré de combattre. Signature, pas encore ratification : rien n'est armé tant que 40 pays n'ont pas ratifié. Mais lis les petites lignes. Sous le vernis « anti-cybercrime » se cache une machine à faire circuler des preuves entre États qui, une fois ratifiée, n'interdit nulle part de **blanchir des données volées par spyware**. Ils appellent ça coopération. C'est, en réalité, de la **surveillance de masse** déguisée en lutte contre la criminalité, organisée entre états membres, de manière **administrative**, pour échapper à tout contrôle de justice.

Ce que tu surveilles, maintenant

1. La ratification, pas la signature. Ne te fais pas avoir par le communiqué : le seul chiffre qui arme ce traité, c'est 40. En dessous, c'est du théâtre. Au-dessus, c'est trop tard.

2. L'origine des preuves. Le texte se fiche de savoir si une preuve a été volée, rien n'interdit de la faire circuler. Si tes élus ne posent pas une réserve explicite en ratifiant, ils signent un blanc-seing pour une surveillance de masse administrative, même par des moyens illégaux.

3. La portée extraterritoriale. Journaliste, chercheur, lanceur d'alerte, diaspora : la cible, c'est toi, pas les cybercriminels. Un régime répressif à l'autre bout du monde pourra réclamer ton dossier, et un gag order t'interdira même de savoir qu'on te l'a pris.

Le fait

Le 16 juillet 2026, le Canada a signé la Convention des Nations Unies contre la cybercriminalité. Rien d’anodin. Le Canada avait combattu le lancement même de ces négociations, et il était absent de la cérémonie d’ouverture à Hanoï, en octobre 2025. Le revirement est complet, et il est passé quasiment inaperçu.

Petit rappel de calendrier, parce qu’il change tout. La Convention a été adoptée par l’Assemblée générale de l’ONU en décembre 2024, ouverte à la signature en octobre 2025, et le Canada vient d’y apposer son paraphe. Or signer n’est pas ratifier. Le texte compte aujourd’hui plus de 70 signataires, mais une poignée de ratifications seulement, et il n’entrera en vigueur que 90 jours après le 40e instrument de ratification déposé. Autrement dit, rien n’est encore opérationnel. Ce qui se joue, c’est la trajectoire.

Et elle mérite qu’on s’y arrête. Derrière le nom rassurant de « convention contre la cybercriminalité » se cache un accord de partage transfrontalier de preuves dont la portée dépasse très largement le piratage.

Pourquoi ça compte pour toi

Commençons par ce qui est écrit noir sur blanc. Les pouvoirs d’enquête du traité ne visent pas que les infractions « cyber » : ils couvrent la preuve électronique de n’importe quelle infraction. La coopération internationale, elle, s’étend à tout « serious crime », défini comme une infraction punie d’au moins quatre ans de prison en droit interne.

Traduction : un État répressif qui a criminalisé le journalisme, le militantisme ou l’homosexualité pourrait convertir ses propres lois en déclencheurs de collecte de preuves à l’autre bout du monde, une fois le traité en vigueur.

Vient ensuite l’angle qui fait mal. Selon l’analyse de Kate Robertson, du Citizen Lab, portant sur le projet de texte, les articles 46 à 48 organisent des canaux de partage qu’elle qualifie de « secretive », sans restriction sur l’origine territoriale des données et, surtout, sans aucune interdiction de partager des données obtenues par spyware.

L’article 40 impose l’entraide « la plus large possible », et les articles 47 et 48 autorisent une coopération policière directe et des enquêtes conjointes qui invitent au forum shopping, ce magasinage entre juridictions, vers les plus complaisantes avec le spyware.

Le point à bien tenir : rien dans le texte n’exige qu’une preuve ait été obtenue légalement pour circuler. C’est un fait établi, pas une supputation. Le risque, lui, est projeté mais argumenté : une fois ratifié, ce traité peut servir à faire entrer par la grande porte des données qu’un spyware a volées par la fenêtre. Robertson le dit sans détour, ce texte est « en passe de devenir un vecteur de complicité dans le commerce mondial de l’espionnage illégal ». Blanchiment n’est pas un gros mot ici, c’est la mécanique.

C’est exactement la logique de Chat Control / CSAR, dont on a suivi le trilogue final, vue sous un autre angle. L’UE veut forcer le scan de tes messages côté client, avant chiffrement. L’ONU, elle, ne touche pas à ta crypto : elle légalise la circulation des preuves une fois qu’elles existent, quelle qu’en soit la provenance. Deux bouts du même tuyau. Et ce traité n’est pas un cas isolé, c’est la 20e pièce de la convergence des textes mondiaux qu’on suit depuis des mois, après les 19 déjà recensés.

Le vrai piège n’est pas la compétence des tribunaux, c’est la portée extraterritoriale de la coopération. Robertson prévient que « la portée excessive du traité et sa compétence extraterritoriale vont accroître encore les risques pour les chercheurs en sécurité ». Michael Geist, lui, parle d’un traité de surveillance déguisé et cite une lettre de vingt organisations canadiennes alertant sur « un canal permanent de répression transnationale » visant les diasporas. Et plus de 120 experts en sécurité redoutent de voir la recherche de bonne foi criminalisée.

Soyons complets : le traité a ses défenseurs, INTERPOL a salué son adoption, et l’idée de coopérer contre la vraie cybercriminalité n’est pas illégitime. Le problème, c’est l’absence quasi totale de garde-fous. Pas de contrôle judiciaire indépendant obligatoire, autorisation laissée au droit interne, gag orders autorisés (ces injonctions de silence qui interdisent de révéler qu’une demande a même eu lieu), aucune exception d’infraction politique, aucun mécanisme pour suspendre un État qui piétine les droits humains. Les protections restent largement facultatives.

Ce que tu fais maintenant

Rien à installer, rien à corriger : le traité n’est pas en vigueur, et ce n’est pas une faille produit. C’est une trajectoire réglementaire, et une trajectoire, ça se surveille. Si tu es journaliste, chercheur en sécurité, lanceur d’alerte ou membre d’une diaspora exposée, c’est toi que la portée extraterritoriale vise en premier.

1. Surveille la ratification, pas la signature. Le compteur qui compte, c’est celui des 40 ratifications : tant qu’il n’est pas atteint, le texte n’a aucun effet.

2. Exige de tes élus une réserve explicite sur l’origine des preuves. Un traité se ratifie avec des garanties nationales : c’est là, dans les lois de mise en œuvre, que se gagne ou se perd le vrai combat.

3. Chiffre par défaut et cloisonne. Ce que Signal, Proton et une bonne hygiène de données ne produisent pas, personne ne pourra le partager. Le meilleur rempart contre un canal de preuves, c’est encore de ne pas générer la preuve.

La bonne nouvelle, c’est qu’un texte pas encore ratifié reste un texte qu’on peut border. La mauvaise, c’est que presque personne ne regarde. Fais partie des rares qui regardent.

Sources

Citizen Lab (citizenlab.ca), le laboratoire de la Munk School à Toronto : Kate Robertson y décortique les risques de la signature canadienne (source primaire).
Kate Robertson, Lawfare, l’analyse de fond article par article du projet de convention.
Michael Geist (michaelgeist.ca), juriste canadien de référence sur le numérique, pour l’angle Canada et la lettre des vingt organisations.
EFF (eff.org), déclaration conjointe de Hanoï sur le partage de preuves et l’absence de mécanisme de suspension.
Gouvernement du Canada (canada.ca), le communiqué officiel de la signature du 16 juillet 2026.
ONUDC (unodc.org), le texte de la Convention et l’état des signatures et ratifications.

Apple Private Relay ne te protège de rien

Mac Souverain — Thu, 13 Aug 2026 14:22:09 GMT

Private Relay n'est pas un VPN. Une large part des abonnés iCloud+ l'active en croyant masquer tout leur trafic, il ne couvre que Safari, et trois fuites WebKit laissent sortir ton IP ou ton DNS. Un cabinet US attaque Apple pour fraude, sans correctif de la marque annoncé.

Ce que tu dois surveiller

1. Passkey, préchargement DNS et WebTransport (introduit avec iOS 26) contournent le relais, côté moteur de Safari.

2. Ce sont des allégations judiciaires plus une recherche de sécurité, pas une exploitation documentée dans la nature.

3. Apple enquête sans calendrier, aucune fuite bouchée tant que ce n'est pas vérifié publiquement.

4. Installe un DNS souverain et chiffré, DNS4EU ou Quad9 en DoH ou DoT. Ça referme la fuite DNS que Private Relay laisse passer, et la protection vaut bien au-delà de Safari.

Le fait

Le cabinet américain Clarkson Law Firm vient de déposer une action collective contre Apple. L’accusation est frontale, fraude et publicité mensongère sur iCloud Private Relay, la fonction incluse dans iCloud+ qu’Apple présente comme un bouclier pour ta navigation. Le même cabinet a arraché à Apple un règlement de 250 millions de dollars en décembre 2025 sur le dossier Siri. Ce n’est pas un plaideur du dimanche.

Le socle technique de la plainte vient d’ailleurs. Deux chercheurs, Tommy Mysk et Talal Haj Bakry, ont documenté trois mécanismes par lesquels ton adresse IP réelle ou tes serveurs DNS peuvent fuir alors même que Private Relay est actif. Proton a relayé leurs travaux le 5 août.

Les trois fuites sont toutes côté WebKit, le moteur de Safari. Un, les connexions par passkey contournent entièrement les serveurs relais. Deux, le préchargement DNS révèle tes serveurs DNS réels. Trois, le protocole WebTransport, une brique ajoutée à WebKit avec iOS 26 (la version stable en cours), expose ton adresse IP réelle dans certaines conditions.

Deux choses à garder froides. Une plainte, ce sont des allégations, pas un jugement. Et à ce stade Apple dit enquêter sans annoncer ni correctif ni calendrier, aucune exploitation dans la nature n’est documentée. Le problème n’est pas qu’on vole tes données ce matin, c’est l’écart entre ce que la fonction laisse croire et ce qu’elle tient vraiment.

Pourquoi ça compte pour toi

Private Relay n’est pas un VPN. C’est la phrase à retenir. Une large part des abonnés iCloud+ l’active en pensant allumer un tunnel qui masque tout leur trafic. Faux. Private Relay ne couvre que Safari et une fraction du trafic système, ton adresse passe par un double saut, un serveur Apple puis un partenaire, pour que personne ne voie à la fois qui tu es et où tu vas. Élégant sur le papier. Sauf que les trois fuites cassent ce contrat à l’intérieur même de son périmètre, sur la partie qu’il est censé protéger, ton IP ou ton DNS peuvent sortir en clair.

Concret. Une connexion par passkey, et le relais est court-circuité. Un préchargement DNS déclenché par une page, et tes serveurs DNS réels apparaissent. WebTransport, arrivé avec iOS 26, et ton adresse IP réelle se montre. Tu n’as rien fait de spécial, la fuite vient du moteur, pas de toi. Ces mécanismes sont nommés et testables, ce n’est pas de la théorie de comptoir.

Nuance, parce que Mac Souverain ne fait pas dans l’alarme facile. Ton compte n’est pas piraté, tes pages ne sont pas lues, il n’y a pas de fuite massive. Ce qui tombe, c’est l’anonymat de ton IP sur la navigation, précisément ce pour quoi tu croyais activer la fonction.

Techniquement, Private Relay n’a jamais promis d’être un VPN. C’est le marketing tout en douceur qui laisse le doute s’installer, et une large part des utilisateurs prend le relais pour un tunnel. C’est le même schéma que l’alias Apple qui laisse remonter à ta vraie adresse, une fonction privacy vendue comme une protection, une faille qui la vide de sa promesse.

Ce que tu fais maintenant

1. Arrête de traiter Private Relay comme un VPN. C’est un relais à double saut pour Safari, pas un tunnel système. Garde-le si tu veux, mais ne lui confie pas ce qu’il ne protège pas.

2. Pour masquer vraiment ton IP sur tout ton trafic, prends un vrai VPN sans-log en juridiction saine, Proton VPN ou Mullvad, doublé d’un DNS souverain. Là tu tiens un tunnel, pas un demi-relais.

À lire : Le DNS, talon d’Achille de ta souveraineté numérique

3. Teste toi-même. Private Relay actif, va sur dnsleaktest.com ou dnscheck.tools et regarde ce qui sort. Le meilleur antidote au marketing, c’est ta propre vérification.

4. Surveille la suite. Apple enquête sans calendrier, ne considère aucune fuite bouchée tant que ce n’est pas vérifié publiquement, pas sur la foi d’une note de version.

Sources

https://www.macrumors.com/2026/08/11/icloud-private-relay-class-action-lawsuit/
https://9to5mac.com/2026/08/11/apple-faces-class-action-lawsuit-for-fraud-over-icloud-private-relay-flaw/
Recherche primaire Tommy Mysk et Talal Haj Bakry, 4 août 2026 : https://mysk.blog/2026/08/04/webkit-proxy-icloud-private-relay-ip-leak/
Relais Proton, blog du 5 août 2026 : https://proton.me/blog/icloud-private-relay-ip-leak

Wazuh, écris la règle qui capte ce que tu cherches vraiment

Mac Souverain — Thu, 13 Aug 2026 10:00:00 GMT

À l’épisode précédent, tu as appris à lire ton SIEM. Tu as ouvert l’audit de configuration, restreint la surveillance de fichiers à ce qui compte, trié tes vulnérabilités par sévérité. Trois usages, trois questions, des réponses nettes. Sauf que toutes ces alertes, tu ne les as pas écrites. Elles sortaient du jeu de règles fourni par Wazuh, des milliers de règles pensées par d’autres, pour des cas génériques.

Aujourd’hui, tu passes de l’autre côté. Tu écris ta première règle.

Et je vais te dire tout de suite ce qui distingue une bonne règle custom d’une mauvaise, parce que c’est tout le sujet. Une mauvaise règle part d’un fantasme, tout couvrir, ne rien rater, verrouiller l’univers. Une bonne règle part d’un log réel que tu as sous les yeux et d’une question précise que tu lui poses. Une seule question. C’est exactement le fil rouge de la série, du plus calme au plus bavard, sauf qu’ici tu tiens le stylo.

Ce tuto vise la branche 4.x de Wazuh, la même que toute la série, version de référence 4.14.7. Prévois une petite heure, un log sous les yeux, et l’envie de résister à la tentation d’en faire trop.

Ce qu’il te faut

Rien de neuf à installer. Tout est hérité de la série.

Ton manager Wazuh 4.x opérationnel, celui du tout-en-un.
Au moins un agent en état Active qui remonte des logs.
Un accès shell au manager, parce que les règles vivent dans des fichiers, pas dans un formulaire.
Un vrai log qui t’intéresse. Pas un exemple de doc, un log de chez toi, celui pour lequel tu te dis « ça, je voudrais le savoir quand ça arrive ».

Ce dernier point n’est pas décoratif. Écrire une règle sans log réel devant soi, c’est deviner. Et une règle qui devine, elle se trompe.

Anatomie d’une règle, décodage, champ, niveau

Avant d’écrire, il faut comprendre le chemin que parcourt un log. Trois étapes, toujours les mêmes.

Un log arrive. Wazuh le pré-décode, il en extrait le squelette commun à tout message système, l’horodatage, le nom de la machine, le nom du programme. Puis un décodeur entre en scène et découpe le reste en champs nommés, un utilisateur, une adresse source, une action. Enfin, le log passe devant le mur des règles. La première règle dont toutes les conditions sont vraies gagne, et elle génère une alerte au niveau qu’elle porte.

Retiens cette distinction, c’est le cœur de tout ce qui suit. Une règle peut chercher de deux façons.

Avec <match> ou <regex>, elle fouille le texte brut du log, la ligne entière, telle quelle.
Avec <field>, elle interroge un champ déjà extrait par un décodeur, proprement isolé.

La première méthode, c’est le filet à grosses mailles. La seconde, c’est la pince à épiler. Une règle précise, celle qui pose une vraie question, s’accroche presque toujours à un décodeur et compare un champ nommé. On y revient.

Côté écriture, une règle est un bloc XML. Ses attributs principaux, tu n’en utiliseras que deux au début.

id, l’identifiant numérique unique de la règle.
level, sa sévérité, sur une échelle dont on parle plus bas.

Et ses balises enfant utiles pour commencer.

<if_sid>, le chaînage, « ne me déclenche que si telle autre règle a déjà matché ». La clé de la précision.
<field name="...">, la comparaison sur un champ décodé.
<match>, la recherche dans le texte brut.
<description>, la phrase qui s’affichera dans l’alerte. Écris-la pour toi dans six mois, pas pour la machine.

D’autres balises existent, frequency et timeframe pour compter les répétitions dans une fenêtre de temps, pcre2 pour les motifs costauds, decoded_as, tu les découvriras quand une question précise les réclamera. Pas avant. Garde la référence des options de règle ouverte le jour où tu écris, c’est la page qui liste tout, balise par balise.

Où vivent tes règles, et l’erreur qui te les efface

Deux fichiers, deux règles d’or.

Tes règles custom vont dans /var/ossec/etc/rules/local_rules.xml. Tes décodeurs custom, quand tu en auras besoin, dans /var/ossec/etc/decoders/local_decoder.xml.

Ce que tu ne touches jamais, c’est le répertoire /var/ossec/ruleset/. C’est le jeu de règles fourni par Wazuh, et il est réécrit intégralement à chaque mise à jour. Une personnalisation posée là-dedans disparaît à la première montée de version, sans un mot d’adieu. Tout ce qui t’appartient reste dans etc/.

Deuxième règle, les identifiants. Réserve à tes règles la plage 100000 à 120000. Le moteur accepte techniquement n’importe quel numéro jusqu’à 999999, mais rester au-dessus de 100000 t’évite d’entrer en collision avec les règles système. La borne haute, 120000, est une recommandation confortable, pas un mur.

Et si tu veux modifier une règle fournie plutôt qu’en créer une ? Tu la recopies dans ton fichier local avec l’attribut overwrite="yes", en gardant son identifiant. Attention, certaines balises structurelles comme if_sid ou if_group ne se laissent pas réécrire ainsi, dans ce cas tu crées une nouvelle règle qui s’appuie sur l’existante.

La méthode, du log réel à la règle testée

Voici la boucle. Tu vas la répéter à chaque règle que tu implémenteras, alors autant la créer proprement dès la première.

Tu attrapes le log brut. La ligne exacte, copiée telle qu’elle apparaît, sans la reformuler.
Tu regardes comment Wazuh la comprend déjà. Quels champs un décodeur en tire, quelle règle système la ramasse peut-être au passage.
Tu écris ta règle dans local_rules.xml, en t’accrochant à ce qui existe.
Tu la testes à froid, avant même de recharger le service, avec wazuh-logtest.
Tu recharges le manager seulement quand le test est vert.

L’outil qui rend tout ça possible, c’est wazuh-logtest, à /var/ossec/bin/wazuh-logtest. Un mot pour les vétérans, si tu as croisé de vieux tutos parlant d’ossec-logtest, c’est le même outil, rebaptisé lors du passage d’OSSEC à Wazuh en version 4.0. Le nom d’aujourd’hui, c’est wazuh-logtest, l’ancien ne répondra plus.

Tu le lances, il t’invite à coller une ligne de log, et il rejoue sous tes yeux les trois phases dont on parlait, pré-décodage, décodage, matching. Le décodage est ton point de contrôle, c’est là que tu vérifies qu’un champ que tu veux interroger existe bien. Le matching t’annonce la règle qui l’emporte, son identifiant, son niveau, sa description.

Cette console, c’est ton banc d’essai. Tu peux y coller un log, voir qu’aucune règle ne le ramasse, écrire ta règle, recoller le log, et regarder la phase 3 changer. Sans jamais toucher à la production.

Un exemple de bout en bout

Assez de théorie. Prenons une vraie question, la plus banale qui soit, et déroulons-la jusqu’au bout.

La question. « Je veux savoir quand quelqu’un rate l’authentification sur mon coffre Vaultwarden, et de quelle adresse il s’y essaie. » Une question, un service, un événement. Quelqu’un qui tape à côté du mot de passe de ton gestionnaire de mots de passe, c’est exactement le genre de bruit que tu veux entendre.

Le log sous les yeux. À chaque échec, Vaultwarden écrit cette ligne.

[2026-08-13 09:42:11.523][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.42. Username: victime@example.com.

Regarde le format, ce n’est pas du syslog classique, pas de machine programme[pid]. Vaultwarden préfixe chaque ligne de [horodatage][module][niveau]. Retiens-le, ça va compter pour le décodeur.

Le premier réflexe, la grosse maille. Tu pourrais écrire une règle qui fouille le texte brut.

<group name="vaultwarden,">
  <rule id="100010" level="5">
    <match>Username or password is incorrect. Try again</match>
    <description>Vaultwarden, échec d'authentification</description>
  </rule>
</group>

Ça marche, ça sonne à chaque échec. Mais tu n’as qu’un fait nu, « quelqu’un s’est planté ». L’adresse et le compte visé sont là, dans la ligne, sauf que Wazuh ne les voit pas comme des champs. Impossible de compter les tentatives par adresse, de géolocaliser, de repérer l’acharné qui revient toutes les dix secondes. Tu as ouvert un robinet, pas posé une question.

La bonne maille, la pince à épiler. On repart de zéro. Pour interroger l’adresse et le compte, il te faut ces champs décodés. Or Vaultwarden ne fait pas partie des formats que Wazuh connaît d’origine, tu vas devoir le lui apprendre, la section suivante détaille le décodeur. Admettons qu’il extraie déjà srcip et srcuser. Ta règle devient alors chirurgicale.

<group name="vaultwarden,">
  <rule id="100010" level="0">
    <decoded_as>vaultwarden</decoded_as>
    <description>Vaultwarden, ligne reconnue, socle de détection</description>
  </rule>

  <rule id="100011" level="10">
    <if_sid>100010</if_sid>
    <match>Username or password is incorrect</match>
    <description>Vaultwarden, échec d'authentification de $(srcuser) depuis $(srcip)</description>
  </rule>
</group>

Regarde ce qui se joue là. La règle 100010 est en level="0", elle ne sonne pas, elle sert juste de socle, elle dit « cette ligne vient de Vaultwarden ». La règle 100011 s’y accroche via <if_sid>, ne se déclenche que sur l’échec d’authentification, et rappelle dans sa description le compte visé et l’adresse d’où vient la tentative.

Une question posée, une réponse donnée, et un silence total sur tout le reste. Et si demain tu ne veux d’alerte que pour un compte précis, tu remplaces ce <match> par un <field name="srcuser">toncompte@exemple.tld</field>, la pince se resserre encore. Le jour où tu voudras hurler quand la même adresse se plante dix fois en une minute, tu ajouteras frequency et timeframe par-dessus, mais ça, c’est une autre règle pour un autre jour.

Le test, avant de déployer quoi que ce soit.

/var/ossec/bin/wazuh-logtest

Colle ta ligne de log. En phase 3, tu dois voir sonner la règle 100011, au niveau 10, avec ta description remplie : Vaultwarden, échec d’authentification de victime@example.com depuis 203.0.113.42. L’adresse est là, récupérée, prête à géolocaliser ou à corréler. Si tu veux valider en une commande, sans lire la sortie, l’option -U compare le résultat à un triplet attendu, identifiant, niveau, décodeur, et te rend un code de sortie propre.

/var/ossec/bin/wazuh-logtest -U 100011:10:vaultwarden

Puis tu recharges.

sudo systemctl restart wazuh-manager

Un redémarrage coupe brièvement la réception des logs, le temps que le service revienne. Sur un manager de PME, c’est indolore.

L’exemple 100010/100011 illustre la syntaxe exacte du chaînage if_sid, avec les champs décodés réinjectés dans la description. Avant de compter sur l’alerte en prod, colle-le dans wazuh-logtest et vérifie que les substitutions $(srcip) et $(srcuser) s’affichent bien. Trente secondes, et pas de coquille découverte le jour où l’alerte compte vraiment.

Quand il faut un décodeur, et quand il n’en faut surtout pas

C’est le piège du débutant zélé, écrire un décodeur pour tout. Ne le fais pas.

Le principe est simple. Si un décodeur existant sort déjà le champ qui t’intéresse, tu n’écris aucun décodeur. Tu écris directement une règle qui s’accroche à la règle existante et compare le champ. La plupart des formats standards, ceux de SSH, des services système, des serveurs connus, sont déjà décodés par Wazuh. Vérifie-le d’abord dans la phase 2 de wazuh-logtest, si ton champ apparaît, le travail est fait.

Tu n’écris un décodeur que dans un cas précis, quand Wazuh ne comprend pas le format d’un log maison ou exotique. La phase 2 du test reste vide, ou ne sort pas le champ que tu cherches ? Alors, et seulement alors, tu apprends à Wazuh à lire ce format.

Un décodeur custom, ça vit dans /var/ossec/etc/decoders/local_decoder.xml, et ça se compose de deux blocs, un parent qui reconnaît l’application, un enfant qui extrait les champs. Pour notre Vaultwarden, ça donne :

<decoder name="vaultwarden">
  <prematch>][vaultwarden::</prematch>
</decoder>

<decoder name="vaultwarden">
  <parent>vaultwarden</parent>
  <regex>IP: (\d+.\d+.\d+.\d+). Username: (\S+).</regex>
  <order>srcip, srcuser</order>
</decoder>

Le parent reconnaît la ligne à une sous-chaîne stable, ][vaultwarden::, le nom du module que Vaultwarden colle dans chacune de ses lignes. Pourquoi pas un <program_name> comme d’habitude ? Parce que Vaultwarden n’écrit pas en syslog, il n’y a pas de champ programme à accrocher. Si tu fais passer tes logs par journald ou syslog en amont, alors le préfixe standard réapparaît et tu peux revenir au <program_name>vaultwarden</program_name> classique.

En lecture directe du fichier ou de la sortie Docker, le <prematch> sur le module est ta prise la plus solide. L’enfant, lui, capture l’adresse puis le compte, dans cet ordre, et les nomme srcip et srcuser, exactement les champs que ta règle 100011 attend. Le nom srcip n’est pas un caprice, c’est celui que Wazuh sait géolocaliser et corréler. La boucle est bouclée.

Un avertissement sur les expressions régulières, parce que c’est là qu’on perd des heures. La syntaxe des motifs Wazuh n’est pas tout à fait la regex classique à laquelle tu penses, le moteur par défaut (OS_Regex) a ses propres conventions. Teste chaque décodeur dans wazuh-logtest avant de t’y fier, et considère l’exemple ci-dessus comme un patron à valider sur ton format réel, pas comme du copier-coller garanti.

Le vrai danger, ce n’est pas la syntaxe, c’est le nombre

Tu sais maintenant écrire une règle. La partie technique est derrière toi. Reste la partie qui tue les SIEM, la retenue.

Chaque règle que tu ajoutes est une bouche de plus qui parlera. Le réflexe, une fois qu’on sait écrire, c’est d’écrire trop, une règle pour ci, une pour ça, au cas où. Trois semaines plus tard, ton flux ressemble au mur indistinct dont l’épisode 1 t’avait sorti, sauf que cette fois, c’est toi qui l’as bâti.

D’où la seule règle d’hygiène qui compte, la même qu’au premier épisode.

Ne crée jamais une règle dont tu ne sais pas quoi faire quand elle sonnera. Si ta seule réaction possible à l’alerte est de hausser les épaules, cette règle n’a pas de raison d’exister.

Le level est ton outil de dosage, il va de 0 à 15, le 16 existe mais reste non documenté. Sers-t’en sérieusement.

Le 0 est silencieux. Il décode et observe sans jamais réveiller personne. C’est le niveau des règles socles, comme la 100010 de l’exemple. Parfaitement légitime, et sous-utilisé.
Les niveaux bas, de 2 à 7, sont le bruit de fond, erreurs mineures, tentatives sans gravité.
Le milieu, de 8 à 11, mérite un œil.
Le haut, de 12 à 14, ce sont les événements de sécurité importants.
Le 15 est l’attaque sévère, celle qui appelle une réaction immédiate, sans faux positif attendu.

N’invente pas de signification pour le 16, non documenté. Et surtout, ne colle pas un niveau élevé à une règle par excès de zèle. Un level haut n’a de sens que si une action concrète est prévue quand il tombe. Sinon, tu fabriques de l’angoisse, pas de la sécurité.

Si ça ne marche pas

Problème, ta règle ne se déclenche jamais dans le test

Cause probable, le champ que tu interroges n’est pas décodé, ou la règle parente référencée dans <if_sid> ne matche pas ce log.

Solution, relance wazuh-logtest avec l’option verbeuse -v et lis la phase 2. Si ton champ n’y apparaît pas, aucun décodeur ne le produit, il te faut donc en écrire un avant d’écrire ta règle. Vérifie aussi que l’identifiant dans <if_sid> correspond bien à une règle qui, elle, ramasse le log.

Problème, wazuh-logtest voit ta règle mais le manager l’ignore en production

Cause probable, le service n’a pas été rechargé depuis que tu as modifié le fichier.

Solution, sudo systemctl restart wazuh-manager. L’outil de test lit tes fichiers directement, le moteur de production, lui, travaille sur le jeu de règles chargé en mémoire. Tant que tu ne recharges pas, il ne connaît pas ta nouvelle règle.

Problème, ta règle a disparu après une mise à jour de Wazuh

Cause probable, tu l’avais écrite dans /var/ossec/ruleset/ au lieu de /var/ossec/etc/rules/.

Solution, réécris-la dans local_rules.xml et ne remets plus jamais les pieds dans ruleset/. Ce répertoire est terrain de Wazuh, réécrit à chaque montée de version.

Pour les pressés

Ce que fait cet article. Il t’apprend à écrire ta première règle de détection Wazuh, en partant d’un log réel et d’une question précise, à la tester hors production, puis à la déployer sans casser quoi que ce soit.

Concrètement, la marche à suivre.

Attrape le log brut qui t’intéresse et lance /var/ossec/bin/wazuh-logtest pour voir quels champs Wazuh en extrait déjà.
Écris ta règle dans /var/ossec/etc/rules/local_rules.xml, identifiant entre 100000 et 120000, jamais dans ruleset/.
Privilégie la précision, accroche-toi à une règle existante avec <if_sid> et compare un champ décodé avec <field>, plutôt que de fouiller le texte brut avec <match>.
Si le champ voulu n’est pas décodé, et seulement dans ce cas, écris un décodeur dans /var/ossec/etc/decoders/local_decoder.xml.
Teste dans wazuh-logtest jusqu’au vert, au besoin avec -U identifiant:niveau:decodeur pour une validation en une commande.
Recharge, sudo systemctl restart wazuh-manager.
Règle d’or, n’écris aucune règle dont tu ne sais pas quoi faire quand elle sonnera. Le level 0 pour observer sans alerter est ton ami.

En résumé

Tu es passé de lecteur à auteur. Tu ne subis plus les règles écrites par d’autres, tu poses tes propres questions à tes propres logs.

Et la leçon n’est pas dans la syntaxe XML, que tu maîtriseras en trois règles. Elle est dans la retenue. Une bonne règle vise un log précis, chaîne sur ce qui existe déjà, et se tait sur le reste. Le décodeur, tu ne l’écris que forcé. Le niveau d’alerte, tu le dis honnêtement. Et chaque règle que tu ajoutes, tu la mérites par une action que tu es prêt à mener quand elle sonnera.

Choisis peu de questions. Réponds-y vraiment. C’est valable pour lire, c’est valable pour écrire.

Pour creuser, la doc officielle

Toute la syntaxe que tu viens de manipuler est documentée, page par page. Garde ces liens sous la main, ce sont tes sources.

Référence des options de règle : id, level, if_sid, field, match, regex, et les options avancées frequency et timeframe.
Règles custom et overwrite, où et comment écrire dans local_rules.xml.
Syntaxe des décodeurs : prematch, parent, regex, order, et les décodeurs custom.
Expressions régulières Wazuh, pour ne pas confondre OS_Regex et PCRE2.
Classification des niveaux, de 0 à 15.
wazuh-logtest, l’outil de test, options -v et -U.

Et après, montre à ton SIEM ce que tu bloques

Tu sais lire ton SIEM, tu sais maintenant lui apprendre de nouvelles questions. Le prochain cran, c’est de lui donner à voir un signal qu’il ne capte pas encore, ce que tes Mac laissent tourner, et surtout ce qu’ils refusent.

Au prochain épisode, on branche le contrôle d’exécution de tes Mac sur Wazuh, pour que chaque blocage devienne une alerte lisible dans le même tableau de bord que le reste. Le geste d’écriture que tu viens d’apprendre y sera ton outil de base.

À lire bientôt : Brancher Santa sur Wazuh, corréler ce qui s’exécute et ce qu’on bloque

Et pour l’épisode qui précède, celui où l’on apprend à lire avant d’écrire.

À lire : Ton SIEM souverain, lis-le vraiment puis fais-le passer à l’action

Des termes techniques ? Consulte le glossaire.

Londres réclame tes sauvegardes iCloud chiffrées

Mac Souverain — Thu, 06 Aug 2026 10:00:00 GMT

Apple attaque devant l'IPT une nouvelle injonction britannique qui réclame l'accès à tes sauvegardes iCloud chiffrées. Elle est réduite aux seuls utilisateurs du Royaume-Uni, retirée en 2025 quand elle visait aussi les Américains. Le hic : si on peut techniquement ouvrir les sauvegardes d'un pays, on peut le refaire partout. Le précédent pèse plus lourd que le périmètre.

Ce que ça change pour toi

1. Sans Protection Avancée des Données, ta sauvegarde iCloud est chiffrée mais avec une clé qu'Apple détient, donc accessible à Apple et mobilisable sur injonction.

2. Avec ADP activé, tes sauvegardes passent en chiffrement de bout en bout, Apple n'a plus rien à remettre. Vérifie ton statut.

3. L'option ne couvre pas iCloud Mail, Contacts ni Calendrier. Pour l'email chiffré, c'est Proton Mail ou Tuta.

Le fait

En juillet 2026, Apple a déposé une plainte devant l’Investigatory Powers Tribunal britannique. La cible : une nouvelle injonction du gouvernement, une Technical Capability Notice, qui exige un accès aux sauvegardes iCloud chiffrées des utilisateurs du Royaume-Uni.

Tout ce que tu viens de lire, tu le sais « selon la presse » et pas autrement, parce que l’Investigatory Powers Act interdit à Apple comme au Home Office de confirmer qu’une telle injonction existe. L’information vient du Financial Times, reprise ensuite par TechCrunch, 9to5Mac, AppleInsider, Euronews et MacRumors.

Ce n’est pas la première manche. En janvier 2025, une première injonction visait déjà les sauvegardes iCloud, mais elle couvrait les clients britanniques et américains. Washington a grincé des dents, la pression diplomatique est montée, et elle a été retirée en août 2025. Le Home Office est revenu à la charge avec une version révisée, cette fois limitée aux seuls utilisateurs du Royaume-Uni. Même loi, même mécanique, carte plus petite.

Le secret est tel qu’aucune audience au fond n’est publiquement calendée pour l’affaire Apple elle-même. Le seul repère fiable, c’est une procédure distincte : Privacy International et Liberty contestent ce régime d’injonctions, et leur dossier sera entendu en décembre 2026. La position d’Apple, elle, n’a pas bougé d’un pouce : refus de construire le moindre accès imposé, avec un argument constant, une fois l’outil fabriqué, il met en danger tous les utilisateurs, pas seulement ceux qu’on visait au départ.

Pourquoi ça compte pour toi

Le réflexe, en lisant « limitée au Royaume-Uni », c’est de souffler. Mauvais réflexe. Un accès qui rétrécit géographiquement n’est pas une reculade, c’est un test de faisabilité réussi. Si Apple peut isoler techniquement les sauvegardes d’un seul pays pour les rendre lisibles sur demande, la même manette fonctionne pour n’importe quel pays qui saura la réclamer. Le périmètre change. Le précédent, lui, ne connaît pas de frontière.

Note aussi par où passe l’attaque. Pas par un texte européen débattu au grand jour, pas par un vote qu’on peut suivre et contester. Par une injonction nationale, secrète, qu’aucun des deux camps n’a le droit de commenter. C’est une autre porte pour entrer dans la même pièce.

À lire : Chat Control, la surveillance de masse qui avance en Europe

Reste la vraie question, celle qui décide si ça te concerne : qu’est-ce qu’une injonction pareille peut techniquement atteindre ? Une sauvegarde iCloud standard est chiffrée en transit et au repos, mais avec une clé qu’Apple détient. Traduction, Apple peut y accéder, donc Apple peut y être contrainte. La Protection Avancée des Données bascule au contraire tes sauvegardes en chiffrement de bout en bout, sans clé côté Apple. Ce qu’Apple ne détient pas, Apple ne peut pas le remettre.

Et une sauvegarde iCloud n’est pas un détail : elle embarque une copie de presque tout, messages, photos, données d’apps, et sans Protection Avancée, de quoi déchiffrer tes iMessages. Une conversation soi-disant chiffrée de bout en bout redevient donc lisible par la sauvegarde tant que l’option n’est pas activée.

Aucune source publique ne dit si l’injonction révisée vise explicitement la Protection Avancée des Données. Ne laisse personne te l’affirmer, c’est du vent. Ce qu’on peut cadrer, c’est la mécanique : sans cette option, ta sauvegarde vit derrière une serrure dont Apple garde le double de clé. Avec ADP, le double n’existe pas.

À lire : Le cloud, c’est l’ordinateur de quelqu’un d’autre

Un dernier point, pour éviter le faux sentiment de blindage. Même avec la Protection Avancée activée, iCloud Mail, Contacts et Calendrier restent hors chiffrement de bout en bout, pour des raisons d’interopérabilité IMAP, CalDAV et CardDAV. L’option protège tes sauvegardes, pas ta boîte mail. Pour un email vraiment chiffré, c’est ailleurs que ça se joue.

Ce que tu fais maintenant

1. Vérifie ton statut Protection Avancée des Données : Réglages → ton nom → iCloud → Protection avancée des données. Sans elle, ta sauvegarde iCloud est chiffrée avec une clé qu’Apple détient. Avec elle, Apple n’a rien à remettre à personne.

2. Garde en tête ce que l’option ne couvre pas. iCloud Mail, Contacts et Calendrier restent hors chiffrement de bout en bout, même Protection Avancée activée. Pour l’email chiffré, Proton Mail ou Tuta font le travail par architecture.

3. Pour ce que tu refuses de confier à la moindre clé tierce, sauvegarde localement sur un disque chiffré, ou passe par un stockage souverain chiffré de bout en bout. Une injonction s’arrête là où l’entreprise n’a pas la clé.

4. Le repère à suivre, c’est décembre 2026 : l’audience Privacy International et Liberty contre ce régime d’injonctions. Faute de pouvoir suivre l’affaire Apple, tenue au secret, c’est là que le cadre légal se débat en public.

Sources

Financial Times, source primaire : https://www.ft.com/content/2cc9c96a-0e5b-4c33-a95a-3d11072a145c
TechCrunch, reprise : https://techcrunch.com/2026/08/03/apple-challenges-uk-governments-latest-demand-for-icloud-backdoor-report/
9to5Mac, reprise : https://9to5mac.com/2026/08/03/apple-launches-second-legal-challenge-to-uk-icloud-backdoor-order-per-report/
AppleInsider, reprise : https://appleinsider.com/articles/26/08/03/uk-faces-new-legal-fight-from-apple-over-backdoor-access-to-icloud-data
Euronews, reprise : https://www.euronews.com/next/2026/08/04/apple-challenges-the-uks-second-attempt-to-gain-access-to-icloud-data
MacRumors, reprise : https://www.macrumors.com/2026/08/03/apple-legal-challenge-against-uk-demand/

Ton SIEM souverain, lis-le vraiment puis fais-le passer à l'action

Mac Souverain — Sun, 02 Aug 2026 12:01:00 GMT

Tu as suivi la série SIEM. Tu as monté Wazuh en tout-en-un sur ton VPS durci, puis déployé les agents. Ton dashboard s’allume, il liste tes machines, il affiche chiffres, courbes et alertes qui montent. Et là tu restes planté devant, avec une question bête que personne ne pose dans les tutos d’installation, tu en fais quoi de toutes ces infos ?

Parce qu’il faut être franc, le dashboard Wazuh, comme ça, de but en blanc, ben… ça ressemble un peu à un cockpit de Boeing. Un de nos lecteurs m’en a gentiment fait part, c’est l’origine de cette série d’articles.

Je dis bien série, parce qu’après avoir un peu réfléchi à la problématique, je me suis dit qu’un seul article au format normal ne suffirait pas.

La mauvaise réponse à la question initiale, celle vers laquelle tout te pousse, c’est de tout allumer d’un coup pour « ne rien rater ». La guirlande de Noël toute éclairée, c’est beau, mais avec tellement de trucs à regarder que tu ne sais plus où donner de la tête.

Wazuh n’est pas un antivirus. Il ne bloque rien avant que l’on active rootcheck et réponse active, il ne nettoie rien, en l’état il ne te protège pas. C’est un collecteur, un moteur de règles et un stockage. Il rend visible ce qui se passe sur tes machines. Toute sa valeur naît le jour où tu lui poses deux ou trois questions précises, pas le jour où tu le laisses tout observer et où tu essaies de suivre le match en même temps.

Aujourd’hui, on active tes trois premiers usages utiles, dans l’ordre, avec un fil rouge unique, ne pas te noyer sous les alertes. Ce tuto vise la branche 4.x de Wazuh, celle de toute la série SIEM, pas la nouvelle version 5.

Ce qu’il te faut

Rien à installer aujourd’hui, tout est déjà en place. On configure et on lit. Trois prérequis, tous hérités de la série.

Ton manager Wazuh opérationnel, celui de l’épisode 2 SIEM.
Au moins un agent en état Active, celui de l’épisode 3.
Ton accès au tableau de bord, verrouillé en Tailnet, comme on l’a laissé.

Le déclic, Wazuh te montre, il ne te défend pas

Imagine une caméra de surveillance sans vigile derrière l’écran. Elle filme tout, parfaitement. Elle n’arrête personne. Wazuh, c’est ça, la caméra. Le vigile, c’est toi.

Et un vigile qui fixe quarante écrans en même temps ne voit plus rien. C’est le piège qui tue les SIEM de PME, pas en six mois, en deux semaines.

Classique, tu actives tous les modules le premier jour, chacun déverse ses centaines, voire milliers, d’événements, tu ne tunes rien, le signal se perd dans le vacarme, et au bout de quinze jours tu ne regardes même plus le dashboard.

Là, ton SIEM est mort. Pas planté, pas cassé, juste ignoré. Ce qui revient au même.

La règle d’or de tout ce qui suit, écris-la sur un post-it.

N’active aucune règle dont tu ne sais pas quoi faire quand elle se déclenchera. Si une alerte tombe et que ta seule réaction possible est de hausser les épaules, cette alerte n’aurait pas dû exister.

Trois usages, dans cet ordre précis. Chacun répond à une question, et à une seule.

Ce que ça change, ce que ça ne change pas

Ce que ça change. À la fin, tu ne regardes plus un mur d’alertes indistinct. Tu as trois vues qui t’apportent chacune une réponse claire, tu sais laquelle ouvrir et pourquoi.

Ce que ça ne change pas. Tu observes, tu ne bloques toujours pas. Décider quelles applications ont le droit de tourner, couper une connexion hostile, ça viendra, c’est un autre étage. Ici, on apprend à regarder juste avant d’apprendre à agir.

Premier usage, l’audit de configuration, ta seule liste qui a une fin

Commence par le SCA, pour Security Configuration Assessment, l’audit de configuration de sécurité. Et commence par lui pour une raison très concrète, c’est le seul module de Wazuh qui produit une liste finie.

Tous les autres crachent un flux sans fin, des événements qui tombent tant que tes machines tournent. Le SCA, lui, prend une machine, la compare à une politique de durcissement de référence, du type des référentiels CIS, et te rend un résultat borné, un score et une liste de points en échec. Cent quatre-vingts vérifications, une partie sans objet sur ta machine, et sur le reste tu en passes à peu près la moitié d’entrée. L’autre moitié te donne une liste d’échecs, bornée, que tu traites en une heure, sans rien tuner, dès le premier jour.

Dans le dashboard, ouvre la vue d’audit de configuration de l’un de tes agents, l’onglet Configuration Assessment si ton interface est en anglais. Tu y trouves un score global et le détail des contrôles, chacun avec son verdict, réussi ou échoué, et surtout la remédiation associée, la valeur attendue et comment l’atteindre.

Ta seule tâche, la voici.

Trie par contrôles en échec.
Repère ceux qui comptent vraiment pour toi, un service SSH mal configuré, un compte sans expiration de mot de passe, une permission trop large sur un répertoire système.
Corrige, relance le scan, regarde ton score grimper.

C’est gratifiant, et ce n’est pas un hasard si je te le fais faire en premier. Le SCA ne te réveille pas la nuit, il ne t’inonde pas.

C’est une check-list que tu ouvres, que tu traites, et que tu refermes. Le contraire exact d’une source d’angoisse. Le bon endroit pour prendre confiance avant d’affronter les modules qui, eux, parlent en continu.

Deuxième usage, la surveillance de fichiers, surveille peu pour entendre quelque chose

Le FIM, pour File Integrity Monitoring, la surveillance d’intégrité des fichiers. Tu l’as croisé à l’épisode 3, quand on l’a déployé via les groupes. Aujourd’hui, ce n’est pas la mécanique qui compte, c’est la discipline.

Le réflexe naturel, catastrophique, c’est de vouloir surveiller large. Tout /etc, tout /usr, tant qu’à faire tout le disque. Sauf que chaque mise à jour de paquets réécrit des dizaines de fichiers parfaitement légitimes, et le FIM t’alerte à chaque fois. Tu surveilles tout, donc tu entends un vacarme permanent, donc tu n’entends plus rien.

Fais l’inverse. Choisis trois ou quatre répertoires qui comptent vraiment, tes données clients, ta comptabilité, un partage métier, les configs critiques d’un service exposé. Ceux où un changement que tu n’as pas décidé est, en soi, une nouvelle qui mérite ton attention.

La configuration, tu la pousses proprement par le groupe, dans le fichier partagé du manager, exactement comme à l’épisode 3.

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

Le check_all="yes" enregistre tout ce qui caractérise un fichier, empreintes, taille, propriétaire, permissions, dates, la moindre altération est vue. Le realtime="yes" demande l’alerte à l’instant du changement.

Une nuance d’honnêteté déjà posée dans la série, ce temps réel n’existe que sur Linux et Windows. Sur macOS, le FIM retombe sur des scans planifiés, une modification entre deux passages n’est vue qu’au passage suivant.

Le principe à retenir tient en une phrase. Chaque répertoire surveillé est une promesse de réagir. Ne surveille que ce sur quoi tu bougerais vraiment. Le reste, c’est du bruit que tu t’infliges à toi-même.

À lire : Déploie Wazuh partout, le SIEM voit enfin ton réseau pour la mécanique complète des groupes et du FIM par agent.

Troisième usage, la détection de vulnérabilités, l’inventaire qui vieillit tout seul

En troisième seulement, la détection de vulnérabilités, l’onglet Vulnerability Detection du dashboard, que les versions récentes ne rangent plus à côté des deux premiers mais dans la section chasse aux menaces. Le principe est élégant, l’agent dresse l’inventaire des paquets installés sur chaque machine, et le manager croise cet inventaire avec un flux de failles connues, les fameuses CVE, pour Common Vulnerabilities and Exposures.

Le résultat, c’est une liste, par machine, des logiciels dont une version vulnérable est installée chez toi. Puissant. Et pour ça même, à manier en dernier des trois, parce que c’est le module qui déverse le plus. Sur un parc réel, tu vas voir tomber des centaines d’entrées, la plupart en sévérité basse ou moyenne.

Si tu débarques là-dessus sans avoir dompté les deux premiers usages, tu te noies. Alors on trie, on ne lit pas tout.

Filtre par sévérité, concentre-toi sur le critique et le haut.
Croise avec l’exposition réelle, une faille sur un service accessible depuis le Tailnet n’a pas le même poids qu’une faille sur un paquet jamais lancé, ou accessible depuis le net.
Traite, patche ou mets à jour, puis laisse le prochain inventaire confirmer que la ligne a disparu.

Le piège ici est sournois. Une liste de vulnérabilités que tu ne tries jamais est pire que pas de liste du tout, parce qu’elle t’installe dans un faux sentiment de sécurité, tu crois savoir, tu ne fais rien. Un inventaire ne vaut que par le tri qui le suit, et par les correctifs qu’il engendre.

Ce qu’on n’allume surtout pas encore

Wazuh embarque d’autres modules, et deux d’entre eux te font de l’œil. Résiste.

Le rootcheck, la détection de rootkits et d’anomalies système, tourne déjà en tâche de fond par défaut. Ne t’y attarde pas pour autant, tant que les trois premiers usages ne sont pas calmes et lus, ce n’est pas là qu’est ta priorité du moment.

Et surtout, surtout, la réponse active. Ce module exécute des scripts en réaction à une alerte, bloquer une adresse, tuer un processus, couper une session. Sur le papier, c’est le rêve, le SIEM qui se défend seul. En vrai, branché avant d’avoir tuné tes règles, c’est le meilleur moyen de te verrouiller toi-même hors de ta propre infrastructure sur un faux positif. Il existe bien un garde-fou, une liste blanche d’adresses jamais bloquées où tu mets ton IP d’admin, mais c’est justement le genre de réglage qu’on ne cale bien qu’une fois qu’on maîtrise le reste.

La réponse active vient en dernier, une fois que tu connais tes règles par cœur et que tu leur fais confiance. Pas avant.

Tu vois le fil, il n’a pas changé depuis le premier paragraphe. On active dans l’ordre du plus calme au plus bavard, et on n’automatise une réaction que le jour où on sait exactement ce qu’elle va faire.

Les limites réelles

Wazuh est un excellent outil, souverain, gratuit, sans limite d’agents. Il a aussi des angles morts précis, que tu dois connaître pour ne pas te faire piéger.

Sur Mac, la surveillance de fichiers n’est pas en temps réel. On l’a vu plus haut, macOS retombe sur des scans planifiés. Concrètement, sur un parc majoritairement Apple, ne compte jamais sur une alerte à la seconde côté FIM, raisonne en fenêtres de scan et place tes garde-fous temps réel sur tes endpoints Linux et Windows.

Le SCA juge ta machine contre des politiques génériques. Certains contrôles ne collent pas à ta configuration réelle et remontent en échec alors que ton choix est délibéré et justifié. Ces faux positifs se trient à la main, une fois, puis se mettent de côté. C’est du travail d’humain, pas un défaut à corriger dans l’outil.

La détection de vulnérabilités raisonne au niveau du paquet et de sa version. Elle peut te signaler une CVE que ta distribution a déjà corrigée par un correctif rétroporté sans changer le numéro de version affiché. Résultat, une alerte pour un trou déjà bouché.

Croise systématiquement avec les bulletins de sécurité de ta distribution avant de t’affoler sur une ligne critique.

Aucune de ces limites n’est rédhibitoire. Toutes se gèrent, à condition de les avoir en tête avant, pas après une nuit blanche.

Si ça ne marche pas

Problème, l’audit de configuration reste vide ou à zéro

Cause probable, le module n’est pas actif sur l’agent, ou aucune politique n’est chargée pour ce système.

Solution, vérifie que le SCA est activé dans la configuration de l’agent et qu’une politique correspond bien à son système d’exploitation. Relance un scan et laisse-lui le temps de remonter.

Problème, le FIM ne t’alerte pas en temps réel sur un Mac

Cause probable, aucune. C’est le comportement attendu, le temps réel n’existe pas côté macOS.

Solution, rien à réparer. Sur Mac, tu raisonnes en scans périodiques. Si tu veux du temps réel, c’est sur tes endpoints Linux et Windows que ça se joue.

Problème, la détection de vulnérabilités n’affiche rien

Cause probable, le module vient d’être activé et son flux de failles n’a pas encore été téléchargé, ou l’inventaire des paquets n’est pas encore remonté.

Solution, patiente le temps du premier téléchargement du flux et de la première remontée d’inventaire. Si après un délai raisonnable c’est toujours vide, vérifie que le module est bien activé côté manager.

Pour les pressés

Ce que fait cet article. Une fois Wazuh installé et les agents déployés, il te dit quoi faire en premier, sans te noyer. Trois usages dans l’ordre, du plus calme au plus bavard, et deux modules qu’on laisse éteints exprès.

Concrètement, la marche à suivre.

Ouvre l’audit de configuration d’un agent, trie les contrôles en échec, corrige les quelques-uns qui comptent, relance le scan.
Restreins la surveillance de fichiers à trois ou quatre répertoires vraiment sensibles, via le groupe, bloc <syscheck> avec check_all="yes" et realtime="yes" (temps réel sur Linux et Windows seulement, pas macOS).
Active la détection de vulnérabilités, filtre par sévérité, traite le critique et le haut, ignore le tout-venant.
Laisse le rootcheck et surtout la réponse active éteints tant que le reste n’est pas calme et maîtrisé.
Règle d’or, n’active aucune règle dont tu ne sais pas quoi faire quand elle se déclenchera.

En résumé

Ton SIEM était allumé et muet pour toi, il devient lisible. Tu es parti d’un dashboard qui crépitait sans te parler, tu repars avec trois vues qui répondent chacune à une question nette.

L’audit de configuration t’a donné une liste finie à traiter en une heure. La surveillance de fichiers, restreinte à l’essentiel, ne t’alerte plus que sur ce qui compte. La détection de vulnérabilités te dresse l’inventaire de ce qui doit être patché, à condition que tu le tries. Et deux modules puissants restent au repos, parce qu’on ne les branche qu’une fois le reste dompté.

La techno n’était pas le dur. Le dur, c’est la retenue. Choisis peu de questions, mais réponds-y vraiment.

Et après, apprends à ton SIEM à agir

Tu viens d’apprendre à faire parler Wazuh, à lui poser peu de questions et à les écouter vraiment. C’est la moitié du chemin. L’autre moitié, c’est de le faire passer de spectateur à acteur, sans qu’il se retourne contre toi.

Cet article ouvre la marche. La suite s’écrit un cran à la fois, dans le même esprit, du plus calme au plus engageant.

Épisode 2, écrire tes propres règles. Pour qu’il te réveille sur ce qui compte chez toi et se taise sur le reste.
Épisode 3, brancher Santa sur Wazuh. Pour que ton SIEM voie non seulement ce qui s’exécute sur tes Mac sous contrôle d’exécution, mais aussi ce qu’on a bloqué.
Épisode 4, la réponse active. Le module qu’on a laissé éteint exprès aujourd’hui, celui qui agit seul, bloque une adresse, coupe une session, et qu’on ne branche qu’une fois qu’on lui fait vraiment confiance.
Épisode 5, la conformité SCA vers NIS2. Transformer l’audit de configuration en rapport de conformité présentable à un auditeur.

Et pour l’ajustement fin, calibrer les seuils, régler les notifications pour n’être réveillé que quand ça compte vraiment, la série a son chapitre dédié.

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

Rappel de la série

Cet article ouvre la suite de la série SIEM souverain, celle où on apprend à ton SIEM à lire puis à agir. Si tu débarques, rattrape d’abord les épisodes qui précèdent.

Épisode 0, le fondement. 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. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ta 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.

Mac et Tailscale, ton réseau privé wireguard en 15 min chrono

Mac Souverain — Sat, 01 Aug 2026 07:00:00 GMT

Tu as plus d’un Mac. Un fixe à la maison, un portable qui bouge, peut-être un vieux Mac recyclé en serveur de fichiers, ou encore un Mac mini dédié pour un LLM souverain (lire l’article).

Ce LLM, tu veux pouvoir l’interroger où que tu sois, et quel que soit le Mac sur lequel tu te trouves.

Et tes dossiers, idem. Parce que pour le moment, sans iCloud, à chaque fois que tu veux passer un dossier de l’un à l’autre, c’est la même comédie : AirDrop qui fait la sourde oreille, une clé USB qu’on ne retrouve pas, ou un partage réseau qui marchait la semaine dernière et plus aujourd’hui.

Il existe une façon propre de régler ça une fois pour toutes. Tu mets toutes tes machines sur un même réseau privé, un mesh, chiffré de bout en bout par un protocole béton, le WireGuard, où chaque Mac peut joindre les autres directement, qu’ils soient dans la même pièce, à l’autre bout du pays ou sur un autre continent.

Le tout en un quart d’heure, sans ouvrir un seul port, sans toucher aux réglages de ta box et sans terminal. Avoue, t’es bluffé, non ?

Cet outil s’appelle Tailscale, et voici comment on monte le réseau.

Un mesh VPN, c’est quoi au juste

Le mot VPN, tu le connais déjà. Un VPN classique, c’est un tunnel : ton Mac se connecte à un serveur distant, et tout ton trafic passe par ce serveur. C’est parfait pour cacher ta navigation ou débloquer un catalogue à l’étranger. Mais ça ne relie pas tes machines entre elles.

À lire : Pourquoi tu as besoin d’un VPN et comment le choisir

Un mesh VPN, c’est l’idée inverse. Au lieu de tout faire transiter par un serveur central, chaque machine parle directement à chaque autre, en ligne droite, dans un tunnel chiffré individuel. Tes cinq Macs forment une toile où chacun est relié à tous les autres. C’est de là que vient le mot mesh, le maillage.

Concrètement, c’est comme si tes machines étaient toutes branchées sur le même switch réseau, dans la même pièce, avec des câbles invisibles et chiffrés. Sauf qu’elles peuvent être chez toi, à l’autre bout du pays et dans un placard à la cave (faut un câble quand même hein !), ça marche pareil.

Sous le capot, Tailscale s’appuie sur WireGuard, un protocole de tunnel chiffré moderne, assez compact pour être audité de fond en comble et intégré directement au cœur de Linux. Mullvad, Proton VPN et pas mal d’autres l’ont adopté, ce n’est pas un gadget maison.

Tu n’as pas à le configurer, Tailscale s’en charge. Ton boulot à toi, c’est de cliquer sur « Se connecter » sur chaque machine. Le sale travail réseau, la traversée des box et des pare-feux, c’est lui qui l’encaisse.

Une chose à poser tout de suite : les applications Tailscale qui vont tourner sur tes machines sont open source et auditées. En revanche, le service se pilote depuis une console web tenue par la société Tailscale, sous juridiction US. On y reviendra en toute fin d’article, parce que ça a son importance pour la suite de la série.

Ce qu’il te faut

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

Au moins deux machines. Deux Macs, ou un Mac et un iPhone, ou dix appareils, peu importe. Le principe est le même à partir de deux.

Un compte pour t’identifier. L’inscription à Tailscale passe par un fournisseur d’identité existant, Apple, Google, GitHub ou Microsoft. Pour rester dans l’esprit maison, tu peux tout à fait choisir « Se connecter avec Apple ». Pas de nouveau mot de passe à retenir.

Un quart d’heure. La majeure partie sera passée à regarder deux téléchargements se terminer. Le reste, c’est des clics.

Note au passage : ce guide parle de Mac, mais l’app existe aussi sur iPhone et iPad. Une fois le réseau monté, ajouter ton téléphone à la même toile prend trente secondes. Pratique pour la famille.

Installer Tailscale sur ton premier Mac

Commence par la machine devant laquelle tu es assis.

Tu as deux façons de récupérer l’app. La plus simple, l’App Store : cherche « Tailscale », installe, comme n’importe quelle app. La seconde, le site officiel, qui te donne une version un peu plus complète côté fonctions avancées. Pour un premier réseau entre tes Macs, la version App Store suffit largement. On notera la différence plus bas, quand elle comptera.

Une fois l’app installée, lance-la. Elle se loge dans la barre de menus, en haut à droite de ton écran, à côté de l’horloge. Clique sur son icône, puis sur « Log in ». Ton navigateur s’ouvre sur la page de connexion Tailscale. Tu choisis ton fournisseur d’identité, tu valides, et c’est fait.

De retour dans la barre de menus, l’icône Tailscale s’anime puis se stabilise. Ta première machine vient de rejoindre son réseau privé, que Tailscale appelle un tailnet. Pour l’instant, elle est toute seule dessus. On va lui trouver de la compagnie.

Si tu préfères tout piloter au clavier, l’app existe aussi via Homebrew avec brew install tailscale. Mais pour un premier montage, l’app graphique est plus parlante. Reste sur elle.

Ajouter les autres Macs au tailnet

Répète l’opération sur ta deuxième machine.

Installe l’app, lance-la, connecte-toi. Point crucial : connecte-toi avec le même compte que sur le premier Mac. C’est ce compte qui définit ton tailnet. Deux machines connectées avec le même identifiant se retrouvent automatiquement sur le même réseau, et se voient l’une l’autre. Rien d’autre à configurer.

Recommence pour chaque Mac que tu veux ajouter. Le Mac du salon, le portable, le vieux serveur dans le placard. Chacun rejoint la toile dès qu’il se connecte avec ton compte.

Pour vérifier que tout ce petit monde s’est bien réuni, ouvre la console d’administration sur Tailscale. Tu y trouves la liste de toutes tes machines, avec leur nom, leur adresse sur le tailnet, et un point vert quand elles sont en ligne. C’est ton tableau de bord. C’est aussi là que tu virerais un appareil que tu ne reconnais pas, en un clic.

À ce stade, tes Macs sont sur le même réseau privé chiffré. Techniquement, tu pourrais déjà les joindre par leur adresse. Sauf que retenir des adresses réseau par cœur, personne n’a envie de le faire. On va régler ça.

MagicDNS, appeler tes Macs par leur nom

Voici le réglage qui transforme le confort d’usage.

Par défaut, chaque machine du tailnet a une adresse numérique. Fonctionnel, mais illisible. MagicDNS remplace ces numéros par les noms de tes machines. Ton MacBook s’appelle mack-macbook ? Tu le joins en tapant mack-macbook, tout simplement. Ton serveur du placard s’appelle mack-mini ? Pareil.

Bonne nouvelle, sur un tailnet monté aujourd’hui, MagicDNS est déjà activé par défaut. Tu n’as rien à faire, sinon jeter un œil dans la console d’administration, onglet DNS, pour confirmer qu’il est bien vert. Chaque machine du tailnet est joignable par son nom, depuis n’importe quelle autre, où qu’elle soit.

Le nom de chaque machine est repris de son nom système, ce qui donne parfois des noms à rallonge, du genre mack-macbook-de-prenom. Tu peux le raccourcir. Dans la console, clique sur une machine, puis sur son nom. Coupe l’interrupteur Auto-generate from OS hostname, tape le nom court que tu veux, et valide. C’est ce nom-là qui te servira à la joindre partout.

Cette résolution de noms reste strictement interne à ton tailnet. Personne d’autre que toi ne peut deviner ni joindre mack-mini. C’est un annuaire privé, qui n’existe que pour tes machines.

Le cas concret, accéder aux fichiers du Mac resté à la maison

Assez de théorie. Voici l’usage qui justifie à lui seul les quinze minutes.

Tu es en déplacement avec ton portable. Le fichier dont tu as besoin est resté sur le Mac de la maison. Tu me diras, iCloud fait déjà ça. Sauf qu’iCloud, ça veut dire copier tes fichiers sur les serveurs d’Apple et ne retrouver que ce que tu y as poussé. Avec Tailscale, tu ouvres le disque du Mac distant en entier, tel quel, comme s’il était branché en USB. Rien ne monte dans un cloud, rien ne quitte tes machines, et tu pioches le fichier depuis ton canapé d’hôtel.

D’abord, sur le Mac de la maison, active le partage de fichiers. Réglages Système, Général, Partage, puis active Partage de fichiers. Tu ne touches à rien d’autre. Surtout pas au routeur, surtout pas à une redirection de port. Le partage écoute, Tailscale s’occupe du chemin.

Ensuite, depuis ton portable, ouvre le Finder. Menu Aller, Se connecter au serveur, ou le raccourci Cmd+K. Tu tapes smb:// suivi du nom MagicDNS de la machine, par exemple smb://mac-maison. Tu valides, tu entres ton identifiant du Mac distant, et son disque s’ouvre dans une fenêtre Finder. Tu glisses ton fichier, exactement comme s’il était en local.

Même logique pour prendre la main sur l’écran d’un autre Mac. Sur le Mac distant, active d’abord le Partage d’écran : Réglages Système, Général, Partage, Partage d’écran. Ensuite, dans la même fenêtre « Se connecter au serveur », tape vnc:// suivi du nom de la machine, et tu contrôles son bureau à distance. Le Mac de tes parents qui rame ? Tu le dépannes depuis chez toi, sans TeamViewer et sans qu’un tiers voie passer la session.

Tout ce trafic circule dans le tunnel chiffré. Rien ne transite par un serveur qui traîne quelque part. C’est ton Mac, ton portable, et une ligne droite chiffrée entre les deux.

Le vrai gain, ne plus rien exposer

Le transfert de fichiers, c’est l’exemple qui parle tout de suite. Mais le meilleur du mesh, c’est ce que tu arrêtes de faire : ouvrir des portes sur Internet.

Avant, pour joindre ton NAS ou ton Mac depuis l’extérieur, il fallait bricoler une redirection de port sur ta box. Autrement dit, planter une porte sur l’Internet public, avec ton adresse écrite dessus. Et cette porte, elle est scannée en boucle, jour et nuit, par des robots qui testent les mots de passe à la chaîne.

Avec Tailscale, il n’y a plus de porte du tout. Tes services écoutent uniquement sur le tailnet, invisibles du reste du monde. Quelqu’un qui scanne ton adresse publique ne voit rien, parce qu’il n’y a rien à voir.

Ça change ce que tu peux te permettre d’héberger chez toi. Un NAS Synology, un Home Assistant, l’admin d’un petit serveur, un site que tu bricoles le week-end : tu les joins par leur nom depuis n’importe où, et ils restent injoignables pour tout le reste du monde.

Tu profites de tes machines à distance sans jamais les mettre en vitrine.

Même les réseaux pourris deviennent inoffensifs. Le WiFi d’un café, d’un aéroport, d’un hôtel, ces endroits où n’importe qui peut renifler ce qui passe. Ton lien vers tes machines reste dans le tunnel chiffré, sur un réseau hostile comme ailleurs.

Ce que tu échanges avec ton tailnet ne fuit pas. Et le jour où un appareil se perd ou se fait voler, tu ouvres la console, un clic, tu le révoques. Il perd l’accès au réseau sur-le-champ, avant même que tu aies fini de paniquer.

Sortir autrement, exit node et DNS no-log

Deux réglages valent le détour si la souveraineté te titille.

Le premier, l’exit node : en l’activant sur une machine, tu fais passer tout le trafic Internet d’un autre appareil par elle. Router ton portable en voyage à travers ton Mac resté à la maison, par exemple, pour naviguer comme si tu y étais.

Le second, dans l’onglet DNS de la console : tu imposes à tout ton tailnet un résolveur qui ne journalise rien, comme Quad9, et tu coupes d’un geste ceux de ton FAI. Tes machines demandent qui est qui à un service no-log, plus à ton opérateur.

Un piège à connaître : ce réglage peut être court-circuité en douce. Si ta box distribue son propre résolveur en IPv6, macOS a tendance à le préférer, et tes requêtes repartent vers ton FAI sans rien te dire.

Le réflexe, une fois ton DNS no-log posé : file sur ipleak.net et vérifie qu’aucun résolveur de ton opérateur ne dépasse. S’il en sort un, coupe l’IPv6 sur ta box, ou déclare aussi ton résolveur en v6. Sinon, tu crois être chez Quad9 alors que tu es toujours chez ton FAI.

Les limites, à savoir avant de te lancer

Tailscale fait le job remarquablement bien, mais il y a des bornes réelles. Autant les connaître.

Le plan gratuit est généreux, pas illimité. Le plan Personal couvre largement un particulier ou une famille : jusqu’à 6 utilisateurs, avec un nombre illimité d’appareils personnels. Tant que tu montes ton propre réseau pour tes machines, tu ne verras jamais le mur.

Ce n’est que si tu veux partager ton tailnet avec toute une tribu, au-delà de six personnes, que tu bascules sur un plan payant. Autre borne du gratuit : il est réservé à l’usage perso. Pour faire tourner une boîte dessus, c’est plan payant.

Ce n’est pas un VPN d’anonymat, du moins pas par défaut. Tailscale chiffre le trafic entre tes machines, mais il ne masque pas ta navigation vers le reste du web.

L’exit node fait sortir ton trafic par une autre machine. Le piège : si cette machine, ton Mac de la maison par exemple, n’a pas de VPN elle-même, ton trafic ressort au grand jour depuis son adresse. Tu sors « depuis chez toi », pas anonymement.

La vraie réponse, c’est l’option Mullvad intégrée à Tailscale : 5 dollars par mois pour cinq appareils, et tu utilises les serveurs Mullvad comme exit nodes, no-log, dans une cinquantaine de pays, sans quitter l’app ni créer de compte à part.

Pourquoi l’add-on plutôt que lancer l’app Mullvad ou Proton VPN à côté ? Parce qu’un VPN classique qui prend la main sur tout ton trafic entre en conflit avec Tailscale et peut carrément couper ton tailnet. L’add-on, lui, cohabite proprement. C’est pour ça que je tourne avec sur mon réseau.

La version App Store est un peu bridée. Pour rester dans le bac à sable d’Apple, la version App Store met de côté quelques fonctions annexes : elle ne sait pas lancer la commande tailscale ssh (il faut passer par le ssh classique), et perd la compatibilité Temps d’écran ainsi que les rapports de configuration complets. L’exit node, lui, fonctionne à l’identique dans les deux versions. Si un jour tu veux ces fonctions, désinstalle et reprends la version du site officiel. Pour le réseau de fichiers décrit ici, aucune différence.

L’identité passe par un tiers. Pas de compte email plus mot de passe maison : tu t’identifies via Apple, Google, GitHub ou Microsoft. C’est plus sûr techniquement, mais ça veut dire qu’un fournisseur externe est dans la boucle de connexion. Choisir Apple limite la casse si ce point te chatouille. Une nuance quand même, Tailscale propose aussi l’option OIDC, brancher ton propre fournisseur d’identité. C’est le fil qu’on tire dans le prochain article.

Et après, couper le cordon du coordinateur

Ton réseau tourne. En quinze minutes, tu as fait ce qui aurait demandé une soirée de config réseau il y a cinq ans.

Reste un détail qui va te turlupiner si tu tiens à ta souveraineté. Le petit serveur qui orchestre tout ça, celui qui présente tes machines les unes aux autres, il est tenu par une société américaine, donc soumis au droit américain, CLOUD Act compris. Washington peut donc lui réclamer ce qu’il détient sur toi, même stocké hors des États-Unis.

La bonne nouvelle, tes fichiers ne fuitent pas par là, le contenu circule chiffré, en direct d’une machine à l’autre, le coordinateur n’a pas les clés. La moins bonne, il voit tout le reste : la liste de tes appareils, leurs noms, qui se connecte à qui et quand. La carte de ton réseau, en somme. Un maillon que tu ne contrôles pas.

Dans le prochain article de la série, on remplace ce maillon par le tien. On monte ton propre serveur de contrôle avec Headscale, la ré-implémentation open source du coordinateur, et là, tout le réseau t’appartient de bout en bout. Une étape de plus vers la maison souveraine.

À lire bientôt : Tailscale souverain, ton propre coordinateur avec Headscale

À lire : Qu’est-ce que la souveraineté digitale en pratique

Des termes techniques dans cet article ? Consulte le glossaire.

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

Mets ton IA locale au travail, sans le cloud

Mac Souverain — Tue, 28 Jul 2026 07:00:00 GMT

Tu as installé ton modèle local. Tu lui as parlé. Tu as même coupé le Wi-Fi pour vérifier qu’il répondait encore, et il répondait. Belle démonstration. Et depuis, ton IA locale vit dans une fenêtre de chat où tu colles ton texte à la main, tu lis la réponse, tu la recolles ailleurs.

Autrement dit, tu as un moteur souverain, et tu t’en sers comme d’un carnet.

Une IA coincée dans sa fenêtre de discussion ne rend que la moitié de ce qu’elle sait faire. L’autre moitié, celle qui compte pour de vrai, c’est quand elle travaille pendant que tu fais autre chose. Trier un lot de mails, résumer un dossier de notes, reformuler trente lignes d’un coup, sans que tu joues les copistes. Et le meilleur, c’est que le geste pour y arriver tient dans un après-midi.

À lire d’abord : Installe ton premier modèle d’IA en local sur Mac. Cet article part de là, un modèle qui tourne déjà chez toi.

Le vrai problème, tu es devenu l’assistant de ton assistant

Regarde comment tu utilises ton modèle local aujourd’hui. Tu ouvres LM Studio, tu tapes ta demande, tu attends, tu récupères le texte. Pour une question, ça va. Pour trente mails à trier ou cinquante notes à résumer, tu deviens la courroie de transmission, le maillon lent entre la tâche et la machine.

C’est exactement le travail répétitif qu’une IA est censée t’enlever. Sauf que là, c’est toi qui l’exécutes à sa place.

Le réflexe classique, quand on veut automatiser, c’est de se tourner vers un Zapier, un IFTTT, un Make. Tu relies deux services, tu ajoutes une pincée d’IA au milieu, et ça tourne tout seul. Pratique. Sauf que chacun de ces outils est un intermédiaire cloud, et que la pincée d’IA, c’est encore un modèle distant. Tu voulais automatiser du travail sensible, tes mails, tes notes, tes documents, et tu viens de le faire transiter par deux entreprises étrangères au lieu d’une.

Tu as monté ton IA en local précisément pour que rien ne sorte. Ce serait dommage de rouvrir la porte par la petite fenêtre de l’automatisation.

La bonne nouvelle : tu n’as besoin d’aucun de ces services. Ton modèle local sait déjà se brancher. Il t’attend, et personne d’autre n’écoute.

La clé que tu ne voyais pas, ton modèle expose une API locale

Voilà ce que personne ne t’a dit en installant LM Studio. La fenêtre de chat n’est qu’une des deux portes de la maison. La seconde, c’est un petit serveur qui tourne sur ta machine et qui parle le même langage que les grands modèles distants.

Une image pour situer. La fenêtre de chat, c’est le comptoir du magasin, tu viens, tu demandes, on te sert. Le serveur local, c’est le quai de livraison à l’arrière, celui par où passent les palettes entières, sans faire la queue au comptoir. Même magasin, même stock, mais un accès taillé pour le volume et pour les machines.

Concrètement, LM Studio peut démarrer un serveur qui écoute en local, sur ta machine et sur elle seule. N’importe quel programme sur ton Mac, un script, une app, un raccourci, peut alors lui envoyer une demande et récupérer la réponse, sans un clic de ta part. Tu passes du « je pose une question » au « ce programme pose mille questions pendant que je déjeune ».

Et le détail qui fait toute la différence, c’est que cette API est compatible OpenAI. Traduction en clair : elle parle exactement le même langage que l’API des gros fournisseurs distants. Le format de la demande, la structure de la réponse, tout est identique. Ça veut dire que la quasi-totalité des outils, tutoriels et bouts de code écrits pour « brancher une IA » fonctionnent avec ton modèle local, en changeant une seule chose, l’adresse. Au lieu de pointer vers un serveur à l’autre bout du monde, tu pointes vers localhost, chez toi.

Ton texte part vers ta propre machine, ta machine répond, rien ne franchit ta carte réseau. Pas de facture à la requête. Pas de conditions d’utilisation. Pas de tiers qui lit au passage.

C’est là que ton IA locale cesse d’être un jouet et devient un outil.

Allumer le serveur, le seul réglage à connaître

Avant de brancher quoi que ce soit, il faut ouvrir le quai de livraison. C’est une case à cocher, littéralement.

Dans LM Studio, va dans l’onglet Developer, celui à l’icône en chevrons >_, l’ancien « Local Server » des versions précédentes. Charge le modèle que tu utilises déjà, celui de l’article précédent, puis bascule le serveur sur « Start ». Une adresse s’affiche, http://localhost:1234.

Retiens deux choses de cet écran, et une seule compte vraiment pour ta tranquillité.

L’adresse commence par localhost, aussi noté 127.0.0.1. Ça signifie « cette machine, et rien d’autre ». Le serveur n’est pas exposé au réseau, ton voisin de café ne peut pas s’y connecter, une page web ouverte dans ton navigateur non plus. C’est le comportement par défaut, et c’est le bon. Ne le change pas pour l’ouvrir à 0.0.0.0 sans savoir précisément pourquoi, ce serait ouvrir ton quai de livraison sur la rue.

Le numéro à la fin, le port, c’est juste la porte précise à laquelle frapper. Note-le, tu vas t’en servir dans deux minutes.

Voilà, le serveur tourne. Ton modèle attend qu’on lui donne du travail.

Sans une ligne de code, l’app Raccourcis

Si le mot « script » te fait déjà lever les yeux au ciel, cette section est pour toi, et elle suffit à te changer la vie.

macOS embarque une app qui s’appelle Raccourcis, celle avec l’icône aux deux carrés colorés. Elle sert à enchaîner des actions automatiquement, et parmi ces actions, il y en a une qui sait parler à un serveur, exactement le nôtre. Elle s’appelle « Obtenir le contenu de l’URL ».

L’idée : tu construis un raccourci qui prend un texte, l’envoie à ton modèle local avec une consigne, et te rend la réponse. Une fois monté, tu le lances quand tu veux, depuis Spotlight ou la barre des menus : il t’ouvre une fenêtre, tu tapes ta question ou tu colles ton texte, et la réponse s’affiche.

Voici la recette, en clair.

L’entrée. Ton raccourci récupère un texte, celui que tu tapes ou que tu colles dans la fenêtre qui s’ouvre au lancement.
La demande. Une action « Obtenir le contenu de l’URL » pointée vers l’adresse de ton serveur, suivie de /v1/chat/completions. Méthode POST, en-tête Content-Type: application/json, et un corps de requête JSON qui contient le nom du modèle, ta consigne et le texte à traiter.
La sortie. Le serveur répond en JSON. Tu extrais le passage utile avec l’action « Obtenir la valeur du dictionnaire », puis tu l’affiches. Un piège t’attend là, et il fait perdre un quart d’heure à tout le monde : dans Raccourcis, le chemin pour attraper la réponse est choices.1.message.content. Oui, 1, pas 0. L’app numérote les éléments d’une liste à partir de un, quand tout le JSON du monde compte à partir de zéro. Mets 0, tu récoltes une erreur ; mets 1, tu récoltes ta réponse.

Un exemple concret et immédiatement utile : un raccourci « Reformule ça proprement ». Tu le lances, tu lui colles un paragraphe bancal, ta consigne dit au modèle « réécris ce texte dans un français clair et poli », et la version corrigée s’affiche. Le texte n’a pas quitté ton Mac. Aucun service en ligne n’a vu passer ton brouillon.

Le premier montage demande un peu de patience, le temps de placer les bonnes actions dans le bon ordre. Après, tu le dupliques et tu changes juste la consigne. « Résume en trois points », « traduis en anglais », « extrais les dates et les montants ». Un raccourci par usage, tous branchés sur le même moteur qui dort sur ta machine.

C’est la voie sans code, et pour beaucoup de gens, elle est largement suffisante.

Pour aller plus loin, quelques lignes de Python

Tu veux traiter non pas un texte, mais un dossier entier ? Là, un petit script fait ce qu’aucun clic ne fera aussi bien. Pas besoin d’être développeur, juste de recopier et d’adapter.

Le principe est le même que pour Raccourcis, en plus souple : ton script parle au serveur local, en boucle, sur autant d’éléments que tu veux. Et comme l’API est compatible OpenAI, tu peux utiliser la bibliothèque Python officielle d’OpenAI en lui donnant simplement l’adresse de ta machine au lieu de celle du cloud.

from openai import OpenAI

# On pointe la bibliothèque vers TON serveur local, pas vers le cloud
client = OpenAI(base_url="http://localhost:1234/v1", api_key="local")

def demande(consigne, texte):
    reponse = client.chat.completions.create(
        model="local-model",  # mets ici l'identifiant du modèle chargé, visible dans l'onglet Developer
        messages=[
            {"role": "system", "content": consigne},
            {"role": "user", "content": texte},
        ],
    )
    return reponse.choices[0].message.content

En local, LM Studio ignore la clé, n’importe quelle chaîne non vide fait l’affaire, « local » ici. Pour model, indique l’identifiant du modèle que tu as chargé, celui affiché dans l’onglet Developer.

Cette poignée de lignes, c’est le socle. Autour, tu enroules la tâche que tu veux. Trois recettes qui rapportent gros, tout de suite.

Résumer un dossier de notes ou de mails exportés. Tu boucles sur les fichiers d’un dossier, tu passes chacun à la fonction avec la consigne « résume en trois points », tu écris le résumé à côté. Cinquante notes digérées le temps d’un café, et pas une ligne partie ailleurs que dans ta RAM.

Trier et classer des documents. Tu demandes au modèle de coller une étiquette à chaque fichier, « facture », « contrat », « courrier », « à ignorer », puis ton script range chaque document dans le bon sous-dossier selon la réponse. Le tri intelligent que tu paierais à un service cloud, tu le fais tourner chez toi, gratuitement, sur des documents qui n’ont rien à faire dehors.

Reformuler ou nettoyer par lot. Une colonne de commentaires clients à uniformiser, une liste de titres à réécrire, un export à mettre au propre. Tu boucles, le modèle passe sur chaque ligne, tu récupères un fichier propre. Le genre de corvée qui prend une heure à la main et deux minutes en local.

Le point commun de ces trois recettes : elles sont répétitives, elles sont un peu sensibles, et elles n’ont aucune raison de sortir de ta machine. C’est le terrain de jeu naturel du local. J’y fais passer mes propres lots de notes depuis des mois, et l’idée qu’un brouillon parte chez un tiers me paraît aujourd’hui aussi bizarre que d’imprimer mon journal intime chez le voisin.

Ce que ça change, et ce que ça ne fait pas

Ton modèle local n’a pas la puissance brute du meilleur modèle distant. Sur une reformulation, un tri, un résumé, la différence est invisible. Sur un raisonnement tordu en dix étapes, elle existe encore, on en a parlé en montant ta machine. Le local n’est pas là pour gagner tous les concours. Il est là pour abattre, en silence et sans facture, la montagne de travail répétitif qui fait l’essentiel de ton volume.

Et le bénéfice cardinal ne se mesure pas en points de performance. Il se mesure en ce qui ne se passe pas.

Pas de requête envoyée à un serveur étranger. Pas de conditions d’utilisation qui changent un matin. Pas de facture qui grimpe avec ton usage. Pas de SaaS d’automatisation qui garde une copie de ce que tu lui fais transiter. Ton texte entre dans ta machine, en ressort transformé, et n’a croisé personne. C’est le même contrat que pour ton modèle en chat, étendu à tout ce que tu automatises.

Reste une limite qu’il faut nommer. Ce que tu viens de brancher, c’est du sur-mesure, tes scripts, tes raccourcis, à toi de les entretenir. Le jour où tu voudras connecter ton IA à des outils entiers, ton agenda, ton dépôt de code, ton système de fichiers, de façon standardisée, il existe une autre voie, plus puissante et plus profonde. Elle porte un nom, MCP, et elle ouvre une porte qu’il faut savoir verrouiller avant de s’en servir. C’est le cran d’après, et il mérite son propre article.

Ton modèle local expose une API, chez toi, compatible avec les outils du marché. Tu l’allumes en cochant une case dans LM Studio. Tu la branches sans code avec Raccourcis, ou avec quelques lignes de Python pour traiter des lots entiers. Et tu automatises enfin le travail répétitif que tu faisais à la main, sans qu’un seul octet ne quitte ta machine.

Le modèle que tu as installé la semaine dernière ne dormait qu’à moitié. Tu viens de le mettre au travail. Choisis une corvée, une seule, celle qui te gonfle le plus, et fais-lui faire ce soir. Le reste suivra tout seul.

À lire : Ton IA peut être éteinte par les US, monte la tienne, le pourquoi de toute cette histoire.

Sources

L’outil et son serveur local

LM Studio, documentation du serveur local, l’application embarque un serveur qui tourne sur ta machine.
LM Studio, compatibilité OpenAI, les endpoints /v1/* et le port 1234 par défaut.

La voie sans code

Apple, faire une requête d’API dans Raccourcis, l’action « Obtenir le contenu de l’URL » en POST JSON.
Apple, analyser des données JSON dans Raccourcis, pour extraire la réponse du modèle.

La voie scriptée

Bibliothèque Python OpenAI, réutilisable contre un serveur local via base_url.

Des termes techniques ? Consulte le glossaire.

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 ensuite : Mets ton IA locale au travail, sans le cloud

À 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

MAJ août 2026. La branche stable est passée à Wazuh 4.14.7 le 29 juillet. Les commandes ci-dessous nomment encore l’agent 4.14.5, remplace le numéro par 4.14.7 ou récupère le dernier .pkg/.msi sur la page des paquets Wazuh.

À 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

MAJ août 2026. La branche stable est passée à Wazuh 4.14.7 le 29 juillet, retrait du daemon déprécié wazuh-dbd, dépendances Python à jour, correctifs de synchro cluster. La commande d’install pointe sur la branche 4.14, elle te sert directement la 4.14.7, rien à changer.

À 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.