Mac Souverain — Articles

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.

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.

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.

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.

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.

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.

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.

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.

Ton Mac a été patché par XProtect à ton insu, c'est pour ton bien

Mac Souverain — Tue, 19 May 2026 07:25:30 GMT

Introduction

MAJ août 2026. Le 5 août, Apple a poussé XProtect 5354 avec un fichier inédit, AppProtectionPolicy.plist, qui liste les Team ID et Signing ID autorisés pour les apps tierces sensibles (messagerie chiffrée, navigateurs, portefeuilles crypto), plus une règle Yara visant MACOS.NEFARIOUSNAPKIN. La version citée plus bas, 5344 du 12 mai, n’est plus la dernière.

Pendant que tu dormais, le 11 mai en début de soirée, 170 paquets logiciels que la moitié du web utilise sont devenus malveillants en six minutes. Le lendemain, Apple a poussé une signature XProtect sur ton Mac, sans rien te dire.

Les deux événements sont liés, probablement. Cependant, tu ne le sauras jamais vraiment. L’épisode a un nom, TanStack. Le mécanisme qui a peut-être réagi sur ton Mac s’appelle XProtect. Tu n’as rien vu passer, moi non plus. Apple s’en assure.

Bienvenue dans le système de défense silencieux de ton Mac.

L’incident TanStack en 30 secondes

Le 11 mai 2026 au soir, l’écosystème TanStack, un kit d’outils JavaScript ultra-populaire utilisé par des millions de développeurs (dont ceux d’OpenAI, Netflix, Shopify), se fait piéger. En six minutes, 170 paquets sortent en version vérolée. Le plus visible, react-router, est téléchargé 12 millions de fois par semaine. Autant dire : une partie significative du web qui se met à jour cette semaine récupère du code piégé sans le savoir.

Le malware s’appelle Mini Shai-Hulud, variante du worm npm qui sévit depuis 2024. Sa cible, c’est ce qui traîne sur le Mac du développeur : mots de passe, clés d’accès cloud, jetons GitHub, fichiers de session. Sur macOS, il s’installe en planque dans un coin du système qui le relance à chaque ouverture de session. Discret, propre, professionnel.

Le détail qui inquiète vraiment, c’est le vecteur. L’attaquant n’a pas volé de mot de passe, ni exploité de faille dans le code. Il a juste soumis une fausse contribution au projet open source TanStack, en exploitant une configuration imprudente du système d’automatisation.

Toute contribution était exécutée avec les vrais droits de publication officiels. Une contribution piégée (pull request) a suffi pour récupérer le jeton de signature et publier 170 paquets sous l’identité légitime du projet. Du côté de npm, tout paraissait normal, signé, vérifié. Tamponné par TanStack lui-même.

OpenAI a été touché par ricochet, via une de ses dépendances. Officiellement, aucune preuve de compromission de produits ou de données utilisateur. Mais la boîte a quand même rotaté toutes ses clés de signature applicative sur macOS, iOS, Windows, Android, et republie l’intégralité de ses apps sous nouveaux certificats.

Inutile de te dire que tu ne fais pas ça quand tout va bien.

Apple a réagi le lendemain. Sans communiqué, sans notification, sans onglet dans Réglages. Une signature XProtect a été poussée silencieusement. Les Macs l’ont récupérée au fil des heures, chacun son tour, sans prévenir personne.

XProtect, l’antivirus muet d’Apple

XProtect, c’est l’antivirus intégré de macOS. Il est là depuis Snow Leopard, et la plupart des utilisateurs ignorent jusqu’à son existence. C’est voulu.

Le système fonctionne en deux briques. La première, c’est le moteur de signatures : un fichier que macOS consulte avant d’exécuter une app téléchargée pour vérifier qu’elle ne correspond pas à un malware connu. La deuxième, c’est XProtect Remediator — XPR —, un scanner qui tourne en tâche de fond et inspecte ton disque à la recherche de menaces déjà installées. Quand il en trouve une, il la neutralise.

Les signatures sont poussées par Apple via CloudKit, le même tuyau silencieux qui synchronise tes photos iCloud et ton trousseau. Quand un malware significatif émerge, Apple compile une signature, la signe, la dépose sur CloudKit. Ton Mac la récupère au prochain check, généralement dans les 24 à 72 heures.

Pas de notification. Pas de redémarrage. Pas de message “votre Mac a été mis à jour”. Apple a fait un choix éditorial assumé, ne pas affoler l’utilisateur. Le revers, c’est que tu n’as aucun moyen de savoir, à l’œil nu, si tu es bien patché pour l’incident récent.

C’est là que ça devient intéressant.

Le push 5344, le 12 mai, lendemain de TanStack

La version XProtect publiée le 12 mai 2026 s’appelle 5344. La précédente, 5342, datait du 5 mai. Concordance temporelle parfaite avec TanStack, à J+1.

Sauf qu’Apple ne documente jamais publiquement le contenu d’une signature XProtect. Howard Oakley, qui décortique chaque release sur eclecticlight.co, observe sur 5344 « quelques ajustements sur des familles de malware connues ». Pas de signature nommée TanStack ou Shai-Hulud. Rien qui dise officiellement « ceci est la réponse à l’incident d’hier ».

Coïncidence ou réaction ciblée ? Apple ne dit rien. C’est précisément ce flou qui justifie qu’on regarde dedans.

Vérifier en 30 secondes que ton Mac est patché

Sur macOS 15 Sequoia et macOS 26 Tahoe, Apple a déplacé XProtect dans un nouvel emplacement et fournit une commande native. C’est la voie recommandée. Sur macOS 14 Sonoma et antérieurs, l’ancien emplacement reste valide. Je donne les deux.

1. La version des signatures XProtect

Sur Sequoia et Tahoe, la commande de référence :

sudo xprotect version

Tu obtiens un numéro du genre 5344 ou 5347. C’est la base de signatures. Plus c’est haut, plus c’est récent.

Sur Sonoma et antérieurs :

defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info CFBundleShortVersionString

L’ancien chemin existe encore sur Sequoia et Tahoe, mais ce n’est plus celui que macOS consulte en premier. Tu peux le lire et tomber sur une version périmée pendant que sudo xprotect version te donne la vraie. C’est exactement le genre de piège qui fait croire à un Mac à la traîne alors qu’il est à jour.

2. La version de XProtect Remediator

defaults read /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/Info CFBundleShortVersionString

Tu obtiens un numéro du genre 157. C’est le scanner lui-même, mis à jour beaucoup moins souvent que les signatures.

3. L’historique d’installation

system_profiler SPInstallHistoryDataType | grep -A 2 -i xprotect

Tu vois toutes les versions XProtect installées avec leurs dates. Pratique pour vérifier que tu n’as pas un Mac coincé sur une vieille base parce que CloudKit a un problème.

Pour comparer ta version à ce qu’Apple publie en temps réel, le tracker public d’Howard Oakley, eclecticlight.co, maintient la liste à jour. Oakley est un ingénieur britannique qui décortique macOS depuis quinze ans, c’est la référence sur le sujet.

Et si ton Mac traîne, tu forces le check :

sudo xprotect update

Sur Sonoma et antérieurs, l’ancienne commande sudo softwareupdate --background-critical reste opérationnelle.

Au moment où je publie, la dernière version est 5344, le 12 mai 2026. Si ton Mac affiche moins, ton canal CloudKit traîne.

Le revers souverain

XProtect, c’est une boîte noire signée Cupertino. Tu ne sais pas quelles signatures sont poussées, tu ne sais pas quelle télémétrie remonte au passage, tu ne sais pas qui décide qu’un binaire est malveillant. Apple décide, Apple pousse, ta machine exécute.

Le mécanisme est utile, très utile même. Bloquer des malwares connus avant qu’ils s’exécutent, c’est la base d’une défense moderne, et le faire sans te solliciter évitera que tu le désactives le jour où t’es fin énervé par cette rognutudju!! de pop-up (cherche pas, si t’as moins de 50 berges, t’as pas la ref).

Les trois commandes ci-dessus te donnent un droit de regard minimal sur ce que ton OS fait sans te demander. C’est un petit pas vers la souveraineté, pas reprendre le contrôle, juste savoir.

La différence entre un utilisateur passif et un utilisateur souverain n’est pas que dans les outils utilisés. Elle est aussi dans les questions qu’il se pose. Quelle version j’ai. Quand a-t-elle été poussée. Qu’est-ce qu’elle contient.

Apple répond aux deux premières en trois lignes Terminal. Sur la troisième, elle se tait. C’est Howard Oakley qui décortique le contenu après coup et publie les diffs sur eclecticlight.co. Tu ne sauras jamais en direct ce qu’Apple a estampillé malveillant cette nuit.

Tous les mois, je vérifie tout de même les versions XProtect sur mes Macs. Rien d’héroïque, juste une habitude. Le jour où le canal CloudKit déconne, j’aurai un point de référence.

À lire : Les paramètres macOS à changer immédiatement

En résumé

XProtect est utile, silencieux, et hors de ton contrôle. Le sujet est de savoir qu’il existe, de connaître les trois commandes qui te disent où tu en es, et de comprendre que dans la chaîne d’approvisionnement JavaScript de 2026, comme dans d’autres chaînes de compromission, c’est lui qui colmate les fuites.

Lance les trois commandes. Note tes numéros. Compare-les à eclecticlight.co de temps en temps. Ça prend trente secondes, et ça te permet de savoir si tu es bien patché et à jour.

À lire : Lockdown Mode face à Coruña, le toolkit d’espionnage gouvernemental

Des termes techniques ? Consulte le glossaire.

kSuite vs Google Workspace, le comparatif honnête

Mac Souverain — Sun, 10 May 2026 14:27:21 GMT

Introduction

Tu paies tous les mois pour Google Workspace. Tu lis MacSouverain et tu te sens concerné par ta Privacy. À un moment, la dissonance devient gênante.

La question n’est pas “Workspace, c’est mauvais ?”. Workspace marche très bien, c’est même la référence. La question, c’est : qu’est-ce que tu paies au juste, et qu’est-ce que tu lui donnes en échange. Et est-ce qu’il existe une alternative qui te rend ton Mac, ta juridiction et tes données sans te coller un downgrade fonctionnel.

kSuite, édité par Infomaniak depuis Genève, se vend exactement sur cette promesse. On va regarder si elle tient.

Les critères qui comptent

Comparer deux suites collaboratives sans grille, c’est faire une publi-rédactionnelle. Voici les six critères que j’ai retenus, et ce que j’ai délibérément écarté.

Juridiction et souveraineté des données. Où sont stockées les données, sous quelle loi, qui peut y accéder par voie légale. Ce critère prime sur tout le reste pour MacSouverain, parce qu’il est structurel et non négociable à coups de feature.

Chiffrement réel. Pas “chiffré” en général. At-rest, in-transit, et surtout end-to-end : qui détient les clés. C’est la seule grille qui résiste à une réquisition.

Prix et lisibilité. Combien tu paies par utilisateur, ce que tu obtiens, ce qui change quand l’éditeur fait du “pricing update”.

Intégration native macOS et iOS. Apple Mail, Calendar, Contacts, Files. Est-ce que tu peux travailler sans installer une seule app de l’éditeur sur ton Mac. C’est le marqueur “souverain pratique”.

Couverture fonctionnelle pro. Mail pro, drive partagé, visio, docs collaboratifs, console admin, SSO, MDM. Une suite qui te force à en garder une autre à côté, c’est une demi-suite.

Sortie possible. Export, formats standards, import depuis le concurrent. Tu n’es pas mariée à ton fournisseur cloud, sauf si tu acceptes de l’être.

Ce que je n’ai PAS évalué : les usages très spécifiques (Workspace for Education, conformité HIPAA US, FedRAMP). Si tu es un hôpital américain, ce comparatif n’est pas pour toi. Si tu es une PME européenne, un freelance ou un family office, on continue.

kSuite, par Infomaniak

La philosophie en deux phrases. Une suite collaborative éditée par un hébergeur suisse de 316 personnes, employee-owned, certifié ISO 27001 et 14001, qui opère ses propres datacenters à Genève et Winterthur. Pas un revendeur qui pose une UI sur des briques tierces, un éditeur vertical intégré.

Les forces.

Suisse, nFADP, hors CLOUD Act. Infomaniak est sous juridiction suisse, régie par la nouvelle Loi fédérale sur la protection des données (nFADP, en vigueur depuis le 01/09/2023). Pas de CLOUD Act applicable. La Suisse bénéficie d’une décision d’adéquation UE pour transferts RGPD. Pour un client UE ou simplement attaché à ce que ses données ne fassent pas escale juridique à Washington, ça se passe d’argument complémentaire.

OpenPGP intégré, gratuit, transparent dans kMail. Infomaniak a activé le chiffrement E2E par OpenPGP côté webmail kMail le 17 juin 2025, pour tous les plans, sans add-on. Tu actives, tu échanges des clés avec ton correspondant, tes mails sont chiffrés bout en bout. Côté suites grand public, seuls Proton et kSuite offrent OpenPGP gratuit dans le webmail. Google Workspace, Microsoft 365 et Zoho réservent leur chiffrement natif aux plans Enterprise.

OnlyOffice sous le capot des Docs, Grids, Points. Le moteur de bureautique de kSuite, c’est OnlyOffice, AGPLv3, open source. Compatibilité haute fidélité avec .docx, .xlsx, .pptx, mieux que Google Docs sur les fichiers Office natifs. Si ton comptable t’envoie un .xlsx avec des macros et une mise en page tordue, OnlyOffice le rend correctement.

Protocoles ouverts partout. IMAP, SMTP, CalDAV, CardDAV, WebDAV. Tu configures Apple Mail, Calendar, Contacts et Files.app sans installer un seul exécutable Infomaniak sur ton Mac. C’est rare, et c’est le critère d’intégration le plus pur qu’une suite cloud puisse cocher.

kMeet avec E2E optionnelle, gratuite. Visioconférence WebRTC avec une option de chiffrement bout en bout activable à la création de la réunion (clé partagée), documentée par Infomaniak. Limitée aux navigateurs Chromium et à l’app desktop, mais existante. Côté Workspace, l’équivalent (CSE) demande Enterprise Plus.

Pricing lisible et stable. kSuite Pro à 7,90 €/utilisateur/mois pour 3 To de stockage et le mail pro complet. Pas de hausse documentée depuis le lancement en 10/2022. La promesse tarifaire tient.

Les faiblesses.

MDM et Apple Business Manager : le trou dans la raquette. Pas d’intégration ABM officielle pour kSuite. Si tu déploies une flotte d’iPhone et de Mac d’entreprise avec federated authentication via Managed Apple ID, Workspace le fait nativement. Côté kSuite, tu passes par un MDM tiers (Jamf, Mosyle, Kandji) avec auth IMAP/CalDAV classique. Ça marche, c’est moins intégré.

Marketplace tiers limitée. Workspace Marketplace, c’est plus de 4 500 apps connectées. kSuite, c’est essentiellement la suite Infomaniak et quelques intégrations standards. Si ton workflow dépend de quinze SaaS qui se branchent sur Google Calendar, prévois une transition.

Apps mobiles : solides, pas références. Infomaniak Mail et kDrive iOS sont propres, mais Gmail et Google Drive iOS restent les références UX du marché. C’est un écart d’expérience, pas un blocage.

Coédition temps réel : bonne, pas excellente. OnlyOffice gère la coédition multi-utilisateurs, mais Google Docs reste la référence absolue sur la latence et l’undo collaboratif. Si tu fais de la rédaction simultanée à six dans le même document toute la journée, tu sentiras la différence. Sinon non.

Euria vs Gemini. Infomaniak a son IA souveraine (Euria) pour transcription kMeet et assistance. C’est honnête, ce n’est pas Gemini. Si l’IA bureautique poussée est ton critère principal, Workspace gagne ce point sans appel.

Pour qui. Le freelance, la PME, le family office, le cabinet libéral qui veut une suite pro complète sans CLOUD Act et sans installer une app propriétaire de plus sur son Mac. Le profil MacSouverain, en somme.

Prix HT (extraits, vraie page éditeur sur infomaniak.com/en/ksuite/ksuite-pro/prices).

my kSuite : gratuit, 20 Go, 1 adresse @ksuite.infomaniak.com, kMeet inclus. Pas de domaine perso.
my kSuite+ : CHF 5,75/mois, 2 To, 1 domaine + 5 alias.
kSuite Standard : 1,90 €/utilisateur/mois, 15 Go par user, mail pro avec domaine.
kSuite Pro : 7,90 €/utilisateur/mois, 3 To par user, mail pro + alias, SSO SAML.
kSuite Enterprise : 14,90 €/utilisateur/mois, 6 To par user, admin avancée.

Google Workspace, par Google LLC

La philosophie en deux phrases. La suite collaborative qui a redéfini le standard depuis 2006. Référence du marché sur Gmail, Docs, Sheets et Meet, intégrée avec à peu près tous les SaaS du monde, sous juridiction US et CLOUD Act.

Les forces.

Le mail anti-spam de référence. Gmail filtre mieux que tout le monde, point. Quinze ans de feedback machine learning sur des milliards de messages, ça se rattrape mal. Si tu changes de fournisseur mail, ton dossier spam va te manquer pendant deux mois.

Coédition Docs, Sheets, Slides. L’inventeur du genre est aussi le maître du genre. Latence, suggestions, mentions, historique granulaire : Workspace bureautique en ligne reste la référence, et toutes les autres suites se mesurent à elle.

Écosystème tiers gigantesque. Workspace Marketplace, 4 500+ apps. Ton CRM, ta facturation, ton outil RH, ton ATS : tous ont un connecteur Google natif. Pour kSuite, prévois des intégrations CalDAV/IMAP à la main quand l’app tierce le permet, ou rien quand elle ne le permet pas.

Apple Business Manager officiel. Federated authentication avec Managed Apple ID, DEP token, déploiement MDM Workspace Endpoint Management qui couvre macOS, iOS, ChromeOS, Android, Windows. Pour une PME qui gère une flotte hétérogène, c’est un argument opérationnel réel.

Gemini AI intégré dans tous les plans. Depuis le 17/03/2025, Google a bundle Gemini dans le tarif core de Workspace. NotebookLM, Gemini in Docs, Gemini in Sheets, transcription Meet : c’est puissant, et c’est dispo sans add-on supplémentaire.

Vault, eDiscovery, DLP, audit BigQuery. Si ton métier a des obligations de rétention légale, de legal hold, de Data Loss Prevention sérieuse, Workspace Plus et Enterprise sont matures sur ces sujets depuis dix ans. kSuite a des audit logs, pas la pile réglementaire complète.

Les faiblesses.

CLOUD Act, l’argument structurel. Google LLC est une entreprise US, soumise au CLOUD Act 2018, qui autorise les autorités américaines à exiger d’un fournisseur sous juridiction US la communication de données stockées n’importe où dans le monde. “Datacenter européen” ne change rien : Microsoft France l’a confirmé sous serment au Sénat, la juridiction prime sur la localisation. Workspace n’est pas qualifié SecNumCloud par l’ANSSI. Le partenariat Thales S3NS pour porter une qualif est en cours, Workspace lui-même ne la porte pas.

Hausse en 03/2025, bundle Gemini imposé. Google a augmenté le tarif core de tous les plans Workspace en intégrant Gemini dans le forfait : +16,7 % sur Business Starter et Standard (annuel), +22,2 % sur Business Plus. Tu n’as pas d’IA générative dans ton workflow ? Tu paies quand même. C’est la deuxième hausse globale après celle de 2023, le pricing Workspace est en hausse continue.

Chiffrement E2E réservé à Enterprise Plus. S/MIME hosted et CSE (Client-Side Encryption) sont disponibles uniquement en Enterprise Plus et Education Plus, avec un KMS externe à configurer (Thales, Fortanix, Stormshield, Flowcrypt). Sur Business Starter, Standard et Plus, tu as TLS in-transit et AES-256 at-rest avec clés Google. Ce n’est pas E2E.

Apps natives Apple : ça marche, sans plus. Apple Mail avec Google Account fonctionne, mais les labels Gmail deviennent des dossiers IMAP, l’expérience est dégradée. CardDAV est officiellement déprécié par Google au profit de People API (toujours fonctionnel via Google Account natif iOS, mais signal long terme). En pratique, l’utilisateur Workspace finit par ouvrir Gmail web et l’app Drive iOS : l’argument “100 % apps natives Apple” tombe.

Verrouillage Gmail. Les labels, les filtres, la catégorisation Gmail sont spécifiques. Google Takeout exporte tout (.mbox, EML), mais le reformatage côté nouveau fournisseur n’est pas trivial. Tu peux sortir, ce ne sera pas confortable.

Données clients vs entraînement IA. Google s’engage contractuellement à ne pas utiliser les données Workspace B2B pour entraîner Gemini. C’est un engagement contractuel, évolutif, distinct de l’engagement commercial Gmail grand public (qui lui, partage des signaux). À surveiller dans le temps.

Pour qui. L’entreprise dont les workflows critiques dépendent du Marketplace, le grand groupe avec besoins eDiscovery sérieux, le client US où la conformité locale impose les certifications Google, l’équipe déjà installée qui n’a aucun argument opérationnel pour bouger.

Prix HT (annuel, page éditeur workspace.google.com/pricing).

Business Starter : 6,80 €/user/mois (annuel), 30 Go par user, Meet 100 participants, max 300 users.
Business Standard : 13,60 €/user/mois, 2 To pooled, Meet 150 + enregistrement.
Business Plus : 21,10 €/user/mois, 5 To pooled, Vault eDiscovery, Meet 500.
Enterprise : sur devis, 5 To+, Meet 1 000, CSE, DLP avancé.

Promo de lancement 50 % les 3 premiers mois sur les 20 premiers utilisateurs, ensuite tarif standard.

Tête-à-tête sur les critères qui comptent

Plutôt qu’un tableau qui aplatit tout au même niveau, regardons les six critères l’un après l’autre.

Juridiction et souveraineté

kSuite est suisse, sous nFADP, hébergée en Suisse (datacenters Genève et région Zurich), hors CLOUD Act, hors RGPD (mais décision d’adéquation UE valide). Workspace est US, sous CLOUD Act, datacenters mondiaux avec option “data regions” Europe en plans Enterprise. Sur ce critère, ce n’est pas un comparatif, c’est une différence de nature. Si la juridiction est décisive pour toi, le sujet est déjà clos.

Chiffrement réel

kSuite : OpenPGP E2E natif et gratuit dans kMail, E2E optionnelle dans kMeet, AES-256 at-rest sur kDrive avec clés Infomaniak. Pas d’E2EE drive natif. Workspace : TLS et AES-256 at-rest partout, S/MIME hosted et CSE en Enterprise Plus uniquement, BYOK avec KMS externe en Enterprise Plus. Pour le mail, kSuite gagne nettement, et gratuitement. Pour le drive, les deux te demandent un compromis : Infomaniak garde les clés, ou tu paies Workspace Enterprise Plus pour avoir CSE.

Prix et lisibilité

À tier équivalent, kSuite est moins cher partout. Solo 2 To : my kSuite+ à 5,75 contre Business Starter à 6,80 € pour 30 Go (un facteur 70 sur le stockage). PME standard : kSuite Pro à 7,90 € contre Business Standard à 13,60 € (kSuite 42 % moins cher, 50 % de stockage en plus). PME premium : kSuite Enterprise 14,90 contre Business Plus 21,10 € (kSuite 29 % moins cher). Et le pricing Workspace monte, celui de kSuite ne bouge pas depuis 10/2022.

Intégration native macOS et iOS

kSuite expose IMAP, SMTP, CalDAV, CardDAV, WebDAV. Apple Mail, Calendar, Contacts, Files.app fonctionnent en natif sans une seule app propriétaire installée. C’est le scénario “100 % Apple” pur. Workspace fonctionne aussi nativement, mais l’expérience réelle pousse l’utilisateur vers Gmail web et Drive iOS. Sur le critère “ne rien installer de l’éditeur”, kSuite gagne sans bouger ; sur le critère “expérience polie”, Workspace garde la main avec ses propres apps.

Couverture fonctionnelle pro

Les deux suites couvrent mail, drive, agenda, contacts, visio, docs collaboratifs, console admin, SSO. Workspace ajoute MDM natif, ABM officiel, Marketplace 4 500 apps, DLP avancé, Vault eDiscovery. kSuite ajoute OnlyOffice haute fidélité, OpenPGP gratuit, kMeet E2E. Sur la couverture pure, Workspace a plus de profondeur ; sur la souveraineté fonctionnelle, kSuite a un cran d’avance.

Sortie possible

kSuite exporte EML, MBOX, vCard, iCal, fichiers natifs OnlyOffice. Workspace exporte via Takeout (mbox, vCard, ics, .docx via conversion). Les deux te laissent partir. kSuite te facilite l’arrivée : un import Workspace intégré est documenté dans la console Manager. L’inverse (sortir de Workspace vers autre chose) marche techniquement mais n’est pas guidé.

Recommandation Mack

Je vais le dire clairement parce que c’est mon job : si tu as le choix, kSuite est meilleur que Workspace pour ta Privacy.

Pas parce que Workspace est mauvais. Workspace est une excellente suite collaborative. Mais le profil MacSouverain n’est pas l’utilisateur médian de Workspace. Le lecteur de ce site, c’est un freelance, une PME européenne, un family office, un indépendant qui paie pour un service et qui veut savoir qui peut lire ses fichiers, qui peut forcer à les communiquer, et ce qui se passe le jour où un audit arrive. Sur ces trois questions, Workspace répond “Google, le CLOUD Act, on s’en occupe”, et kSuite répond “toi, personne, et un fichier d’export EML”, totale Privacy.

Si tu es freelance ou solo et que le budget compte. my kSuite+ à CHF 5,75/mois pour 2 To, c’est un choix évident face à Business Starter et ses 30 Go.

Si tu es PME 5-50 personnes en Europe. kSuite Pro à 7,90 €/user. Tu économises 42 % par rapport à Business Standard, tu gardes ton mail pro avec domaine, tu peux configurer Apple Mail et Calendar sur toute la flotte sans installer une app, et tu sors du CLOUD Act. La seule question à poser : ta flotte a-t-elle un besoin de MDM fédéré via ABM. Si oui, évalue sérieusement le coût d’un Mosyle ou d’un Jamf en complément.

Si tu es déjà sur Workspace avec tout ton workflow branché dessus. Une migration coûte. Tu n’as pas à la faire ce trimestre. Mais il y a deux moments où la repenser fait sens : à chaque hausse de prix Workspace (la prochaine arrivera), et au moment où un workflow critique casse à cause d’un changement Google. Ces deux moments arrivent, statistiquement.

Si tu es family office en Suisse, en Allemagne ou ailleurs en UE et que la juridiction US te dérange. Tu ne paies pas un cloud américain pour stocker ta correspondance pro et tes documents financiers, c’est aussi simple que ça. kSuite est la réponse la plus courte.

Pour mon usage perso, j’ai fait un autre choix, Proton Workspace, qui rend la même promesse de souveraineté sous un autre angle (E2E partout par défaut, écosystème Proton complet). Si tu hésites entre les deux mondes souverains, retiens la grille : kSuite a la longueur d’avance sur l’intégration Apple native pure (CalDAV, CardDAV, IMAP standards) et OnlyOffice haute fidélité ; Proton a l’avance sur le E2E systématique et l’app suite cohérente. Aucun des deux ne te ramène au CLOUD Act, c’est l’essentiel.

En résumé

kSuite est moins chère à tier équivalent, plus souveraine par construction (Suisse, nFADP, employee-owned, ISO 27001), expose des protocoles ouverts qui rendent les apps natives Apple pleinement utilisables, et inclut le chiffrement OpenPGP gratuit dans le mail. Workspace est plus polie sur Gmail, Docs et l’écosystème tiers, plus intégrée avec Apple Business Manager, et beaucoup plus mature sur les sujets Vault et DLP, au prix d’une juridiction US et d’une hausse continue.

Concrètement :

Freelance ou solo, budget compte → my kSuite+ à CHF 5,75/mois.
PME européenne 5-50 personnes → kSuite Pro à 7,90 €/user/mois, avec un MDM tiers si besoin fédéré.
Workflow Workspace critique déjà en place → reste, prépare la migration au prochain pricing update.
Conformité réglementaire US lourde → reste sur Workspace.
Family office UE, juridiction non négociable → kSuite, sans hésiter.

Sources

Les éditeurs eux-mêmes

Infomaniak, l’hébergeur suisse de Genève, employee-owned, qui édite kSuite depuis 10/2022. Page produit, prix et certifications ISO 27001 / 14001 / 50001 publics.
Google Workspace, Mountain View, sous juridiction US et CLOUD Act. Page pricing, security whitepaper, ISO 27001 publics.

La doc technique

Annonce OpenPGP gratuit dans kMail, reprise par Yahoo Finance le 17 juin 2025.
Apple Business Manager × Workspace, guide officiel Apple, fédération Managed Apple ID native côté Google, pas côté kSuite.

Les analyses indépendantes

Wire, CLOUD Act vs souveraineté UE, l’éditeur suisse de messagerie chiffrée explique pourquoi un datacenter européen ne suffit pas si l’entreprise est US.
9to5Google, hausse Workspace 03/2025, la presse tech qui a documenté le bundle Gemini imposé et la grille tarifaire actualisée.

Voir aussi

Souveraineté digitale, en pratique : la grille générale dont kSuite est un cas d’application.
Le cloud, c’est l’ordinateur de quelqu’un d’autre : le cadre mental qui sous-tend ce comparatif.
DNS, le talon d’Achille de ta privacy : même logique de juridiction sur une autre couche.

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

Mac Souverain — Tue, 05 May 2026 11:57:32 GMT

MAJ juillet 2026. dns0.eu, le résolveur DNS chiffré européen que Little Snitch proposait en preset, a fermé fin mai 2026 (ressources insuffisantes). Little Snitch l’a basculé sur DNS4EU, et l’article suit, on te renvoie désormais vers DNS4EU ou Quad9.

Mise à jour, 2 juillet 2026. Little Snitch est passé en 6.4.1 (juin 2026) : déverrouillage des réglages verrouillés par Touch ID, copie de règles entre profils au glisser-déposer, mises à jour horaires des listes de blocage. La 6.4.1 corrige un rejet d’anciennes licences. Le verdict du comparatif ne bouge pas, les versions de référence ci-dessous sont à jour.

Introduction

Pendant que tu lis cet article, ton Mac parle. À quarante-sept serveurs, sans te demander ton avis. Apple iCloud, Adobe, Microsoft Telemetry, l’app météo qui réveille un CDN à Singapour, le mini-jeu Solitaire qui poste tes scores chez un éditeur que tu ne connais pas.

Personne, ou presque, ne regarde la sortie réseau de ses données.

C’est là que le pare-feu sortant sur Mac entre en scène. Pas l’ALF intégré (Application Firewall, qui ne filtre que l’entrée), pas pf (puissant mais aveugle au process). Un vrai pare-feu sortant process-aware, qui te dit “tel binaire essaie de joindre tel domaine, tu autorises ?”. Sur macOS, deux outils dominent : Little Snitch (payant, closed-source, viennois) et LuLu (gratuit, open source, américain, signé Patrick Wardle).

À lire : Les réglages privacy macOS à changer en 15 minutes

Pourquoi un pare-feu sortant process-aware

Pare-feu sortant en deux phrases. Un logiciel qui intercepte les connexions sortantes de tes apps avant qu’elles partent vers Internet et te demande “j’autorise ou je bloque ?”. Le pare-feu entrant fait l’inverse, il filtre ce qui rentre depuis le réseau. Little Snitch et LuLu jouent côté sortant uniquement, c’est leur job.

macOS livre nativement deux couches de sécurité. ALF (Application Layer Firewall) filtre les connexions entrantes. XProtect et MRT scannent les binaires connus comme malveillants. C’est ce que tu as out-of-the-box.

Si tu veux du sérieux, tu en empiles d’autres par dessus, à ta charge : Santa (NorthPoleSec, OSS) pour bloquer les exécutables non whitelistés, Wazuh pour remonter les événements vers un SIEM, et précisément ce dont parle cet article, un pare-feu sortant process-aware. Toutes ces couches, natives ou ajoutées, font ce qu’elles doivent faire, en se complétant.

Une app peut être signée, validée par Apple, exécutée par un user légitime, et envoyer ton carnet d’adresses à un serveur tiers. ALF ne voit rien (c’est de la sortie). Santa ne voit rien (le binaire est autorisé à s’exécuter). XProtect ne voit rien (le binaire n’est pas dans la base malware). C’est exactement le rôle d’un pare-feu sortant process-aware : combler ce trou. Filtrer non par adresse IP, mais par process et par destination, avec un verdict allow/drop par connexion.

Sur macOS, depuis Big Sur, ces outils utilisent tous le framework Apple NEFilterDataProvider (Network Extension). Plus de kernel extension à charger, plus de risque de kernel panic lié à un kext tiers. C’est Apple qui maintient le chemin réseau, l’outil tiers ne fait que rendre un verdict.

Les protagonistes

Little Snitch 6.4.1

Édité par Objective Development Software GmbH, à Vienne, Autriche, depuis 2003. Vingt-deux ans d’âge, équipe stable, zéro rachat, zéro pivot. Licence perpétuelle, closed-source propriétaire. Un seul incident de sécurité connu (faille de code-signing en 2018, fix livré avant la disclosure publique de Patrick Wardle). Depuis la v5 (2020), plus de kernel extension, uniquement Network Extension Apple. Version actuelle : 6.4.1, sortie le 22 juin 2026, supporte macOS Sonoma, Sequoia et Tahoe. UI en anglais et allemand. Pas de français.

LuLu 4.3.2

Développé par Patrick Wardle, fondateur d’Objective-See (États-Unis), depuis 2017. Wardle est une référence mondiale sécurité Mac : ex-NSA, créateur du Mac Malware Project, intervenant régulier à Black Hat, DEFCON et Objective by the Sea. Open source, GPL-3.0, sources publiques sur GitHub, binaire compilable maison. Modèle 100 % gratuit, financé par dons via Patreon (pas de freemium, pas de tier payant). Version actuelle : 4.3.2, sortie le 3 mai 2026. Supporte macOS 10.15+, Tahoe inclus depuis la 4.0. UI principalement en anglais.

Ce qu’ils font, ce qu’ils ne font pas

Prompts Little Snitch (gauche) et LuLu (droite). Captures officielles obdev.at et objective-see.org. © Objective Development et © Objective-See, GPL-3.0.

Cœur produit partagé. Les deux sont des pare-feu sortants process-aware bâtis sur le même framework Apple NEFilterDataProvider, donc le chemin réseau est dicté par macOS, pas par l’éditeur. Ni l’un ni l’autre ne fait de filtrage entrant, ils laissent ça à ALF natif. Versions de référence ici : Little Snitch 6.4.1 (sortie le 22 juin 2026, premier macOS Tahoe 26 supporté côté LS depuis la 6.3) et LuLu 4.3.2 (sortie le 3 mai 2026, GPL-3.0). Apple Silicon natif des deux côtés.

Granularité des règles. Little Snitch te laisse cibler par process, domaine, port, protocole, interface réseau, horaire et profil. LuLu te laisse cibler par process, domaine ou IP, scope (process spécifique ou global), et durée. La différence n’est pas cosmétique : un horaire (autorise Spotify entre 8h et 22h, par exemple), un port précis, ou encore un profil dédié au train, c’est sur LS uniquement.

Profils réseau. LS bascule automatiquement sur le SSID Wi-Fi ou l’interface (réseau de confiance vs réseau public, profil VPN adapté au contexte). C’est l’argument MacBook nomade qui n’a pas d’équivalent. LuLu a des profils depuis la 4.0, mais le switch est manuel. Tu choisis avant de te connecter, ou tu as oublié.

DNS chiffré intégré. LS livre du DoH, DoT, DoQ vers Quad9, Cloudflare, DNS4EU, Google (tu auras compris que ce n’est pas le choix MS), en option directe dans la conf de l’app. Tu n’as plus besoin d’un profil système séparé pour le DNS chiffré. LuLu a un toggle “Allow DNS Traffic” basique sur UDP:53, le DNS chiffré n’est pas son problème, à toi de gérer en amont (dnscrypt-proxy, AdGuard, etc.). Et attention au conflit Network Extension décrit plus bas.

Wildcard DNS et le piège Chrome. LS gère les re-routages CDN type Akamai ou iCloud sans casser les règles, parce qu’il fait de la résolution wildcard côté domaine. LuLu n’a pas le wildcard côté hostname (issue GitHub #379, demandée depuis longtemps, pas implémentée). Conséquence sérieuse côté Chrome : Chrome n’utilise pas Network.framework Apple pour ses résolutions DNS, donc avec LuLu, le blocage par hostname est inopérant sur Chrome, fallback IP-only seulement (issue #410). Si tu vis dans Chrome, c’est une limite produit majeure, peu connue.

Network Monitor live et Research Assistant. LS a une map réseau temps réel, un graphe de trafic 5 min, un inspector connexion par connexion, et un Research Assistant qui te dit ce que la communauté a déjà jugé pour ce process (réduit la fatigue whitelist). LuLu a Netiquette comme outil annexe, à lancer séparément, pas intégré au prompt. Pas de base communautaire de réputation.

Petits trucs qui s’additionnent. LS a un mode silencieux (auto-allow ou auto-deny pendant un meeting, une présentation), des blocklists intégrées (trackers, pubs, malwares, MAJ quotidienne), des notifications acoustiques configurables par règle, des règles bidirectionnelles depuis LS 6, l’identification du process par signature de code (résiste au remplacement par un faux binaire au même chemin), et des statistiques d’usage par règle.

LuLu n’a pas le mode silencieux automatisé (issue #540), pas de blocklist native, pas de sons, pas de bidir (sortant uniquement par design), identifie le process par chemin (plus fragile), et ne stocke pas de stats.

CLI et automatisation. LS livre une CLI mature littlesnitch avec export-model, restore-model, diagnostics, switch-profile, write-rules. Tu peux backup ton modèle de règles, le versionner, et le restaurer sur un autre Mac (avec mapping users si différents et mot de passe Keychain si export chiffré). Format JSON natif côté backup, format .lsrules JSON côté subscription rule sets, les deux Git-friendly.

LuLu n’a pas de CLI officielle, le format des règles est un plist binaire fragile, l’export user rules existe depuis 4.2.1 mais reste moins normalisé. Pour une fleet de plusieurs Macs gérée en infra-as-code, l’écart est direct.

Logs et SIEM. LS écrit dans un subsystem at.obdev.littlesnitch (unified log macOS), plus une DB SQLite locale exploitable, plus un decoder Wazuh propre à écrire en quelques lignes. LuLu écrit dans os_log sans subsystem documenté, donc le tail Wazuh côté manager demande plus de regex et moins de structure. Si tu remontes tes événements vers un SIEM (Wazuh, Splunk, Elastic), LS te donne de la matière propre, LuLu te donne du best effort.

Limite macOS commune. Un seul provider de filtrage actif à la fois sur le système. Activer LS, ou LuLu, ou un profil DNS chiffré tiers (NextDNS par exemple), pas les trois. C’est une contrainte Apple, pas un défaut produit. LS contourne en intégrant son DNS chiffré, LuLu non.

Cycles de release. LS, régulier, 6.3.1, 6.3.2, 6.3.3 sur septembre-novembre 2025 puis 6.4 et 6.4.1 en juin 2026, équipe stable depuis 22 ans. LuLu, plus erratique, 4.2.0 en octobre 2023, 4.3.0 en mars 2026, 4.3.2 en mai 2026, projet maintenu sur le temps disponible de Wardle et de la fondation Objective-See. Aucun des deux n’est en français côté UI.

Score brut : Little Snitch couvre environ 22 fonctionnalités natives complètes sur 24 vérifiées. LuLu en couvre environ 10 complètes, 5 partielles, 9 absentes.

L’écart est franc. Et il ne disparaîtra pas avec la prochaine release de LuLu : certaines absences (CLI, DNS chiffré, Network Monitor intégré) sont des choix architecturaux, pas des oublis.

Souveraineté : LuLu gagne

C’est le point le plus mal compris du débat francophone, donc on va être direct.

LuLu est plus souverain que Little Snitch. Point.

Pourquoi ? Trois raisons qui s’empilent.

1. LuLu est open source GPL-3.0. Le code intégral est sur GitHub. Tu peux le lire, l’auditer, le compiler toi-même, le forker. Aucune backdoor n’est insérable sans laisser de trace publique. Aucun kill-switch éditeur n’est possible sans qu’un chercheur le repère. Aucune télémétrie cachée ne tient face à un grep sur les sources. C’est le modèle de confiance vérifiable, pas le modèle de confiance déléguée.

2. Little Snitch est closed-source propriétaire. L’éditeur viennois peut être impeccable (et il l’est, depuis 22 ans), tu n’as aucun moyen de le vérifier autrement qu’en lui faisant confiance. La signature Apple garantit que le binaire vient bien d’Objective Development. Elle ne garantit rien sur ce que ce binaire fait. Aucun audit indépendant formel n’a été publié sur Little Snitch (ni sur LuLu d’ailleurs). À ce jeu, l’OSS auditable l’emporte sur le closed-source non audité.

3. L’argument “Wardle est américain donc juridiction US” ne tient pas. Un argument circule depuis la sortie de la version Linux gratuite de Little Snitch en 2025, surtout côté marketing obdev : LuLu serait américain, donc moins souverain que LS qui est viennois. C’est faux, ou au mieux trompeur. Pour une raison simple : le code de LuLu est public, GPL-3.0, compilable maison. Aucune injonction américaine ne peut forcer Wardle à insérer une backdoor sans que la communauté la repère au prochain commit. Le binaire que tu compiles depuis tes sources locales n’a plus aucun lien juridictionnel avec Wardle. C’est précisément ce que l’OSS auditable rend impossible : la prise juridictionnelle non détectable. Pendant ce temps, Little Snitch reste closed-source côté UE, donc l’argument souveraineté s’inverse littéralement quand on regarde l’auditabilité plutôt que le siège social.

Et Wardle n’est pas n’importe qui. Ex-NSA, fondateur d’Objective-See, créateur du Mac Malware Project, conférencier régulier Black Hat et DEFCON, organisateur d’Objective by the Sea. Sa recherche publique a documenté plusieurs bypass des firewalls macOS (BlackHat 2018), ce qui nourrit directement la défense de son propre produit. Sur la couche pare-feu sortant Mac, c’est une autorité.

Verdict souveraineté : LuLu, sans débat. Si la souveraineté est ton critère absolu, l’arbitrage est trivial. Si quelqu’un te vend Little Snitch comme “plus souverain car éditeur UE”, il confond souveraineté juridictionnelle (vraie sur d’autres couches : Proton, DNS4EU) et auditabilité (la vraie question sur du code qui inspecte ton trafic).

LuLu fenêtre des règles, capture officielle objective-see.org. © Objective-See, GPL-3.0.

Fonctionnalités : Little Snitch gagne

Sur l’autre axe, l’écart est tout aussi franc, mais dans l’autre sens.

Cinq fonctionnalités font basculer le choix dès qu’on dépasse l’usage “je veux juste qu’une app arrête de phoner home”.

1. Profils réseau auto-switch sur SSID. Tu es chez toi sur ton Wi-Fi domestique : règles permissives. Tu pousses ton MacBook sur le Wi-Fi d’un café : règles strictes (blocklist trackers activée, DNS chiffré forcé, apps bureautiques restreintes). Tu rentres au bureau : profil pro qui autorise les outils internes. Little Snitch bascule automatiquement sur le SSID. LuLu a des profils, mais le switch reste manuel. Pour un MacBook nomade, c’est un point à considérer.

2. DNS chiffré intégré. DoH, DoT, DoQ, choix du provider (Quad9 en Suisse, DNS4EU en UE, Cloudflare ou Google côté US). LuLu n’en a pas, et c’est plus pénible que ça en a l’air : tu peux toujours installer un profil DNS chiffré tiers (Quad9, DNS4EU), sauf que macOS interdit deux Network Extensions actives simultanément. Donc tu as LuLu, ou ton profil DNS chiffré, pas les deux. Little Snitch contourne en intégrant le DNS chiffré directement dans son extension.

3. Wildcard hostname mature. iCloud, Akamai, Adobe et la plupart des CDN modernes ré-routent constamment leurs IPs. Une règle “autorise *.icloud.com” tient la route. Une règle “autorise 17.X.X.X” se casse à la première rotation. Little Snitch gère les wildcards proprement. LuLu non (issue #379, pas implémenté). Et sur Chrome, qui n’utilise pas le framework réseau Apple natif, LuLu retombe en filtrage IP-only, ce qui veut dire que ton blocage par hostname ne marche plus du tout sur Chrome (issue #410). Limite produit majeure peu connue.

Little Snitch Network Monitor, capture officielle obdev.at. © Objective Development.

4. Network Monitor temps réel. Pendant la phase whitelist, ou pendant un audit, tu veux voir le trafic vivant : qui parle à quoi, quel volume, quelle destination géographique. Little Snitch a une map live et un graphe 5 minutes intégrés à l’app. LuLu propose Netiquette, un outil annexe d’Objective-See, qu’il faut lancer séparément. C’est OSS et ça fait le job, mais c’est moins fluide.

5. CLI scriptable pour la fleet. C’est le point qui fait basculer dès qu’on a plus de deux Macs à gérer. Little Snitch expose un binaire littlesnitch qui sait faire export-model (backup JSON du modèle de règles), restore-model (restauration depuis fichier JSON, avec map des UID utilisateurs et mot de passe Keychain si l’export est chiffré), diagnostics, switch-profile, write-rules. Le workflow réel sur une fleet ressemble à ça : ssh mac-source littlesnitch export-model > rules.json côté Mac de référence, tu commites rules.json dans un repo Git, et sur chaque Mac cible tu fais scp rules.json mac-cible: puis littlesnitch restore-model -m oldUID>newUID rules.json. Pas un one-liner magique en pipe stdin, mais versionné, diff propre, code review possible. LuLu n’a pas de CLI officielle. Pour pousser des règles, tu copies un plist binaire fragile, qui change de format entre les versions, sans garantie de reproductibilité.

Verdict fonctionnalités : Little Snitch, sans débat. Si tu veux la granularité maximale, les profils nomades, la scriptabilité fleet et l’intégration SIEM propre, l’arbitrage est vite fait.

Limites communes (qu’on ne te dit pas ailleurs)

Avant de trancher, quatre limites qui s’appliquent aux deux outils. Honnêteté radicale, on ne fait pas semblant.

1. Apple apps qui bypass les Network Extensions. Depuis Big Sur, Apple a une whitelist d’apps système exemptées de tout filtrage NEFilterDataProvider tiers. Apple Mail, App Store, certains services iCloud passent à travers Little Snitch comme à travers LuLu. Ni l’un ni l’autre ne voit 100 % du trafic Apple natif. Ce n’est pas un bug des outils, c’est une décision d’Apple, et c’est documenté (Michael Tsai 2020).

2. Conflit Network Extensions. macOS n’autorise qu’un seul provider de filtrage réseau actif à la fois. Tu actives Little Snitch, ou LuLu, ou un profil DNS chiffré tiers (NextDNS, DNS4EU), pas les trois. C’est une contrainte plateforme, pas un défaut produit.

3. Pas d’audit indépendant formel. Ni Little Snitch ni LuLu n’ont eu d’audit tiers publié type Cure53, Trail of Bits ou ANSSI/CSPN. C’est une limite à connaître. Côté LuLu, l’OSS GPL-3.0 compense (audit communautaire continu). Côté Little Snitch, le track record 22 ans sans incident majeur compense partiellement (un seul vuln code-signing 2018, fix avant disclosure). Mais sur la rigueur formelle, les deux outils sont au même niveau : zéro audit publié.

4. La phase whitelist est un coût caché. Pendant les premiers jours d’usage, tu vas être prompted toutes les deux minutes. Ton OS, tes apps, ton anti-virus, ta sauvegarde, ton client mail, chacun veut joindre quelque chose. Compte une à deux semaines de friction sérieuse avant que ton modèle de règles soit stable. C’est vrai avec les deux outils. Si tu n’as pas la patience, désactive plutôt que de tout autoriser sans regarder (auto-allow par défaut casse l’intérêt même de l’outil).

Combien ça coûte vraiment

LuLu, c’est zéro euro. Pas de freemium, pas de tier payant, dons libres via Patreon. Si tu veux soutenir Wardle et la fondation Objective-See, fais-le. Ce n’est pas obligatoire pour utiliser le produit.

Little Snitch, c’est plus subtil. La grille publique obdev.at, capture vérifiée le 5 mai 2026, propose cinq formules. La Single License à 59 € pour un Mac. La Family License à 115 €, sur laquelle obdev ne précise pas combien de Macs sont couverts sur la page order, donc à clarifier auprès du support avant achat. La Multi License explicite, 5 Macs à 239 € (environ 48 € par Mac) ou 10 Macs à 419 € (environ 42 € par Mac). Et le Snitch Bundle (Little Snitch + Micro Snitch, le contrôle micro/caméra du même éditeur) à 63,49 € pour un Mac.

Licence perpétuelle, pas d’abonnement. Maj majeure (5 → 6 par exemple) = upgrade payant à tarif réduit. Sur la durée, tu payes une fois, tu uses jusqu’à la prochaine bascule majeure.

Pour une fleet 5 Macs en Multi License, le coût réel est de environ 48 € par Mac, en licence perpétuelle. Pour 10 Macs, environ 42 € par Mac. C’est un calcul que personne ne fait, mais qui change l’équation comparée au “59 € le Single Mac” cité partout.

Verdict à deux axes

Pas de gagnant unique. Deux axes, deux gagnants, un choix qui dépend de ton critère prioritaire.

Si la souveraineté est ton critère absolu : LuLu. Open source GPL-3.0, sources auditables, binaire compilable maison, auteur de référence sécurité Mac. Aucune prise juridictionnelle non détectable. Gratuit. Tu acceptes en échange une granularité plus faible, pas de profils auto, pas de DNS chiffré intégré, pas de CLI fleet. Pour un Mac unique, usage personnel, blocage process basique, c’est largement suffisant.

Si la richesse fonctionnelle est ton critère absolu : Little Snitch. Profils auto-switch SSID, DNS chiffré intégré, wildcard hostname, Network Monitor live, CLI scriptable, intégration Wazuh propre. Tu acceptes en échange le closed-source (avec un éditeur viennois stable depuis 22 ans, mais non auditable), un coût licence (de 42 à 59 € par Mac selon le pack), pas de version française. Pour une fleet familiale ou TPE, un usage nomade MacBook, ou une intégration SIEM sérieuse, c’est l’outil.

Aucun des deux n’est “meilleur dans l’absolu”. Ils répondent à deux questions différentes.

Et si tu hésites encore : commence par LuLu. Gratuit, OSS, deux clics à installer. Si après deux mois tu sens que la granularité te manque, le wildcard te frustre, ou que la fleet à scripter devient une corvée, passe à Little Snitch en connaissance de cause. Le contraire (commencer par LS payant et redescendre vers LuLu) coûte 59 € de plus pour rien.

Aucune affiliation Objective Development, aucun lien commercial avec Objective-See. Cet article ne touche pas un centime sur les achats Little Snitch.

Voir aussi

Sources

Les éditeurs eux-mêmes

Objective Development (obdev.at), l’entreprise autrichienne qui développe Little Snitch depuis 2003 : page produit, notes de version, communiqués
Objective-See (objective-see.org), la fondation de Patrick Wardle, ex-NSA devenu chercheur en sécurité Mac, qui publie LuLu gratuitement

Le code et la doc technique

Le code source de LuLu sur GitHub, librement consultable, avec les discussions publiques entre l’auteur et les utilisateurs (bugs, limitations : #280, #379, #410)
La documentation Apple de NEFilterDataProvider, l’interface système que les deux logiciels utilisent depuis qu’Apple a fermé l’ancienne méthode en 2019

Les analyses indépendantes

MacGeneration, site français de référence sur l’écosystème Apple, pour la revue de Little Snitch 6
Howard Oakley (The Eclectic Light Company), ingénieur britannique qui décortique les entrailles de macOS, pour comprendre comment ces pare-feu s’intègrent au système
Patrick Wardle lui-même, pour l’annonce LuLu v4 sur son Patreon (2025) où il documente la refonte complète du pare-feu

Proton Meet : Visio chiffrée E2EE, pour Privacy Max

Mac Souverain — Thu, 30 Apr 2026 10:24:38 GMT

Introduction

Tu organises une réunion Zoom avec ton comptable pour parler de chiffres. Ou un appel Teams avec un client pour finaliser un contrat. Tu fais confiance à l’icône de cadenas dans le navigateur.

Problème : ce cadenas protège le transport des données, pas le contenu. Zoom, Teams et Google Meet déchiffrent ton appel sur leurs serveurs par défaut pour pouvoir traiter la vidéo, la qualité audio, les sous-titres automatiques. Ça s’appelle du chiffrement en transit, pas du chiffrement de bout en bout. La nuance est massive. Les trois proposent un mode E2EE optionnel, mais il désactive la plupart des fonctionnalités intelligentes et reste invisible à 99% des usages.

Proton a lancé Proton Meet le 31 mars 2026. La promesse tient en une phrase : même Proton ne peut pas accéder à tes appels, ton partage d’écran ou ton chat. Les clés de déchiffrement ne quittent jamais les appareils des participants, point. On va voir ce que ça signifie concrètement, pour qui ça vaut vraiment le coup, et où sont les limites réelles.

Ce que Zoom et Teams font de tes réunions

Commençons par poser le contexte. Quand tu utilises Zoom, Google Meet ou Microsoft Teams, tes données audio et vidéo transitent chiffrées entre ton appareil et leurs serveurs. Jusque-là, rien de choquant. Mais sur leurs serveurs, ces données sont déchiffrées pour être traitées.

Pourquoi ? Parce que toutes les fonctionnalités “intelligentes” que tu utilises quotidiennement l’exigent. Les sous-titres automatiques, la suppression de bruit, les flous d’arrière-plan, l’optimisation adaptative de la qualité vidéo : tout ça nécessite d’accéder au contenu brut de ton appel. Ce modèle s’appelle le chiffrement en transit, et il est parfaitement légal, largement documenté dans les conditions d’utilisation que personne ne lit.

Ce que ça implique concrètement :

Zoom peut être contraint par injonction judiciaire américaine (CLOUD Act) de livrer le contenu de tes appels (sauf si tu as activé son mode E2EE optionnel, ce qui n’est jamais le défaut)
Google peut nourrir le profil personnel associé à ton compte avec les métadonnées de tes appels Meet (qui, quand, durée) si tu utilises un compte Google grand public. En Workspace, contractuellement Google ne s’en sert pas pour la pub. Mais il les garde quand même (audit, “service improvement”, CLOUD Act). Pas zero-knowledge pour autant.
Microsoft Teams stocke les métadonnées de tes réunions (qui, quand, combien de temps, avec qui) dans ses systèmes

Zoom ne lit probablement pas tes appels d’affaires de façon systématique. Mais techniquement et légalement, il le peut. C’est cette possibilité qui pose problème, pas l’intention déclarée.

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

Comment Proton Meet fonctionne différemment

Le chiffrement de bout en bout — E2EE — change radicalement le modèle. Tes données ne sont jamais accessibles en clair sur les serveurs de Proton, parce que les clés de déchiffrement ne quittent jamais tes appareils et ceux de tes interlocuteurs.

Proton Meet utilise le protocole MLS — Messaging Layer Security — développé par l’IETF, le même organisme qui standardise les protocoles fondamentaux d’internet. MLS est conçu spécifiquement pour les groupes : il gère efficacement les entrées et sorties de participants en cours d’appel sans avoir à re-chiffrer l’intégralité de la session à chaque fois, un problème technique que les implémentations naïves de E2EE rencontraient.

Ce que ça couvre en pratique :

L’audio et la vidéo, évidemment
Le partage d’écran, intégralement
Le chat en temps réel pendant l’appel

Ce que “même Proton ne peut pas voir” signifie techniquement : les serveurs de Proton voient passer des paquets chiffrés qu’ils ne peuvent pas déchiffrer. Ils savent qu’une réunion a lieu (ils en gèrent la signalisation), mais pas ce qui s’y dit, se montre ou s’écrit.

Le code de Proton Meet est open source. Proton fait régulièrement auditer ses produits par des cabinets indépendants (Mail, VPN, Drive, Pass) ; un audit dédié à Meet est attendu suite au lancement. L’open source permet à n’importe quel chercheur en sécurité de vérifier que les affirmations correspondent à l’implémentation réelle.

Les plans et ce qu’ils couvrent

Version gratuite :

Jusqu’à 50 participants
Durée maximum : 1 heure par appel
Compte Proton requis pour créer la réunion ; aucun compte requis pour les participants invités (un lien dans le navigateur suffit)
Création instantanée de lien de réunion, partage en un clic
Partage d’écran et chat inclus

Pour un indépendant qui veut faire une réunion client sans friction, c’est utilisable immédiatement. Tu crées le lien, tu l’envoies, ton client clique, l’appel démarre dans son navigateur. Aucune installation, aucun compte Proton requis pour les participants.

Meet Professional (à partir de $7,99 USD/utilisateur/mois, inclus dans les plans Workspace) :

Jusqu’à 250 participants
Durée : jusqu’à 24 heures par appel
Fonctionnalités de modération avancées
Intégration Proton Calendar

Proton Workspace (Standard et Premium), pour les équipes :

Proton Workspace positionne Meet comme composant d’une suite complète qui inclut Mail, Calendar, Drive, Docs, Sheets, VPN, Pass (gestionnaire de mots de passe d’équipe) et Lumo, un assistant IA privacy-first disponible sur le plan Premium.

Workspace Standard (€12,99/utilisateur/mois en facturation annuelle) : 1 To par utilisateur, Meet jusqu’à 100 participants, 15 domaines email, Mail, Calendar, Drive, Docs, Sheets, VPN, Pass.

Workspace Premium (€19,99/utilisateur/mois en facturation annuelle) : 3 To par utilisateur, Meet jusqu’à 250 participants, 20 domaines email, Lumo (IA privacy-first) inclus, assistant rédaction email, policies de retention configurables.

Workspace vise les équipes qui veulent remplacer Google Workspace ou Microsoft 365 par une alternative entièrement chiffrée. C’est la cible PME directe : tu gardes une organisation collaborative complète (email, documents, réunions, mots de passe) mais tu bascules sur une juridiction suisse avec un modèle économique fondé sur les abonnements, pas sur la publicité ou la revente de données.

Proton AG est certifié ISO 27001 et audité SOC 2 Type II. Workspace est compatible RGPD, HIPAA et CCPA.

Ce que ça change concrètement pour un indépendant ou une PME

Pour les cas où la confidentialité compte :

Appel avec un avocat pour discuter d’un litige. Réunion avec ton expert-comptable sur une restructuration. Échange avec un client qui partage des données sensibles. Revue de code en équipe sur un projet confidentiel (et tu devrais considérer que tous tes projets le sont).

Dans ces situations, la différence entre “chiffré en transit” et “chiffré de bout en bout” n’est pas théorique. C’est la différence entre un document dans une enveloppe et un document dans un coffre que le transporteur ne peut pas ouvrir.

Zéro friction pour tes interlocuteurs :

Ton client n’a pas besoin de créer un compte, de télécharger une app, ni de te demander “c’est quoi Proton ?”. Tu lui envoies un lien, il clique, il est dans la réunion depuis son navigateur. C’est le niveau de friction de Zoom ou Google Meet, avec le niveau de confidentialité d’une infrastructure chiffrée de bout en bout. Pour convaincre ton équipe, ou encore un client réticent à “changer d’outil”, c’est l’argument le plus solide.

Pour les équipes à distance :

Si ton équipe est déjà dans l’écosystème Proton (Mail, Drive), Workspace Standard ou Premium donne accès à Meet avec des limites de participants et de durée cohérentes avec la plupart des usages professionnels. La promesse de ne pas avoir à sortir de l’écosystème souverain pour une visio est réelle.

Ce que Proton Meet ne fait pas (encore) :

Pas d’enregistrement cloud côté Proton : architecturalement cohérent avec le E2EE, le serveur ne peut pas enregistrer ce qu’il ne peut pas déchiffrer. L’enregistrement local côté hôte reste possible si tu en as besoin (conformité, documentation). Pas non plus de transcription auto, sous-titres en direct ou résumés IA : ces features nécessitent un traitement serveur du contenu en clair, incompatible avec E2EE strict. C’est l’arbitrage assumé : privacy ou IA serveur, pas les deux.

À lire : Apple Mail vs Gmail vs Proton Mail : le comparatif honnête

Les limites réelles à connaître

La version gratuite est limitée. Une heure par appel, cela peut s’avérer insuffisant pour un entretien client large, un atelier ou une formation. 50 participants suffisent pour la grande majorité des réunions d’équipe, mais c’est juste pour un webinaire.

La migration de l’écosystème a un coût. Si ton équipe est habituée à Teams avec ses intégrations Office 365, passer à Workspace n’est pas transparent. Les docs Proton (Docs, Sheets) sont fonctionnels mais n’ont pas encore la maturité de Google Workspace sur les fonctionnalités avancées de collaboration. C’est un choix, pas une amélioration sur tous les tableaux.

Les intégrations tierces sont limitées. Proton Meet s’intègre nativement avec Proton Calendar pour l’insertion de liens de réunion. En dehors de ça, les intégrations avec des outils comme Slack, Notion ou des CRM sont absentes ou limitées, là où Zoom et Teams ont des années d’écosystème derrière eux.

Le prix par rapport à la concurrence. La bonne comparaison n’est pas Meet Pro contre une autre ligne de visio. Il faut regarder l’angle des suites complètes.
Proton Workspace Standard (€12,99/utilisateur/mois) contre Google Workspace Business Starter (~6,80 €/utilisateur/mois) ou Microsoft 365 Business Basic (~6 €/utilisateur/mois).

Proton est environ deux fois plus cher. Google et Microsoft proposent E2EE en option mais ça désactive sous-titres auto, transcription, Copilot/Duet .

Proton Meet ne propose pas non plus ces features, mais c’est par cohérence E2EE assumée dès le départ. Le delta de prix, c’est le coût d’un service privacy complet, qui vit de ton abonnement plutôt que de tes données.

À lire : Proton Bridge + Apple Mail sur Mac : le chiffrement sans sacrifier le confort

Pour les pressés

Proton Meet est une visioconférence E2EE qui utilise le protocole MLS, open source, audité indépendamment, juridiction suisse. Lancement le 31 mars 2026.

Plan gratuit : 50 participants, 1 heure. Tes invités rejoignent depuis leur navigateur, sans compte ni installation.

Meet Professional : jusqu’à 250 participants, 24 heures, à partir de $7,99 USD/utilisateur/mois (inclus dans Workspace Standard et Premium).

Proton Workspace : suite complète pour équipes avec apps Mail, Calendar, Drive, Docs, Sheets, Meet, VPN, Pass, en Standard et Premium (Lumo IA compris pour Premium).

Ce n’est pas un remplacement universel de Zoom ou Teams. C’est la bonne option si la confidentialité architecturale de tes réunions compte pour toi, ou bien si tu es déjà dans l’écosystème Proton.

Si tu veux une suite entièrement chiffrée et cohérente pour ton équipe, sans dépendre d’une infrastructure américaine soumise au CLOUD Act et à la juridiction 5 Eyes, et que tu veux que tes données n’abreuvent pas en plus une régie publicitaire, la suite Proton Workspace s’adresse à toi et à ton équipe. C’est un candidat très sérieux à évaluer.

Pour un indépendant avec des appels clients inférieurs à une heure, le plan gratuit avec 50 participants max est largement suffisant. Pour une équipe qui veut migrer hors Google Workspace ou Microsoft 365 : Proton Workspace mérite une évaluation sérieuse.

Des termes techniques ? Consulte le glossaire.

Six mois et dix-neuf textes mondiaux, la terrible convergence

Mac Souverain — Thu, 30 Apr 2026 08:43:55 GMT

MAJ juillet 2026. Point de calendrier sur le volet CSAR : le trilogue du 4 mai a eu lieu, et le 9 juillet le Parlement a laissé passer la reconduction de Chat Control 1.0 (volontaire, E2E exclu) faute des 361 voix pour le bloquer, majorité contre. Le scanning obligatoire (2.0) décrit dans cette carte n’est pas tranché : il repart en trilogue en septembre. Détails dans le radar.

Ta Privacy ? Elle n’est plus vraiment à toi.

Personne ne te l’a confisquée d’un coup, non. Ça c’est pour les régimes pressés. On te la grignote juste petit à petit, lentement, pour que tu ne te rendes compte de rien.

Un projet de loi à Washington qui fait de ton Mac un checkpoint d’identité. Un règlement européen qui remplace tes messages chiffrés par un mouchard. Un jury au Nouveau-Mexique qui colle 375 millions de dollars d’amendes à Meta pour avoir osé déployer du chiffrement fort.

Six mois. Dix-neuf textes. Quatre continents. Une seule direction.

Voici la carte.

Trois mécaniques, une seule trajectoire

Les dix-neuf textes que je vais te présenter ne se ressemblent pas en surface. Une loi américaine, un règlement européen, une décision de justice, un produit privé. Mais empilés, trois mécaniques émergent, et elles travaillent ensemble.

M1, l’identification universelle. Plus d’anonymat sur Internet, pas même pour les adultes. Chaque connexion, chaque inscription, chaque message demande une preuve d’identité.

M2, le cassage du chiffrement bout-en-bout. Le chiffrement reste sur le papier. Mais les contenus sont scannés avant qu’il s’applique, ou le déployer devient juridiquement risqué.

M3, la centralisation chez deux ou trois acteurs. Apple, Google, Microsoft, ou un Sam Altman décidé à monopoliser la vérification d’humanité. Tu ne te logues plus sur un site, tu te logues à travers un courtier d’identité.

La plupart de ces textes sont passés sous le radar, parce qu’ils sont arrivés un par un. Quand tu les vois ensemble, le tableau change.

M1, l’identification universelle sans exception adulte

Le 13 avril 2026, Josh Gottheimer (D-NJ) et Elise Stefanik (R-NY) déposent HR 8250 Parents Decide Act à la Chambre des représentants américaine. Le texte oblige Apple, Google et Microsoft à exiger une date de naissance à la création de tout compte OS, et à exposer ensuite cette information aux éditeurs d’apps via une interface dédiée. Pas d’exception adulte. Tu installes un Mac neuf en 2027, le système t’identifie, et toute app peut le lire.

Andy Yen, CEO de Proton, a synthétisé l’enjeu en une phrase : « Nous ne pouvons pas accepter un monde où chaque adulte est censé présenter une pièce d’identité comme prix d’entrée pour aller sur Internet. » Huit jours plus tard, l’Illinois HB 5511 est voté à la Chambre de l’État, 82 contre 27. Logique identique, déplacer la vérification d’âge depuis chaque app vers l’OS, plus difficile à contourner parce que l’OS est lié au compte vérifié et au moyen de paiement.

La logique n’est pas uniquement américaine. Le UK Online Safety Act est entré en application le 25 juillet 2025. Au premier trimestre 2026, l’Ofcom a ouvert plus de quatre-vingt-dix enquêtes et prononcé six amendes, dont 1,35 million de livres contre 8579 LLC. L’Australie a activé son Online Safety Amendment le 10 décembre 2025, étendu à dix plateformes. Le Brésil a promulgué la loi 15.211/2025 en septembre 2025. Et le 14 avril 2026, la Commission européenne dévoile son app de vérification d’âge harmonisée pour les vingt-sept États membres.

Au passage, elle est contournée en deux minutes par un consultant britannique, Paul Moore. Pour les détails, tu peux lire le radar depuis le lien ci-dessous. À pleurer de rire, vraiment. Ou à pleurer tout court, selon.

À lire : Vérification d’âge EU, hackée en 2 minutes, la surveillance mal codée

Le 2 mars 2026, 371 chercheurs en cybersécurité de 29 pays signent une lettre ouverte. Ronald Rivest, Turing Award et co-inventeur de RSA. Bart Preneel, président de l’IACR. Pas exactement des activistes du dimanche.

La lettre soutient que la méthode n’est pas sûre et risque d’exposer les utilisateurs à des malwares ou à des arnaques sur les sites illicites qui n’implémentent pas la vérification, ou de divulguer plus d’informations personnelles aux fournisseurs de services. Leur conclusion sur les déploiements en cours : « dangereux et socialement inacceptable ».

Pour qu’un système de vérification d’âge fonctionne réellement, écrivent-ils, il faudrait des « pièces d’identité émises par l’État, avec une protection cryptographique forte, pour chaque interaction avec le service ».

M2, casser le chiffrement dans la loi ou dans la jurisprudence

Côté UE, le dossier est connu, je l’ai déjà détaillé.

À lire : Chat Control 2.0 : l’UE veut lire tes messages avant que tu les envoies

À lire : NIS2 oblige les entreprises à chiffrer. CSAR leur interdit de le faire vraiment.

La nouveauté, c’est l’aveu. Vera Jourova, Vice-Présidente de la Commission, a reconnu publiquement au sommet de l’EDPS que le CSAR briserait le chiffrement. Trois ans de discours « CSAR ne casse pas le chiffrement » de Ylva Johansson, démentis par sa propre collègue. Le prochain trilogue est fixé au 4 mai 2026, l’adoption visée en juillet. Le compteur tourne.

Mais l’attaque la plus brutale contre le chiffrement bout-en-bout vient des États-Unis, et elle ne ressemble pas à une loi. De la jurisprudence, et c’est bien pire.

Le 24 mars 2026, un jury du Nouveau-Mexique condamne Meta à 375 millions de dollars de pénalités civiles. Le procureur général a utilisé la décision de Meta de déployer le chiffrement bout-en-bout dans Messenger comme preuve d’irresponsabilité envers les mineurs.

Et la séquence qui suit est encore plus parlante que le verdict : pendant le procès, avant même la sentence, Meta annonce le retrait de l’E2E des messages directs Instagram. Effet programmé au 8 mai 2026. La simple existence du procès aura suffi à les décider.

Et le véritable problème de la jurisprudence, c’est qu’un seul juge aura suffi, pour que tous les autres puissent reprendre son arrêt dans d’autres jugements. Avec de lourdes indemnisations à la clé, ce qui aura pour effet, dans un horizon très bref, de décourager les startups qui viseraient à chiffrer leurs services. Parce que 375M$ pour Meta, c’est de la broutille. Pour une startup, c’est la mort assurée.

Plus efficace encore, qu’une loi ou un règlement.

Pour autant que ce soit tentant, on ne peut pas jeter toute la pierre au juge. Le comportement irresponsable (volontaire ?) de Meta a façonné la décision. Je m’explique :

Une note interne signée Monika Bickert (directrice de la politique de contenu de Meta à l’époque) a fini dans le dossier d’instruction. Ironie noire absolue : « Nous nous apprêtons à faire une mauvaise chose en tant qu’entreprise. C’est tellement irresponsable. » Bickert ne critiquait pas le chiffrement en lui-même, elle alertait sa hiérarchie sur le timing.

Activer l’E2E par défaut sur Messenger sans avoir d’abord trouvé comment continuer à détecter les abus sur mineurs, ça revenait à aveugler volontairement les systèmes de signalement de Meta. Le procureur du Nouveau-Mexique a sorti cette note pour démontrer la chose la plus difficile à prouver dans une affaire civile : que Meta savait que sa décision laisserait passer des prédateurs, et l’a prise quand même.

Là, c’est vraiment, vraiment important. Il ne faut pas se tromper sur le rôle de chacun dans cette affaire. Meta n’est pas victime du procès. Pour Zuckerberg, l’E2E n’a jamais été une valeur, c’était un argument marketing pour rester compétitif face à WhatsApp et Signal.

C’est exactement ce qui sépare Meta de Signal ou Proton. Signal ne peut pas retirer l’E2E, ce serait dissoudre le produit. Proton non plus, sa proposition entière repose dessus. Meta peut, parce que pour elle, l’E2E était une option de cuisine, pas une fondation.

Et c’est précisément cela qui crée le précédent que les juges pourront brandir face à Signal ou Proton ensuite. « Voyez, même Meta a reculé, vous pouvez bien le faire aussi. » Meta ne subit pas la chute de l’E2E. Elle y participe activement.

Et c’est aussi la conclusion de Bruce Schneier, sommité mondiale de la cryptographie. Déployer du chiffrement fort sur ton produit peut désormais être attaqué juridiquement comme un acte de mauvaise foi. Pas illégal en soi. Juste… dommageable au civil, devant un juge américain.

Le tableau US se complète avec FISA Section 702. La loi expirait le 20 avril 2026. Le Congrès a voté une extension de dix jours en urgence et bloqué d’avance l’amendement « exigence de mandat ». La NSA aspire les communications d’étrangers ciblés hors des États-Unis, les Américains qui leur écrivent rentrent alors dans la base, le FBI l’interroge sans mandat. Sept mille requêtes US-person en 2025, sous-déclarées de l’aveu du DOJ lui-même.

À l’autre bout du monde, Hong Kong. Le 23 mars 2026, les règles d’enforcement de la National Security Law sont modifiées, la police peut désormais exiger tes mots de passe et tes clés de chiffrement. Refuser est un délit pénal. Schneier en a fait une note de blog. Hong Kong contraint frontalement. Les démocraties, elles, contournent par contrat (CSAR), par jurisprudence (Meta NM), ou par barrières d’âge au niveau de l’OS. Résultat équivalent, emballage différent.

Convergence sans concertation, mais convergence quand même.

M3, courtiers privés et publics, l’identité comme infrastructure

Une fois HR 8250 voté, ou Illinois HB 5511, Apple et Google deviennent courtiers d’âge. Pas par choix, par contrainte légale. Techniquement, c’est juste une option régionale, le genre de switch qu’Apple bascule déjà pour le RGPD. Le vrai risque, c’est que les autres gouvernements voient le système tourner aux US et le copient. Effet RGPD à l’envers, par mimétisme.

Pendant que les États débattent, Sam Altman pousse son alternative privée. Le 17 avril 2026, World ID annonce son intégration avec Tinder, Zoom, DocuSign, Okta, Shopify et VanEck. Dix-huit millions d’utilisateurs déjà vérifiés par scan d’iris (l’Orb), dans cent soixante pays. Le pitch : « la première couche d’identité décentralisée pour l’humanité », face aux bots et aux deepfakes, que la même industrie IA produit en masse.

C’est élégant. Tu génères le problème (deepfakes IA), tu vends la solution (scan d’iris). Au passage, tu construis une base biométrique privée à l’échelle planétaire, que tu connectes à Tinder, Zoom, DocuSign et Shopify. Le scanné devient bêta-testeur d’humanité gratuit, et paie en iris. L’industrie IA gagne encore plus de données gratuites, mais surtout surqualifiées.

On peut difficilement faire mieux, en effet, que de pouvoir pister précisément un individu à travers tous les services qu’il utilise au quotidien. Je te dis pas la mine d’or !

Côté étatique, le UK avance son GOV.UK Wallet et son permis de conduire numérique, déploiement complet courant 2026. Rien d’obligatoire à ce stade, photocards physiques valides jusqu’en 2030. Mais l’infrastructure est là, prête à devenir obligatoire dès qu’un futur gouvernement l’aura décidé.

Trois acteurs émergent comme courtiers d’identité dominants, Apple plus Google côté OS, World ID côté privé global, GOV.UK Wallet et ses jumeaux côté étatique. Personne ne s’est concerté. La convergence est politique, économique, structurelle.

Pourquoi cette convergence

Ce n’est pas un complot. C’est plus ennuyeux que ça, c’est de la mécanique systémique.

D’abord, l’imitation transatlantique. Le UK Online Safety Act voté en 2023 sert de modèle. L’Australie le réplique en 2025. La Commission européenne le cite explicitement comme « bonne pratique » pour son app de vérification d’âge. HR 8250 et Illinois HB 5511 reprennent la même architecture six mois plus tard. Pas de coordination secrète, juste du « regarde, ça marche chez eux, copions ».

Ensuite, le coût marginal nul pour Apple, Google et Microsoft. Une fois l’infrastructure de vérification d’âge construite au niveau OS pour un État, l’export vers les autres pays ne coûte rien de plus.

Enfin, le momentum réglementaire crée le marché privé. Les plateformes cherchent des fournisseurs de vérification d’identité ? Worldcoin lève la main. Les États veulent leur wallet souverain ? Les intégrateurs (Thales, IDEMIA, Entrust) se positionnent sur les appels d’offres eIDAS 2.0. La régulation crée le besoin, le marché vend la solution.

Le résultat est exactement ce que la lettre des 371 chercheurs redoute, un système où chaque interaction avec un service en ligne suppose une preuve d’identité émise par un État ou par un courtier privé.

Les contre-mouvements

Finir sur une note totalement défaitiste serait malvenu.

Le 1er avril 2026, le gouverneur Brad Little signe Idaho SB 1299, qui interdit aux entités gouvernementales de l’État d’exiger un digital ID. Premier État américain à repousser frontalement, texte juridiquement solide et réplicable.

Deux jours plus tard, le gouverneur Tony Evers du Wisconsin exerce un veto AB 105, sur un projet de vérification d’âge pour sites adultes. Premier veto de gouverneur américain sur un projet de loi de vérification d’âge, trois objections argumentées, intrusion Privacy sur les adultes, absence de restrictions de partage, vulnérabilités exposant les internautes au vol et au chantage.

Le 23 avril 2026, Thomas Massie (R-KY) et Lauren Boebert (R-CO) déposent HR 8470 Surveillance Accountability Act. Mandat et cause probable exigés avant toute surveillance d’Américains, fermeture de la « faille des courtiers de données ». Bipartisan dans l’esprit, signe que le débat sur la surveillance traverse les deux partis.

Et le 8 avril, la DINUM française annonce la migration de 2,5 millions de postes administration vers Linux. David Amiel, ministre du Budget, demande des plans ministériels avant l’automne 2026. Sept axes de réduction de dépendance, visio souveraine pour 200 000 agents fin 2026, 2,5 millions en 2027.

Soyons honnêtes deux secondes. La France ne migre pas pour protéger la Privacy de ses fonctionnaires, elle s’en moque. Elle migre parce que dépendre de Microsoft coûte entre 500 et 800 millions d’euros de licences par an, et parce qu’un Trump 2.0 a fini de rappeler à Bruxelles et à Paris qu’un fournisseur américain peut être désactivé par décret de la Maison Blanche. Souveraineté budgétaire et souveraineté stratégique. Privacy nulle part.

Mais c’est précisément pour ça que l’exemple est intéressant. Un État sort d’un stack hégémonique pour des raisons d’argent et de géopolitique, pas par idéologie.

Le résultat, par effet de bord, c’est que ses 2,5 millions de fonctionnaires arrêtent d’être télémétrés en continu par Redmond.

Ce qu’un État fait pour ses raisons, un citoyen peut le faire pour les siennes. Et protéger sa Privacy online n’est pas un crime, du moins pas encore.

Sortir, techniquement et politiquement

J’utilise Proton Mail et un serveur de mail self-host Stalwart pour les emails, Matrix pour la messagerie instantanée, un réseau mesh Tailscale wireguard avec exit node Mullvad pour la sécu, un résolveur DNS unbound self-host, et divers autres outils open source pour ma souveraineté numérique.

Ce n’est pas absolu, bien sûr, mais c’est déjà une énorme indépendance, une réelle Privacy, une importante limitation pour des tiers commerciaux, ou étatiques, à pouvoir me pister en continu.

À part Proton, et l’hébergement de mes VPS chez Infomaniak, tous ces outils sont gratuits, open source, audités pour la plupart, et soutenus par des communautés dynamiques. C’est la preuve que la Privacy n’est pas morte et qu’elle intéresse, au contraire, nombre de personnes.

Tu n’es certes pas obligé d’aller jusque là, même si pour ton activité pro en particulier, je te conseille vivement d’aller jusqu’à cet arsenal-là. Mais chaque geste que tu feras pour ta Privacy compte. C’est le droit inaliénable pour toi de disposer de tes données numériques, comme tu l’entends, et de définir avec qui tu les partages. C’est aussi fondamental que la liberté d’aller et venir.

Si CSAR passe, si HR 8250 progresse, et que tu te sens concerné, le bon réflexe est de choisir des architectures dont la conception technique rend le scan de tes données impossible, et le tracking extrêmement pénible.

Signal et Proton ne peuvent pas implémenter le client-side scanning sans casser leur modèle. Ce n’est pas une politique, c’est une impossibilité technique. Les choisir eux, ou d’autres bâtis sur le même modèle, c’est te protéger.

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

Côté politique, si ça t’intéresse, écris à tes représentants. Le trilogue CSAR du 4 mai 2026 est un point de bascule. La pression publique a fonctionné sur Chat Control 1.0, elle peut fonctionner sur CSAR 2.0.

EDRi, EFF, noyb, maintiennent des outils de contact direct avec les citoyens. Utilise-les et participe à l’action, si cela te parle.

Et suis les Radars MacSouverain. Chaque texte, chaque verdict, chaque tour de vis est suivi en temps réel. La vigilance Privacy, c’est de l’attention au quotidien, pas de l’épisodique.

Pour les pressés

Six mois, dix-neuf textes, quatre continents. Trois mécaniques qui s’emboîtent, identification universelle, cassage du chiffrement, centralisation des données d’identification chez deux ou trois courtiers. Ce n’est pas un complot, juste des trajectoires convergentes qui aboutiront à moins de Privacy, voire à plus de Privacy du tout, si on les combine dans chaque pays.

Tout le monde en sort gagnant, c’est comme ça qu’on te le vend, sauf l’utilisateur final, à bien lire. Autrement dit, toi, moi, et tous les citoyens.

Idaho SB 1299, Wisconsin veto Evers, Surveillance Accountability Act, 371 chercheurs, des points d’appui réels, démontrent qu’une autre voie est possible.

Tes choix techniques d’aujourd’hui, Signal, Proton, MacOS bien réglé et à jour, Linux pourquoi pas, sont aussi des choix politiques. Et soutenir EDRi et EFF, refuser les fonctions de confort qui pavent la voie, est aussi le bon moyen de combiner les deux.

Ce qui arrive n’est pas encore totalement écrit. Mais c’est d’ores et déjà inscrit dans une trajectoire.

À toi de choisir ce que tu en fais.

Sources

Textes officiels et législatifs

HR 8250 Parents Decide Act, Congress.gov : https://www.congress.gov/bill/119th-congress/house-bill/8250/text
Illinois HB 5511 Digital Age Assurance, ILGA : https://ilga.gov/Legislation/BillStatus/FullText?GAID=18&DocNum=5511&DocTypeID=HB&LegId=167486&SessionID=114
HR 8470 Surveillance Accountability Act, GovTrack : https://www.govtrack.us/congress/bills/119/hr8470/text
Idaho SB 1299, Idaho Legislature : https://legislature.idaho.gov/sessioninfo/2026/legislation/S1299/
UK Online Safety Act enforcement, Ofcom : https://www.ofcom.org.uk/online-safety/protecting-children/age-checks-to-protect-children-online
Australia Online Safety Amendment, eSafety : https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions
New Mexico Department of Justice, verdict Meta : https://nmdoj.gov/press-release/new-mexico-department-of-justice-wins-landmark-verdict-against-meta/
UK GOV.UK digital driving licence : https://www.gov.uk/government/news/digital-driving-licence-coming-this-year

Analyses et coalitions

EDRi, ECtHR sur le chiffrement comme droit fondamental : https://edri.org/our-work/european-court-of-human-rights-confirms-weakening-of-encryption-can-violate-the-human-right-to-privacy/
Bruce Schneier sur le verdict Meta NM : https://www.schneier.com/blog/archives/2026/04/new-mexicos-meta-ruling-and-encryption.html
Bruce Schneier sur Hong Kong NSL : https://www.schneier.com/blog/archives/2026/04/hong-kong-police-can-force-you-to-reveal-your-encryption-keys.html
Lettre ouverte des 371 chercheurs cybersécu, Euronews : https://www.euronews.com/next/2026/03/02/dangerous-and-socially-unacceptable-experts-warn-against-rushed-rollout-of-online-age-chec
Andy Yen, Proton CEO, sur HR 8250, The Register : https://www.theregister.com/2026/04/23/proton_ceo_age_checks_id_checkpoint/
App EU age verification contournée, Cybernews : https://cybernews.com/security/eu-age-verification-app-hack/
World ID partenariats, TechCrunch : https://techcrunch.com/2026/04/17/sam-altmans-project-world-looks-to-scale-its-human-verification-empire-first-stop-tinder/
Wisconsin veto Evers, 404 Media : https://www.404media.co/wisconsin-age-verification-bill-vetoed/
France DINUM, IT Social : https://itsocial.fr/logiciel-agilite/logiciel-agilite-actualites/la-dinum-lache-windows-pour-linux-et-impose-un-plan-de-souverainete-numerique-a-chaque-ministere-avant-lautomne/

Voir aussi

Le DNS, talon d'Achille de ta souveraineté numérique

Mac Souverain — Sat, 25 Apr 2026 15:35:46 GMT

Le paradoxe de la souveraineté à moitié

Tu paies un VPN sérieux. Tu as migré vers Proton Mail. Tu as monté un mesh Tailscale entre tes Macs. Tu as activé la Protection Avancée des Données iCloud, désactivé la moitié des analytics, basculé Safari en mode privacy max.

Et ton FAI sait pourtant que hier soir, petit coquinou, tu as ouvert un onglet sur un site de rencontres à 23h47.

Pas parce que le VPN a fui. Pas parce qu’Apple a craqué. Parce que la couche la plus banale d’internet, celle dont tout le monde a entendu le nom sans jamais s’en occuper, fonctionne en clair par défaut. Cette couche s’appelle le DNS, et c’est le maillon faible que personne ne regarde, y compris dans des stacks privacy par ailleurs solides.

Cet article explique pourquoi ce maillon est cassé, pourquoi les réponses faciles, ces fameux Cloudflare 1.1.1.1 et iCloud Private Relay, ne sont pas vraiment des réponses, et comment reprendre le contrôle en trois niveaux gradués.

Le DNS, c’est quoi

L’annuaire qui rend internet utilisable

Les humains retiennent des noms : proton.me, apple.com, macsouverain.fr. Les machines, elles, ne savent parler qu’avec des adresses IP : 185.70.43.10, 17.253.144.10, 83.228.215.109. Entre les deux, il faut un traducteur en temps réel. C’est le DNS, Domain Name System.

Imagine un téléphone fixe sans répertoire. Tu connais le nom de ton plombier mais pas son numéro. Tu appelles donc d’abord les renseignements téléphoniques, qui te donnent le numéro, puis tu rappelles ton plombier. Le DNS, c’est exactement ça : un service de renseignements automatique, interrogé des dizaines de fois par minute, sans que tu t’en rendes compte.

Le flux complet d’une résolution

Quand tu tapes signal.org dans Safari, voilà ce qui se passe en quelques dizaines de millisecondes :

Ton Mac regarde dans son cache local. A-t-il déjà demandé cette adresse récemment ? Si oui, il la réutilise et c’est terminé.
Sinon, il interroge le resolver configuré sur la machine. Par défaut, c’est celui que ta box t’a poussé en DHCP, donc celui de ton FAI.
Ce resolver, s’il n’a pas la réponse en cache, attaque la hiérarchie DNS. Il interroge d’abord un root server, l’une des treize adresses de référence de l’annuaire global (déployées sur des centaines d’instances physiques en anycast), qui lui dit « pour .org, demande à ces serveurs-là ».
Il interroge ensuite le serveur TLD du .org, qui lui dit « pour signal.org, demande à ces serveurs-là ».
Il interroge enfin le serveur authoritative de signal.org, qui détient la vérité officielle et lui renvoie l’adresse IP.
Le resolver te transmet la réponse, ton Mac peut établir la connexion HTTPS.

Cette descente de la hiérarchie, c’est ce qu’on appelle une résolution récursive. Le resolver fait le travail de remontée à ta place.

Et c’est précisément sur ce premier maillon, entre ton Mac et le resolver, que tout se joue.

Pourquoi c’est le talon d’Achille

Par défaut, tout passe en clair

Le DNS classique tourne sur le port 53, en UDP, sans chiffrement. Quand ton Mac demande proton.me à ton FAI, la question et la réponse circulent en clair sur le réseau, lisibles par n’importe quel équipement entre les deux : ta box, le DSLAM du quartier, le routeur de l’opérateur, et bien sûr le serveur DNS du FAI lui-même qui fait le travail.

Le HTTPS ne change rien à ça. HTTPS chiffre le contenu des pages, pas la question DNS qui les a précédées. Tu peux avoir le plus beau cadenas du monde sur Safari, ton FAI a déjà noté la destination avant que la connexion chiffrée ne commence.

Ton FAI voit chaque domaine, avec horodatage

C’est l’équivalent de connaître la liste de tous les magasins que tu visites dans une journée, sans savoir ce que tu y achètes. Pour un profilage commercial ou un examen judiciaire, c’est largement suffisant.

Un appel au site web d’un avocat spécialisé en droit du divorce en dit long sur toi. Une visite à 3h du matin sur une plateforme de pari en ligne renseigne ton FAI tout aussi bien. Idem pour une consultation matinale et systématique d’un site médical spécialisé. Tes données de navigation, c’est une manne de données gratis, à revendre ou à exploiter.

En France, les FAI sont légalement tenus de conserver ces métadonnées pendant un an (décret 2006-358, contesté mais maintenu malgré les arrêts de la CJUE). Aux États-Unis, des FAI ont vendu des historiques de navigation à des courtiers en données, légalement, faute de protection fédérale comparable. Le risque n’est pas l’espionnage ciblé du quotidien, c’est l’exposition structurelle : des données collectées automatiquement, stockées des mois, accessibles sur réquisition ou via une fuite.

Chiffré côté FAI ≠ chiffré bout en bout

Beaucoup d’utilisateurs croient que parce que leur box affiche un cadenas dans l’interface admin ou parce que leur abonnement mentionne « DNS sécurisé », ils sont protégés. Erreur. Le FAI peut très bien chiffrer la liaison entre ses propres serveurs et un upstream, ça ne change rien : c’est lui qui résout, c’est lui qui voit, c’est lui qui logue.

La seule manière de soustraire ta question DNS au regard de ton FAI, c’est qu’elle ne passe jamais par ses serveurs. Pas par lui, pas par sa box, pas par son resolver « amélioré ».

Et même avec un VPN, ça peut fuir

Tu as un VPN qui tourne. Tout ton trafic est chiffré dans un tunnel WireGuard. Et pourtant, tes requêtes DNS peuvent contourner le tunnel et aller directement chez ton FAI. C’est ce qu’on appelle une fuite DNS, et c’est l’un des défauts les plus silencieux des VPN mal configurés ou trop bon marché.

Le mécanisme est simple : ton appareil garde en mémoire le resolver DHCP de la box, le VPN ne pousse pas son propre resolver assez fort, et certaines requêtes système partent en parallèle du tunnel. Ton trafic web est protégé, ton DNS est exposé.

Test en trente secondes : dnsleaktest.com ou dnscheck.tools. Si ton FAI apparaît dans la liste alors que ton VPN est connecté, tu fuis.

À lire : Pourquoi tu as besoin d’un VPN, et ce qu’il fait vraiment

Le piège DoH, DoT et Private Relay

Chiffrer, oui, mais chez qui

Pour répondre au DNS en clair, l’industrie a poussé deux protocoles : DoH (DNS-over-HTTPS, port 443) et DoT (DNS-over-TLS, port 853). Sur le fond, ils font la même chose : encapsuler la requête DNS dans un tunnel chiffré entre ton Mac et un resolver. Sur la forme, le DoH se fond dans le trafic HTTPS normal et est plus discret, le DoT est plus facile à identifier et à bloquer côté admin réseau.

Activer DoH ou DoT sort enfin tes requêtes DNS du regard de ton FAI. C’est un vrai progrès. Sauf qu’on n’a pas vraiment résolu le problème, on l’a juste déplacé.

Parce que la vraie question n’est pas « est-ce que c’est chiffré sur le câble ? » Elle est « qui est en face ? ».

La centralisation, c’est l’autre nom du fouineur

Quand tu actives DoH par défaut sur Chrome, Firefox, ou via un profil macOS générique, tu te retrouves typiquement chez Cloudflare, Google, ou NextDNS. Cloudflare gère une part énorme du DNS public mondial. Google aussi. Tous les deux sont des entreprises américaines, soumises au CLOUD Act, donc contraignables par la justice US à remettre les données qu’elles stockent, indépendamment de la nationalité de l’utilisateur.

Tu as remplacé un fouineur, ton FAI réquisitionnable par la justice française, par un autre fouineur, un cloud américain réquisitionnable par les Etats-Unis, sans mandat au besoin, merci au Cloud Act 2018. La conversation n’est plus en clair sur le câble, elle est juste enregistrée chez quelqu’un d’autre.

C’est ici que la plupart des comparatifs DNS détournent le regard. « Cloudflare 1.1.1.1, c’est gratuit et c’est rapide ». C’est vrai. « C’est privé » est une affirmation qui peut se révéler trompeuse et qui demande à être contextualisée par la juridiction et le modèle économique de l’opérateur.

Apple Private Relay, l’illusion premium

iCloud Private Relay, inclus dans iCloud+, est une variante intéressante du même piège. Le mécanisme : Apple chiffre tes requêtes DNS et ton trafic Safari, les fait sortir d’abord par un serveur Apple, puis par un partenaire (Cloudflare ou Fastly dans la plupart des régions). L’idée, c’est qu’aucun acteur seul ne voit à la fois qui tu es et où tu vas.

Sur le papier, c’est élégant. Dans les faits, deux problèmes massifs.

D’abord, Private Relay ferme le DNS au niveau OS, pour Safari et certaines app système, en court-circuitant ce que tu aurais configuré. Tu pensais utiliser ton resolver Quad9 ? Apple repasse par Cloudflare ou Fastly pour Safari, sans te demander.

Ensuite, ça ne couvre que Safari et une fraction du trafic iCloud. Ton Chrome, ton Firefox, ton Mail, ton Slack, ton Discord, ton client SSH, ton terminal, ton client torrent, tes apps tierces : Private Relay ne touche pas à leurs requêtes DNS.

Tu paies un service « premium » pour une couverture partielle qui déporte la confiance sur un tandem Apple+Cloudflare que tu ne peux ni configurer ni remplacer. Apple voit que tu navigues, Cloudflare voit où tu vas, séparément par design, mais toujours deux acteurs CLOUD Act sur lesquels tu n’as aucune prise. Pour la moitié du trafic, tu n’as rien gagné.

À lire : Privacy macOS, les paramètres à changer immédiatement

Ce que ça change concrètement

Ce que ton FAI voit, et ne voit pas

Sans DNS chiffré, ton FAI dispose d’un journal complet : domaine, horodatage, fréquence, durée approximative de session. Il peut établir que tu visites un site bancaire chaque jour à 8h, que tu consultes un site médical spécifique tous les mardis soir, que tu passes un certain temps sur des sites de presse alternative, que tu te connectes à signal.org à des horaires précis. Il ne lit pas tes messages, il n’a pas besoin.

Avec un DNS chiffré et un resolver de confiance, ton FAI ne voit plus que des connexions TLS vers des adresses IP. Il sait que tu utilises internet, pas vers qui tu te connectes en premier lieu. Une partie de l’IP reste révélatrice, mais c’est un saut qualitatif énorme par rapport au défaut.

Ce qui peut quand même être corrélé

Soyons clairs sur ce qui reste exposé même avec un DNS souverain.

Le SNI (Server Name Indication) : pendant la poignée de main TLS, ton navigateur annonce encore en clair quel domaine il veut joindre, pour que le serveur présente le bon certificat. Cette information est lisible par les acteurs réseau, indépendamment du DNS. La parade s’appelle ECH (Encrypted Client Hello). Les navigateurs majeurs supportent ECH côté client, c’est le déploiement serveur qui traîne. Pour les sites sans ECH côté serveur, le SNI reste lisible par les acteurs réseau.

L’adresse IP de destination : même si personne ne lit ton DNS et ton SNI, la connexion à un serveur révèle son IP. Pour un service utilisant un grand CDN partagé (Cloudflare, AWS), l’IP toute seule ne dit pas grand chose. Pour un petit site auto-hébergé, l’IP suffit à l’identifier.

Le fingerprinting navigateur : c’est là que ça devient plus concret. Ton navigateur divulgue passivement, au moment de charger n’importe quelle page, une combinaison de signaux : rendu canvas, GPU, polices installées, résolution d’écran, timezone, plugins actifs. Pris ensemble, ils forment une empreinte suffisamment unique pour t’identifier à travers les sites, sans cookie, sans identifiant visible.

C’est la technique de tracking post-cookie des réseaux adtech et des data brokers, Meta Pixel, Google Analytics, et des dizaines d’acteurs moins visibles. Elle fonctionne en navigation privée. Elle survit à la suppression des cookies. Et elle n’a rien à voir avec ton resolver DNS : tu peux passer par Quad9 chiffré, ton empreinte navigateur reste aussi lisible.

Le DNS souverain n’est donc pas une baguette magique. C’est une couche de protection parmi d’autres. Elle bouche le trou le plus visible, le plus systématique, et celui que personne ne regarde.

Idées reçues à démonter

« J’ai un VPN, donc le DNS est couvert »

Pas nécessairement. Un VPN sérieux pousse son propre resolver DNS et force toutes les requêtes dans le tunnel. Un VPN gratuit ou bon marché ne le fait pas, ou le fait mal. Et même avec un VPN sérieux, certaines configurations macOS, des apps qui résolvent par leur propre stack, des fallbacks DHCP, peuvent contourner. Test obligatoire à dnscheck.tools.

« DoH égale privacy »

DoH chiffre le tuyau. Il ne change pas la nature de l’opérateur en face. Activer DoH par défaut dans Chrome, c’est typiquement balancer son DNS chez Cloudflare ou Google. Centralisation et juridiction US sont des questions distinctes du chiffrement, et elles ne disparaissent pas avec un cadenas en plus.

« Je n’ai rien à cacher »

L’argument classique repose sur une hypothèse fausse : que le problème serait ce que toi tu fais. Le vrai problème, c’est ce que d’autres peuvent faire avec tes données. Un historique DNS de plusieurs mois, croisé avec des bases tierces, dessine un profil comportemental dont tu ne contrôles ni l’usage, ni la durée de rétention, ni les destinataires futurs. « Rien à cacher » suppose que tu connais d’avance toutes les manières dont ces données peuvent être réutilisées contre toi. Personne ne le sait.

« Apple Private Relay, c’est top »

Sur un sous-ensemble du trafic Safari, Private Relay améliore le statu quo. Sur le reste, il ne fait rien. Et il déporte la confiance vers Apple + Cloudflare/Fastly sans alternative configurable. Pour quelqu’un qui n’a aucune envie de toucher aux réglages, c’est mieux que rien. Pour quelqu’un qui essaie d’avoir une stack souveraine cohérente, c’est un placebo qui peut donner un faux sentiment de sécurité.

« Cloudflare 1.1.1.1, c’est rapide et gratuit »

C’est vrai. C’est aussi un cloud américain dont le modèle économique repose sur la collecte agrégée de données réseau, et qui est soumis au CLOUD Act. Pour un utilisateur ordinaire, c’est mieux que le DNS de la box. Pour quelqu’un qui veut sortir des juridictions Five Eyes sur sa stack privacy, c’est un point de départ, pas un point d’arrivée.

Reprendre le contrôle, en trois niveaux

Trois niveaux d’engagement, du plus simple au plus souverain. Chacun est une vraie amélioration. Choisis celui qui correspond à ton temps disponible et à ton seuil de tolérance technique.

Niveau 1, gain immédiat, deux minutes

Tu changes le resolver système macOS pour un opérateur respectueux, en DoH ou DoT, via un profil de configuration. Pas d’app à installer, pas de service à lancer.

Concrètement, les étapes :

Choisis un resolver. Deux candidats sérieux, accessibles sans connaissances techniques particulières : Quad9 (fondation à but non lucratif, Suisse, juridiction nLPD) et Mullvad DNS (Suède, no-logs déclaré, infrastructure auditée Cure53, opérateur transparent). Les deux : un fichier .mobileconfig, deux clics, c’est plié.
Récupère le profil de configuration .mobileconfig officiel sur quad9.net ou mullvad.net selon ton choix.
Double-clique le fichier sur ton Mac, va dans Réglages Système > Confidentialité et sécurité > Profils, valide l’installation.
Vérifie le résultat sur dnscheck.tools : tu devrais voir le resolver choisi, plus ton FAI.

Avantage : deux minutes, zéro maintenance, gain immédiat. Tes requêtes ne sont plus visibles par ton FAI.

Limite : tu confies quand même tes requêtes à un opérateur externe. Quad9 et Mullvad ont des politiques no-log vérifiées et des audits indépendants et c’est autrement plus sérieux que ton FAI. Mais c’est une fondation ou une entreprise, pas toi. Pour ceux qui veulent moins déléguer, on monte d’un cran.

Niveau 2, local-first avec dnscrypt-proxy

Tu installes dnscrypt-proxy sur ton Mac. C’est un petit service local qui devient ton resolver. Il gère DoH, DoT, le protocole DNSCrypt, le cache local, le filtrage de domaines, et surtout l’anti-leak : il intercepte toutes les requêtes système et les force dans son tunnel chiffré, peu importe ce que macOS aurait fait par défaut.

Comment ça marche concrètement : ton Mac demande proton.me. La requête part en 127.0.0.1:53, vers dnscrypt-proxy qui tourne en local. Le proxy chiffre la requête et l’envoie à un ou plusieurs resolvers en anycast (Quad9, Mullvad, des serveurs DNSCrypt communautaires). Les réponses reviennent, sont mises en cache local, et servent ton Mac. Le tout sans que ton FAI voie quoi que ce soit, et avec la possibilité de réveiller plusieurs upstreams pour ne pas mettre tous tes œufs dans le même panier.

Concrètement, les étapes :

Installation : brew install dnscrypt-proxy.
Configuration : éditer /opt/homebrew/etc/dnscrypt-proxy.toml pour activer DoH, désactiver le DNS clair, choisir une liste de resolvers (Quad9, Mullvad, communautaires non-loggés).
Démarrage : sudo brew services start dnscrypt-proxy. Le service s’enregistre et démarre au boot.
Configurer macOS pour utiliser 127.0.0.1 comme seul resolver (Réglages Système > Réseau > avancé > DNS).
Vérifier sur dnscheck.tools : tu vois plusieurs upstreams qui tournent, jamais ton FAI, jamais Cloudflare ou Google.

Avantage : souverain à 80%. Ton Mac ne fait plus confiance à un opérateur unique. Tu peux distribuer la charge sur plusieurs resolvers no-logs européens. Anti-leak natif. Cache local rapide.

Limite : un cran de plus en config initiale, environ trente minutes la première fois. Maintenance ensuite minimale, mises à jour via brew. Tu fais toujours confiance à des resolvers tiers, simplement à plusieurs au lieu d’un seul, et en pouvant en changer en deux lignes de config.

Niveau 3, plein contrôle, Unbound récursif sur VPS perso

Tu montes ton propre resolver récursif. Pas de tiers du tout. Ton Mac interroge ta machine, qui descend la hiérarchie root → TLD → authoritative toute seule, comme une grande. Personne en face ne voit l’agrégat de tes requêtes : chaque serveur autoritaire ne voit que la requête qui le concerne, sans rien savoir du reste.

Comment ça marche concrètement : tu as un VPS chez un hébergeur souverain (Infomaniak en Suisse, Hetzner en Allemagne, etc…). Sur ce VPS tourne Unbound, un serveur DNS récursif open source réputé pour la propreté de son code. Tu connectes ton Mac à ce VPS via Tailscale, donc en tunnel WireGuard chiffré sur réseau privé. Tu configures ton Mac pour utiliser l’IP Tailscale du VPS comme resolver. Les requêtes sont chiffrées dans Tailscale, atterrissent chez Unbound qui fait la résolution récursive, et reviennent. Et parce que tout ton trafic transite dans le tunnel WireGuard Tailscale, ton FAI ne voit même plus le SNI de tes connexions HTTPS : uniquement des paquets chiffrés vers les endpoints Tailscale.

Aucun opérateur commercial ne logue l’ensemble de tes requêtes. Les serveurs autoritaires voient une IP de datacenter européen, pas ton IP résidentielle. Le seul maillon résiduel dans la config de base : les requêtes récursives d’Unbound sortent du VPS en UDP non chiffré. L’éliminer est simple : configurer Unbound en mode forward-tls-upstream vers Quad9 ou Mullvad en DoT (port 853), et tout le chemin devient chiffré, ton hébergeur ne voit plus rien non plus.

Concrètement, les étapes :

Provisionner un petit VPS (1 vCPU, 1 Go RAM, suffit largement) chez un hébergeur souverain.
Installer Unbound + DNSSEC validation activée.
Joindre le VPS au mesh Tailscale.
Restreindre Unbound à n’écouter que sur l’interface Tailscale, jamais sur l’interface publique.
Configurer macOS pour utiliser l’IP Tailscale du VPS comme seul resolver.

Avantage : souveraineté maximale sur le DNS. Aucun opérateur tiers. Validation DNSSEC bout à bout. Tu peux ajouter tes propres listes de filtrage (publicité, trackers, télémétrie Apple, télémétrie Microsoft) sans dépendre d’un service externe. Le résolveur t’appartient.

Limite : le frein, c’est l’installation. Compter une demi-journée la première fois si tu n’as jamais touché à Unbound. Une fois en place, la maintenance est minimale, mise à jour mensuelle du paquet et logs occasionnels. Tu paies un VPS, quelques euros par mois.

C’est excessif pour la plupart des particuliers, mais cohérent quand le reste de la stack est déjà souverain (mail, drive, password manager, mesh) et que le DNS resterait sinon le seul maillon centralisé.

À lire : Souveraineté digitale en pratique

Ce qui reste exposé, et comment le fermer

Le DNS souverain ferme le trou le plus systématique. Trois autres existent.

Le SNI (Server Name Indication) : pendant la poignée de main TLS, ton navigateur annonce en clair le domaine de destination. Même avec un DNS parfait, cette info reste lisible par les acteurs réseau, tant qu’ECH n’est pas déployé côté serveur.

L’adresse IP de destination reste visible. Pour les services derrière un grand CDN partagé, l’IP seule ne dit pas grand chose. Pour un site auto-hébergé sur un VPS dédié, elle suffit à l’identifier.

Le fingerprinting navigateur : rendu canvas, GPU, polices, timezone forment une empreinte cross-site que les adtech utilisent indépendamment du DNS, et qui survit à la navigation privée. Ni le DNS souverain, ni Tailscale n’y changent quoi que ce soit : c’est une couche applicative, dans le navigateur. La réponse est ailleurs, Firefox avec arkenfox, Brave avec sa randomisation native, ou des extensions comme CanvasBlocker. Sujet à part entière, article à venir.

La parade pour le SNI et l’IP : Tailscale avec exit node. Tout ton trafic transite dans un tunnel WireGuard chiffré. Ton FAI ne voit plus ni les requêtes DNS, ni le SNI, ni la destination. DNS souverain + Tailscale exit node, c’est le combo qui ferme ces deux portes d’un coup.

DNS souverain seul, c’est la première brique. DNS souverain + Tailscale exit node, c’est la stack réseau réellement blindée. L’architecture Tailscale, c’est donc la suite et, promis, on t’explique tout ça en détail, dans un nouvel article à venir bientôt.

En résumé

Le DNS, c’est l’annuaire d’internet. Par défaut sur la plupart des connexions, il fonctionne en clair, et ton FAI voit chaque domaine que tu visites avec horodatage. Le HTTPS ne change rien à ça : il chiffre le contenu, pas la destination. Et un VPN mal configuré peut laisser fuir le DNS hors du tunnel sans que tu t’en rendes compte.

Les solutions faciles sont en réalité des déplacements de problème. Activer DoH par défaut, c’est typiquement basculer chez Cloudflare ou Google, des clouds américains soumis au CLOUD Act. iCloud Private Relay couvre Safari et oublie le reste, en redonnant les clés à Apple et Cloudflare sur la partie qu’il couvre. Tu n’as pas supprimé le fouineur, tu en as juste changé.

Reprendre le contrôle se fait en trois niveaux gradués : gain immédiat avec Quad9 ou Mullvad DNS en DoH, deux minutes via profil de configuration. Local-first avec dnscrypt-proxy sur ton Mac, anti-leak natif et multi-resolvers, en trente minutes. Plein contrôle avec Unbound récursif sur un VPS perso joint à ton mesh Tailscale, exit node activé, demi-journée d’install, DNS et SNI réglés d’un coup.

Concrètement, les actions :

Teste maintenant tes fuites DNS sur dnscheck.tools. Si ton FAI ou Cloudflare apparaissent et que ce n’était pas un choix conscient, tu sais ce que tu as à faire.
Choisis un niveau d’engagement honnête avec ton temps. Niveau 1 immédiat, c’est mieux que niveau 3 jamais.
Si tu as déjà une stack privacy ailleurs (VPN, Proton, Tailscale), assure-toi que le DNS n’est pas le maillon faible qui révèle ce que le reste protège.

Le DNS, c’est la première brique d’une souveraineté réseau cohérente. Sans elle, le reste est en partie du théâtre. Avec elle et Tailscale en exit node, c’est une stack réellement blindée.

Voir aussi

Des termes techniques ? Consulte le glossaire.

NIS2 oblige les entreprises à chiffrer. CSAR leur interdit de le faire vraiment.

Mac Souverain — Sat, 18 Apr 2026 13:46:22 GMT

MAJ juillet 2026. Le calendrier a bougé : le 9 juillet, le Parlement européen a laissé passer la reconduction de Chat Control 1.0, faute des 361 voix nécessaires pour bloquer alors que la majorité votait contre, avec l’E2E explicitement exclu de ce texte. Le CSAR 2.0, celui qui contredit NIS2 et qui est décrit ici, repart en trilogue en septembre : le « 4 mai » évoqué plus bas est périmé. Détails dans le radar.

Bruxelles a une idée brillante : t’obliger à chiffrer tes données. Elle a aussi une autre idée, moins brillante mais plus totalitaire, pouvoir les lire quand elle veut.

Ce ne sont pas deux politiques venues de deux institutions différentes. C’est la même Commission européenne, à quelques mois d’écart, qui signe les deux textes (si, si, c’est possible, je t’assure : bienvenue en absurdie).

NIS2 te contraint à sécuriser sous peine de sanctions. CSAR 2.0 te contraint à laisser une porte ouverte pour que l’on puisse t’espionner à bon compte.

Et, comme tout bon méli-mélo de textes pondus par nos chers technocrates européens, sous la pression de nos chers politiques, la main droite ne semble pas savoir ce que fait la main gauche.

Voici ce que ça veut dire concrètement pour ta protection numérique, et pourquoi cette incohérence n’est pas un accident.

NIS2 : l’UE découvre (enfin) la cybersécurité

La directive NIS2 est entrée en vigueur en janvier 2023. Elle s’appelait NIS1 avant, elle concernait environ 500 entités en France. NIS2 élargit le périmètre à 15 000-18 000 entités françaises selon l’ANSSI.

Ce ne sont plus seulement les opérateurs d’infrastructures critiques, c’est toute entreprise atteignant 50 salariés et 10 millions d’euros de chiffre d’affaires, ou de bilan, dans les secteurs couverts. La santé, l’énergie, les transports, le numérique, les finances. Le secteur hospitalier figure en Annexe I, hautement critique.

L’article 21 est le cœur du dispositif. Il liste dix catégories de mesures obligatoires, dont le chiffrement des données en transit et au repos, l’authentification multifacteur (MFA), et la mise en place de communications sécurisées. En langage humain : si tu gères des données dans un secteur concerné, chiffrer n’est plus un conseil, c’est une obligation légale.

La nouveauté structurelle de NIS2, c’est l’article 20. La responsabilité ne pèse plus seulement sur la société, elle pèse sur la personne physique qui dirige. Pas de DSI bouc émissaire, pas de « notre prestataire s’en chargeait ». Les organes de direction sont personnellement responsables de la mise en conformité (Doc, si t’es là, ton cabinet va pas désemplir, je connais des dirigeants qui vont droit vers la prise de tranxène).

La France, elle, est en retard (Ben comme d’hab, non ?). La deadline de transposition fixée par l’UE était le 17 octobre 2024. On approche de mai 2026 (essaie de faire ça avec une de tes échéances, et on en reparle) et le texte n’est toujours pas voté à l’Assemblée nationale. Ce retard n’exonère pas : les obligations NIS2 arrivent, la question est quand, et pas si.

Et dans le projet de loi français, un article sort du lot. L’article 16 bis du projet de loi interdit explicitement d’imposer des accès forcés dans les outils de chiffrement. Aucun fournisseur de solutions de chiffrement ne peut être contraint de laisser un accès imposé à leurs outils.

C’est là que les choses deviennent intéressantes.

CSAR : l’UE veut lire ce qu’elle vient de te demander de chiffrer

Le CSAR, officiellement Child Sexual Abuse Regulation, est l’autre texte. Si tu veux le détail complet du mécanisme et du dossier politique, l’article sur le Chat Control 2.0 l’explique intégralement.

Tu verras que si l’objectif est louable et que nous le partageons tous, les modalités de son application relèvent plus de pratiques totalitaires d’un autre temps, que de la saine démocratie.

La version courte :

Le CSAR obligerait les messageries à scanner le contenu de tes messages sur ton appareil, avant qu’ils soient chiffrés. Le terme technique est « client-side scanning ».

En pratique : ton message est lu sur ton appareil, avant d’être chiffré et envoyé. En France, accéder au contenu d’une correspondance sans autorisation est un délit aggravé quand c’est un agent public qui s’en charge. Apparemment, quand tu es l’Europe, tu peux, et ça ne te chiffonne pas.

Le chiffrement de bout en bout reste « techniquement intact » pendant le transport, mais il a été contourné avant de s’appliquer. Scanner avant de chiffrer, c’est chiffrer pour la galerie.

L’état du dossier au moment de la publication : le Conseil de l’UE a adopté sa position le 26 novembre 2025. Les trilogues, ces négociations opaques entre Parlement, Conseil et Commission où le texte final se fabrique en coulisses, ont commencé. Prochain trilogue : 4 mai 2026. Adoption formelle visée : juillet 2026.

Les termes ont évolué depuis la première version : « client-side scanning » s’appelle désormais « mesures d’atténuation des risques » dans les documents officiels. L’emballage est plus présentable. L’effet sur ta machine est identique.

La même Commission européenne qui a produit NIS2 pousse CSAR. Ce n’est pas une métaphore.

À lire : Chat Control 2.0 : l’UE veut lire tes messages avant que tu les envoies : mécanisme complet, Signal, Proton, et ce que tu peux faire.

La contradiction fondamentale

Posons les deux textes côte à côte.

NIS2, article 21 : chiffrement des données en transit et au repos, MFA, communications sécurisées. Obligation légale, responsabilité personnelle du dirigeant, sanctions en cas de non-conformité.

CSAR : scanning des messages avant chiffrement sur chaque appareil, sans mandat judiciaire, sans notification à l’utilisateur, pour toutes les communications, pas seulement les communications suspectes.

Le scan lit vraiment tout, et une IA décide de ton sort. Les faux positifs vont être grandioses. Gageons que la perquisition à six heures du mat, avec plates excuses à la clé, ou non, va l’être tout autant.

Pourquoi ces deux textes sont physiquement incompatibles : pour scanner un contenu « avant chiffrement », il faut qu’il soit accessible, à un moment donné, en clair, par un processus tiers. Ce processus crée un point d’accès obligatoire : assumé et légalisé, dans le cas de CSAR. Cette disposition est totalement incompatible avec les objectifs de NIS2.

C’est précisément ce que le droit français, dans le projet de loi de transposition de NIS2, via son article 16 bis, interdit d’imposer aux fournisseurs de chiffrement.

La même Commission a rédigé les deux textes. Le commissaire à la sécurité numérique supervise NIS2. Le commissariat à l’intérieur pousse CSAR. Ce ne sont pas deux ministères ennemis. En France, même schéma : l’ANSSI publie des référentiels de sécurité, la DGSI remonte ses besoins à son ministre, là encore, les intérêts divergent.

Le COM(2025)740 final (27 novembre 2025), rapport d’évaluation de la Commission elle-même, admet que le dispositif ne permet pas d’établir de lien démontrable entre les signalements générés et des condamnations réelles, ni de quantifier le nombre d’enfants effectivement identifiés grâce à lui.

Ce n’est pas une critique externe. C’est l’institution porteuse du texte qui, dans son propre bilan, reconnaît l’impossibilité méthodologique de valider l’outil qu’elle entend imposer à 450 millions d’Européens.

On construit l’infrastructure pour un espionnage de masse.

Son prétexte ne tient pas, à l’aune de la technique implémentée et des résultats non prouvés.

Ce que ça dit sur ta protection

NIS2 reste un bon texte. L’obligation de chiffrer, de prendre la cybersécurité au sérieux, de responsabiliser les dirigeants, ce sont de vraies avancées. Si tu es dans une entité concernée, NIS2 va te forcer à faire ce que tu aurais dû faire il y a dix ans. Ce n’est pas le problème.

Le problème, c’est ce que cette incohérence révèle sur la solidité de ta protection.

La protection numérique individuelle ne peut pas reposer sur la cohérence réglementaire des institutions. Elles se contredisent structurellement. NIS2 t’oblige à chiffrer aujourd’hui. CSAR veut rendre ce chiffrement contournable demain. La loi qui te protège et la loi qui t’espionne peuvent coexister dans le même corpus juridique, avec la même légitimité formelle.

Ce qui te protège vraiment, c’est la conception technique, pas la conformité légale.

Signal ne peut pas implémenter le client-side scanning sans casser son modèle architectural. C’est la raison pour laquelle Meredith Whittaker a dit préférer quitter le marché européen plutôt que de le faire. Ce n’est pas une posture : c’est une impossibilité technique déguisée en position politique. Proton fonctionne sur le même principe.

Un outil dont la conception technique rend le scan impossible est protégé autrement qu’un outil qui « respecte la loi en vigueur ». La loi peut changer. L’architecture, elle, demeure. C’est ta garantie.

Pour les entreprises concernées par NIS2, une nuance s’impose : cette conformité reste obligatoire et nécessaire. Chiffrer tes données en transit et au repos, mettre en place la MFA, sécuriser tes communications internes, ce sont des obligations réelles avec des sanctions réelles si non tenues.

Les implémenter avec des outils dont la conception est solide, dont le code est audité, dont la juridiction est favorable, c’est empiler deux couches de protection plutôt qu’une seule. NIS2 et la prudence architecturale ne sont pas en opposition. Ils devraient se compléter.

Ce qui ne tient pas, c’est de croire que « conformité NIS2 = protection complète » si CSAR passe. La conformité légale devient un filet insuffisant, le jour où une autre loi crée une brèche dans ce que la première exigeait de construire.

L’article 16 bis du projet de loi français, celui qui interdit le scan dans les outils de chiffrement, est une ligne de défense réelle. Le fait qu’il coexiste dans le même projet de loi que les obligations de NIS2 est encourageant. Le fait qu’il soit en friction politique avec CSAR, porté par la même Commission, donne une idée du terrain sur lequel cette tension va se jouer dans les prochains mois.

En résumé

Deux textes, une même institution, deux directions opposées. NIS2 t’oblige à chiffrer, responsabilise tes dirigeants et, pour la France, interdit explicitement le scanning dans les outils de chiffrement. CSAR veut scanner avant le chiffrement, c’est-à-dire contourner le chiffrement par conception, sans mandat judiciaire, pour toutes tes communications.

Ce n’est pas une contradiction surmontable par un amendement. C’est une incohérence structurelle entre deux priorités institutionnelles incompatibles : sécuriser et surveiller.

Concrètement, les points d’attention :

1. Si tu es concerné par NIS2, avance sur la conformité sans attendre le vote français. Les obligations arrivent, retard de transposition ou pas.

2. Choisis des outils dont la conception technique rend l’accès forcé impossible, pas seulement des outils qui « respectent les réglementations en vigueur ». Les réglementations bougent. L’architecture, moins.

3. Suis les trilogues CSAR : 4 mai 2026 est le prochain point de bascule. La pression publique a fonctionné sur Chat Control 1.0.

Pour aller plus loin sur le chiffrement de bout en bout, et pourquoi ça reste le seul rempart solide, l’article sur ce sujet arrive prochainement.

L’article sur le CSAR reste la référence pour le mécanisme détaillé, les positions de Signal et Proton, et les actions concrètes que tu peux prendre maintenant.

À lire : Chat Control 2.0 : l’UE veut lire tes messages avant que tu les envoies

Si la question de la souveraineté numérique te concerne au-delà du seul cadre réglementaire, le concept de base est posé dans l’article fondateur.

À lire : La souveraineté digitale, c’est quoi concrètement ?

La page ANSSI dédiée à NIS2 recense les secteurs concernés et les obligations en détail.

Chat Control 2.0 : l'UE veut lire tes messages avant que tu les envoies

Mac Souverain — Sat, 18 Apr 2026 13:46:19 GMT

MAJ juillet 2026. Le calendrier de cet article est dépassé : le trilogue du 4 mai a eu lieu, et le 9 juillet le Parlement européen a laissé passer la reconduction de Chat Control 1.0 (scanning volontaire), non par un vote pour mais faute des 361 voix requises pour bloquer, alors que la majorité votait contre. Le chiffrement de bout en bout est explicitement exclu de ce texte. Le vrai combat, le CSAR (2.0) décrit ci-dessous, repart en trilogue en septembre. Détails dans le radar.

Tu envoies un message à un ami sur Signal. Chiffré de bout en bout, personne ne peut le lire entre toi et lui. C’est le principe, c’est la promesse, c’est ce qui fait que des centaines de millions de personnes utilisent des messageries chiffrées.

L’Union européenne trouve que c’est un problème.

Sous couvert de lutter contre la pédopornographie, la Commission européenne pousse un règlement qui obligerait chaque messagerie à scanner le contenu de tes messages avant qu’ils soient chiffrés. Signal menace de quitter l’Europe. Proton dit préférer être bloqué. Apple ne dit rien. Et c’est peut-être le plus inquiétant.

À lire : Radar Chat Control 2.0 : l’UE veut scanner tous tes messages

Le problème : un mouchard sur ton propre appareil

Imagine un facteur qui lirait systématiquement chaque lettre que tu postes, la comparerait à une liste noire, puis la glisserait dans une enveloppe scellée. L’enveloppe est bien fermée, personne ne peut l’ouvrir en chemin. Mais le facteur a déjà tout lu.

C’est exactement ce que le CSAR (Child Sexual Abuse Regulation) imposerait aux messageries chiffrées. Le terme technique est « client-side scanning ». En langage humain : ton appareil scanne le contenu de tes messages, photos et fichiers avant de les chiffrer et de les envoyer. Le résultat du scan est comparé à une base de données de contenus illicites. Si une correspondance est détectée, signalement automatique aux autorités.

Le chiffrement de bout en bout reste « techniquement » intact. Le message est bien chiffré pendant le transport. Sauf qu’il est lu avant.

Un chiffrement qu’on contourne avant qu’il s’applique, c’est un chiffrement de façade.

Le mécanisme : comment ça fonctionne concrètement

Le scanning côté client repose sur trois étapes, toutes exécutées sur ton appareil.

Interception pré-chiffrement : au moment où tu tapes un message ou attaches une photo, le contenu est capturé en clair, avant que le protocole de chiffrement E2E ne s’applique. C’est la clé du mécanisme : le chiffrement n’est jamais « cassé », il est contourné.
Comparaison par hash perceptuel : le contenu est converti en empreinte numérique et comparé à une base de données d’empreintes de contenus connus. Le problème des faux positifs est documenté : des photos de famille, des images médicales, des mèmes ont déjà déclenché des signalements erronés dans les systèmes existants de Google et Meta.
Signalement automatisé : si correspondance, transmission aux autorités sans intervention humaine et sans notification à l’utilisateur. Tu ne sais pas que tu as été signalé. Tu ne peux pas contester avant que le processus soit enclenché.

Le tout fonctionne en silence, en arrière-plan, sur chaque message envoyé par chaque utilisateur. Le plus beau : sans aucun mandat judiciaire. La porte ouverte à tous les abus administratifs.

C’est de l’espionnage de masse par conception, sous couvert de démocratie bien proprette.

Et c’est là que l’analogie du facteur atteint ses limites. Le facteur, tu peux le voir. S’il se fait attraper, c’est délit aggravé direct. Case prison probable.

Le scanner intégré à ton propre appareil, lui, il est tranquilou. Si tu ne lis pas mes articles, tu n’es même pas au courant qu’il est juste là, à travailler sous ton nez.

Ce que ça change concrètement

Deux textes, deux destins

Il faut démêler deux choses qui circulent souvent confondues.

Chat Control 1.0, dans sa version la plus agressive, n’a pas été prolongé, c’est vrai. Mais la réalité est plus nuancée. Le 11 mars 2026, le Parlement européen a voté à 458 voix pour l’extension de la dérogation ePrivacy jusqu’au 3 août 2027. L’ancienne dérogation expirait le 3 avril 2026. La résolution protège explicitement le chiffrement de bout en bout : les mesures ne peuvent pas s’appliquer aux communications E2EE. Ce n’est pas « Chat Control 1.0 est mort ». C’est une victoire partielle : le scanning E2EE obligatoire est écarté, une extension limitée est votée, et le temps laissé au texte permanent CSAR de se négocier. Prochains trilogues CSAR : 4 mai 2026 et 29 juin 2026.

Chat Control 2.0, officiellement baptisé CSAR, c’est une autre histoire. Et c’est celle-là qui est en jeu.

Le Conseil de l’UE a adopté sa position le 26 novembre 2025, vote serré, Pologne et Pays-Bas contre. Depuis décembre 2025, le texte est en trilogue : la phase de négociation entre Parlement, Conseil et Commission où le texte final se fabrique. Ces négociations sont opaques par design. Les positions des trois parties ne sont pas publiques, les compromis se font en coulisses.

Prochain trilogue : 4 mai 2026. Adoption formelle visée : juillet 2026.

Les termes ont changé depuis la première version. « Client-side scanning » est devenu « mesures d’atténuation des risques » et « activités volontaires de détection ». L’emballage est plus présentable. L’effet pratique est identique selon l’EDRi, l’EFF et noyb.

Signal, Proton, Apple : trois réponses très différentes

Signal a été direct. Meredith Whittaker, directrice exécutive, déclarait en octobre 2025 que Signal prendrait « malheureusement la décision de quitter le marché européen » plutôt que de compromettre son chiffrement. Signal est une association à but non lucratif. Pas d’actionnaires, pas de revenus publicitaires, pas d’obligations de marché. Quand ils disent ça, c’est crédible.

Proton, juridiction suisse, même posture : « we’d rather be blocked ». La Suisse n’est pas dans l’UE, Proton bénéficie d’une distance juridique réelle vis-à-vis du droit européen. Le CSAR ne s’appliquerait à Proton que si Proton opère dans l’UE via ses utilisateurs européens, mais la marge de manœuvre juridique est plus large qu’un simple « on se plie ou on ferme ».

Apple n’a rien dit publiquement sur le CSAR.

Ce silence est significatif. En décembre 2022, Apple avait abandonné son propre projet de client-side scanning pour les photos iCloud, après un backlash massif de la communauté des chercheurs en sécurité. Le message semblait clair : pas de scanning côté client.

Sauf qu’Apple n’est pas Signal. Apple est une entreprise cotée en bourse, avec des Apple Store physiques dans toute l’Europe, des filiales locales, un chiffre d’affaires européen qui se compte en dizaines de milliards. Signal peut dire « on ferme ». Apple, plus difficilement.

Pour un utilisateur Mac, c’est l’angle le plus inconfortable. Tu utilises iMessage au quotidien, tu fais confiance au chiffrement E2E d’Apple, et l’entreprise qui le fournit n’a pas pris position publique sur la menace la plus directe qui pèse sur ce chiffrement.

Le pattern mondial : même prétexte, même infrastructure

L’Europe n’agit pas dans le vide.

Aux États-Unis, l’EARN IT Act suit exactement la même logique : même prétexte (protection des enfants contre le CSAM), même effet (destruction du chiffrement de bout en bout), même stratégie rhétorique. Qui pourrait être contre la protection des enfants ? Personne. C’est précisément pour ça que c’est le levier choisi.

Ce n’est pas une coïncidence. C’est un pattern. Des deux côtés de l’Atlantique, des législateurs utilisent la cause la plus moralement inattaquable pour créer l’infrastructure technique d’une surveillance généralisée. L’infrastructure, une fois construite, ne disparaît plus.

Quand un juge suffit

En mars 2026, un tribunal du Nouveau-Mexique a condamné Meta à 375 millions de dollars pour pratiques déloyales envers les mineurs. Dans ce procès, le procureur général avait présenté la décision de passer Messenger en E2E par défaut comme un « choix de conception » ayant rendu plus difficile la transmission des signalements aux forces de l’ordre. Le juge a suivi, créant ainsi une jurisprudence.

L’argument du « design choice » est redoutable : si cet angle juridique fait école, toute décision d’améliorer la sécurité des utilisateurs peut devenir une preuve à charge dans un futur procès. Pourquoi ajouter du chiffrement ? Un avocat en fera « un outil délibéré de protection des criminels ». Cette logique est juridiquement crédible, et elle vient d’être testée avec succès.

Ce jugement ne concerne que Meta, aux États-Unis. Mais Apple est également exposée juridiquement sur le sol américain. Si ce précédent fait école, la pression sur iMessage sera d’une nature différente de celle sur Signal. Signal peut dire « on ferme » sur une zone géographique. Apple, non.

Quand la Commission avoue que ça ne sert à rien

Le rapport d’implémentation COM(2025)740, publié par la Commission européenne elle-même, contient un aveu remarquable : il n’est actuellement pas possible d’établir un lien clair entre les signalements soumis par les prestataires et les condamnations prononcées, ni de fournir un aperçu fiable du nombre d’enfants secourus.

Ce n’est pas un argument de militant libertaire. C’est la Commission, dans son propre document d’évaluation, qui reconnaît que l’outil qu’elle veut imposer à 450 millions d’Européens n’a pas de résultats démontrables.

On crée une infrastructure de scanning généralisé des communications privées sans pouvoir démontrer qu’elle protège qui que ce soit.

Le seul résultat garanti, c’est la surveillance elle-même.

Les limites : idées reçues et fausses évidences

« C’est pour protéger les enfants, donc c’est légitime »

L’objectif est légitime. Le moyen ne l’est pas. Lutter contre la pédocriminalité, tout le monde est d’accord. Mais créer un système qui scanne chaque message de chaque citoyen pour attraper une infime minorité de criminels, c’est de l’espionnage de masse.

Cela renvoie directement aux États totalitaires. Ceux que l’Europe et la France ne manquent pas de brocarder, à grands coups de défense des droits de l’homme et de libertés publiques.

Et les spécialistes de la protection de l’enfance, y compris au sein de la société civile européenne, pointent des alternatives ciblées plus efficaces : renforcement des moyens des forces de l’ordre, coopération internationale, détection comportementale côté serveur sur les plateformes non chiffrées. Le scanning de masse n’est pas le seul outil. C’est le plus intrusif.

« Le chiffrement est protégé dans le texte »

Le texte du CSAR contient effectivement une clause de protection du chiffrement. Mais cette clause coexiste avec l’obligation de scanner les contenus avant chiffrement. C’est comme garantir l’inviolabilité du courrier tout en exigeant que le facteur le lise avant de le cacheter.
Du vrai foutage de gueule.

« Ça ne concerne que les criminels »

Non. Le scanning est systématique, appliqué à toutes les communications, pas aux communications suspectes. Il n’y a pas de mandat judiciaire. Il n’y a pas de ciblage. Si tu utilises une messagerie chiffrée en Europe, tes messages seraient scannés. Tous.

Les faux positifs existent. Des systèmes similaires déployés par Google et Meta ont signalé des parents envoyant des photos de leurs enfants à leur pédiatre. Innocent, scanné, signalé.

« Une fois votée, la loi est irréversible »

Pas nécessairement. La version agressive de Chat Control 1.0 (scanning E2EE obligatoire) a été écartée grâce à la mobilisation citoyenne et au vote du Parlement européen. La pression publique change les votes. Le trilogue du 4 mai 2026 est le prochain point de bascule, et le texte n’est pas encore gravé dans le marbre.

Le précédent politique

Le vrai danger du CSAR dépasse la question technique du scanning.

Si l’Union européenne, la juridiction qui a inventé le RGPD et qui se présente comme le champion mondial de la protection des données personnelles, normalise le scanning obligatoire des communications privées chiffrées, le signal envoyé au reste du monde est dévastateur.

Chaque gouvernement qui rêve de surveiller les communications de ses citoyens aura un modèle, validé par l’UE, clé en main.

J’ai passé les deux dernières années à construire une infrastructure numérique souveraine, chiffrée, en grande partie auto-hébergée. Signal pour le courant. Matrix pour les messages internes , Proton pour les emails, DNS chiffrés, navigateurs durcis. Par principe, certes, mais aussi pour le Business.

Alors, ce qui me sidère dans ce texte, c’est qu’il est porté par la même institution qui a créé le RGPD. Celle qui se pare de toutes les vertus attachées aux droits de l’homme et aux libertés.

L’espionnage de masse et son infrastructure ne viennent jamais avec une date d’expiration. Une fois en place, ils ne font que s’étendre.

Les bases de données de comparaison, aujourd’hui limitées au CSAM, pourraient demain inclure du contenu terroriste, du contenu extrémiste, du contenu de désinformation. Sauf que pour être caractérisé ainsi aujourd’hui, un contenu doit répondre à des critères précis, légaux, qu’un juge doit confirmer.

Sans contrôle de justice, avec un brin d’élan, on pourrait facilement glisser sur des sujets comme les avis politiques divergents, le journalisme d’investigation qui dérange (Rhaaa! Mediapart et le Canard, poils à gratter des élus…) le secteur syndical, les ONG qui font trop de buzz là où ça fait mal, le secret médical, bref, tout ce qu’un dirigeant totalitaire pourrait rêver pour égayer ses journées.

Tout ça par le simple biais administratif, sans mandat, et sans juge. Franco doit s’en vouloir à mort d’avoir loupé ça.

Les catégories sont élastiques par nature. L’infrastructure retenue crée le cadre de l’extension.

Ce que tu peux faire

Tu ne peux pas empêcher un trilogue de se tenir. Mais tu peux rendre la surveillance plus difficile à appliquer sur tes propres appareils, et tu peux peser sur le résultat politique.

Protège tes communications

Signal pour tes conversations. C’est la seule messagerie, E2EE de bout en bout, dont l’opérateur a publiquement déclaré qu’il préférait fermer le service en Europe, plutôt que de compromettre son chiffrement.

Open source, sans publicité, sans collecte de données. Financé par donations, dont 50 millions de dollars de Brian Acton, cofondateur de WhatsApp, à la création de la Signal Foundation en 2018. Pas d’actionnaires, pas de modèle publicitaire : aucun intérêt économique à monétiser tes messages.

J’utilise Matrix/Elements parce que je self-host en mode privacy maximum, mais Signal au quotidien, pour des messages chiffrés sans complications, est le choix de référence. Si tu devais utiliser un seul outil de cette liste, ce serait ma reco.

Proton Mail pour tes emails. Chiffrement de bout en bout, juridiction suisse, même posture que Signal face au CSAR. Tes emails professionnels, bancaires, administratifs n’ont rien à faire sur Gmail et personne ne devrait pouvoir les lire.

À lire : Apple Mail vs Gmail vs Proton Mail : le comparatif honnête

À lire : Migrer de Gmail vers Proton Mail

Réduis ta surface d’exposition

VPN comme couche supplémentaire. Si Signal ou Proton venaient à être géo-bloqués en Europe, un VPN avec une IP hors UE te donnerait accès au service. Mullvad est celui que je recommanderais : pas de compte, pas d’email, paiement en cash ou crypto, juridiction suédoise. Le VPN ne remplace pas le chiffrement de la messagerie, il le complète en masquant ton accès.

DNS souverain. Change les résolveurs DNS de tous tes appareils. Si les FAI européens sont contraints de bloquer des domaines, un résolveur hors juridiction UE court-circuite ce blocage. Quad9 (9.9.9.9), géré par une association suisse à but non lucratif, ne journalise pas tes requêtes.

Pour chiffrer les requêtes DNS nativement sur Mac et iPhone, installe le profil de configuration DoH de Quad9 depuis leur page documentation (docs.quad9.net, section Apple). Dix minutes bien investies.

Si Signal ou Proton quittent l’Europe ?

C’est la question pratique. Si la loi passe et que Signal ou Proton mettent leur menace à exécution, comment continuer à les utiliser ?

Signal distribue son APK Android directement sur signal.org. Sur iOS, le DMA (Digital Markets Act), en vigueur depuis mars 2024, ouvre la porte au sideloading. Signal pourrait distribuer son application via un canal alternatif, hors App Store. C’est techniquement faisable.

Proton est E2EE natif : tes emails et fichiers sont chiffrés par conception, Proton n’y a pas accès. Confidentialité maximale par défaut. Si un blocage géographique intervenait, un VPN avec une IP hors UE suffit à le contourner. Le VPN est lui aussi chiffré de bout en bout : deux couches indépendantes.

Nuance importante : « quitter le marché » serait d’abord une menace de négociation, un signal politique. Des recours judiciaires passeraient en premier. Signal et Proton le savent. Les législateurs aussi. C’est un jeu de pression, pas un ultimatum immédiat.

À lire : Pourquoi tu as besoin d’un VPN

Pèse sur le résultat

Le trilogue du 4 mai 2026 est le prochain point de bascule. La pression publique fonctionne : le vote sur Chat Control 1.0 le prouve. La version agressive a été écartée par la mobilisation citoyenne.

L’EDRi (European Digital Rights) et Patrick Breyer, ancien eurodéputé Pirate et l’une des voix les plus constantes contre ce texte, maintiennent des outils de contact direct avec les eurodéputés. Utilise-les. Écris à tes représentants. Ce n’est pas du militantisme de salon, c’est de la démocratie appliquée.

Le CSAR n’est pas encore voté. Il n’est pas encore mort non plus.

En résumé

L’Union européenne prépare un règlement qui transformerait chaque smartphone en mouchard silencieux, scannant chaque message avant qu’il soit chiffré. L’objectif affiché est la protection des enfants. L’effet réel est une infrastructure de surveillance de masse dont même la Commission ne peut pas prouver l’efficacité.

Signal et Proton ont tracé une ligne : plutôt quitter l’Europe que compromettre leur chiffrement. Apple n’a rien dit. Pour un utilisateur Mac qui fait confiance à iMessage au quotidien, ce silence devrait poser question.

Installe Signal. Utilise Proton Mail. Change tes DNS. Contacte tes eurodéputés avant le trilogue du 4 mai. Ce sont des actions concrètes, faisables aujourd’hui, qui réduisent ton exposition quoi qu’il arrive.

Migrer de Gmail vers Proton Mail sur Mac

Mac Souverain — Thu, 09 Apr 2026 12:15:14 GMT

Introduction

MAJ juillet 2026. La faille Hide My Email désanonymise les alias Apple (divulgation publique le 1er juillet, toujours pas corrigée). Un argument de plus pour les alias souverains : voir la mise à jour du comparatif email.

MAJ mai 2026. Une raison de plus de migrer : Proton Mail propose désormais le chiffrement post-quantum pour les nouveaux emails, gratuit inclus. Tes communications restent illisibles même pour un futur ordinateur quantique qui aurait stocké les versions chiffrées d’aujourd’hui. Détails dans le radar.

Gmail, c’est comme cet appartement en colocation où le propriétaire lit ton courrier. Pas méchamment, juste systématiquement. Depuis 2004. Pour te proposer de la publicité.

Passer à Proton Mail, c’est récupérer les clés. Tes emails entre utilisateurs Proton sont chiffrés de bout en bout, clés générées sur tes appareils, Proton n’y a techniquement pas accès. Pour les emails entrants depuis l’extérieur (depuis Gmail, par exemple), Proton les chiffre à réception avec ta clé publique, et toi seul peux les déchiffrer. Dans les deux cas, Proton ne peut pas lire tes emails, même contraint légalement.

La migration elle-même est plus simple qu’elle n’en a l’air. Compte 30 minutes pour un compte léger, 1 à 2 heures si tu as des années d’archives Gmail. À la fin, tu auras tous tes anciens emails dans Proton, tes contacts importés, et Gmail redirigera automatiquement les nouveaux messages vers ta boîte Proton pendant la transition.

À lire : Apple Mail vs Gmail vs Proton Mail : le comparatif honnête pour comprendre pourquoi Proton Mail est architecturalement différent.

Avant de commencer

Ce qu’il te faut :

Un Mac sous macOS 12 Monterey ou plus récent
Un compte Gmail actif avec accès IMAP activé (activé par défaut sur la plupart des comptes)
Un compte Proton Mail (le plan gratuit suffit pour tester ; si tu as plus de 1 Go d’emails, un plan payant sera nécessaire, voir Étape 1)
Entre 30 minutes et 2 heures selon le volume de ta boîte

Ce que ça va changer :

Tes emails transitent désormais par les serveurs de Proton (Suisse), chiffrés côté serveur
Tu accèdes à ta boîte depuis l’app Proton Mail sur Mac (payante, essai 14 jours gratuit) ou depuis le web sur mail.proton.me, ou depuis Apple Mail avec Proton Bridge (plan payant requis pour Bridge)
Ta nouvelle adresse est en @proton.me (ou @protonmail.com)

Ce que ça ne changera pas tout de suite :

Tes emails existants sur Gmail restent là jusqu’à ce que tu les importes
Tes abonnements newsletters et comptes enregistrés gardent ton ancienne adresse Gmail jusqu’à ce que tu les mettes à jour manuellement
Tu peux garder Gmail actif en parallèle pendant toute la transition

L’opération est entièrement réversible. Tu ne supprimes rien chez Google à ce stade.

Étape 1 : Créer ton compte Proton Mail

Rends-toi sur proton.me/mail et crée un compte.

Plan gratuit : 1 adresse @proton.me, 500 Mo de stockage de base (extensible à 1 Go en complétant la checklist de démarrage Proton), accès web et app mobile. Easy Switch est disponible sur le plan gratuit, mais le stockage disponible fait office de plafond d’import : avec 1 Go, tu peux importer environ 1 Go d’anciens emails.

Plan Mail Plus : 15 Go de stockage, 10 adresses, support de domaine personnalisé, l’accès à Proton Bridge si tu veux utiliser Apple Mail, et SimpleLogin inclus (un service d’alias email, on en reparle à l’étape 6). Tarif : 3,99 $/mois (facturation annuelle).

Si ta boîte Gmail dépasse 1 Go d’archives, il faudra passer à un plan supérieur ou faire le tri avant de migrer.

💡 Tu peux commencer sur le plan gratuit, importer les 12 derniers mois, et passer à un plan supérieur pour le reste si nécessaire.

Choisis ton adresse soigneusement. prenom.nom@proton.me pour un usage pro, quelque chose de plus court si c’est pour le quotidien. Tu ne pourras pas la changer après.

Étape 2 : Importer tes emails depuis Gmail via Easy Switch

Proton propose un outil d’import intégré qui se connecte directement à ton compte Gmail via OAuth, sans que tu aies à entrer ton mot de passe Gmail dans Proton. Google génère une autorisation temporaire, Proton s’en sert pour lire ta boîte, et c’est tout.

Dans Proton Mail web :

Va dans Paramètres (icône engrenage en haut à droite) > Tous les paramètres
Clique sur Importer via Easy Switch
Sélectionne Gmail
Clique sur Se connecter à Google, une fenêtre OAuth Google s’ouvre
Connecte-toi avec ton compte Gmail et autorise l’accès à ta messagerie

Une fois connecté, Easy Switch affiche tes dossiers Gmail (Boîte de réception, Envoyés, Archives, etc.) et te laisse choisir ce que tu veux importer. Par défaut, il sélectionne tout : Starred, All Mail, Important, contacts et calendriers.

Chemin : Proton Mail web > Paramètres > Tous les paramètres > Importer via Easy Switch > Gmail > Se connecter à Google

Ce que tu dois voir : la liste de tes dossiers Gmail avec les compteurs de messages, et une estimation du temps d’import.

💡 Si tu as des années d’archives, l’import peut prendre plusieurs heures et se fait en arrière-plan. Tu peux fermer l’onglet et revenir plus tard.

Recommandation : importer d’abord les 12 derniers mois pour commencer à utiliser Proton rapidement, puis revenir pour le reste.

Étape 3 : Importer tes contacts

Les emails sans les contacts, c’est moitié moins utile. Google Contacts s’exporte facilement.

Depuis Google Contacts :

Va sur contacts.google.com
Clique sur Exporter dans le menu latéral gauche
Sélectionne Tous les contacts et le format vCard (.vcf)
Télécharge le fichier .vcf sur ton Mac

Chemin : contacts.google.com > Exporter > Tous les contacts > Format vCard

Dans Proton Mail web :

Va dans l’onglet Contacts (icône en haut à gauche)
Clique sur Importer
Sélectionne le fichier .vcf téléchargé
Confirme l’import

Chemin : Proton Mail web > Contacts > Importer > sélectionner le fichier .vcf

Ce que tu dois voir : un récapitulatif du nombre de contacts importés, avec éventuellement des doublons détectés à fusionner.

Étape 4 : Configurer Proton Mail sur Mac

Deux options selon ton abonnement.

Option A : App Proton Mail desktop (plan payant, essai 14 jours)

Télécharge l’app Proton Mail depuis proton.me/mail/download.

C’est une app Electron (comme VSCode), pas une app native AppKit. Ce n’est pas aussi fluide qu’Apple Mail, mais elle gère les emails chiffrés de bout en bout sans configuration supplémentaire.

Attention : l’app desktop est réservée aux plans payants. Les comptes gratuits ont droit à un essai de 14 jours, après quoi l’accès est limité à la version web sur mail.proton.me.

Lance l’app, connecte-toi avec ton compte Proton, et tu accèdes à ta boîte directement.

Option B : Apple Mail via Proton Bridge (plan payant)

Si tu veux continuer à utiliser Apple Mail avec tes emails Proton chiffrés, il te faut Proton Bridge, un outil qui fait la traduction entre Apple Mail et les serveurs Proton en déchiffrant localement sur ton Mac.

Proton Bridge est réservé aux plans payants.

À lire : Proton Bridge + Apple Mail sur Mac, le guide complet avec toutes les étapes de configuration.

Étape 5 : Activer la redirection Gmail vers Proton (optionnel)

Cette étape est facultative mais fortement recommandée pendant la période de transition. Elle permet de ne rien manquer pendant que tu mets à jour tes comptes.

Dans Gmail :

Ouvre Paramètres (icône engrenage en haut à droite) > Voir tous les paramètres
Va dans l’onglet Transfert et POP/IMAP
Clique sur Ajouter une adresse de transfert
Entre ton adresse Proton Mail
Gmail envoie un email de vérification à ton adresse Proton, récupère le code de confirmation
Retourne dans Gmail, entre le code, et active la redirection

Chemin : Gmail > Paramètres > Voir tous les paramètres > Transfert et POP/IMAP > Ajouter une adresse de transfert

Ce que tu dois voir : ton adresse Proton apparaît dans la liste des adresses de transfert avec le statut “Activé”.

💡 Garde cette redirection active pendant 3 à 6 mois. Elle te protège contre les oublis pendant que tu mets à jour tes comptes importants.

Étape 6 : Mettre à jour tes comptes importants

C’est la partie la moins automatisable, et franchement la plus longue. Priorise dans cet ordre :

Comptes critiques en premier : banques, impôts, assurances, médecin, employeur, admin
Comptes courants : e-commerce (Amazon, etc.), services en ligne, abonnements
Réseaux sociaux : LinkedIn, Instagram, etc.
Newsletters : en dernier, ou lors du désabonnement

Une astuce : cherche dans ta boîte Gmail les emails récents contenant “ne pas répondre”, “no-reply” ou “transaction” pour repérer les services actifs.

Mieux que de donner ta vraie adresse partout : utilise SimpleLogin. C’est un service d’alias email racheté par Proton et inclus dans tous les plans payants.

Au lieu de mettre prenom.nom@proton.me sur chaque site, tu crées un alias unique par service (genre amazon.2k6x@simplelogin.co). Les emails arrivent dans ta boîte Proton, mais si un service se fait pirater ou revend ton adresse, tu désactives l’alias et c’est réglé. Zéro spam, zéro fuite de ta vraie adresse. Tu gères tout ça depuis app.simplelogin.io ou directement depuis l’extension navigateur SimpleLogin.

Pour chaque service, connecte-toi, va dans les paramètres compte, et mets à jour l’adresse email — idéalement avec un alias SimpleLogin plutôt que ton adresse Proton directe. Vérifie bien l’email de confirmation sur ta boîte Proton.

Si ça ne marche pas

Problème : l’import s’arrête en cours de route ou semble stagner

Cause probable : Gmail impose une limite de bande passante quotidienne sur les exports IMAP. Si ta boîte est volumineuse, Gmail coupe le flux au bout d’un certain volume.
Solution : ne rien faire. Easy Switch reprend automatiquement le lendemain quand Gmail réinitialise la limite. Pour les très grandes boîtes, l’import peut s’étaler sur plusieurs jours.

Problème : Easy Switch reste bloqué ou affiche une erreur d’autorisation

Cause probable : accès IMAP désactivé sur le compte Gmail, ou compte Google Workspace avec restrictions administrateur.
Solution : dans Gmail > Paramètres > Voir tous les paramètres > Transfert et POP/IMAP > Activer IMAP. Si tu es sur un compte professionnel Workspace, l’admin Google a peut-être désactivé l’accès IMAP tiers, contacte-le.

Problème : l’import est très lent ou semble bloqué

Cause probable : volume d’emails important, serveurs Proton sous charge.
Solution : laisse tourner en arrière-plan. L’import peut prendre plusieurs heures pour des boîtes volumineuses. Proton envoie un email de confirmation à la fin.

Problème : l’email de vérification pour la redirection Gmail n’arrive pas sur Proton

Cause probable : délai de propagation, ou l’email a atterri dans le dossier Spam Proton.
Solution : vérifie le dossier Spam dans Proton. Si toujours absent après 10 minutes, relance la vérification depuis les paramètres Gmail.

Problème : Proton Bridge ne se connecte pas à Apple Mail

Cause probable : mot de passe spécifique à l’application Bridge non copié correctement dans Apple Mail.
Solution : dans Bridge, régénère le mot de passe de l’application et reporte-le dans Apple Mail > Comptes > [compte Proton] > Mot de passe. Voir le guide dédié.

Pour les pressés

Ce que cet article fait : migrer une boîte Gmail vers Proton Mail sur Mac sans perdre d’emails, en conservant une redirection temporaire pendant la transition. L’import se fait via l’outil Easy Switch de Proton (connexion OAuth, aucun mot de passe Gmail à donner à Proton).

Concrètement :

Créer un compte sur proton.me/mail (gratuit pour commencer)
Proton Mail web > Paramètres > Importer via Easy Switch > Gmail > Se connecter à Google
contacts.google.com > Exporter > Tous les contacts > vCard (.vcf)
Proton Mail web > Contacts > Importer > sélectionner le fichier .vcf
App Proton Mail desktop sur proton.me/mail/download (payant, essai 14 jours gratuit) ou version web sur mail.proton.me (gratuit) ou configurer Proton Bridge + Apple Mail (payant)
Gmail > Paramètres > Transfert et POP/IMAP > Ajouter une adresse de transfert = ton adresse Proton
Mettre à jour les comptes importants par ordre de criticité (banques, admin, services, réseaux)

Des termes techniques ? Consulte le glossaire.

Lockdown Mode, pourquoi l'activer

Mac Souverain — Tue, 07 Apr 2026 09:05:30 GMT

Introduction

Fin mars 2026, on apprend l’existence de Coruna, un toolkit de surveillance iOS développé par un sous-traitant militaire américain pour des agences gouvernementales. Problème : il a été exploité pendant quatre ans avant d’être identifié. Volé en interne, revendu à un courtier russe, il a fini entre les mains de groupes d’espionnage russes, puis de cybercriminels asiatiques spécialisés dans la fraude crypto.

L’outil exploite des dizaines de vulnérabilités iOS distinctes réparties en cinq chaînes d’attaque complètes. Il vise les iPhones sous iOS 13 à iOS 17.2.1, soit quatre ans de versions et plusieurs centaines de millions d’appareils potentiellement exposés.

Et face à lui, Lockdown Mode a tenu. Le code de Coruna vérifie activement si Lockdown Mode est activé sur l’appareil cible, et s’il l’est, il ne fait rien. Pas de tentative. Pas de contournement. Abandon complet.

C’est une information concrète, vérifiable, qui dit quelque chose d’important sur la philosophie de sécurité derrière cette fonctionnalité.

Le problème

Quand un outil d’État devient un outil criminel

L’histoire de Coruna suit une trajectoire que les chercheurs en sécurité ont appris à reconnaître depuis les Shadow Brokers et la fuite des outils NSA en 2017 : un outil conçu pour des usages étatiques contrôlés finit par proliférer bien au-delà de son cadre d’origine.

Coruna a été développé par Trenchant, la division espionnage et surveillance de L3Harris, un grand groupe de défense américain. L’outil était prévu pour des agences gouvernementales, dans un cadre légal et opérationnel strictement défini.

Ce qui n’était pas prévu, c’est Peter Williams. Ancien directeur général chez Trenchant, Williams a subtilisé au moins huit zero-days du système interne de L3Harris entre 2022 et 2025, et les a revendus à Operation Zero, un courtier russe en zero-days, pour environ 1,3 million de dollars en cryptomonnaies et biens de luxe. En début d’année 2026, il a été condamné à 87 mois de prison fédérale.

La suite est mécanique : les outils volés passent de Trenchant à Operation Zero, d’Operation Zero à des groupes d’espionnage russes, et de là, inévitablement, à des acteurs qui n’ont aucune contrainte opérationnelle.

Concrètement : le même framework qui était censé cibler des adversaires étrangers précis s’est retrouvé en 2025 dans des attaques watering hole contre des utilisateurs ukrainiens (groupe UNC6353, identifié par Google), puis fin 2025 sur un réseau de faux sites crypto et financiers ciblant n’importe quel iPhone vulnérable.

Le problème que Coruna illustre

Coruna n’est pas un outil écrit à la va-vite par une équipe de hackers opportunistes. C’est cinq ans de recherche et développement, des techniques d’obfuscation JavaScript sur quatre couches, une exploitation chaînée de 23 vulnérabilités distinctes.

Face à ça, la vraie question n’est pas de savoir si ton iPhone peut être compromis. Il peut l’être, si tu utilises une version non patchée sans précaution particulière. La vraie question, c’est comment te protéger efficacement.

Le mécanisme

Coruna : comment ça fonctionne

Coruna est ce que les chercheurs appellent un exploit kit watering hole. Tu n’as pas besoin de cliquer sur un lien piégé ou d’ouvrir une pièce jointe. Il suffit de visiter un site web qui héberge le code malveillant, et ton iPhone fait le reste tout seul.

Le kit enchaîne cinq techniques distinctes :

1. RCE WebKit : une faille d’exécution de code à distance dans le moteur de rendu web d’Apple. C’est la porte d’entrée. Le JavaScript du site déclenche une vulnérabilité dans le moteur JIT (Just-In-Time compilation) de WebKit pour exécuter du code arbitraire.

2. Élévation de privilèges noyau : depuis le contexte navigateur, Coruna exploite une vulnérabilité kernel pour obtenir les droits root sur le système.

3. Injection dans des processus système : le code malveillant s’injecte dans des processus légitimes d’iOS, powerd et locationd, pour devenir invisible aux outils de détection classiques.

4. Déploiement de modules : depuis cette position, le kit cible plus d’une centaine d’extensions et applications de cryptomonnaie pour exfiltrer clés privées et phrases de récupération.

5. Communication C2 persistante : les communications avec le serveur de commande et contrôle passent via imagent, le démon Apple Messages, pour se fondre dans le trafic réseau normal.

C’est du travail de précision.

La réponse : Lockdown Mode

Lockdown Mode a été lancé par Apple en 2022, dans iOS 16. La promesse était explicite : une protection extrême pour les utilisateurs exposés à des menaces de niveau étatique, journalistes, défenseurs des droits humains, opposants politiques, avocats travaillant sur des affaires sensibles.

Le principe est simple mais radical : réduire la surface d’attaque au maximum, quitte à casser des fonctionnalités.

Concrètement, Lockdown Mode désactive ou restreint :

Côté Web (Safari et WebKit) : le compilateur JIT JavaScript est coupé. WebAssembly est désactivé. Plusieurs technologies web avancées sont bloquées. Les performances de navigation chutent de façon significative dans les benchmarks, parfois jusqu’à 95%. Ce n’est pas un bug. C’est le point.

Côté messagerie : la plupart des types de pièces jointes sont bloqués. Les previews de liens sont désactivés. Les appels entrants de personnes non présentes dans les contacts sont bloqués par défaut.

Côté réseau : la connexion automatique aux réseaux Wi-Fi non sécurisés est désactivée. Les réseaux 2G, historiquement exploités pour des attaques IMSI, sont bloqués.

Côté appareils connectés : les accessoires USB nécessitent une approbation explicite, même si l’iPhone est verrouillé.

L’idée centrale est celle-là : si tu élimines les parseurs complexes, si tu coupes les chemins d’exécution de code dynamique, si tu supprimes les surfaces qui ne sont strictement pas nécessaires, alors la plupart des exploits n’ont plus rien sur quoi s’appuyer.

Coruna confirme cette logique. Le kit vérifie la présence de Lockdown Mode via deux sondes spécifiques sur des API désactivées en mode Lockdown : IndexedDB et les opérations MathML. Si ces API ne répondent pas, Coruna conclut qu’il est face à un appareil en Lockdown Mode et abandonne l’attaque. Pas de tentative de bypass. Pas de plan B. Il repart les mains vides.

Quatre ans de zéro compromission documentée

Apple a déclaré fin mars 2026 : “Nous n’avons connaissance d’aucune attaque de spyware mercenaire réussie contre un appareil Apple sur lequel Lockdown Mode était activé.”

C’est Apple qui parle, donc prendre avec une certaine prudence. Mais l’affirmation est corroborée indépendamment.

Donncha Ó Cearbhaill, directeur du Security Lab d’Amnesty International, a confirmé n’avoir “vu aucune preuve d’un iPhone compromis par un spyware mercenaire avec Lockdown Mode actif au moment de l’attaque.”

Le Citizen Lab de l’Université de Toronto, qui documente les attaques de spyware depuis des années, a lui-même confirmé au moins deux cas où Lockdown Mode a activement bloqué des attaques, une tentative liée à Pegasus de NSO Group, et une autre liée à Predator d’Intellexa.

Quatre ans. Zéro compromission documentée. Face à des outils de niveau gouvernemental.

Pour qui Lockdown Mode est pertinent

Journalistes d’investigation travaillant sur des sujets sensibles (corruption, crime organisé, gouvernements autoritaires).

Défenseurs des droits humains opérant dans des contextes où des gouvernements ont documenté l’usage de spyware contre des activistes (NSO/Pegasus a ciblé des journalistes marocains, des dissidents saoudiens, des opposants mexicains).

Avocats travaillant sur des affaires confidentielles (États, corruption, blanchiment, etc.).

Dirigeants d’entreprises détenant des actifs numériques ou des données sensibles (cryptos, brevets, fichiers clients).

Militants politiques dans des pays où le gouvernement a un historique d’usage de ce type d’outils contre l’opposition.

Lockdown Mode impose quelques compromis, c’est vrai. Apple l’a conçu pour des profils à risque, mais les particuliers détenteurs de wallets cryptos ont tout intérêt à l’activer aussi, vu l’explosion des stealers ciblant macOS.

Une honnêteté nécessaire : les frictions au quotidien

Lockdown Mode n’est pas indolore. Au-delà des extensions Safari désactivées, il y a des petits trucs qui finissent par agacer :

FaceTime : les appels entrants des personnes hors contacts sont bloqués par défaut, et même certains contacts enregistrés ne passent pas. SharePlay et les Live Photos sont désactivés
Affichage cassé sur certains sites : avec WebAssembly et JIT JavaScript coupés, des sites web modernes (apps cloud, éditeurs en ligne, certains dashboards) s’affichent mal ou ne fonctionnent plus
Ralentissements de navigation : certains sites complexes mettent plusieurs secondes à se charger là où c’était instantané
Profils de configuration bloqués : impossible d’installer un profil MDM si tu en as besoin pour ton boulot

J’ai testé Lockdown Mode en permanence pendant un moment, et j’ai fini par le couper. Pas parce que ce n’est pas efficace, ça l’est. Mais parce que les frictions s’accumulent et ça devient pénible au quotidien.

Le bon compromis pour la majorité : activation ponctuelle. Si tu es dirigeant de PME en déplacement dans une zone à risque (salon professionnel, voyage à l’étranger, hôtel), ou si tu te connectes sur un Wi-Fi public louche, active Lockdown Mode juste pendant la période exposée. Tu désactives une fois rentré chez toi.

Ça donne le meilleur des deux mondes : protection maximale quand tu en as vraiment besoin, confort le reste du temps.

Ce que l’histoire de Coruna dit sur la surface d’attaque

Il y a une leçon plus large dans la philosophie de Lockdown Mode que Coruna illustre : la complexité est une surface d’attaque.

Le compilateur JIT de WebKit est une merveille d’ingénierie. Il rend la navigation rapide. Il est aussi l’une des surfaces les plus exploitées dans l’histoire des attaques iOS, parce qu’il exécute du code dynamique, par définition difficile à sécuriser exhaustivement.

Lockdown Mode ne cherche pas à rendre le JIT plus sûr. Il le coupe. C’est brutal, et ça coûte quelques performances. C’est aussi efficace.

La même logique s’applique à WebAssembly, aux previews de pièces jointes, aux technologies web avancées. Chaque parseur complexe est une zone où un bug peut devenir une porte d’entrée.

Pour comprendre ce que l’architecture Apple Silicon apporte comme base à cette philosophie de sécurité, voir Apple Silicon et sécurité : ce que Secure Enclave change vraiment.

Les limites

Ce que Lockdown Mode ne fait pas

Lockdown Mode n’est pas un bouclier universel, et Apple est le premier à le dire.

Il ne protège pas contre les erreurs humaines. Si tu ouvres une pièce jointe malveillante depuis une application hors navigateur, Lockdown Mode n’intervient pas sur ce vecteur d’attaque.

Il ne protège pas contre les vulnérabilités non web. Les attaques passant par Bluetooth, des failles dans des composants système non couverts par Lockdown Mode, ou des vecteurs physiques restent hors périmètre.

“Pas de compromission documentée” n’est pas “impossible à compromettre”. La nuance est importante. On ne sait pas ce qu’on ne sait pas. Un acteur étatique ayant un bypass de Lockdown Mode fonctionnel n’a aucun intérêt à l’utiliser sur des cibles qui ne justifient pas d’exposer cette capacité.

Il n’est pas rétroactif. Si ton iPhone était déjà compromis avant l’activation de Lockdown Mode, il ne désinfecte rien.

Coruna et les versions iOS patchées

Les vulnérabilités exploitées par Coruna visent iOS 13 à iOS 17.2.1, soit des versions sorties jusqu’en décembre 2023. Apple a patché la plupart de ces failles dans les versions ultérieures d’iOS 17 et dans iOS 18.

Si tu utilises iOS 18.x à jour, Coruna ne te concerne pas directement, même sans Lockdown Mode. La mise à jour régulière d’iOS est la mesure de base, avant toute autre chose.

Pour un panorama complet des paramètres de sécurité et privacy à configurer sur macOS, voir Privacy macOS : les paramètres à changer immédiatement.

En résumé

Coruna est la preuve que personne n’est à l’abri. Un outil conçu pour des cibles d’État a fini sur des sites de phishing crypto visant des particuliers. La prolifération des armes numériques suit toujours le même chemin : du ciblé vers le massif.

Et c’est tout un écosystème qui est menacé. Il faut parfois des années à Apple pour identifier et colmater une faille. Coruna en exploitait 23 simultanément, réparties sur quatre ans de versions iOS. Le temps que les patchs arrivent, le mal est fait.

Mieux vaut prévenir que guérir. Lockdown Mode ne corrige pas les failles, il supprime les surfaces sur lesquelles elles s’appuient.

Active Lockdown Mode. Mets iOS à jour. Les deux ensemble, c’est la meilleure défense disponible aujourd’hui.

Le cloud c'est l'ordinateur de quelqu'un d'autre, et alors

Mac Souverain — Sat, 04 Apr 2026 13:01:48 GMT

Introduction

Tu as des fichiers sur iCloud, ou Google Drive, ou Dropbox. Ça synchronise partout, ça marche, tu n’y penses plus.

Puis tu entends cette phrase : “Le cloud, c’est l’ordinateur de quelqu’un d’autre.” Et tu te demandes vaguement si tu devrais t’en inquiéter.

La réponse honnête : ça dépend. De ce que tu y stockes, de qui est ce “quelqu’un d’autre”, et de ce que tu as accepté sans forcément t’en rendre compte. Cet article déroule le mécanisme, sans dramatiser mais sans minimiser, pour que tu puisses faire un choix éclairé, plutôt que de risquer de n’en faire aucun.

Le problème

Ce que “cloud” veut dire vraiment

“Cloud” est un mot marketing. Ce qu’il désigne, c’est simple : tes fichiers ne sont pas sur ton disque dur. Ils sont sur un serveur, dans un datacenter, qui appartient à une entreprise. Quand tu ouvres un document sur iCloud depuis ton Mac, ton Mac télécharge une copie depuis les serveurs d’Apple, ou depuis une infrastructure cloud de sociétés américaines en Europe si tu as de la chance.

La phrase “l’ordinateur de quelqu’un d’autre” vient du monde du logiciel libre, utilisée comme pique contre la centralisation. Elle est un peu simpliste, mais elle a le mérite de mettre le doigt sur quelque chose de réel : tu utilises une ressource informatique que tu ne possèdes pas, que tu ne contrôles pas, et dont les conditions d’utilisation peuvent changer sans ton accord.

Ce n’est pas une raison d’arrêter. C’est une raison de comprendre.

Trois choses que tu cèdes sans y penser

Quand tu mets tes fichiers sur un service cloud tiers, tu cèdes potentiellement trois choses.

L’accès. L’entreprise peut lire tes fichiers si elle veut, ou si on le lui demande. Sur iCloud sans Protection Avancée des Données activée, Apple détient les clés de chiffrement. Elle peut donc accéder à tes photos, tes documents, tes sauvegardes iPhone, et les transmettre à un gouvernement sur demande judiciaire. Apple publie un rapport de transparence : dans leur rapport de transparence, Apple indique avoir fourni des données pour la grande majorité des demandes judiciaires américaines.

La continuité. L’entreprise peut te couper l’accès à tout moment. Violation de CGU (réelle ou algorithmiquement supposée), faillite, fusion-acquisition, décision unilatérale. Tes fichiers sont chez eux, pas chez toi. Le jour où ils ferment la porte, tu ramasses ce qu’ils veulent bien te laisser prendre.

La juridiction. Les lois du pays où sont hébergés tes fichiers s’appliquent, qu’elles te plaisent ou non. iCloud, Google Drive, Dropbox, OneDrive : tous sous juridiction américaine, soumis au CLOUD Act de 2018. Cette loi permet au gouvernement américain d’exiger l’accès à des données stockées n’importe où dans le monde si l’entreprise est américaine, sans passer par les procédures d’entraide judiciaire internationale habituelles. Même tes fichiers dans un datacenter français.

Le mécanisme

Comment le chiffrement change (ou ne change pas) la donne

La réponse standard des fournisseurs cloud quand tu soulèves ce problème : “Tes données sont chiffrées.” C’est vrai. Ce qui compte, c’est qui détient les clés.

Il y a deux modèles fondamentalement différents.

Chiffrement serveur (le plus courant). Tes fichiers sont chiffrés sur les serveurs de l’entreprise, avec des clés que l’entreprise gère. C’est mieux que rien, ça protège contre les pirates qui voudraient s’introduire dans les datacenters, mais ça ne protège pas contre l’entreprise elle-même, ni contre une demande judiciaire. iCloud sans Protection Avancée des Données fonctionne ainsi pour la majorité des données.

Chiffrement de bout en bout — E2EE. Les clés de chiffrement sont générées sur ton appareil, pas sur les serveurs. L’entreprise stocke un fichier qu’elle ne peut pas lire, même si elle le voulait, même sous injonction judiciaire. C’est ce que fait Proton Drive par architecture. C’est ce que fait iCloud pour certaines catégories de données quand tu actives la Protection Avancée des Données.

La nuance pratique : E2EE a un coût. Si tu perds ton mot de passe ET ta clé de récupération, tes données sont inaccessibles définitivement. L’entreprise ne peut pas te les rendre, parce qu’elle n’a jamais eu les clés.

Ce que “juridiction européenne” change vraiment

On entend souvent “mes données sont en Europe, donc je suis protégé par le RGPD.” C’est partiellement vrai, et partiellement faux.

Le RGPD encadre comment tes données sont collectées et utilisées dans l’Union européenne. Il impose des règles strictes aux entreprises opérant sur le territoire européen. Ce n’est pas rien.

Mais ça ne protège pas de tout. Si l’entreprise est américaine, le CLOUD Act prime sur le RGPD dans les faits. En 2023, la Commission européenne a adopté le Data Privacy Framework (DPF), un nouvel accord de transfert UE-US censé remplacer le Privacy Shield invalidé par Schrems II. Il est déjà contesté devant les tribunaux européens et son avenir reste incertain. En attendant, si les données sont sur des serveurs européens d’une filiale américaine, les autorités américaines peuvent théoriquement y accéder quand même.

La juridiction compte. Mais “serveurs en Europe” n’est pas la même chose que “entreprise sous droit européen avec siège hors Five Eyes”. Infomaniak, par exemple, est une entreprise suisse, avec ses serveurs en Suisse, sous droit helvétique. Ce n’est pas un bouclier absolu, mais c’est une juridiction significativement plus protectrice que les États-Unis, et hors CLOUD Act.

Les trois niveaux de confiance en pratique

Pour y voir clair, voici comment lire un service cloud selon ce critère :

Niveau 1 — Tu fais confiance à l’entreprise ET à sa juridiction. Tu utilises iCloud avec la Protection Avancée des Données activée : E2EE pour la plupart des données, sauf iCloud Mail, Contacts et Calendrier qui restent exclus (contraintes d’interopérabilité IMAP/CalDAV/CardDAV). Tu restes chez Apple, sous droit américain. Bon pour le quotidien, insuffisant pour des données sensibles.

Niveau 2 — Tu fais confiance au chiffrement, pas à l’entreprise. Tu utilises un service E2EE comme Proton Drive ou Cryptomator par-dessus n’importe quel cloud : même si l’entreprise reçoit une injonction, elle remet des fichiers illisibles. Le maillon faible ici, c’est le code lui-même. Si le chiffrement est mal implémenté, ou si une faille se cache dans l’application, la promesse E2EE ne tient plus. C’est pourquoi deux choses comptent : que le code soit open source (n’importe qui peut vérifier ce qui tourne), et qu’il ait été audité par un tiers indépendant (Proton Drive a été audité par Securitum, code source publié sur GitHub).

Niveau 3 — Tu contrôles l’infrastructure. Tu auto-héberges ton propre stockage (Nextcloud sur VPS ou NAS hébergé, ou self-host chez toi sur serveur maison). Zéro entreprise tierce dans la boucle. Le maillon faible, c’est ta propre sécurité : un Nextcloud mal configuré ou un NAS exposé sur internet, c’est pire qu’iCloud.

Ce que ça change concrètement

Pour le particulier qui veut faire mieux sans tout réinventer

Si tu utilises iCloud aujourd’hui, la première chose à faire ne coûte rien : activer la Protection Avancée des Données (Réglages → ton nom → iCloud → Protection avancée des données). Ça bascule la majorité de tes données iCloud en E2EE (exception : iCloud Mail, Contacts et Calendrier, qui restent hors E2EE pour des raisons d’interopérabilité). Tu gardes l’écosystème Apple, tu récupères le chiffrement de bout en bout sur le reste. Le seul vrai inconvénient : si tu perds l’accès à ton compte sans clé de récupération, Apple ne peut pas t’aider. Tu notes ta clé quelque part de sûr.

Si tu veux aller plus loin sans quitter le cloud, Proton Drive est l’alternative E2EE la plus accessible : app Mac native, app iOS, interface web, E2EE par défaut, code audité. Juridiction suisse. Ce n’est pas la solution la moins chère, mais c’est le meilleur compromis confort/souveraineté disponible sans compétence technique particulière.

À lire bientôt : Proton Drive vs iCloud vs Infomaniak, où stocker tes fichiers ?

Pour l’indépendant avec des données clients

La question devient business, pas juste personnelle. Des données clients dans un cloud américain sous juridiction CLOUD Act, c’est une exposition légale et contractuelle. Ce n’est pas hypothétique, c’est la nature du droit applicable.

La question devient aussi juridique. Depuis l’arrêt Schrems II (2020), stocker des données personnelles de clients européens sur un cloud américain sans mesures de protection supplémentaires pose un vrai problème de conformité RGPD. Les sanctions restent rares, mais le risque légal existe, et un client pourrait le soulever.

En Europe, le RGPD s’impose à toute entreprise qui traite des données personnelles. Ce n’est pas une clause contractuelle optionnelle, c’est la loi. “iCloud, c’est pratique” n’est pas une réponse recevable face à un client ou une autorité de contrôle.

Options pragmatiques : Proton Drive (E2EE) ou Infomaniak kDrive, tous deux sous juridiction suisse et conformes RGPD pour les données de sociétés européennes. Ou Nextcloud auto-hébergé si tu as la compétence technique. L’article comparatif #13 détaille les différences en profondeur.

Ce que ça ne protège pas

La souveraineté cloud ne protège pas de tout. Un fichier chiffré de bout en bout dans Proton Drive, c’est illisible pour Proton, mais si tu l’ouvres sur un Mac compromis, le fichier déchiffré est là, en clair, à la merci de ce qui tourne sur ta machine. La sécurité du cloud ne compense pas une sécurité endpoint défaillante.

À lire : Pourquoi ton client mail est une passoire — et comment colmater ça

Et un Nextcloud auto-hébergé mal configuré expose plus que Dropbox. Le contrôle total, c’est aussi la responsabilité totale.

Le vrai coût de la souveraineté, c’est aussi le prix. Proton Drive et Infomaniak kDrive ne sont pas gratuits. iCloud 50 Go à 0,99€/mois, c’est imbattable en tarif. Tu paies la souveraineté, comme tu paies Proton Mail E2EE plutôt que Gmail. C’est un choix conscient, pas une évidence.

Idées reçues

Mais les nuages d’Apple sont en Europe

Apple a des datacenters en Europe. Ça ne change pas que la maison mère est à Cupertino, que les clés maîtres de chiffrement (hors Protection Avancée) sont gérées par Apple Inc., et que le CLOUD Act s’applique aux entreprises américaines quelle que soit la localisation physique des serveurs.

“Serveurs en Europe” est un argument marketing utile pour la conformité RGPD locale. Pas un argument de souveraineté contre une injonction fédérale américaine.

Les fournisseurs souverains sont moins pratiques

C’était vrai en 2018. Proton Drive en 2026 a une app Mac native, la synchronisation automatique des dossiers, le partage de fichiers, et une bonne interface web. Infomaniak kDrive a une intégration macOS propre. Ce n’est pas aussi transparent qu’iCloud Finder, mais l’écart s’est considérablement réduit.

Je n’ai rien à cacher

L’argument est faux, pas parce que tu aurais des choses inavouables, mais parce qu’il repose sur une hypothèse incorrecte : que le problème c’est ce que tu fais, pas ce que d’autres peuvent faire avec tes données.

Tes documents comptables dans un cloud lisible par des tiers, ce n’est pas un problème si tu n’as rien fait de mal. C’est un problème si tes données sont utilisées pour te cibler commercialement, si elles fuient lors d’une brèche, exposant ainsi des données clients, ou encore si elles sont transmises à un gouvernement dans un cadre que tu n’as pas anticipé.

En résumé

Le cloud, c’est effectivement l’ordinateur de quelqu’un d’autre. La question n’est pas “est-ce qu’il faut l’utiliser” mais “est-ce qu’on comprend ce qu’on accepte en l’utilisant”.

Trois paramètres à regarder pour n’importe quel service cloud : qui détient les clés de chiffrement (toi ou l’entreprise), quelle est la juridiction applicable (pas juste la localisation des serveurs), et que se passe-t-il si l’entreprise disparaît ou te coupe l’accès.

Sur l’usage concret : si tu utilises iCloud, commence par activer la Protection Avancée des Données. Si tu as des données professionnelles, regarde Proton Drive ou Infomaniak kDrive. Si tu veux le contrôle total, l’auto-hébergement Nextcloud est la prochaine étape, mais ça demande un peu plus de technique et de la maintenance.

Le comparatif détaillé des options, avec les prix, les cas d’usage et les limites réelles de chacun, c’est dans l’article #13.

À lire bientôt : Proton Drive vs iCloud vs Infomaniak, où stocker tes fichiers ?

Gestionnaire de mdp sur Mac : Apple, Bitwarden, KeePassXC ou 1Password

Mac Souverain — Wed, 01 Apr 2026 07:58:35 GMT

Introduction

Quatre options, quatre philosophies radicalement différentes.

L’app Mots de passe (Apple) est gratuite, intégrée, et déjà là. KeePassXC est un coffre local, sans serveur, sans abonnement, sans entreprise au bout de la chaîne. Bitwarden est open source avec une version gratuite et auto-hébergeable. 1Password est payant, cross-platform, mais cloud propriétaire sous juridiction 5 Eyes.

Le bon choix dépend d’une seule chose : ton profil d’usage et ce que tu es prêt à confier à qui.

À lire : Les réglages privacy macOS à changer en 15 minutes

Les critères qui comptent

On garde les critères utiles, pas ceux qui font joli dans un tableau :

Architecture de sécurité : qui peut techniquement accéder à tes données ?
Privacy et juridiction : sous quelle loi tes données sont-elles soumises ?
Portabilité : ça marche sur Android, Windows, Linux ?
Fonctions avancées : Travel Mode, partage équipe, 2FA intégré
Hébergement : cloud tiers, ou chez toi
Prix : gratuit, abonnement, ou achat unique
Audits indépendants : est-ce que les affirmations ont été vérifiées ?

Ce qu’on n’évalue pas : les thèmes, le nombre de widgets, et les fonctionnalités que personne n’utilise.

App Mots de passe (Apple)

Philosophie

Apple a construit son gestionnaire autour de la sécurité et de la facilité d’emploi : tout se passe sur les appareils que tu détiens, chiffré avec tes propres clés. Synchro iCloud, passkeys pour le 2FA, déverrouillage par Touch ID ou Face ID, tout est fait pour te faciliter la vie.

Les forces

Gratuit et intégré. L’app Mots de passe est disponible sur macOS Sequoia (15.x) et Tahoe (26.x), iOS 18 et iPadOS 18. Elle gère mots de passe, identifiants, codes 2FA (TOTP), passkeys, mots de passe Wi-Fi, et notes sécurisées. Rien à installer, rien à configurer, rien à payer.

Chiffrement de bout en bout. Avec la Protection avancée des données iCloud activée, les données de l’app Mots de passe sont chiffrées avec des clés générées localement. Apple ne peut pas les lire, même contraint légalement. Sans cette option, certaines métadonnées restent accessibles à Apple.

À lire : Apple Silicon et Secure Enclave : ce que ça change vraiment

Passkeys. L’intégration native des passkeys est probablement le point le plus solide en 2026. Les passkeys remplacent les mots de passe par une paire de clés cryptographiques : rien n’est jamais transmis au serveur. Sur Mac et iPhone, ça fonctionne sans friction avec Face ID ou Touch ID.

Partage familial. L’app permet de créer des coffres partagés pour la famille iCloud : identifiants personnels d’un côté, accès communs (Netflix, Wi-Fi) dans le coffre partagé.

Détection des mots de passe compromis. Vérification automatique via un système propriétaire Apple utilisant le protocole k-anonymity : aucun mot de passe n’est envoyé tel quel. Apple ne communique pas les bases de fuites utilisées, mais le mécanisme vérifie tes identifiants contre des listes de compromissions connues sans exposer tes données.

Les limites honnêtes

Apple uniquement, presque. Mac, iPhone, iPad, Apple Watch. Sur Windows, il existe une extension iCloud Passwords pour Chrome et Edge, mais c’est une béquille. Sur Android ? Rien. Si ton setup dépasse l’écosystème Apple, l’app Mots de passe devient un frein réel.

Juridiction américaine. Apple est soumis au CLOUD Act, aux National Security Letters, et à la surveillance américaine. La Protection avancée des données iCloud renforce la protection technique, mais ne change pas la juridiction.

Audits publics limités. Apple publie des white papers mais pas d’audit public indépendant sur l’app Mots de passe, contrairement à 1Password ou Bitwarden.

Pour qui : utilisateurs 100% Apple, particuliers comme professionnels, familles.

Prix : gratuit.

KeePassXC

Philosophie

KeePassXC est dans une catégorie à part. Ce n’est pas un service cloud, pas un abonnement, pas une entreprise avec des serveurs. C’est un logiciel desktop qui chiffre un fichier sur ton disque. Pour comprendre KeePassXC, il faut comprendre sa logique : tes mots de passe sont dans un fichier (.kdbx), chiffré, que tu stockes où tu veux. Ce fichier, c’est ton coffre-fort. KeePassXC est la clé qui l’ouvre.

Comment ça marche concrètement

Sur Mac, tu installes KeePassXC (un .dmg, comme n’importe quelle app). Tu crées une base de données, un fichier .kdbx protégé par ton mot de passe maître. Ce fichier contient tous tes identifiants, chiffrés. Tu le stockes dans un dossier synchronisé (Nextcloud, NAS, ou même iCloud si tu veux), et KeePassXC l’ouvre à la demande. Une extension navigateur (KeePassXC-Browser) remplit automatiquement tes identifiants sur les sites web. Touch ID fonctionne pour le déverrouillage rapide.

Sur iPhone, tu installes KeePassium, une app open source (GPLv3), développée au Luxembourg, zéro collecte de données. Tu la pointes vers ton fichier .kdbx sur Nextcloud via WebDAV (l’adresse de ton Nextcloud + tes identifiants, 10 minutes de configuration). KeePassium le télécharge, le cache localement, et le synchronise à chaque ouverture. Touch ID et Face ID fonctionnent pour le déverrouillage. Tu actives le remplissage automatique dans les réglages iOS, et c’est fini.

La synchronisation est bidirectionnelle. Tu ajoutes un mot de passe sur iPhone ? KeePassium écrit dans le fichier sur Nextcloud. Tu ouvres KeePassXC sur Mac ? Il détecte le changement et recharge la base. Même chose dans l’autre sens. Le fichier sur Nextcloud sert de point de synchronisation, toujours chiffré, que ce soit au repos ou en transit.

Les forces

Zéro serveur tiers, zéro entreprise, zéro juridiction. Le fichier .kdbx est chez toi : sur ton Mac, ton Nextcloud, ton NAS. Personne ne peut y accéder sans ton mot de passe maître, parce qu’il n’y a aucun intermédiaire dans la boucle. C’est toi qui décides où tes mots de passe vivent.

Open source et certifié. KeePassXC est sous licence GPL, le code est public. L’application a fait l’objet d’un audit indépendant en 2023 (Zaur Molotnikov, rapport public), avec des conclusions positives sur la protection cryptographique. Mieux encore : KeePassXC 2.7.9 a obtenu le visa de sécurité CSPN de l’ANSSI, reconnu en France et en Allemagne (certification sur v2.7.9 / Windows 10 ; l’architecture cryptographique est commune à toutes les plateformes). C’est une certification officielle, pas un audit commandité par l’éditeur.

100% gratuit, sans limite. KeePassXC n’est pas freemium : il n’y a pas de version payante, pas d’abonnement, pas de fonctionnalité derrière un paywall. Le projet vit de contributions bénévoles et de dons. Tu installes, tu utilises, c’est fini.

Sur iOS, c’est KeePassium qui prend le relais. La version de base est gratuite ; la version premium (multi-base, déverrouillage automatique) est optionnelle.

Fonctions complètes. KeePassXC gère les mots de passe, les passkeys (depuis la version 2.7.7), les codes 2FA (TOTP), l’intégration SSH (agent SSH pour tes clés), le remplissage automatique via extension navigateur, le support des clés de sécurité physiques (YubiKey), et la vérification de mots de passe compromis via Have I Been Pwned (intégrée dans l’app, requête k-anonymity sans exposer tes données).

Cross-platform desktop. Mac, Windows, Linux. L’interface est cohérente sur les trois plateformes.

Les limites honnêtes

Pas d’extension Safari. L’autofill et les passkeys de KeePassXC fonctionnent via une extension navigateur, disponible pour Firefox, Chrome et Edge. Safari n’est pas supporté. Sur Safari, il faut copier-coller depuis l’app (Cmd+B pour l’identifiant, Cmd+C pour le mot de passe, presse-papier effacé automatiquement). C’est la principale limite pour un utilisateur Mac.

Interface austère. KeePassXC est fonctionnel, pas beau. L’interface a été modernisée ces dernières années mais reste moins intuitive que 1Password ou Bitwarden. Ce n’est pas rédhibitoire, mais il y a une courbe d’apprentissage.

Pas d’app iOS native. Sur iPhone, tu passes par KeePassium, une app tierce, certes souveraine (open source, Luxembourg), mais c’est un logiciel supplémentaire à connaître. L’expérience est très bonne une fois configurée, mais ce n’est pas aussi transparent que Bitwarden ou 1Password où tout est intégré.

Travel Mode naturel. KeePassXC n’a pas de bouton “Travel Mode”, mais l’architecture fichier fait mieux : tu as plusieurs fichiers .kdbx, tu choisis lesquels sont sur quel appareil. Avant un voyage, tu ne synchronises pas le fichier sensible sur ton iPhone, c’est tout. Et si tu utilises un fichier-clé en plus du mot de passe maître, tu peux révoquer un appareil instantanément : supprime le fichier-clé de l’appareil, et même si quelqu’un a la base .kdbx, il ne peut rien en faire. C’est la granularité que les solutions cloud ne peuvent pas offrir.

Pour qui : utilisateurs avec un profil un peu plus technique, qui ne veulent aucun serveur tiers dans la boucle, intégration avec flux SSH ou YubiKey.

Prix : gratuit.

Bitwarden

Philosophie

Bitwarden est la réponse open source au problème des gestionnaires de mots de passe cloud. Le code est public, auditable par n’importe qui, le modèle économique est honnête, et tu peux héberger toi-même si tu ne veux pas dépendre de leurs serveurs.

Les forces

Open source. Le code est sur GitHub, sous licence GPL. Audité annuellement par des tiers indépendants (Cure53 en 2018, Fracture Labs en 2024, ETH Zurich en 2025 pour la cryptographie), rapports publics sur bitwarden.com/compliance. C’est la transparence maximale pour un outil de sécurité.

Version gratuite fonctionnelle. Contrairement à 1Password (100% payant), Bitwarden a une version gratuite réelle : stockage illimité de mots de passe, synchronisation cross-platform, partage avec une autre personne. La version Premium (19,80 $/an) ajoute les codes 2FA (TOTP), les rapports de sécurité (détection de fuites via Have I Been Pwned, mots de passe faibles ou réutilisés), et les pièces jointes chiffrées. À noter : KeePassXC offre la plupart de ces fonctions Premium (2FA, vérification HIBP) gratuitement, mais sans la synchronisation cloud intégrée.

Passkeys et 2FA. Comme Apple et KeePassXC, Bitwarden gère les passkeys nativement. Les codes 2FA (TOTP) sont réservés au plan Premium (19,80 $/an).

Clés de sécurité physiques et stockage. Depuis la hausse de janvier 2026, le Premium a été étoffé pour justifier le tarif. Tu peux maintenant associer jusqu’à 10 clés physiques (YubiKey, Nitrokey) à ton compte, contre 2 auparavant. Le stockage de pièces jointes chiffrées passe à 5 Go. Un bloqueur de phishing est également annoncé, pas encore déployé à l’heure où cet article est publié. Pour la comparaison : KeePassXC supporte lui aussi les YubiKey nativement, sans abonnement, mais sans le cloud derrière.

Cross-platform complet. Mac, iPhone, iPad, Windows, Android, Linux, extensions pour tous les navigateurs. Plus large que 1Password sur le support Linux.

Auto-hébergement. Tu peux faire tourner ton propre serveur Bitwarden sur ton NAS ou ton VPS. En pratique, la plupart des gens en auto-hébergement utilisent Vaultwarden : c’est une réécriture communautaire du serveur Bitwarden en Rust (un langage axé sécurité et performance, Apple migre d’ailleurs des composants macOS vers Rust). Vaultwarden est ultra-léger, tourne sur un Raspberry Pi, et reste 100% compatible avec les apps Bitwarden officielles. Tes mots de passe restent sur ton infrastructure, sous ta juridiction, avec ton niveau de sécurité. Pour l’audience de MacSouverain, c’est l’option la plus souveraine d’un gestionnaire cloud.

Juridiction américaine gérable. Bitwarden est basé aux États-Unis, ce qui est défavorable en soi. Mais avec l’auto-hébergement, la question de la juridiction de l’entreprise devient secondaire puisque tes données ne sont pas sur leurs serveurs.

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

Les limites honnêtes

Interface moins léchée que 1Password. Bitwarden est fonctionnellement complet, mais l’expérience utilisateur est moins polie. Ce n’est pas rédhibitoire, mais ça se ressent au quotidien.

Auto-hébergement : le frein, c’est l’installation. Héberger Vaultwarden sur un VPS ou un NAS demande une configuration initiale (Docker, reverse proxy). Une fois en place, la maintenance est minimale : une mise à jour de temps en temps, un backup de la base, et ça tourne tout seul. On y reviendra dans nos futurs guides pour monter une infrastructure souveraine complète.

2FA intégré (TOTP) en version payante seulement. La version gratuite ne gère pas les codes 2FA directement dans Bitwarden. Il faut passer au Premium (19,80 $/an) ou utiliser une app 2FA séparée.

Pas de Travel Mode. Bitwarden n’a pas d’équivalent au Travel Mode de 1Password.

Pour qui : utilisateurs qui veulent open source et/ou auto-hébergement, budgets serrés.

Prix : gratuit (basique) ou 19,80 $/an pour le Premium (hausse janvier 2026, de 10 $/an, avec stockage 5 Go et support 10 clés physiques en contrepartie).

1Password

Philosophie

1Password résout un problème précis : avoir un gestionnaire fiable, auditable, cross-platform, avec des fonctions avancées pour les usages professionnels. Son architecture repose sur deux facteurs : ton mot de passe maître et une Clé secrète, une clé de 128 bits générée localement et jamais envoyée à leurs serveurs. Même si leurs serveurs étaient compromis, tes données sont inexploitables sans cette clé.

Les forces

Clé secrète : une différence structurelle. L’app Mots de passe dépend principalement de ton mot de passe iCloud pour la récupération. 1Password ajoute une couche cryptographique qui ne peut pas être brute-forcée depuis leurs serveurs. Ce n’est pas du marketing, c’est de l’ingénierie.

Cross-platform complet. Mac, iPhone, iPad, Windows, Android, Linux, extensions pour Chrome, Firefox, Safari, Edge. Si une personne de ton entourage a un Android ou un PC Windows, 1Password fonctionne partout sans friction.

Travel Mode. Tu pars dans un pays à contrôle aux frontières et tu ne veux pas qu’une inspection accède à certains coffres ? Tu les marques comme “non voyage”, ils disparaissent de l’application jusqu’à réactivation depuis un appareil de confiance. Ça ne protège pas contre un mot de passe extorqué, mais ça protège contre une fouille physique.

Watchtower. Surveillance en continu via la base Have I Been Pwned (14 milliards de comptes compromis) : mots de passe présents dans des fuites, mots de passe faibles ou réutilisés, sites sans 2FA activé, certificats SSL expirés, dates d’expiration proches. C’est l’audit de sécurité le plus complet des quatre. En comparaison, l’app Mots de passe Apple détecte les fuites, les mots de passe faibles et réutilisés, fonctionnel mais basique. Bitwarden propose des rapports similaires (Vault Health Reports) mais à générer manuellement et avec le dark web monitoring réservé au plan payant. KeePassXC se limite à la vérification de force et aux doublons, pas de détection de fuites intégrée.

Audits indépendants. Audité régulièrement par Cure53 entre 2020 et 2022 (rapports publics). Depuis 2025, les rapports de pentest annuels sont accessibles via le Trust Center de 1Password (accès sur demande). Ce n’est pas open source, mais c’est un niveau de transparence acceptable pour un outil de sécurité payant.

Plans équipe. Gestion d’accès partagés, politiques de sécurité, rapports d’activité. Pour un indépendant qui gère des accès clients ou une petite équipe, c’est une vraie différence.

Les limites honnêtes

Propriétaire et payant. 1Password n’est pas open source. Tu fais confiance à leurs audits, pas à du code vérifiable. Le plan individuel coûte 2,74 €/mois facturés annuellement (tarif promotionnel première année pour les nouveaux clients). Pas cher pour un outil de sécurité, mais non nul.

Canada, membre des 5 Eyes. AgileBits est basée à Toronto. Le Canada est membre des 5 Eyes, l’alliance de surveillance partagée entre États-Unis, Royaume-Uni, Canada, Australie et Nouvelle-Zélande. L’architecture à connaissance zéro limite le risque, mais la juridiction reste défavorable comparée à la Suisse ou à une solution auto-hébergée.

Pas de version gratuite. Essai 14 jours, puis payant.

Pour qui : utilisateurs cross-platform, professionnels, voyageurs fréquents, petites équipes.

Prix : 2,74 €/mois individuel, 4,31 €/mois famille 5 utilisateurs (facturés annuellement, tarif promotionnel première année pour les nouveaux clients).

La recommandation de Mack

Tu es 100% dans l’écosystème Apple. L’app Mots de passe fait le travail, que tu sois particulier ou pro. Gratuit, chiffré, passkeys, partage famille, et surtout : Touch ID et Face ID déverrouillent tes comptes sans friction. Active la Protection avancée des données iCloud et ne cherche pas plus loin.

Tu veux que tes mots de passe soient en mode souveraineté maximale. KeePassXC. Fichier local chiffré, synchronisation sur ton Nextcloud, aucune entreprise dans la boucle. Sur iPhone, KeePassium (open source, Luxembourg) fait le relais avec Touch ID et Face ID. C’est la souveraineté maximale sur ce sujet, et le Travel Mode le plus élégant : tu contrôles physiquement ce qui est sur chaque appareil. Certifié ANSSI.

Tu veux open source avec l’option auto-hébergement, ou tu as un budget serré. Bitwarden. Gratuit pour l’essentiel, Premium à 19,80 $/an pour le reste, et Vaultwarden sur ton NAS si tu veux garder le contrôle total. Open source, audité, souverain si tu l’héberges toi-même. Touch ID et Face ID supportés partout.

Tu as des appareils hors Apple et tu as besoin de Travel Mode ou de gestion d’équipe. 1Password fait le job techniquement, et il le fait bien. L’architecture zero-knowledge avec clé secrète est solide, Watchtower est le meilleur audit de sécurité du marché, et le Travel Mode est unique. Mais c’est un cloud propriétaire sous juridiction canadienne (Five Eyes).
La souveraineté, c’est aussi la juridiction : tes données sont hébergées par une entreprise soumise aux lois de surveillance des Five Eyes. C’est la raison pour laquelle MacSouverain ne peut pas le recommander comme solution privacy, malgré ses qualités techniques indéniables.

À lire : Pourquoi ton client mail est une passoire et comment intégrer un gestionnaire de mots de passe dans une posture de sécurité complète.

Pourquoi ton client mail est une passoire, et comment colmater ça

Mac Souverain — Wed, 25 Mar 2026 14:05:23 GMT

Introduction

MAJ juillet 2026. La faille Hide My Email désanonymise les alias Apple (divulgation publique le 1er juillet, toujours pas corrigée). Un argument de plus pour les alias souverains : voir la mise à jour du comparatif email.

MAJ mai 2026. Nouveau cran sur l’évolution mainstream du chiffrement email : Proton Mail propose désormais une option de chiffrement post-quantum, sur OpenPGP standardisé, gratuit inclus. Premier mail à le faire sur un standard ouvert. Détails dans le radar.

Le débat sur la sécurité email tourne en boucle autour d’un seul axe : “Gmail lit tes emails pour faire de la pub.” C’est vrai, c’est problématique, et c’est couvert un peu partout, y compris dans le comparatif Apple Mail vs Gmail vs Proton Mail.

Mais même si tu migres chez Proton, pour avoir des mails chiffrés demain matin, ta boîte mail reste un vecteur d’attaque important. Un email n’est pas un fichier texte inerte. C’est un document HTML interprété par un moteur de rendu de plusieurs millions de lignes de code (WebKit pour Apple Mail), qui charge des ressources distantes, exécute du CSS, et embarque des pièces jointes que tu ouvriras dans d’autres logiciels tout aussi complexes.

Ce tutoriel couvre les six vecteurs d’attaque réels et te donne les réglages exacts pour chacun. Il te faut un Mac avec Apple Mail, 15 minutes, et éventuellement un compte Proton Mail si tu veux la protection maximale. À la fin, ta surface d’attaque email sera réduite de façon drastique.

Avant de commencer

Ce qu’il te faut :

Un Mac sous macOS Tahoe (26.x), Sequoia (15.x) ou Sonoma (14.x)
Apple Mail configuré (avec ou sans Proton Bridge)
15 minutes

Ce que ça va changer :

Les pixels espions ne te traquent plus
Le HTML/CSS des emails ne peut plus te fingerprinter
Les pièces jointes ne s’ouvrent plus automatiquement
Tu sais vérifier si un email est authentique (SPF/DKIM/DMARC)

Ce que ça ne changera PAS :

Qui lit tes emails côté serveur (ça, c’est le choix du fournisseur, voir le comparatif email)
Le phishing bien ciblé qui exploite la confiance humaine

Étapes

Étape 1 : Bloquer les pixels espions

Un pixel de tracking, c’est une image de 1x1 pixel, transparente, hébergée sur un serveur distant, intégrée dans le corps HTML de l’email. Quand ton client mail charge l’email, il charge l’image, ce qui envoie une requête HTTP au serveur. Cette requête révèle ton IP, ton client mail, l’horodatage et un identifiant unique lié à ton adresse email.

En une image invisible, l’expéditeur sait que tu as ouvert son email, depuis quelle ville, sur quel OS, à quelle heure, combien de fois. Tout le monde l’utilise : newsletters, sales B2B (Mailchimp, HubSpot, Outreach), services e-commerce. C’est légal, quasi invisible, et très répandu.

Jusqu’au 14 avril 2026, du moins. La CNIL a adopté ce jour-là sa recommandation sur les pixels de suivi dans les emails. On y revient un peu plus bas, dans un chapitre dédié. Tu peux déjà garder en tête que ta case “Bloquer tout le contenu distant” est désormais alignée avec la doctrine du régulateur.

Chemin : Mail > Réglages > Confidentialité

Deux niveaux de protection, du plus souple au plus strict :

Niveau 1, “Protéger l’activité Mail” : Apple charge les images distantes à ta place via ses propres serveurs (proxy). L’expéditeur voit l’IP d’Apple, pas la tienne. Les pixels espions sont neutralisés, mais les images se chargent quand même. C’est le minimum.

Niveau 2, “Bloquer tout le contenu distant” : aucune ressource distante ne se charge, point. Pas d’images hébergées sur un serveur, pas de pixels, pas de CSS externe. L’email s’affiche en texte et images embarquées dans le message (CID) uniquement, sans aucun appel réseau. Un bouton “Charger le contenu distant” apparaît en haut de chaque email si tu veux charger au cas par cas.

Le niveau 2 rend le niveau 1 redondant (si rien ne se charge, rien à proxifier). Mais active les deux : si tu cliques “Charger le contenu distant” sur un email, c’est le niveau 1 qui prend le relais et proxifie les images via Apple au lieu de les charger directement. Ceinture et bretelles.

Ce que tu dois voir : les deux options cochées.

Sur Proton Mail : actif par défaut, rien à faire. Sur Proton Mail + Bridge + Apple Mail : la protection opère côté serveur Proton avant même d’arriver dans Apple Mail. Active quand même le réglage Apple Mail ci-dessus, la redondance est une bonne pratique.

Étape 2 : Réduire la surface HTML/CSS

Un email HTML, c’est une page web. Et une page web, ça s’exécute dans un moteur de rendu. Ce moteur a des caractéristiques mesurables qui permettent de t’identifier sans cookie et sans JavaScript, uniquement via CSS et HTML.

Des media queries peuvent charger différentes ressources selon ton mode sombre, ta taille d’écran, ta résolution. Des techniques avancées permettent d’extraire du contenu via CSS seul. Des homoglyphes Unicode rendent des URLs de phishing visuellement identiques à l’original.

Apple Mail ne propose plus de bascule globale “texte brut” sur macOS Ventura+. La protection passe par deux approches :

Option 1, bloquer le contenu distant (déjà fait à l’étape 1) : avec “Bloquer tout le contenu distant” activé, le rendu CSS devient inerte. Aucune ressource externe ne se charge.

Option 2, basculer en texte brut sur un email précis :

Ouvre l’email en question
Menu Présentation > Message > Texte brut alternatif
L’email repasse en texte pur, aucun CSS ne s’exécute

Ce que tu dois voir : emails affichés sans mise en forme riche quand le contenu distant est bloqué. Option texte brut disponible au cas par cas.

Avec Proton Mail (web ou app desktop), tu peux activer le texte brut par défaut pour tous les emails (Paramètres > Apparence > Composer en texte brut). Le blocage des images distantes et le blocage de l’ouverture automatique des pièces jointes sont actifs par défaut. Ce que tu configures manuellement sur Apple Mail est déjà réglé d’office sur Proton.

Étape 3 : Pièces jointes, les réflexes qui comptent

Les pièces jointes sont le vecteur de malware le plus documenté de la dernière décennie. Macros Office VBA, PDF avec JavaScript embarqué (Adobe Reader l’exécute par défaut), fichiers TNEF (winmail.dat) d’Outlook.

Sur les anciennes versions de macOS, Apple Mail proposait une option “Ouvrir les pièces jointes sécurisées automatiquement” dans Mail > Réglages > Général. Apple l’a supprimée à partir de macOS Sequoia : les pièces jointes ne s’ouvrent plus automatiquement. Le fait qu’Apple ait retiré le choix à l’utilisateur en dit long sur le niveau de risque que ça représentait.

Le réglage est réglé. Ce qui reste, c’est tes réflexes :

Avant d’ouvrir une pièce jointe : appuie sur Espace (Quick Look) directement depuis l’email. Le fichier s’affiche en lecture seule sans s’exécuter.
Pour les PDF : utilise Aperçu (Preview) plutôt qu’Adobe Reader, surface d’attaque bien plus réduite.
Pour les .docx / .xlsx venant de sources inconnues : Quick Look d’abord, pas Office. Jamais activer les macros dans un document reçu par email, même d’une source connue (un compte compromis envoie des macros crédibles).
Un fichier .app, .dmg, .pkg ou .command reçu par email ? Suppression immédiate. Aucun expéditeur légitime n’envoie un exécutable par mail.

Étape 4 : Mettre à jour le client mail sans délai

Les zero-days sur les clients mail existent. CVE-2023-23397 sur Outlook (CVSS 9.8) : un email malveillant déclenchait une authentification NTLM vers un serveur attaquant, sans aucune interaction de l’utilisateur. Juste recevoir l’email suffisait. Exploité activement par APT28 avant le patch.

Apple Mail a un historique plus modeste qu’Outlook, mais pas inexistant. CVE-2020-9922 : Apple Mail pouvait envoyer des emails en clair même avec S/MIME activé dans certaines conditions.

Chemin : Réglages Système > Général > Mise à jour de logiciels > Mises à jour automatiques

Tout activer, y compris “Installer les mises à jour de sécurité et fichiers système”. Ne jamais repousser une mise à jour macOS qui inclut un patch Mail.

Ce que tu dois voir : toutes les options de mise à jour automatique cochées.

Si tu utilises Proton Bridge : ouvre Bridge > icône barre de menus > Vérifier les mises à jour. Bridge a son propre cycle de mise à jour indépendant de macOS.

Étape 5 : Apprendre à vérifier un email suspect (SPF/DKIM/DMARC)

L’email a été conçu dans les années 70 sans aucun mécanisme d’authentification. N’importe qui peut envoyer un email avec le champ From: qu’il veut. Trois mécanismes de contrôle ont été ajoutés :

SPF, Sender Policy Framework, vérifie que le serveur d’envoi est autorisé pour ce domaine
DKIM, DomainKeys Identified Mail, signe cryptographiquement l’email pour vérifier qu’il n’a pas été modifié en transit
DMARC, Domain-based Message Authentication, Reporting & Conformance, lie SPF et DKIM et définit quoi faire en cas d’échec

Sur Apple Mail :

Ouvre l’email suspect
Menu Affichage > Message > En-têtes longs (ou Cmd+Shift+H)
Cherche la ligne Authentication-Results:
Lis les trois valeurs : spf=pass / dkim=pass / dmarc=pass. Un fail ou none sur DMARC est un signal d’alerte

Ce que tu dois voir : les en-têtes complets avec les résultats d’authentification.

spf=pass dkim=pass dmarc=pass : email authentifié, expéditeur légitime. Tout va bien.

dmarc=fail : l’expéditeur ne correspond pas au domaine déclaré. Phishing probable. Alerte élevée.

dkim=fail : l’email a été modifié en transit ou vient d’un serveur non autorisé. Alerte élevée.

spf=fail seul : moins concluant, les configs SPF sont parfois imparfaites. Alerte moyenne.

Tous à none : le domaine n’a configuré aucune authentification. Méfiance maximale.

Alternative simple : copie les en-têtes complets et colle-les sur mxtoolbox.com/EmailHeaders.aspx, le résultat est lisible en 10 secondes.

Important : Apple Mail ne peut pas rejeter automatiquement un email qui échoue. Il affiche les résultats d’authentification dans les en-têtes, mais le tri se fait côté serveur, par ton fournisseur email. C’est là que le choix du fournisseur fait la différence :

iCloud Mail : applique DMARC, mais Apple est peu transparent sur le niveau d’application stricte. Pas de filtres avancés côté serveur.
Gmail : applique DMARC, mais peut livrer en spam au lieu de rejeter. Filtres puissants, mais Google lit tout au passage.
Proton Mail : applique la politique DMARC du domaine expéditeur côté serveur. Un dmarc=fail avec politique reject, l’email n’arrive jamais dans ta boîte. En plus, Proton propose des filtres Sieve : un langage de règles côté serveur qui te permet de trier, déplacer, rejeter ou étiqueter automatiquement tes emails selon l’expéditeur, le sujet, les en-têtes, etc. C’est bien plus puissant que les règles d’Apple Mail.

À lire bientôt : Configurer Proton Bridge avec Apple Mail sur Mac

Réflexe à retenir : demande urgente + dmarc=fail = appel téléphonique avant toute action, sans exception.

Étape 6 : Configurer la combinaison optimale (Proton Mail + Bridge + Apple Mail)

Si tu veux la protection maximale sur Mac, la combinaison Proton Mail + Bridge + Apple Mail empile trois couches indépendantes :

Proton Mail : ne peut pas lire tes emails (chiffrement E2EE, clés sur ton appareil), filtre les pixels espions et ressources distantes côté serveur avant même de te les transmettre
Proton Bridge : déchiffre localement sur ton Mac, ne transmet rien sur le réseau
Apple Mail : n’exécute pas de JavaScript, bloque le contenu distant (si configuré comme ci-dessus)

Aucune de ces trois couches n’exécute de code actif contenu dans un email. C’est structurellement meilleur que n’importe quel webmail.

Bridge est disponible à partir du plan Proton Mail Plus (à partir de 3,99 euros/mois en abonnement annuel). Le plan gratuit Proton Mail ne donne pas accès à Bridge.

Essayer Proton Mail

À lire bientôt : Configurer Proton Bridge avec Apple Mail sur Mac

Pixels de suivi : ce que change la recommandation CNIL du 14 avril 2026

Le 14 avril 2026, la CNIL a adopté sa recommandation sur les pixels de suivi dans les emails, version finale après la consultation publique de juin 2025. Ce n’est ni une loi, ni un règlement, simplement une recommandation. Mais c’est la doctrine sur laquelle la CNIL s’appuie pour te contrôler, et pour contrôler ceux qui t’écrivent. Et quand le régulateur publie sa grille de lecture, les audits qui arrivent derrière s’en servent.

Un pixel espion, en trois lignes

Un pixel espion, c’est une image d’un pixel sur un pixel, transparente, hébergée sur un serveur à l’autre bout d’internet. L’expéditeur la glisse dans le corps HTML de son email, au milieu du texte, invisible à l’œil. Quand ton client mail affiche le message, il télécharge cette image. Ce simple téléchargement envoie une requête HTTP au serveur, qui enregistre au passage ton IP, ton client mail, l’heure, et un identifiant unique collé à ton adresse email.

Résultat : l’expéditeur sait que tu as ouvert, quand, depuis quelle ville approximative, sur quel OS, combien de fois. Tu n’as rien fait de particulier, tu as juste lu. Multiplié par toutes les newsletters, tous les emails B2B, toutes les notifications commerciales que tu reçois, ça dessine un profil détaillé de ton attention.

Ce que la CNIL encadre désormais

La base juridique, c’est l’article 82 de la Loi Informatique et Libertés, celui qui régit les cookies et traceurs. Et les lignes directrices du Comité européen de la protection des données, 2/2023, qui rangent explicitement les pixels d’emails dans la catégorie des traceurs. La recommandation du 14 avril 2026 applique cette grille au cas précis des pixels dans les emails.

Principe retenu par la CNIL : un pixel de suivi est un traceur. Il lit et écrit de l’information sur ton terminal (ton client mail, ton téléphone, ton Mac). Donc par défaut, il relève du consentement préalable, au même titre qu’un cookie publicitaire.

Une seule exemption au consentement : la mesure de délivrabilité individuelle liée à un service que tu as demandé. En clair, pour les emails transactionnels, confirmation d’achat, alerte de sécurité, reset de mot de passe, activation de compte, l’expéditeur peut vérifier si l’email t’est bien parvenu, sans te demander ton accord. C’est vu comme un composant technique du service que tu as sollicité.

Tout le reste exige un consentement explicite. Personnalisation du contenu selon ton comportement, mesure d’audience marketing, ciblage publicitaire, segmentation commerciale, analytics fines. Si ton expéditeur utilise le pixel pour autre chose que vérifier que l’email est arrivé, il doit te demander. Explicitement, au niveau du consentement RGPD standard, pas un bandeau enterré en bas d’une page.

Le délai, et ce qui arrive après

La CNIL laisse trois mois pour se mettre en conformité. Concrètement : mi-juillet 2026. Après, les audits commencent. La recommandation n’est pas contraignante au sens strict, mais elle est opposable en contrôle. Un acteur audité ne peut plus plaider l’ignorance de la doctrine : elle est publique, datée, détaillée.

Et la CNIL a annoncé des contrôles. Les premiers viseront probablement les gros émetteurs B2C, newsletters commerciales, e-commerce, médias avec tracking massif. Mais la grille vaut pour tous : freelances, PME, associations. Si tu envoies une newsletter avec un pixel Mailchimp qui mesure tes ouvertures à des fins marketing, sans consentement collecté, tu es hors clous.

Ce que ça change pour toi qui lis tes emails sur Mac

Ici, rien à faire de plus. Les réglages de l’étape 1, “Protéger l’activité Mail” et “Bloquer tout le contenu distant” dans Apple Mail, étaient déjà la meilleure défense possible avant la recommandation. Ils le restent. La différence : ce qui était présenté comme “bonne pratique privacy” par les geeks est maintenant la position du régulateur. Tu n’es plus parano, tu es aligné avec la CNIL.

Proton Mail de son côté filtre les pixels espions par défaut, côté serveur, avant même que l’email arrive dans ta boîte. Cette option n’est pas un gadget : c’est exactement ce que la recommandation CNIL impose comme standard minimum en matière de respect du lecteur. Là aussi, l’outil était en avance sur la norme, la norme a rattrapé l’outil.

Le seul vrai changement, côté utilisateur : tu peux considérer que tout email commercial qui te piste sans t’avoir demandé ton consentement est désormais en infraction. Ça ne te rend pas grand-chose directement, mais ça donne un levier aux associations de défense, à la CNIL elle-même, et aux concurrents européens des géants du marketing automation. Le rapport de force a bougé.

Et si tu es du côté émetteur

Si tu envoies des emails dans un cadre pro, association, PME, freelance, indépendant avec une newsletter, la recommandation te concerne directement. Trois réflexes :

Tes emails transactionnels (confirmation, alerte, reset) peuvent garder un pixel de délivrabilité sans consentement, à condition qu’il serve vraiment à ça et rien d’autre.
Tes emails marketing, newsletters, campagnes doivent passer par un consentement explicite au traçage, distinct du simple opt-in à la newsletter. Lire ta lettre et accepter d’être mesuré, ce sont deux actes différents.
Tes outils d’emailing (Mailchimp, Brevo, Sendinblue, Substack) doivent te permettre de désactiver le pixel par défaut ou de le conditionner au consentement. Si ton outil ne le propose pas, tu vas devoir en changer avant mi-juillet.

Ce n’est pas la fin du mailing. C’est la fin du mailing aveugle, la fin de “j’ouvre, donc on me mesure”. Pour un site comme MacSouverain qui recommande depuis le début les outils qui respectent le lecteur, c’est une victoire silencieuse.

Si ça ne marche pas

Problème : les emails sont illisibles après avoir bloqué le contenu distant

Cause probable : l’email ne contient pas de version texte, uniquement du HTML avec images.
Solution : clique “Charger le contenu distant” en haut de l’email pour ce message spécifique. Le réglage global reste actif pour tous les autres.

Cause probable : variante macOS. Sur certaines versions de Sequoia/Tahoe, le chemin peut différer.
Solution : essaie Affichage > En-têtes de message > Personnalisé, puis coche les champs souhaités.

Problème : un collègue m’envoie des winmail.dat

Cause probable : il utilise Outlook en mode TNEF.
Solution : demande-lui d’envoyer en HTML ou texte brut. Si c’est récurrent, ne pas ouvrir avec des outils tiers non maintenus. Quick Look peut souvent afficher le contenu.

Pour les pressés

Cet article sécurise ton client mail contre les six principaux vecteurs d’attaque : pixels espions, fingerprinting CSS, pièces jointes piégées, zero-days client, spoofing email, et code actif dans les emails. Nouveauté 14 avril 2026 : la recommandation CNIL sur les pixels de suivi rend le blocage des pixels opposable en contrôle à partir de mi-juillet 2026. Tes réglages Apple Mail et Proton Mail ci-dessous étaient déjà conformes, ils le restent.

Concrètement, les réglages :

Confidentialité Mail

Mail > Réglages > Confidentialité > Protéger l’activité Mail = Activé

… > Bloquer tout le contenu distant = Activé

Pièces jointes & mises à jour

Mail > Réglages > Général > Ouvrir les pièces jointes sécurisées automatiquement = Désactivé

Réglages Système > Général > Mise à jour de logiciels > Mises à jour automatiques = Tout activé

Vérifier un email suspect

Affichage > Message > En-têtes longs (Cmd+Shift+H) → chercher Authentication-Results

Protection maximale

Proton Mail + Bridge + Apple Mail (3 couches indépendantes, zéro exécution de code actif)

Des termes techniques ? Consulte le glossaire.