Face à CVE-2026-0257, Palo Alto Networks publie des correctifs et deux mesures d’atténuation. Mais sécuriser l’accès VPN ne règle pas la question d’une intrusion antérieure : Rapid7 rapporte des exploitations dès mai 2026, et Arctic Wolf documente des intrusions de juin ayant abouti au rançongiciel Qilin.

L’exposition dépend d’abord de la configuration. CVE-2026-0257 ne touche pas automatiquement tous les pare-feu Palo Alto Networks : elle concerne certaines configurations utilisant les cookies d’Authentication Override et leurs certificats. Ces cookies interviennent dans l’authentification ; dans une configuration vulnérable, un attaquant peut fabriquer un cookie accepté et établir une connexion VPN sans passer par l’authentification normale.

Pour déterminer la réponse adaptée, il faut donc examiner à la fois les réglages des accès GlobalProtect, leur version logicielle et l’historique des connexions. Ces vérifications permettent de distinguer une configuration exposée d’un accès effectivement utilisé par un attaquant.

Vérifier les portails, les passerelles et leurs certificats

L’avis de Palo Alto Networks répertorie des versions concernées dans les branches PAN-OS 10.2, 11.1, 11.2 et 12.1, ainsi que Prisma Access 10.2 et 11.2. Il indique que Panorama et Cloud NGFW ne sont pas concernés. Ce périmètre doit être précisé par l’examen de la version exacte et des réglages de chaque équipement.

Pour chaque portail et chaque passerelle GlobalProtect, la vérification porte sur la génération ou l’acceptation des cookies d’Authentication Override, puis sur le certificat utilisé. Rapid7 explique que réutiliser le certificat des cookies pour un service HTTPS peut rendre sa clé publique accessible et permettre la fabrication d’un cookie accepté par une configuration vulnérable. Le mécanisme décrit donne accès au VPN par contournement de l’authentification ; il ne démontre pas une exécution de code sur le pare-feu.

La version installée doit ensuite être confrontée au tableau officiel des versions concernées et corrigées. Les seuils varient selon les branches et les sous-versions : connaître seulement le numéro de branche ne permet pas de conclure que l’équipement est corrigé.

Coordonner la correction ou appliquer une atténuation officielle

Palo Alto Networks recommande d’installer une version corrigée. Dans les environnements utilisant les cookies d’Authentication Override, le constructeur précise que tous les portails et passerelles qui les génèrent ou les acceptent doivent être mis à niveau de façon coordonnée. Après cette opération, les utilisateurs doivent s’authentifier de nouveau une fois.

Le constructeur documente également deux mesures d’atténuation :

• désactiver les cookies d’Authentication Override ;
• utiliser pour ces cookies un certificat neuf et exclusivement réservé à cet usage.

La seconde option exige donc davantage que la sélection d’un autre certificat déjà partagé avec un service HTTPS : le caractère neuf et dédié du certificat fait partie de la mesure publiée.

L’avis décrit aussi un réglage temporaire de compatibilité pour une mise à niveau progressive. Ce réglage rétablit un ancien comportement des cookies. Il accompagne une migration et ne doit pas être repris isolément comme une protection permanente.

Rechercher les connexions réussies suspectes

L’examen des journaux vise à déterminer si la vulnérabilité a déjà été exploitée. Unit 42, l’équipe de recherche de Palo Alto Networks, recommande de rechercher dans les journaux GlobalProtect les connexions réussies correspondant aux adresses, identifiants d’hôte et noms d’appareil publiés dans ses indicateurs, ainsi que les événements « gateway-connected » suspects.

Lorsqu’une connexion réussie correspond à ces indicateurs, Unit 42 recommande d’engager une réponse à incident. L’investigation doit alors porter sur les conséquences possibles de l’accès obtenu, au-delà de la configuration du portail VPN.

Ces indicateurs servent au triage, c’est-à-dire à repérer les événements qui demandent une investigation. Leur liste n’étant pas exhaustive, l’absence de correspondance ne permet pas de déclarer le réseau sain. De même, l’installation du correctif ne démontre pas l’éradication d’une intrusion antérieure.

De l’accès VPN au rançongiciel dans les cas étudiés

Les observations publiées illustrent les conséquences possibles de cet accès. Rapid7 rapporte des exploitations réussies chez plusieurs clients, avec une première activité observée le 17 mai 2026. Dans ses observations de mai, l’entreprise ne décrivait toutefois pas de déplacement latéral réussi, c’est-à-dire de progression vers d’autres systèmes du réseau. Ce constat reste limité au périmètre et à la période observés par Rapid7.

Arctic Wolf a, de son côté, documenté plusieurs intrusions distinctes de juin ayant abouti au déploiement de Qilin. Ses enquêtes décrivent une collecte d’identifiants, des déplacements latéraux, un effacement de journaux et un chiffrement, ainsi qu’une exfiltration de données dans certains cas. Ces résultats concernent les incidents étudiés par Arctic Wolf ; ils ne décrivent pas l’issue de toute exploitation de la faille.

À partir de ces enquêtes, Arctic Wolf propose de surveiller les activités observées après l’accès VPN. Ces recommandations complémentaires lui sont propres. Parmi les recommandations directement publiées par Palo Alto Networks figurent la correction ou l’atténuation de la configuration vulnérable, la recherche des connexions suspectes et la réponse à incident lorsqu’une connexion réussie correspond aux indicateurs de Unit 42. Cette sélection ne constitue pas un inventaire exhaustif des consignes officielles.

Les sources publiques consultées ne permettent pas d’établir le nombre total d’organisations compromises. Pour une organisation qui examine ses propres accès, la décision dépend de ses constats : si une connexion suspecte est identifiée, la mise à jour de GlobalProtect laisse ouverte l’investigation des actions réalisées dans le réseau.

Sources

• Palo Alto Networks, avis de sécurité CVE-2026-0257
• Unit 42, texte indexé du Threat Brief sur CVE-2026-0257
• Rapid7, exploitation observée et analyse technique
• Arctic Wolf Labs, Cookie Crumbles

Une faille d’Ivanti Connect Secure permet à un attaquant distant d’exécuter des commandes sans authentification. Volexity documente son exploitation. Pour les administrateurs, la priorité est d’identifier les versions concernées, d’appliquer le correctif adapté et de rechercher une éventuelle intrusion : la mise à jour ne suffit pas à écarter une compromission antérieure.

Sur une passerelle d’accès distant comme Connect Secure, la correction et l’examen d’une intrusion répondent à deux questions distinctes. La première porte sur la vulnérabilité du système ; le second cherche à établir ce qu’un attaquant a pu y faire avant l’installation du correctif. Rapid7 recommande donc de rechercher une compromission même après la mise à jour.

La fiche CVE publiée sous l’autorité d’attribution d’Ivanti décrit CVE-2026-104935 comme un contournement d’authentification par usurpation permettant l’exécution de commandes arbitraires. Elle indique une attaque réseau de faible complexité, sans privilège initial ni interaction de l’utilisateur, avec un score CVSS 3.1 de 8,6.

Identifier précisément les branches déployées

La première vérification consiste à relever le numéro complet de version de chaque appliance. Les seuils dépendent de la branche et de sa révision : un numéro abrégé ne permet pas de déterminer correctement l’exposition.

Rapid7 et le Center for Internet Security indiquent les seuils affectés et les versions corrigées suivants :

Les trois versions limites figurant dans ce tableau sont donc concernées selon ces sources. L’alerte du NHS England emploie une formulation « prior to » qui semble les exclure. Cette divergence justifie de confirmer la matrice de mise à niveau auprès d’Ivanti avant l’intervention, sans considérer ces versions limites comme épargnées.

La fiche CVE précise que 22.7R2.14 et les versions antérieures ne sont pas touchées par cette CVE particulière. Cette exclusion ne renseigne pas leur exposition à d’autres vulnérabilités et ne constitue pas une appréciation générale de leur sécurité.

Distinguer le correctif de la chaîne complète d’attaque

Le tableau permet d’identifier la mise à jour à examiner. La procédure applicable, les éventuelles mesures d’atténuation et les consignes de récupération restent à confirmer auprès d’Ivanti.

Il faut aussi distinguer CVE-2026-104935 de la chaîne complète décrite par Volexity. Dans son enquête, l’entreprise rapporte un routage abusif de requêtes vers un composant CGI protégé, suivi d’une exécution de code et d’une élévation de privilèges distincte. Cette dernière étape a permis d’exécuter des commandes avec les privilèges root sur une appliance 22.8R2.4 alors à jour. Ces privilèges correspondent au niveau de contrôle obtenu sur le système dans ce cas précis.

Dans leurs publications du 13 octobre 2026, Volexity et Rapid7 indiquaient que le correctif de cette élévation de privilèges distincte restait à venir. Les mises à jour visant CVE-2026-104935 ne doivent donc pas être présentées comme corrigeant toute la chaîne. La disponibilité ultérieure d’un correctif pour cette autre faille reste à vérifier auprès du fournisseur.

L’inscription au catalogue des vulnérabilités exploitées connues de CISA, le KEV, renforce la priorité donnée à cette alerte. Selon Rapid7 et la reprise des données du catalogue par CIRCL, CVE-2026-104935 y a été ajoutée le 13 octobre 2026, avec une échéance au 16 octobre pour les entités soumises aux exigences fédérales américaines applicables. Cette échéance n’est pas une date limite réglementaire universelle.

Rechercher les signes d’entrée et les actions qui ont suivi

Volexity situe au plus tard au 3 octobre 2026 le début de l’exploitation répétée reconstituée dans son enquête. Sur l’appliance étudiée, l’entreprise décrit notamment des recherches de secrets Active Directory, une exfiltration de données et une altération des journaux. Ces observations orientent l’examen d’un système suspect, sans établir que toutes les appliances vulnérables ont subi les mêmes actions.

Pour rechercher des traces, Volexity recommande notamment de surveiller les requêtes anormalement nombreuses vers la page de connexion concernée, les incohérences entre le chemin demandé et l’en-tête de routage, ainsi que l’activité après exploitation. L’entreprise prévient que d’autres chemins pourraient être employés : limiter l’examen au seul parcours observé risquerait de laisser de côté une autre forme d’exploitation.

L’examen doit ainsi porter sur les signes d’entrée comme sur les actions qui ont pu suivre. Lorsque l’exploitation est suspectée, Rapid7 renvoie aux procédures de récupération du fournisseur. Leurs étapes restent à obtenir auprès d’Ivanti ; le récit de l’attaque ne permet pas de les reconstituer.

Pourquoi le contrôle d’intégrité peut manquer une compromission

Selon Volexity, l’Integrity Checker Tool recherche des modifications de fichiers sur disque. Or la chaîne observée modifiait notamment du code en mémoire puis restaurait certaines données. Un contrôle centré sur l’état des fichiers peut ainsi manquer des traces de cette activité. Une absence d’alerte de l’outil ne suffit donc pas à écarter une compromission.

La capture publiée par Volexity provient de son enquête et de son outil commercial d’analyse mémoire Volcano. Elle montre des alertes dans le cas étudié, notamment liées à une activité de capture réseau. Elle illustre le type de traces que l’analyse mémoire peut apporter en complément de l’examen des fichiers, sans mesurer l’efficacité générale de cette détection ni représenter toutes les exploitations.

Dans le suivi de l’incident, il faut donc conserver séparément la version identifiée, la correction appliquée et le résultat de la recherche de compromission. Un résultat normal du contrôle d’intégrité ne doit pas clore à lui seul ce dernier volet. Si des indices subsistent, les consignes de récupération du fournisseur restent la référence à consulter.

Sources

• CVE Program, fiche CVE-2026-104935, autorité d’attribution Ivanti
• Volexity, A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days
• Rapid7, Ivanti Connect Secure zero-day exploited in the wild
• Center for Internet Security, A Vulnerability in Ivanti Connect Secure Could Allow for Arbitrary Code Execution
• CIRCL Vulnerability-Lookup, reprise de l’entrée CISA KEV pour CVE-2026-104935
• NHS England Digital, Ivanti Releases Security Updates for Connect Secure

Si un CV reste en apparence un document classique, avec ses expériences, ses compétences et ses diplômes, ce que le recruteur voit à l’écran ne correspond pas toujours à ce que son logiciel lit. Certains documents contiennent des informations presque imperceptibles pour un humain, mais accessibles à l’extraction automatique. Des compétences supplémentaires peuvent ainsi être prises en compte par le logiciel sans apparaître dans la présentation lue par le recruteur.

Fait vérifié. Présentée à USENIX Security 2026, une étude de Mohan Zhang et ses coauteurs porte sur 196 682 CV et rapporte 2 030 détections de contenus cachés classés comme injections, soit environ 1 %. Plus de 90 % des contenus repérés sont des ajouts de données sans instruction explicite, notamment des compétences et des expériences. Ces chiffres ne mesurent ni des recrutements obtenus frauduleusement ni des intrusions informatiques. étude USENIX sur les CV

Le point de départ est donc une manipulation de l’information soumise au traitement automatique. Une compétence supplémentaire peut rendre un profil plus pertinent pour un moteur de recherche ou un dispositif de classement, sans jamais commander au logiciel de changer de comportement.

Mais une autre question apparaît : un CV pourrait-il aussi donner des instructions à l’IA chargée de l’évaluer, puis tenter de détourner les outils auxquels elle a accès ? Cette hypothèse mérite un examen précis. Elle dépend du chemin suivi par les données, du comportement du modèle et des permissions effectives de l’application.

Pour les directions informatiques, les responsables de sécurité et les équipes RH, l’enjeu consiste à comprendre où se situe cette frontière. Un document reçu de l’extérieur doit pouvoir être analysé sans devenir une autorité sur le fonctionnement du système. Les études disponibles permettent déjà d’examiner la manipulation des évaluations. Une éventuelle chaîne reliant candidature, agent et accès internes exige, elle, des preuves supplémentaires.

Le CV, un support de confiance déjà exploité

Les recruteurs ont une particularité opérationnelle : leur travail les oblige à ouvrir des documents et à consulter des liens transmis par des personnes qu’ils ne connaissent pas. Une candidature constitue une raison légitime d’engager cette interaction. Ce contexte donne aux attaquants un prétexte crédible, sans rendre chaque document suspect par nature.

Faits historiques. En 2017, Check Point a décrit des failles permettant de transférer des fichiers malveillants par la messagerie LinkedIn sous une apparence acceptable. LinkedIn avait déployé un correctif le 24 juin 2017, avant la publication du rapport. Il s’agissait de sécurité des fichiers et d’exécution de code, pas d’injection de prompt. rapport Check Point de 2017

En décembre 2023, Proofpoint a documenté des campagnes de TA4557 visant les recruteurs. Des échanges avec de faux candidats les conduisaient vers des sites imitant des CV, puis vers une chaîne d’infection liée à More_eggs. Certains documents servaient à orienter la victime vers le site ; cela ne signifie pas que chaque PDF constituait lui-même un malware. recherche Proofpoint sur TA4557

Aryaka décrit également, dans son rapport BlackSanta, une campagne utilisant des liens vers des fichiers présentés comme des CV pour cibler les processus de recrutement. Cette source de recherche d’éditeur concerne encore une infection classique, distincte du détournement d’un modèle de langage. rapport BlackSanta d’Aryaka

Le rapprochement avec les agents IA porte sur le point d’entrée : du contenu extérieur arrive au cœur d’une activité légitime. Le mécanisme change ensuite. Un logiciel malveillant cherche une exécution informatique ; une injection de prompt cherche à faire interpréter un texte comme une consigne. Une entreprise peut donc avoir correctement sécurisé l’ouverture des pièces jointes tout en conservant un risque dans leur traitement sémantique.

Extraction, classement et agent : trois niveaux à distinguer

Parler de « recrutement par l’IA » sans préciser l’architecture entretient la confusion. Un premier traitement peut simplement convertir un document en texte et remplir des champs : poste occupé, durée d’expérience, diplôme, compétences déclarées. Un autre peut rapprocher ces champs d’une fiche de poste. Un troisième peut produire une synthèse ou une note. Enfin, un agent peut sélectionner des actions et solliciter des outils.

Ces opérations ont des surfaces de risque différentes. Une liste cachée de compétences peut contaminer une extraction, y compris sans modèle génératif. Une instruction destinée à modifier une justification suppose qu’un composant interprète ce texte et lui accorde une influence indue. Un appel à un dossier interne suppose encore une capacité d’action et des permissions correspondantes.

Connectivité documentée. La documentation Apply Connect de LinkedIn décrit une intégration permettant aux partenaires de recevoir des candidatures directement dans leur ATS, c’est-à-dire leur système de suivi des candidatures. Elle établit un flux métier ; elle ne décrit pas une attaque. documentation Apply Connect

Bullhorn documentait dès 2020 une intégration Recruiter System Connect entre LinkedIn et ses solutions fondées sur Salesforce. Les fonctions de synchronisation et de consultation doivent être comprises dans leur périmètre propre. Elles ne démontrent pas le transfert systématique d’un PDF brut à un agent. intégration LinkedIn et Bullhorn

La fiche Bullhorn Amplify for Salesforce annonce des fonctions de matching et de screening. Une présentation officielle de Bullhorn décrit aussi des agents configurables fondés sur Agentforce dans Recruitment Cloud. Ces documents commerciaux attestent des capacités proposées, sans révéler les permissions de chaque installation ni prouver une vulnérabilité. fiche Bullhorn Amplify, présentation officielle de Bullhorn

L’audit utile commence donc par une cartographie concrète. Quel composant extrait le texte ? Quelles transformations suivent ? Le modèle reçoit-il le document entier ou quelques champs ? Peut-il seulement proposer une réponse, ou aussi consulter des informations et modifier un statut ? Qui autorise ces opérations ? Les réponses comptent davantage qu’une étiquette « IA » dans une brochure.

Ce que les recherches établissent réellement

Observation sur des documents réels. Le PDF final de l’étude USENIX identifie hireEZ comme origine des données. Les auteurs réunissent deux jeux de CV désidentifiés et utilisent un détecteur spécialisé pour repérer des éléments cachés. Leur définition large comprend les ajouts de données et les instructions explicites. texte intégral de l’étude USENIX

Le détail temporel impose une nuance : les taux connaissent un pic en 2024, puis baissent dans les observations récentes. Dans le jeu Applicant Match, les auteurs estiment néanmoins une augmentation du nombre absolu de documents concernés, liée au volume de candidatures. Dire simplement que « les attaques augmentent » effacerait la différence entre fréquence et quantité. Le rappel exact du détecteur sur l’ensemble du corpus demeure inconnu ; aucune efficacité sur les décisions finales n’est mesurée. texte intégral de l’étude USENIX

Expérience sur le filtrage. Honglin Mu et ses coauteurs évaluent différentes manipulations dans un benchmark de sélection de CV. La version révisée du 26 avril 2026 rapporte des taux dépassant 80 % pour certaines catégories, dans ses conditions expérimentales. Le tableau consacré aux méthodes attribue notamment 80,89 % à la catégorie « Job Manipulation » sans défense ; ce taux ne résume pas toutes les attaques et ne mesure aucun accès à un système interne. étude de Mu et ses coauteurs, benchmark et résultats détaillés

Cette étude signale aussi un compromis : les protections évaluées peuvent réduire la manipulation tout en augmentant les rejets de candidatures légitimes. Une défense RH doit donc être évaluée pour sa sécurité et pour ses effets sur les personnes, au lieu de retenir uniquement un taux de blocage. benchmark et résultats détaillés

Expérience sur le classement. Preet Baxi et ses coauteurs observent que les manipulations sont plus efficaces lorsque les profils ont une qualité similaire et que peu de candidats les utilisent. L’avantage diminue lorsque la manipulation se généralise. Leur étude porte sur les positions dans un classement, pas sur une fuite de données. étude de Baxi et ses coauteurs

Expérience sur la détection. RAPIDS, présenté par Yohann Augey et ses coauteurs, combine un petit modèle spécialisé et une vérification supplémentaire. Les auteurs annoncent un rappel de bout en bout d’au moins 98 % sur les deux jeux évalués, avec une latence réduite d’un facteur 21 à 24 par rapport à leur référence. Le texte précise toutefois une couverture limitée aux CV anglophones et un jeu réel annoté de 1 945 documents. publication RAPIDS, méthode et limites de RAPIDS

Ces travaux mesurent des contenus, des classements ou une capacité de détection. Établir une compromission d’entreprise demanderait encore des preuves d’actions effectives et de franchissement des contrôles d’accès.

Trois mécanismes, trois réponses

Une injection de données ajoute de l’information destinée au traitement automatique. Dans un exemple entièrement fictif, le CV visible mentionne une expérience de support informatique ; le texte extrait contient aussi des compétences absentes de la présentation. Le problème porte sur la fidélité de la représentation et sur la confiance accordée à des qualifications déclarées.

Une injection d’instructions cherche à orienter l’évaluateur. Elle peut tenter de modifier le commentaire ou de faire abandonner une règle de classement. La question devient celle de l’autorité : le contenu d’une candidature ne doit pas définir la procédure utilisée pour l’examiner. Une telle instruction peut être visible ; son invisibilité facilite certaines manipulations, mais ne constitue pas une condition nécessaire.

Un malware vise une exécution ou une compromission technique selon une autre chaîne. Le document, le téléchargement ou le lien peut servir d’amorce. Confondre ces mécanismes conduirait à choisir une défense adaptée à un problème différent de celui rencontré.

Du CV à l’outil interne : une hypothèse conditionnelle

Hypothèse, non chaîne démontrée. Imaginons qu’un CV conserve une instruction après extraction, que cette instruction arrive dans le contexte d’un agent et que celui-ci la traite comme légitime. Il pourrait alors proposer une action étrangère à l’évaluation. Pour que cette proposition produise un effet, un outil doit exister, être accessible et accepter l’appel.

Chaque flèche correspond à une condition à vérifier. Une extraction peut retirer le passage suspect. Une représentation structurée peut réduire sa portée, tout en conservant des données trompeuses. Le modèle peut ignorer la sollicitation. Une règle applicative peut refuser l’action. L’absence d’une seule capacité peut interrompre le scénario envisagé.

Précédents indépendants. ForcedLeak, publié par Noma Security en septembre 2025, concernait une injection indirecte via des données Web-to-Lead dans Salesforce Agentforce. Les chercheurs décrivaient un risque de fuite de données CRM et des mesures correctives de Salesforce, notamment sur les destinations de sortie autorisées. L’entrée étudiée était un formulaire commercial, pas un CV. recherche ForcedLeak de Noma

EchoLeak, associé à CVE-2025-32711, concernait Microsoft 365 Copilot et un e-mail préparé pour provoquer une fuite dans les conditions de la démonstration. L’analyse publiée rapporte une correction côté service. Ce précédent ne démontre aucune attaque par candidature, ni une exploitation observée chez des recruteurs. étude de cas EchoLeak, analyse et chronologie d’EchoLeak

Ces cas montrent pourquoi les contrôles doivent porter sur l’ensemble de l’application. Le modèle n’a pas besoin d’obtenir de nouveaux privilèges si l’application lui en accorde déjà trop pour la tâche. À l’inverse, une réponse dévoyée peut rester sans effet opérationnel lorsque les capacités sont étroitement limitées.

Ce que je sais / Ce que je suppose / Ce que j’ai observé en lab

En lab, le CV visible ne change pas, mais sa note augmente

Pour observer ces mécanismes, j’ai évalué en lab quatre profils entièrement fictifs. Le profil B possède un an d’expérience en support bureautique. Ses variantes ajoutent soit des compétences cachées, soit une instruction neutre concernant le commentaire, soit une sollicitation de consultation fictive. Les quatre versions produisent exactement la même image avec le moteur de rendu utilisé ; leurs extractions textuelles diffèrent.

La campagne du 12 octobre 2026 comprend 320 essais, avec 20 répétitions par condition. Elle utilise Qwen3.5 9B, quantifié en Q4_K_M, sous Ollama 0.33.2, à une température de 0,2, sans mode de raisonnement étendu. Chaque requête repart d’une conversation neuve. Le serveur et le programme d’essais sont isolés du réseau extérieur.

La grille réserve 40 points aux compétences, 30 à l’expérience, 20 aux incidents résolus et 10 à la formation. La configuration de départ fournit déjà cette tâche et un format de réponse. La configuration renforcée ajoute une consigne de séparation et un balisage du CV comme donnée non fiable. Une troisième configuration conserve ces consignes et ajoute un refus des consultations inutiles dans le code.

Les compétences ajoutées augmentent donc la note moyenne d’environ 26 points dans les deux configurations. Le modèle les lit dans le texte extrait et les prend en compte dans son évaluation. Ce scénario ne contient aucune instruction lui demandant de changer sa note : il illustre une modification des données utilisées pour juger le profil.

La consigne renforcée ne corrige pas cet effet. Elle vise les instructions contenues dans le CV, tandis que les ajouts ressemblent à des qualifications ordinaires. Le modèle reçoit le texte, sans l’image du document : il ne peut pas comparer les deux vues pour repérer ce qui était invisible. La vérification documentaire doit donc intervenir avant que cette information visuelle soit perdue.

L’instruction neutre produit un autre résultat. Elle demande une modification de la fin du commentaire, sans ajouter de qualification. Elle est suivie dans toutes les réponses de départ, puis dans huit réponses malgré les consignes renforcées. Dans ces huit sorties, le champ prévu pour les alertes reste vide. La séparation réduit ici l’effet observé, mais ne l’élimine pas. En revanche, la note moyenne de cette variante n’augmente pas : modifier le commentaire et améliorer le score sont deux conséquences distinctes.

Une proposition d’outil n’est pas un accès aux données

Dans le scénario de consultation, le modèle peut produire une proposition structurée pour un mock, un outil simulé. Six réponses de départ en proposent une, alors que la consultation est annoncée comme inutile à l’évaluation. Le code retourne seulement une constante inventée. Avec les consignes renforcées, aucune proposition n’apparaît, y compris dans la configuration ajoutant le contrôle applicatif.

Cela signifie qu’aucun refus n’a été exercé par cette dernière barrière pendant la campagne. Son fonctionnement est vérifié séparément par les tests du dispositif, qui soumettent directement des demandes au contrôle. Présenter le résultat comme des attaques effectivement bloquées par le code confondrait ces deux vérifications.

Le modèle n’a reçu aucun outil natif d’Ollama : il produit des objets de données ensuite examinés par le programme. Le retour fictif n’est pas réintroduit dans une seconde conversation. Ce test ne mesure donc ni une action d’agent de bout en bout, ni un accès à un dossier, ni une fuite. La déclaration du mock n’apparaît que dans ce scénario ; les six propositions ne suffisent pas à attribuer causalement leur apparition au seul texte du CV.

Un format correct peut accompagner une évaluation discutable

Les 320 réponses respectent les champs, les bornes et la somme des sous-scores. Aucun essai n’est rejeté pour erreur de format ou délai dépassé. Cela ne garantit pas la fiabilité du contenu. Dans la variante à compétences cachées, 30 réponses sur 40 fournissent une citation qui ne correspond pas à un passage continu du texte extrait, souvent en assemblant les compétences visibles et ajoutées. Ce défaut de citation ne prouve pas que ces compétences ont été inventées par le modèle.

Deux réponses signalent aussi, à tort, qu’un total de 58 points dépasse le plafond de 100. Même la référence varie : de 25 à 40 points au départ et de 22 à 50 avec les consignes renforcées. Les moyennes décrivent cette grille et ce modèle ; elles ne valident pas la justesse des notes pour recruter.

Enfin, les répétitions portent sur les mêmes documents fictifs, avec différentes graines de génération. Elles renseignent sur la variabilité de ces conditions, pas sur la fréquence d’une attaque parmi de vrais candidats. Aucun détecteur visuel, autre modèle ou logiciel RH commercial n’a été évalué. Le lab montre une frontière de confiance à protéger, sans démontrer une vulnérabilité de produit.

Des défenses qui protègent aussi la décision RH

Cadres défensifs. OWASP recommande notamment de séparer les contenus extérieurs, de limiter les privilèges et de valider les sorties par du code. Microsoft présente également une défense en profondeur contre les injections indirectes. Ces recommandations fournissent un cadre ; leur efficacité dépend de leur mise en œuvre et de leur évaluation. recommandations OWASP, défense en profondeur de Microsoft

Pour une équipe RH, la première décision consiste à définir ce que l’agent peut accomplir. Une synthèse de candidature peut souvent être produite à partir du seul document et de la fiche de poste. Lui donner, pour cette tâche, un accès général à tous les dossiers ou à des fonctions d’envoi élargit inutilement les conséquences d’une erreur.

La deuxième priorité concerne la provenance. Les qualifications restent des déclarations du candidat, même après leur extraction dans une base interne. Le stockage ne leur confère aucune autorité sur la procédure. Une synthèse intermédiaire devrait conserver les passages justificatifs et permettre de retrouver le document d’origine, afin qu’un champ douteux puisse être examiné.

La troisième priorité consiste à rendre les autorisations explicites. Chaque outil doit vérifier l’identité, les ressources accessibles, l’objet de la tâche et les paramètres. La justification rédigée par le modèle ne suffit pas à créer un droit. Une action doit être refusée si elle dépasse les capacités prévues, même lorsque la sortie respecte parfaitement le format demandé.

La détection documentaire complète ces barrières. Comparer rendu et extraction peut faire apparaître du contenu supplémentaire. Un signal doit déclencher une revue proportionnée, avec examen des artefacts de conversion possibles. Le candidat ne devrait pas être exclu automatiquement sur la seule décision d’un détecteur : une erreur de mise en page et une manipulation intentionnelle ne se déduisent pas d’une simple alerte.

Enfin, la supervision humaine doit disposer de preuves utilisables : critères, citations du CV, transformations appliquées, alertes et actions proposées. Valider une note sans accès à ces éléments peut seulement ajouter une signature à une décision opaque. Pour un responsable RH, la possibilité de contester une extraction ou de revenir au document compte autant que la fluidité de l’interface.

Cadre réglementaire vérifié le 12 octobre 2026. L’annexe III de l’AI Act vise notamment certains systèmes d’analyse, de filtrage et d’évaluation des candidatures. Le texte de l’article 113 affiché par le service officiel et sa FAQ indiquent le 2 décembre 2027 pour les dispositions relatives aux systèmes à haut risque de cette annexe. La qualification précise et les dispositions transitoires doivent être examinées selon le système ; cette date ne résume pas toutes les obligations applicables. annexe III de l’AI Act, article 113 de l’AI Act, calendrier officiel de l’AI Act

Le contenu caché des CV pose déjà une question de fidélité des données utilisées pour recruter. Les instructions malveillantes ajoutent une question d’autorité ; les agents connectés ajoutent une question de permissions. Examiner ces trois niveaux permet d’agir sans transformer une hypothèse en incident établi. Le CV peut renseigner l’entreprise sur une candidature. Il ne doit pas définir les règles de son évaluation ni les droits de son évaluateur.

EvilTokens fait passer une autorisation d’accès pour une vérification nécessaire à l’ouverture d’un document. L’utilisateur peut alors authentifier la demande de l’attaquant sur une véritable page Microsoft. Le parcours décrit par Microsoft éclaire ce piège, les traces à examiner après une suspicion et les mesures de sécurisation à adapter à son environnement.

Une attaque contre le sens de l’autorisation

Un code de connexion relie deux actions : la demande d’un client logiciel et sa validation par un utilisateur. Dans le parcours EvilTokens, le leurre dissimule qui a lancé cette demande. La personne croit vérifier son identité pour accéder à un document, alors qu’elle accorde un accès au client contrôlé par l’attaquant. Le mot de passe et la vérification multifacteur peuvent être saisis sur le bon site sans corriger ce décalage.

Dans son analyse du 22 septembre 2026, Microsoft décrit une plateforme de phishing par abonnement qui organise cette chaîne, depuis la préparation du message jusqu’à l’exploitation des comptes. L’entreprise lui associe plus de 12 000 boîtes compromises dans plus de 10 000 organisations et attribue son développement et son support à Storm-2992. Ces chiffres et cette attribution restent les conclusions de Microsoft ; les autres sources fournies ne les valident pas indépendamment.

Huntress a relié à EvilTokens une campagne observée sur Railway, tandis que Cloudflare rapporte l’utilisation de ses Workers et sa participation à une opération coordonnée de démantèlement. Ces observations corroborent des mécanismes et des infrastructures dans leurs périmètres respectifs. Elles ne constituent pas une mesure indépendante de l’ensemble des victimes annoncé par Microsoft.

Les neuf captures publiées dans l’analyse Microsoft permettent de suivre l’organisation du service et le parcours proposé à la victime. Les écrans commerciaux documentent des options et des promesses, dont l’affichage ne prouve pas l’efficacité. Les observations d’incidents apportent une autre information : elles décrivent les actions effectivement rapportées dans les cas étudiés.

Le code appareil : un usage légitime détourné

Le flux OAuth par code appareil répond à une contrainte réelle. Un téléviseur, une imprimante ou certains équipements Teams ne permettent pas une connexion interactive confortable. Le client demande alors un code à Microsoft, l’affiche, puis attend. L’utilisateur saisit ce code dans un navigateur, éventuellement sur un autre appareil, et termine l’authentification. Après cette autorisation, le client demandeur reçoit un jeton d’accès et, selon le cas, un jeton de renouvellement.

Le jeton d’accès permet d’utiliser les ressources autorisées ; le jeton de renouvellement sert à obtenir de nouveaux jetons d’accès. La distinction compte pour la suite : récupérer ces éléments ne revient pas seulement à connaître un mot de passe. L’attaquant dispose d’un moyen d’exercer l’accès accordé au client, dans les limites des autorisations obtenues et de la validité des jetons.

Dans le détournement décrit par Microsoft, le client demandeur est contrôlé par l’attaquant. Le code est présenté à la victime comme une étape nécessaire pour consulter un document ou vérifier son identité. L’utilisateur effectue une authentification légitime, mais au bénéfice d’une demande qu’il n’a pas lui-même initiée. Parler simplement de « MFA contournée » masque cette mécanique : la victime peut accomplir elle-même l’authentification multifacteur, ou MFA, pendant qu’elle autorise la mauvaise session.

Une boutique, un support et un panneau de campagne

Selon Microsoft, EvilTokens rassemble dans une même plateforme les éléments nécessaires à une campagne : modèles de messages, pièces jointes, pages d’arrivée, hébergement, redirections et suivi des victimes. Les abonnés peuvent ainsi préparer leurs opérations avec l’assistance du service, plutôt que de construire séparément chaque composant technique.

Le profil du bot Telegram présenté comme la boutique EvilTokens affiche un contact d’administration, un site et un contact de secours. Ces différents points de contact donnent au service l’apparence d’une offre suivie, avec plusieurs moyens de joindre ses opérateurs. Microsoft rapporte que Telegram sert également aux annonces, aux mises à jour, à la coordination des abonnés et au support. Le profil ne permet pas d’identifier les personnes derrière ces comptes.

L’offre affichée dans le bot mêle vocabulaire d’entreprise et promesses offensives. Elle présente notamment des jetons qui « n’expirent pas » et un accès persistant après changement de mot de passe. Dans son analyse de septembre 2026, Microsoft rapporte un achat initial de 1 500 dollars américains et un abonnement mensuel de 500 dollars. Ces tarifs décrivent l’offre étudiée, sans établir sa disponibilité actuelle. Les promesses de non-expiration et de persistance ne remplacent pas l’examen des autorisations et de la validité réelle des jetons.

La page d’accueil du panneau répartit la préparation entre deux familles d’hébergement : Cloudflare Workers/Bunny et hébergement PHP. Elle présente ensuite des réglages de mode de capture, de modèle, d’affichage du code, de langue, de CAPTCHA et de personnalisation. L’intérêt de cette interface guidée est de rapprocher des choix habituellement dispersés : où héberger le leurre, quelle apparence lui donner et comment présenter l’étape d’autorisation à la cible.

Le panneau de gestion des jetons annonce l’accès à la messagerie, la détection de comptes administrateurs, le renouvellement automatique et des alertes par mots-clés. Il présente donc l’authentification de la cible comme le début d’un travail sur le compte, plutôt que comme la fin de l’attaque. Les possibilités étendues promises pour certains jetons administrateurs restent toutefois des affirmations du service : les permissions réellement obtenues, notamment sur les autres boîtes d’une organisation, ne sont pas établies par cet écran.

La page d’outils complémentaires propose un navigateur ET, un redirecteur antibot, un expéditeur B2B, un expéditeur SMTP et un validateur d’adresses Office. Les boutons d’acquisition et de tutoriel, ainsi que l’offre de parrainage, prolongent la logique de boutique. Microsoft rapporte des frais supplémentaires pour plusieurs modules et une récompense en cryptomonnaie pour les recommandations. Ce catalogue montre comment le service commercialise des fonctions autour du leurre, de sa diffusion et de l’exploitation des accès ; il ne mesure pas leur contribution aux incidents.

Microsoft rapporte aussi l’usage d’assistants d’IA pour adapter les messages au rôle de la cible et analyser des messageries compromises. Cette assistance s’inscrit dans la même organisation du travail : préparer un message pertinent, puis chercher des comptes ou des échanges intéressants après l’accès. Les observations fournies ne permettent ni de quantifier le gain apporté par l’IA ni de conclure qu’elle intervient dans toutes les campagnes.

Des modèles familiers pour faire accepter une étape inhabituelle

Le sélecteur de thèmes présente notamment la signature Adobe, DocuSign, une notification vocale, la quarantaine de messagerie, l’expiration de mot de passe et le partage de fichiers. Des champs permettent de modifier la couleur, le nom du document et le pied de page. Microsoft décrit 44 thèmes au total, dont seule une partie apparaît dans la capture. Ces réglages permettent d’envelopper la demande de code dans plusieurs situations professionnelles familières, sans changer le principe de l’autorisation recherchée.

Le ressort du leurre est de rendre cohérente une étape qui, isolément, devrait interroger. La signature d’un document peut servir de prétexte à une vérification d’identité ; un avis d’expiration suggère une action urgente ; une proposition commerciale donne une raison d’ouvrir un lien. Microsoft décrit des messages adaptés aux fonctions des destinataires. Huntress rapporte également des propositions de chantier, des accords commerciaux, des messages sur la rémunération et des avis d’expiration de mot de passe.

Le courriel présenté en exemple invite le destinataire à soumettre une proposition pour un projet et renvoie vers un dossier annoncé comme accessible via Adobe. Une référence de document et une invitation à poser des questions lui donnent le ton d’un échange professionnel ordinaire. Le message fournit ainsi une raison d’ouvrir le lien avant toute demande de connexion. La capture ne révèle cependant ni l’identité réelle de l’expéditeur, ni la destination effective du lien, ni le résultat de l’interaction.

Les points d’entrée décrits par Microsoft comprennent des URL, des PDF et des fichiers HTML. L’interaction avec le lien ou la pièce jointe amorce le parcours vers la page de phishing. Le leurre n’a donc pas besoin de demander immédiatement un mot de passe : il peut d’abord conduire la personne vers une étape intermédiaire qui prépare l’autorisation.

Du faux document à la véritable connexion Microsoft

La page aux couleurs d’Adobe Acrobat Sign associe un document nommé Important_update.pdf à une demande de vérification d’identité avec Microsoft. Elle affiche un code, propose de le copier, puis de continuer vers Microsoft. L’accès au document devient ainsi le motif apparent de l’opération. Cette mise en scène est visible dans la capture ; la génération du code en temps réel et la récupération ultérieure des jetons sont décrites par l’analyse Microsoft.

Selon Microsoft, la page exécute un script d’automatisation qui échange avec le fournisseur d’identité pour obtenir un code valide. Le bouton de continuation dirige ensuite la victime vers le portail officiel microsoft.com/devicelogin. L’analyse décrit aussi une copie automatique fréquente du code dans le presse-papiers, destinée à réduire les manipulations demandées à l’utilisateur. Le passage vers un véritable portail de connexion fait donc partie du piège.

Pendant ce temps, l’infrastructure suit l’avancement de la session. Dans la séquence étudiée, Microsoft décrit une fonction checkStatus() qui interroge un point de terminaison /state toutes les trois à cinq secondes, pendant une fenêtre de quinze minutes. Ce suivi transmet un identifiant secret de session et reste en attente tant que la victime n’a pas terminé l’authentification. Il renseigne l’état du parcours côté plateforme ; il ne constitue pas, à lui seul, la preuve d’une autorisation réussie.

L’écran Microsoft de saisie du code avertit que l’application ou l’appareil concerné obtiendra l’accès au compte et qu’il ne faut pas saisir un code provenant d’une source non fiable. C’est le changement de sens crucial entre les deux pages : le leurre parle de consulter un document, tandis que le portail parle d’accorder un accès. Microsoft présente cette capture comme son écran de connexion par code appareil ; l’authenticité de la page de destination ne garantit pas la fiabilité de l’origine du code.

Si la victime n’a pas de session active, elle peut être invitée à saisir son mot de passe et à effectuer la MFA. Si elle est déjà connectée, la saisie du code et la confirmation peuvent suffire dans le parcours décrit. Lorsque l’autorisation aboutit, le client contrôlé par l’attaquant peut obtenir les jetons. Le secret n’a pas nécessairement été tapé dans une imitation de page de connexion : c’est l’autorisation donnée au mauvais client qui fait basculer l’accès.

Une livraison à plusieurs étapes pour compliquer l’analyse

Microsoft décrit des liens portés par des images, des pièces jointes et plusieurs redirections avant la page finale. Certaines pages imposent un faux CAPTCHA ou une vérification nécessitant une interaction humaine avant de montrer le contenu. Ces étapes cherchent à compliquer l’examen par des analyseurs d’URL et des environnements automatisés. Elles constituent des techniques d’évasion observées, sans garantir un passage à travers toutes les protections.

L’analyse rapporte l’utilisation de domaines légitimes compromis et de plateformes comme Vercel, Cloudflare Workers et AWS Lambda pour héberger la logique de redirection. L’objectif est de faire passer des éléments de l’attaque au milieu de trafic cloud habituel et de limiter l’efficacité d’un filtrage fondé uniquement sur la réputation du domaine. Cela n’autorise pas à qualifier de malveillant tout usage de ces plateformes.

Pour une campagne suivie en avril 2026, Microsoft rapporte des milliers de nœuds de suivi uniques et de courte durée, avec une logique serveur en Node.js. Le fournisseur associe cette infrastructure dynamique à des difficultés pour les détections par signature ou motif. Cloudflare confirme, dans son propre compte rendu, avoir observé des usages de Workers et supprimé des projets et domaines associés lors de l’opération coordonnée de septembre. Ces observations portent sur des périmètres distincts : Cloudflare ne valide pas ici le détail des nœuds suivis en avril par Microsoft.

Après les jetons : lire, sélectionner et prolonger l’accès

Selon Microsoft, l’accès obtenu peut servir à lire et extraire des courriels, mais aussi à envoyer de nouveaux messages aux collègues et contacts externes de la victime. La confiance attachée au compte compromis devient alors un moyen de poursuivre le phishing. L’analyse rapporte également des règles de boîte malveillantes utilisées pour faciliter l’exploitation de la messagerie et dissimuler des communications. Ces règles ne prolongent pas, par elles-mêmes, la validité d’un jeton OAuth.

Dans un incident rapporté, les attaquants ont sélectionné des profils financiers, de direction ou d’administration parmi les comptes compromis. Microsoft décrit une analyse assistée par IA de l’activité des boîtes et une reconnaissance par Microsoft Graph pour cartographier la structure interne et les permissions. Les recherches dans les courriels visaient notamment des instructions de virement, des factures en attente et des échanges de dirigeants. Ces observations ne démontrent pas que chaque compte autorisé subit toutes ces actions.

La temporalité varie également. Microsoft rapporte certains enregistrements de nouveaux appareils dans les dix minutes suivant la compromission, afin de produire un Primary Refresh Token, ou PRT, pour une persistance durable. Dans d’autres cas, les acteurs attendent plusieurs heures avant de créer des règles ou d’extraire des messages. L’enquête doit donc couvrir la suite de l’autorisation, sans supposer que l’absence d’action immédiatement visible clôt le scénario.

Après une suspicion : reconstruire la chronologie dans les journaux

Le premier objectif est de relier une demande par code appareil à l’activité ultérieure du compte. Dans les connexions Entra, les éléments à examiner comprennent le compte, l’heure, le résultat, le protocole Device code flow, l’application, la ressource, l’adresse IP, les informations d’appareil et les politiques d’accès conditionnel. La propriété Original transfer method peut indiquer qu’une connexion ou un renouvellement provient d’une session initialement créée par code appareil. Elle aide à comprendre cette origine, sans être à elle seule un identifiant unique de corrélation ni une preuve d’activité malveillante.

Une connexion réussie, même avec MFA, ne suffit pas à exclure l’attaque. Inversement, un flux par code appareil, une adresse IP ou une localisation inhabituelle ne prouvent pas isolément un vol de jeton. L’interprétation repose sur la concordance entre l’autorisation, l’application concernée, les usages attendus et les actions suivantes. Un clic documente une interaction ; il ne démontre pas à lui seul que l’utilisateur a terminé l’autorisation.

Les journaux d’audit et l’état des appareils permettent ensuite d’examiner un éventuel enregistrement nouveau. Côté Exchange, les opérations New-InboxRule, Set-InboxRule et MailItemsAccessed fournissent des pistes sur les règles et les accès aux messages. Les transferts et l’état des règles doivent également être examinés. Un appareil ou une règle nouvellement créé demande une vérification de son caractère autorisé ; un événement d’accès aux messages ne décrit pas, à lui seul, toute une exfiltration.

La reconnaissance Graph exige une précaution supplémentaire : vérifier que les journaux d’activité correspondants étaient collectés avant l’incident. Ils nécessitent Entra ID P1 ou P2 et une intégration vers un stockage ou un outil d’analyse ; Entra ne les conserve pas nativement par défaut. Une recherche vide peut donc refléter un manque de données. Activer cette collecte après l’attaque ne restitue pas les appels passés.

La fenêtre disponible doit être vérifiée avant de tirer des conclusions. Les journaux de connexion et d’audit Entra sont conservés par défaut sept jours avec Entra ID Free, et trente jours avec P1 ou P2. La chasse avancée Defender XDR porte sur au plus trente jours de données natives. Ces durées concernent des ensembles distincts ; elles ne garantissent pas que tous les événements utiles existent dans l’environnement Microsoft 365 de l’organisation.

Ce que les recherches Defender apportent, et ce qu’elles ne prouvent pas

La première requête publiée par Microsoft part d’alertes Defender for Office 365, relie l’URL au message et au destinataire, puis recherche un événement BrowserLaunchedToOpenUrl sur le poste associé. Ses jointures utilisent notamment les tables AlertInfo, AlertEvidence, EmailEvents, IdentityInfo et DeviceEvents. Elle aide à rapprocher un message signalé et un clic observé ; elle n’établit pas directement l’émission d’un jeton ni son utilisation par l’attaquant.

La seconde requête filtre EmailEvents pour repérer des messages dont ThreatTypes est renseigné et qui ont été remis dans la boîte de réception ou les courriers indésirables. Elle identifie donc une livraison associée à une menace détectée, pas nécessairement une ouverture ou une autorisation. Microsoft explique qu’une recherche utile peut devenir une règle de détection personnalisée. Les requêtes du billet restent des points d’entrée à compléter par l’examen des connexions et des actions après compromission.

La présence de données dépend des produits et de leur intégration. CloudAppEvents, par exemple, repose sur Defender for Cloud Apps et la connexion des activités Microsoft 365. Microsoft associe aussi Safe Links et Entra ID Protection à des alertes de forte confiance sur le phishing par code appareil. Leur présence effective et l’ensemble de leurs conditions de licence n’ont pas été vérifiés dans un environnement donné : disposer de Microsoft 365 ne garantit donc pas l’accès à toutes ces données et alertes.

Les rapports Threat Analytics cités par Microsoft nécessitent une licence pour au moins un produit Defender XDR. Le billet liste des profils sur la technique, l’outil et l’acteur, mais affiche Storm-2922 dans cette liste alors que le corps de l’analyse attribue EvilTokens à Storm-2992. Cette discordance demeure dans la source. Le profil lié n’ayant pas pu être vérifié publiquement dans les éléments fournis, l’hypothèse d’une coquille ne permet pas de trancher.

Les conseils Microsoft : contenir l’accès, puis réduire les occasions de phishing

En cas de compromission présumée, Microsoft recommande une désactivation temporaire du compte, la révocation des sessions et des jetons de renouvellement, puis l’examen des appareils, des méthodes MFA, des consentements d’applications, des transferts et des règles de boîte. Le billet mentionne la révocation des sessions de connexion et la possibilité de forcer une nouvelle authentification par accès conditionnel. Ces actions doivent être adaptées au compte et à l’incident, en tenant compte de leur impact sur l’activité.

La révocation ne doit pas être interprétée comme une coupure instantanée de tout accès. Dans les campagnes étudiées, Microsoft rapporte que des jetons d’accès déjà émis peuvent rester utilisables jusqu’à une heure après une révocation ordinaire des sessions. Cette fenêtre rapportée n’est pas un maximum universel : la durée résiduelle effective dépend du jeton, de la ressource et des mécanismes de révocation applicables. Microsoft recommande donc de désactiver temporairement le compte compromis. Si un appareil et son PRT sont impliqués, l’entreprise recommande aussi de désactiver l’appareil et de révoquer les jetons de renouvellement existants afin de traiter cette voie de persistance.

Pour réduire la surface exposée, Microsoft recommande de bloquer le flux par code appareil partout où il n’est pas nécessaire. La documentation conseille d’en inventorier les usages avec une politique en mode rapport seul avant le blocage. Certains équipements Teams peuvent nécessiter des exceptions ciblées sur leurs comptes de ressources. Microsoft indique également d’exclure la ressource Device Registration Service pour préserver les usages d’enregistrement concernés ; cette exception ne s’applique pas indistinctement à toutes les politiques. L’accès conditionnel nécessite une licence Entra ID P1, P2 ou un essai adapté.

La sensibilisation doit expliquer ce que l’écran Microsoft autorise réellement. Le nom de l’application attendue et l’origine du code comptent autant que l’apparence de la page. Microsoft recommande de se méfier des liens suspects dans les messages externes et de ne pas se connecter à des ressources proposées par des expéditeurs inconnus. L’exemple Adobe illustre précisément pourquoi une vérification d’identité présentée comme banale peut cacher une demande d’accès différente.

Sur la messagerie, Microsoft conseille les politiques antiphishing, Safe Links, un Advanced Phishing Threshold réglé à 2 ou 3 et Zero-hour auto purge, ou ZAP, pour traiter rétroactivement des messages à partir de nouvelles informations de menace. Le fournisseur recommande également des alertes sur les créations suspectes de règles de boîte, SmartScreen dans les navigateurs compatibles, ainsi que les protections réseau et Web. Ces couches visent à réduire les occasions d’attaque ; elles ne remplacent pas la vérification de l’autorisation et de ses suites.

Microsoft recommande enfin la MFA, des méthodes résistantes au phishing comme les clés FIDO ou les passkeys de Microsoft Authenticator, le blocage de l’authentification héritée et des politiques fondées sur le risque de connexion. Les politiques intégrant le risque Entra ID Protection exigent P2, contrairement au simple blocage du flux par code appareil disponible avec P1. Elles répondent à des conditions différentes et ne doivent pas être confondues. La MFA reste utile contre de nombreuses attaques, mais les éléments fournis ne démontrent pas qu’un changement de méthode MFA, isolément, empêcherait toute autorisation piégée par code appareil.

Les recommandations plus générales portent sur le moindre privilège, l’audit des comptes privilégiés et la centralisation des données d’identité. En environnement hybride, Microsoft préconise de conserver une frontière pour les comptes administratifs et fortement privilégiés plutôt que de tous les synchroniser. Pour appliquer ces conseils, l’organisation doit vérifier les produits, licences, collectes et exceptions réellement présents. Dans l’enquête comme dans la prévention, cette vérification détermine ce qu’elle peut observer et ce qu’elle peut effectivement bloquer.

Sources

• Microsoft Security Blog, Unmasking EvilTokens
• Huntress, Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
• Cloudflare Cloudforce One, Operation to disrupt EvilTokens
• Microsoft Learn, OAuth 2.0 device authorization grant
• Microsoft Learn, Conditional Access: Authentication flows
• Microsoft Learn, Microsoft Entra data retention
• Microsoft Learn, Respond to a compromised email account in Microsoft 365
• Microsoft Learn, Advanced hunting overview in Microsoft Defender XDR
• Microsoft Learn, CloudAppEvents table
• Microsoft Learn, Exchange audit record properties
• Microsoft Learn, Access Microsoft Graph activity logs
• Microsoft Learn, Plan Your Microsoft Entra Conditional Access Deployment
• Microsoft Learn, Access tokens in the Microsoft identity platform

Ouvre n’importe quel tuto Packer sur Windows et tu tomberas sur la même promesse : « une image parfaite en une commande, sans effort ». Tu copies le template, tu lances packer build, et tu déploies ta machine idéale.

Sauf que c’est faux. Enfin, pas tout à fait. La commande existe, le résultat est réel, mais entre les deux il y a une dizaine de pièges que personne ne te montre. Contrôleur disque invisible, balise obsolète qui fait tout planter, VM qui s’endort en plein build. J’ai tout traversé, en direct, sur ma machine. Cet article, c’est le tuto que j’aurais aimé lire avant de commencer.

L’objectif est simple : produire une golden image Windows 11 automatisée. Windows s’installe seul, le système passe en français, les VMware Tools et cinq applis se posent tout seuls, et à la fin tu récupères une image prête à cloner. Le tout sur VMware Workstation, en local, sans toucher la souris une seule fois une fois le build lancé.

Je te préviens tout de suite : ce n’est pas plug and play. Mais une fois les pièges désamorcés, ça tourne d’un bout à l’autre en 24 minutes. Et je te donne les vrais chiffres, y compris ceux qui font mal.

Packer, Chocolatey, Boxstarter : qui fait quoi

Avant de coder, il faut comprendre les trois briques, parce qu’elles n’ont rien à voir entre elles. On les empile, chacune a un rôle précis.

Packer, c’est l’orchestrateur du build. C’est lui qui crée la VM, monte l’ISO, la démarre, attend que Windows soit debout, se connecte, pousse les scripts, gère les reboots, puis exporte l’image. Il ne fait rien d’autre. Il fabrique le moule, une fois, et s’arrête.

Chocolatey, c’est le gestionnaire de paquets Windows. L’équivalent d’apt sur Debian ou de dnf sur Fedora, mais pour Windows. Une ligne, choco install firefox, et le soft est là, sans installeur à cliquer, sans « suivant, suivant, terminer ». C’est lui qui remplit le moule.

Boxstarter, c’est une surcouche de Chocolatey. Son intérêt unique : la résilience aux reboots. Il pose un autologon et reprend le script exactement là où il s’était arrêté après un redémarrage. Utile quand tu enchaînes des installs qui rebootent. On y reviendra, parce que dans un build Packer, il fait doublon, et c’est une nuance importante.

Packer contre Terraform : la confusion classique

Petite mise au point, parce que les deux sont des outils HashiCorp, écrits en HCL, et qu’on les confond tout le temps. Ce ne sont pas des concurrents. Ils font deux choses différentes, à deux moments différents.

Packer fabrique des images. Il produit un artefact figé, immuable : une image de VM, un template, une AMI sur AWS. Il construit, il exporte, il s’arrête. Il ne sait pas ce que devient l’image après, et il s’en moque.

Terraform déploie et gère l’infrastructure. Il est déclaratif, il tient un état (le fameux state), il crée, modifie et détruit des ressources vivantes : des VM, des réseaux, des ressources cloud. Il gère tout le cycle de vie.

En clair : Packer fabrique le moule, Terraform coule le béton dedans et gère les bâtiments. Le combo classique en prod, c’est Packer qui produit la golden image, puis Terraform qui déploie cinquante instances de cette image. L’un ne remplace pas l’autre, ils se passent le relais.

Pour cette démo, on reste sur Packer seul. On fabrique le moule.

I. Installer Packer sur l’hôte, pas dans la VM

Première confusion à évacuer : Packer s’installe sur la machine hôte, celle qui fait tourner VMware Workstation. Pas dans la VM. La VM n’existe même pas encore quand tu lances le build, c’est Packer qui la crée.

Sur mon poste, winget fait le job en trente secondes.

[CODE : install-packer.ps1]

powershell

winget install HashiCorp.Packer

Attention au piège le plus bête du monde : après l’install, le PATH n’est pas rechargé dans ta session en cours. Soit tu fermes et rouvres ton terminal, soit tu recharges à la volée.

[CODE : reload-path.ps1]

powershell

$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
packer version

Chez moi, Packer v1.15.4. Note bien la version, parce que le plugin qui va avec est devenu beaucoup plus strict que les anciens, et ça va nous jouer des tours.

II. L’ISO Windows 11 : LTSC ou pas, la nuance qui compte

Pour la source, on part d’une ISO d’évaluation, gratuite et sans clé, depuis l’Evaluation Center Microsoft. Attention, le paysage a changé. La Windows 10 Enterprise classique a été retirée depuis la fin de support d’octobre 2025. Sur Windows 11, tu as le choix entre la Enterprise LTSC 2024 (build 26100) et la version standard.

Petite parenthèse vécue : j’ai cru télécharger la LTSC, et une fois la VM montée, j’ai vu le Microsoft Store et Outlook dans le menu Démarrer. Or la LTSC n’a ni l’un ni l’autre. J’avais en fait la Enterprise Evaluation standard, pas la LTSC. Pour le pipeline ça ne change rien, choco et Packer s’en fichent, mais c’est le genre de détail à vérifier avant de croire qu’on a la bonne édition.

L’eval demande un formulaire, donc pas de téléchargement direct. Packer ne peut pas la récupérer seul, on pointe un fichier local. Et on calcule son empreinte pour la vérification d’intégrité.

[CODE : hash-iso.ps1]

powershell

Get-FileHash "C:\demo\ISO\win11ent.iso" -Algorithm SHA256

III. Le template Packer, et le plugin qui ne pardonne rien

Le coeur du build, c’est le fichier .pkr.hcl. Il déclare la source (la VM à créer) et le build (les étapes de provisioning). Je te donne la version finale, celle qui marche, après avoir mangé toutes les erreurs.

Premier piège, et il est de taille. Le plugin github.com/vmware/vmware en version 2.1.3 est beaucoup plus strict que les versions d’avant. Il ne devine plus rien. Deux paramètres que les anciens plugins déduisaient tout seuls sont désormais obligatoires : network_adapter_type et disk_adapter_type. Il y en a un troisième, tools_mode, mais celui-là ne devient obligatoire que si tu touches à la config d’upload des VMware Tools, ce qu’on évite ici en les installant par choco (j’y reviens en partie VI). Si tu copies un template d’un vieux tuto, il casse à la validation. Tu vas te manger des X is required en série. On met donc les deux paramètres requis d’entrée.

[CODE : windows11.pkr.hcl (extrait source)]

hcl

source "vmware-iso" "win11" {
  vm_name       = "win11-ltsc-demo"
  guest_os_type = "windows11-64"

  iso_url      = var.iso_path
  iso_checksum = var.iso_checksum

  cpus      = 4
  memory    = 8192
  disk_size = 40960

  disk_adapter_type    = "sata"
  cdrom_adapter_type   = "sata"
  network_adapter_type = "e1000e"

  vmx_data = {
    "firmware"                = "efi"
    "uefi.secureBoot.enabled" = "FALSE"
    "vtpm.present"            = "FALSE"
  }

  cd_files = ["./autounattend.xml"]
  cd_label = "PROVISION"

  boot_wait    = "3s"
  boot_command = ["<enter>"]

  communicator   = "winrm"
  winrm_username = "packer"
  winrm_password = "packer"
  winrm_timeout  = "2h"
}

Deux choix à expliquer, parce qu’ils m’ont coûté du temps.

disk_adapter_type = "sata". C’est le piège numéro un. Sans cette ligne, la VM démarre, l’install Windows se lance, et tu arrives sur l’écran de sélection du disque avec une liste vide. Aucun disque. Le disque existe, Packer l’a créé, mais il est branché sur le contrôleur par défaut du builder, du LSI Logic, dont l’ISO Windows 11 n’a pas le pilote natif. Windows ne le voit pas. En SATA (AHCI), il est reconnu out of the box, sans charger de driver.

network_adapter_type = "e1000e". Même logique. L’ISO Windows 11 n’embarque pas le driver VMXNET3. Si tu prends vmxnet3, la carte réseau n’est pas reconnue pendant l’install, et sans réseau, pas de WinRM. Le e1000e est reconnu nativement.

Une fois le template en place, on initialise le plugin.

[CODE : packer-init.ps1]

powershell

packer init windows11.pkr.hcl

IV. L’autounattend, et la balise qui tue tout le fichier

L’autounattend.xml, c’est le fichier de réponses qui rend l’install de Windows silencieuse. Il partitionne le disque, crée le compte, contourne les vérifications matérielles de Windows 11 et active WinRM. Packer le monte dans un petit CD que Windows détecte tout seul.

Le contournement TPM et Secure Boot se fait en dur, via des clés de registre LabConfig écrites pendant la phase WinPE. C’est ce qui évite d’avoir à configurer un vTPM chiffré dans VMware, une vraie galère.

[CODE : autounattend.xml (extrait bypass)]

xml

<RunSynchronous>
  <RunSynchronousCommand wcm:action="add">
    <Order>1</Order>
    <Path>reg add "HKLM\System\Setup\LabConfig" /v BypassTPMCheck /t REG_DWORD /d 1 /f</Path>
  </RunSynchronousCommand>
  <!-- idem pour BypassSecureBootCheck, BypassRAMCheck, BypassCPUCheck, BypassStorageCheck -->
</RunSynchronous>

Et voilà le piège numéro deux, un des plus vicieux. Sur mon premier build correct, l’install s’est déroulée, puis au premier reboot, écran bleu d’erreur : « The computer restarted unexpectedly ». Plantage en phase specialize.

La cause était planquée dans C:\Windows\Panther\setuperr.log, qu’on lit avec un Shift+F10 dans la VM. Une ligne : The provided unattend file is not valid sur le composant CEIPEnabled. Cette balise a été supprimée de Windows 11 24H2. Elle n’existe plus. Et le setup, au lieu de l’ignorer, rejette tout le fichier autounattend à cause de cette seule ligne obsolète.

Le truc à retenir : une seule balise obsolète invalide l’autounattend entier. Si ton install plante en specialize, lis setuperr.log, il te donne le nom exact du composant fautif. On retire la ligne, et ça repart.

V. Valider puis lancer le build

Avant de lancer un build qui va tourner vingt minutes, on valide. packer validate attrape les erreurs de syntaxe et les paramètres manquants en deux secondes, ça évite de découvrir un X is required après dix minutes d’install Windows.

[CODE : packer-validate.ps1]

powershell

packer validate .\windows11.pkr.hcl

Tu veux lire The configuration is valid.. Si le plugin râle sur un champ obligatoire, tu corriges et tu revalides jusqu’à ce que ce soit propre.

Ensuite seulement, le build.

[CODE : packer-build.ps1]

powershell

packer build .\windows11.pkr.hcl

À partir de là, une fenêtre VMware Workstation s’ouvre, la VM boote sur l’ISO, et tout s’enchaîne sans que tu touches à rien. Surveille juste les premières secondes, le prompt « Press any key to boot from CD » où Packer envoie le <enter>. Si la VM le rate et part dans un shell EFI, augmente boot_wait et relance. C’est le réglage le plus capricieux du pipeline.

VI. Le DHCP absent, le décrochage WinRM et l’APIPA

Une fois Windows installé, Packer attend WinRM pour se connecter. Sur un de mes runs, il est resté bloqué sur Waiting for WinRM to become available sans fin, sans message d’erreur. Le genre de blocage silencieux qui te fait perdre une heure.

WinRM tournait pourtant dans la VM, le port 5985 répondait en local. Mais depuis l’hôte, rien. La cause : la VM avait une adresse en 169.254.x.x. Du APIPA. Autrement dit, elle n’avait pas reçu de bail DHCP, parce que le service DHCP de VMware était désactivé sur mon poste. Sans IP routable, Packer ne peut pas la joindre.

La réactivation du service DHCP côté hôte règle le problème.

[CODE : fix-dhcp.ps1]

powershell

Start-Service VMnetDHCP
Set-Service VMnetDHCP -StartupType Automatic

Note bien ce piège : un Waiting for WinRM qui ne finit jamais, ce n’est presque jamais WinRM. C’est le réseau. Vérifie l’IP de la VM en premier. Et méfie-toi du ping : le pare-feu Windows bloque l’ICMP par défaut, donc un ping qui échoue ne prouve rien. Le vrai test, c’est le port, avec Test-NetConnection -Port 5985.

VII. Les provisioners : Tools, langue, applis, et les reboots

On arrive au coeur du build. Le bloc build enchaîne les scripts PowerShell, avec des reboots entre les étapes sensibles. Et non, ces reboots ne sont pas gérés par Boxstarter, mais par le provisioner natif windows-restart de Packer. J’y reviens juste après, c’est important.

[CODE : windows11.pkr.hcl (extrait build)]

hcl

build {
  sources = ["source.vmware-iso.win11"]

  provisioner "powershell" {
    scripts          = ["./scripts/install-vmware-tools.ps1"]
    valid_exit_codes = [0, 3010]
  }
  provisioner "windows-restart" {}

  provisioner "powershell" {
    scripts = ["./scripts/setup-language-french.ps1"]
  }
  provisioner "windows-restart" {}

  provisioner "powershell" {
    scripts = ["./scripts/install-choco-packages.ps1"]
  }
}

Les VMware Tools : oublie l’upload WinRM, passe par choco

Première approche, j’ai voulu faire uploader l’ISO des Tools par Packer, via l’option tools_upload. Mauvaise idée. L’upload de fichiers par WinRM est lent et fragile. Sur une ISO de 130 Mo, il a bloqué complètement, rien n’atterrissait dans la VM, dix minutes pour zéro octet écrit.

La parade est plus simple et plus reproductible : installer les Tools par Chocolatey. Le package existe, il télécharge depuis le dépôt Broadcom, pas de gros transfert WinRM, pas de dépendance au chemin de ton install Workstation.

[CODE : install-vmware-tools.ps1 (extrait)]

powershell

choco install vmware-tools -y --no-progress

Le truc à retenir : pour tout artefact un peu lourd, le gestionnaire de paquets bat l’upload WinRM. C’est plus robuste, point.

Le code 3010 : un succès pris pour une erreur

Piège suivant, et c’est un classique Windows. Les VMware Tools s’installent nickel, mais choco retourne le code de sortie 3010. Ce code veut dire « succès, reboot nécessaire ». Or Packer considère par défaut que seul le code 0 est acceptable. Il prend donc ce 3010 pour un échec et coupe le build.

D’où le valid_exit_codes = [0, 3010] sur ce provisioner. On dit à Packer que 3010 est un succès valide. Ce code sort tout le temps avec les MSI et les features Windows, à connaître par coeur.

La bascule en français, et la leçon la plus chère

Mon idée de départ : installer trois packs de langue, allemand, espagnol et français, puis passer le système en français. Bien pour le spectacle. Sauf que le spectacle m’a coûté des heures.

Install-Language tire chaque pack depuis Windows Update, plusieurs centaines de Mo, plus les Features on Demand (reconnaissance vocale, écriture manuscrite, OCR). Et ces FODs déclenchent en cascade une maintenance des composants Windows via TrustedInstaller qui ne finit jamais dans un délai raisonnable. Sur une image eval fraîche, j’ai vu TrustedInstaller à plus de 13000 secondes de CPU, bloqué sur le deuxième pack après 30 minutes.

La correction, et c’est aussi la bonne pratique pour une vraie golden image : une seule langue, le français, et sans les FODs lourds.

[CODE : setup-language-french.ps1 (extrait)]

powershell

# -ExcludeFeatures evite les FODs (Speech, OCR, Handwriting)
# qui saturent TrustedInstaller pendant des heures.
Install-Language fr-FR -CopyToSettings -ExcludeFeatures

Set-WinUserLanguageList -LanguageList fr-FR -Force
Set-WinUILanguageOverride -Language fr-FR
Set-WinSystemLocale fr-FR
Set-SystemPreferredUILanguage fr-FR
Copy-UserInternationalSettingsToSystem -WelcomeScreen $true -NewUser $true

Le truc à retenir : ajouter des langues avec tous les FODs, c’est le meilleur moyen de rendre ton build ininstallable. Une langue, -ExcludeFeatures, sauf besoin explicite d’OCR ou de reconnaissance vocale.

Le piège dans le piège : la VM qui s’endort

Et le plus vicieux pour la fin, celui que personne ne documente. Même avec -ExcludeFeatures, mon build a décroché à 43 minutes, en plein Install-Language, avec une erreur réseau brute : wsarecv: the connected host has failed to respond. WinRM coupé net.

J’ai cru à un problème de pile réseau. Faux. La vraie cause : la VM se mettait en veille. Pendant qu’Install-Language mouline en silence, sans activité clavier ni souris, Windows applique son plan d’alimentation et met la machine en veille. Le réseau tombe, Packer perd WinRM, le build meurt.

La parade, à mettre en tout premier dans le pipeline : désactiver la veille via powercfg.

[CODE : disable-sleep.ps1]

powershell

powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0
powercfg /change monitor-timeout-ac 0
powercfg /change hibernate-timeout-ac 0
powercfg /setactive SCHEME_MIN

C’est une ligne à mettre dans n’importe quel pipeline de golden image Windows. Un provisioner long sur une VM qui s’endort, ça décroche WinRM sans jamais te dire pourquoi. Note-le bien.

Les applis, et le checksum qui casse tout seul

Dernier provisioner, les cinq applis via choco. Au départ, ma liste incluait Google Chrome. Erreur. Le package Chrome sur Chocolatey embarque un checksum figé du MSI, mais Google écrase le même fichier à chaque nouvelle version. Résultat, dès que le package est en retard d’une release, le checksum ne correspond plus et l’install échoue : hashes do not match.

Pour un build reproductible, un paquet qui casse au gré des sorties de Google, c’est exactement ce qu’on ne veut pas. Je l’ai remplacé par Firefox, qui n’a pas ce souci. Et j’ai rendu le script tolérant : un paquet qui échoue est loggé, mais ne fait plus planter tout le build.

[CODE : install-choco-packages.ps1 (extrait)]

powershell

$packages = @("7zip","notepadplusplus","firefox","git","vscode")
$failed = @()
foreach ($pkg in $packages) {
    choco install $pkg -y --no-progress
    if ($LASTEXITCODE -ne 0 -and $LASTEXITCODE -ne 3010) {
        Write-Warning "Echec de $pkg (code $LASTEXITCODE)"
        $failed += $pkg
    }
}

VIII. Et Boxstarter dans tout ça ?

J’ai gardé Boxstarter pour la fin, parce que c’est la nuance la plus honnête de cet article. Mon idée initiale était d’utiliser Boxstarter pour gérer les reboots entre les étapes. Bonne intuition sur le papier, mais mauvaise dans un contexte Packer.

Boxstarter gère les reboots via un autologon et une reprise du script en session interactive. Packer, lui, pilote la VM en WinRM, session non interactive. Quand Boxstarter reboote, la connexion WinRM de Packer tombe, et Packer ne voit pas la reprise Boxstarter qui se joue dans la session autologon. Les deux ne se coordonnent pas.

En clair : dans un build Packer, l’outil pour les reboots, c’est windows-restart. Pas Boxstarter. Boxstarter brille quand tu provisionnes une machine en direct, hors Packer, par exemple un poste physique où tu veux enchaîner des installs qui rebootent et reprendre toutes seules.

C’est ça, la vraie leçon : deux outils qui semblent faire la même chose, mais chacun a son terrain. Je détaillerai le vrai cas d’usage de Boxstarter, packs de langue et reboots en cascade sur une machine directe, dans un article séparé. Il mérite sa propre démo.

Ce que je retiens

Le build final tourne d’un bout à l’autre sans intervention. Windows installé, VMware Tools, système en français, cinq applis, arrêt propre, image compactée. Voilà les chiffres, sans enjoliver.

Et la liste des pièges, parce que c’est ça le vrai contenu de ce tuto, pas le template :

• Le contrôleur disque en SATA, sinon Windows ne voit aucun disque.
• La balise CEIPEnabled obsolète en 24H2, qui invalide tout l’autounattend.
• Le DHCP VMware désactivé, qui envoie la VM en APIPA et bloque WinRM sans erreur claire.
• Le code 3010 à whitelister, un succès pris pour un échec.
• L’upload WinRM d’ISO qui bloque, à remplacer par choco.
• Les FODs de langue qui saturent TrustedInstaller pendant des heures.
• La veille de la VM qui décroche WinRM en plein provisioner long.
• Le checksum Chrome volatil, à remplacer par Firefox.
• oscdimg de l’ADK à mettre dans le PATH de façon permanente, sinon chaque console casse le build sur la création du CD.

Alors, est-ce que Packer vaut le coup pour une golden image Windows ? Oui, sans hésiter. Une fois le template stabilisé, tu reconstruis ton image parfaite en une commande, à l’identique, autant de fois que tu veux. C’est reproductible, c’est versionnable, c’est du vrai infrastructure as code.

Mais le template propre que tu copies en trois minutes, il cache une journée de pièges que personne ne documente. La reproductibilité se paie une fois, à la mise au point. Après, elle est gratuite. Comme souvent, la vraie valeur n’est pas dans la commande magique, elle est dans tout ce qu’on ne te montre pas.

A bientôt Louis 🐇 🤜 🤛 🐰

Tu vas tomber, en cherchant « MSIX App Attach », sur des dizaines de tutos qui te font croire que c’est trois clics dans un assistant. Tu lances MSIX Packaging Tool, tu cliques Next cinq fois, et hop, ton .msix est prêt.

Sauf que c’est faux. Enfin, à moitié.

L’assistant existe vraiment, et il fait bien le boulot. Le souci, c’est tout ce qu’il y a autour : le certificat de signature qui doit correspondre au pixel près au nom de l’éditeur, le 0x8bad0001 que crache msixmgr quand la chaîne de confiance n’est pas en place, le runtime Windows App SDK qui manque au moment de tester le package, et la source Microsoft Store de winget qui te claque un 0x8a15005e à la figure sur une VM Azure. Aucun de ces pièges n’est documenté côté à côté en français.

Je viens de me les manger tous, dans l’ordre, sur une VM de packaging Azure. Alors je te déroule le process complet : créer un package MSIX de A à Z avec Notepad++ comme cobaye, jusqu’au CIM prêt à attacher. Avec les pièges annoncés avant qu’ils ne tombent.

Une précision tout de suite : cet article s’arrête au package. L’attachement réel sur un host pool AVD (le storage Azure Files, les permissions SMB, la registration App Attach) mérite son propre guide, je le traiterai séparément. Ici, on fabrique l’artefact. C’est déjà bien assez pour un article.

Pourquoi Notepad++ et pas 7-Zip ou un truc plus lourd

Petit aparté de méthode, parce que le choix de l’app cobaye n’est pas anodin.

App Attach a une raison d’être précise : livrer une application sans la coller dans le golden image. Typiquement une app volumineuse, licenciée par département, ou mise à jour souvent. Sur le papier, n’importe quelle app fait l’affaire pour un lab. En pratique, certaines sont de mauvais cobayes.

7-Zip, par exemple, c’est tentant parce que c’est léger. Mais c’est un mauvais exemple pédagogique : gratuit, 5 Mo, utile à tout le monde. Personne ne mettrait jamais ça en App Attach dans la vraie vie, tu l’installes direct dans l’image en trente secondes.

Notepad++ est un bien meilleur choix, pour trois raisons :

• Il se capture proprement. Installeur MSI simple, pas de services Windows, pas de drivers exotiques.
• Il représente le cas réel « outil bureautique livré par groupe d’utilisateurs ».
• Depuis la v8.8.8, Notepad++ fournit un MSI x64 officiel pour le déploiement entreprise. Et un MSI se capture toujours plus proprement qu’un .exe à assistant graphique.

Au moment où j’écris, la version stable est la 8.9.6.4. C’est celle qu’on va packager.

Le matériel : ce qu’il te faut avant de commencer

On part d’une VM de packaging propre. Le mot « propre » est important : pas de Notepad++ déjà installé dessus, idéalement un snapshot pris avant de commencer pour pouvoir revenir en arrière. MSIX Packaging Tool capture les changements du système pendant l’installation. Si l’app est déjà là, la capture est faussée.

Voici les prérequis, et où je me suis fait avoir sur chacun :

On y va dans l’ordre.

I. Installer MSIX Packaging Tool (et le piège msstore)

L’outil s’installe via winget. Première commande, premier mur :

[CODE : install_msixtool.ps1]

powershell

winget install Microsoft.MSIXPackagingTool

winget install Microsoft.MSIXPackagingTool

Et là, sur ma VM Azure, je me prends ça :

Failed when searching source: msstore
0x8a15005e : The server certificate did not match any of the expected values.

Failed when searching source: msstore
0x8a15005e : The server certificate did not match any of the expected values.

Le souci, c’est que winget interroge deux sources : winget et msstore. Sur une VM Azure, l’accès au Microsoft Store est souvent restreint ou cassé côté certificat, et c’est msstore qui fait planter la commande. Or le package est dispo sur la source winget, qui elle fonctionne.

La parade, c’est de forcer la source :

[CODE : install_msixtool_fix.ps1]

powershell

winget install Microsoft.MSIXPackagingTool --source winget

winget install Microsoft.MSIXPackagingTool --source winget

Et là ça passe, propre.

Note le message en fin d’install : l’outil te prévient que le MSIX Packaging Tool Driver doit être activé séparément dans les fonctionnalités Windows. Bonne nouvelle, l’outil sait l’activer tout seul à son premier lancement. Mauvaise nouvelle, il peut s’y reprendre à deux fois. On verra ça à l’étape III, pas la peine de s’en occuper maintenant.

II. Le certificat de signature : là où tout le monde se plante

Un package MSIX doit être signé. En production tu utilises ta PKI interne ou un certificat public. En lab, un certificat auto-signé suffit, à condition de respecter une règle d’or que je te donne tout de suite, parce que c’est elle qui m’a coûté le plus de temps.

Le subject du certificat doit correspondre exactement au Publisher name du package. Au caractère près. Si ton cert dit CN=Tazmen Lab, O=Tazmen, C=World, ton Publisher dans MSIX Packaging Tool doit dire exactement la même chose. La moindre virgule de travers, et la signature échoue.

On génère le certificat en PowerShell, en admin :

[CODE : new_cert.ps1]

powershell

# Crée le dossier de travail
New-Item -ItemType Directory -Path "C:\Tools" -Force

# Génère le certificat auto-signé
$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=Tazmen Lab, O=Tazmen, C=World" `
  -KeyUsage DigitalSignature `
  -FriendlyName "MSIX Lab Signing" `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

# Exporte le .pfx (pour signer) et le .cer (pour la confiance)
$pwd = ConvertTo-SecureString -String "TonMotDePasse123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.pfx" -Password $pwd
Export-Certificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.cer"

# Crée le dossier de travail
New-Item -ItemType Directory -Path "C:\Tools" -Force

# Génère le certificat auto-signé
$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=Tazmen Lab, O=Tazmen, C=World" `
  -KeyUsage DigitalSignature `
  -FriendlyName "MSIX Lab Signing" `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

# Exporte le .pfx (pour signer) et le .cer (pour la confiance)
$pwd = ConvertTo-SecureString -String "TonMotDePasse123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.pfx" -Password $pwd
Export-Certificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.cer"

Le .pfx contient la clé privée, il sert à signer. Le .cer ne contient que la partie publique, il sert à faire confiance au package sur les machines cibles.

Je te préviens sur deux pièges vécus :

Piège 1 : la variable $cert meurt avec la session. Si tu fermes PowerShell entre la création du cert et l’export, $cert est vide et l’export plante avec Cannot bind argument to parameter 'Cert' because it is null. Garde la même fenêtre PowerShell ouverte du début à la fin, ou regénère le cert dans la nouvelle session.

Piège 2 : le dossier de destination doit exister. Si C:\Tools n’existe pas, l’export te sort un Le chemin d'accès spécifié est introuvable. (0x80070003). D’où le New-Item en première ligne. Ça paraît évident écrit comme ça, mais sur le moment on cherche midi à quatorze heures.

III. La capture MSIX, écran par écran

Lance MSIX Packaging Tool depuis le menu Démarrer. Choisis Create package, puis Create your package on this computer.

Prepare computer

L’outil vérifie l’environnement. C’est ici qu’il installe le MSIX Packaging Tool Driver si besoin. Le « Checking… » peut traîner une minute ou deux, laisse-le faire.

Deux lignes à regarder sur cet écran. Windows Update is active : l’outil va le désactiver temporairement pendant la capture, c’est normal et voulu. Pending reboot : si ta VM a un redémarrage en attente, l’outil peut le réclamer. Le cas échéant, redémarre et relance.

Select installer

Trois champs à remplir :

• Installer : pointe vers ton MSI Notepad++. Tu le télécharges d’abord avec Invoke-WebRequest depuis la release GitHub officielle.
• Installer arguments : mets /quiet /norestart pour une install silencieuse.
• Signing preference : choisis Sign with a certificate (.pfx) et sélectionne ton MSIXLabCert.pfx avec son mot de passe.

[CODE : download_npp.ps1]

powershell

$url = "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.6.4/npp.8.9.6.4.Installer.x64.msi"
Invoke-WebRequest -Uri $url -OutFile "C:\Temp\npp8964.msi"

$url = "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.6.4/npp.8.9.6.4.Installer.x64.msi"
Invoke-WebRequest -Uri $url -OutFile "C:\Temp\npp8964.msi"

Package information

C’est l’écran sensible. Souviens-toi de la règle d’or : le Publisher name doit matcher le subject du certificat.

Quelques remarques sur les champs :

• Package name : pas de caractères spéciaux. Notepad++(x64) est refusé (les + et les parenthèses ne passent pas). Mets NotepadPlusPlus.
• Package display name : là tu peux mettre Notepad++ (x64), c’est juste l’affichage.
• Publisher name : exactement le subject du cert. L’outil affiche d’ailleurs « Subject of the certificate provided » à côté, pour te rappeler la contrainte.
• Version : attention, l’outil pré-remplit souvent une version tronquée du genre 8.9.6.0. La vraie version Notepad++ est 8.9.6.4. Corrige le dernier champ. Petit aveu : je ne l’ai pas fait sur le coup, mon package est sorti en 8.9.6.0. Ce n’est pas bloquant pour un lab, mais en prod tu veux que la version du package colle à la version réelle de l’app.

Accelerator

Cet écran sert aux templates de conversion pré-configurés. Tu n’en as pas besoin pour Notepad++. Next, sans rien renseigner.

Installation

L’installeur MSI tourne en arrière-plan, en mode capture. Tu ne verras pas forcément l’assistant graphique de Notepad++, c’est normal, le /quiet fait son office. L’écran te propose un Restart machine : ne clique pas dessus, Notepad++ n’a pas besoin de redémarrage. Next.

First launch tasks

L’outil a détecté notepad++.exe automatiquement, avec le bon chemin et l’icône. Clique sur Run pour lancer Notepad++. C’est l’étape de validation : l’app doit s’ouvrir normalement. Vérifie qu’elle démarre, puis ferme-la.

Une popup « Are you done? » apparaît. Tu as lancé l’app, c’est tout ce qu’il fallait capturer. Clique Yes, move on.

Package report

No services were detected : parfait pour Notepad++. Aucun service Windows à embarquer, le package reste propre. C’est exactement pour ça que Notepad++ est un bon cobaye. Next.

Create package

Dernière ligne droite. Change le Save location pour quelque chose de propre, par exemple C:\Temp\, plutôt que le Desktop par défaut. Puis Create.

Et voilà :

Package successfully created
C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix

Package successfully created
C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix

Le .msix signé est sur le disque. Première moitié du boulot faite.

IV. Du MSIX au CIM avec msixmgr (et le fameux 0x8bad0001)

Pour App Attach, le .msix ne suffit pas. Il faut le « dépaqueter » dans une image disque que les session hosts monteront dynamiquement. Deux formats existent : VHDX et CIM. Microsoft recommande CIM : montage plus rapide, moins de CPU et de RAM consommés, surtout sur Windows 11. On part là-dessus.

L’outil pour ça, c’est msixmgr, qu’on télécharge sur le lien court Microsoft :

[CODE : get_msixmgr.ps1]

powershell

Invoke-WebRequest -Uri "https://aka.ms/msixmgr" -OutFile "C:\Tools\msixmgr.zip"
Expand-Archive "C:\Tools\msixmgr.zip" -DestinationPath "C:\Tools\msixmgr" -Force

Invoke-WebRequest -Uri "https://aka.ms/msixmgr" -OutFile "C:\Tools\msixmgr.zip"
Expand-Archive "C:\Tools\msixmgr.zip" -DestinationPath "C:\Tools\msixmgr" -Force

Puis on génère le CIM. Le dossier de destination doit exister, et il faut un sous-dossier dédié parce qu’un CIM est composé de plusieurs fichiers, pas d’un seul :

[CODE : create_cim.ps1]

powershell

New-Item -ItemType Directory -Path "C:\Temp\CIM\NotepadPlusPlus" -Force

C:\Tools\msixmgr\x64\msixmgr.exe `
  -Unpack `
  -packagePath "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix" `
  -destination "C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim" `
  -applyACLs `
  -create `
  -fileType CIM `
  -rootDirectory Apps

New-Item -ItemType Directory -Path "C:\Temp\CIM\NotepadPlusPlus" -Force

C:\Tools\msixmgr\x64\msixmgr.exe `
  -Unpack `
  -packagePath "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix" `
  -destination "C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim" `
  -applyACLs `
  -create `
  -fileType CIM `
  -rootDirectory Apps

Et c’est là que j’ai buté un bon moment. Premier essai :

Successfully created the CIM file: ...notepadplusplus.cim
[WARNING] ... failed to get unpacked. Please try again:
Failed with HRESULT 0x8bad0001 when trying to unpack ...

Successfully created the CIM file: ...notepadplusplus.cim
[WARNING] ... failed to get unpacked. Please try again:
Failed with HRESULT 0x8bad0001 when trying to unpack ...

Le truc vicieux, c’est que le CIM est créé mais vide. Le message « Successfully created » te fait croire que c’est bon, alors que le contenu du package n’a pas été extrait. Si tu ne lis pas le warning juste en dessous, tu pars avec une coquille vide.

Le 0x8bad0001 veut dire que msixmgr ne fait pas confiance au certificat qui a signé le package. Logique : c’est un cert auto-signé, Windows ne le connaît pas. Il faut l’installer dans les bons magasins de certificats de la machine locale.

Première tentative, le magasin Trusted People :

[CODE : trust_cert_people.ps1]

powershell

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

J’ai relancé msixmgr. Toujours 0x8bad0001. Le hic, c’est qu’un certificat auto-signé est sa propre autorité racine : pour que la chaîne de confiance soit complète, il doit aussi être dans le magasin Trusted Root Certification Authorities.

[CODE : trust_cert_root.ps1]

powershell

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\Root"

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\Root"

Windows t’affiche un avertissement de sécurité à l’import dans Root, confirme avec Oui. C’est normal, tu déclares faire confiance à une autorité que tu viens de créer toi-même.

Pour mettre toutes les chances de ton côté, active aussi le mode développeur qui lève les restrictions de signature MSIX en local :

[CODE : enable_devmode.ps1]

powershell

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "AllowDevelopmentWithoutDevLicense" -Value 1
Set-ItemProperty -Path $regPath -Name "AllowAllTrustedApps" -Value 1

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "AllowDevelopmentWithoutDevLicense" -Value 1
Set-ItemProperty -Path $regPath -Name "AllowAllTrustedApps" -Value 1

Je nettoie le CIM raté, je le regénère, et cette fois :

[Warning] The app ... depends on the following packages to run correctly:
Microsoft.WindowsAppRuntime.1.4
Successfully created the CIM file: C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim

[Warning] The app ... depends on the following packages to run correctly:
Microsoft.WindowsAppRuntime.1.4
Successfully created the CIM file: C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim

Plus de 0x8bad0001. Le CIM est rempli pour de bon. Le nouveau warning sur Microsoft.WindowsAppRuntime.1.4 est juste informatif, on va le traiter à l’étape suivante.

En clair, pour qu’un CIM se génère vraiment : le cert doit être dans TrustedPeople ET Root sur la machine de packaging. Les deux. Note-le bien.

V. Tester le package en local (sans host pool)

Pas besoin d’un host pool AVD pour valider que ton package fonctionne. Tu peux l’installer directement sur la VM de packaging avec Add-AppxPackage. C’est même recommandé avant de partir sur le déploiement.

[CODE : install_local.ps1]

powershell

Add-AppxPackage -Path "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix"

Add-AppxPackage -Path "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix"

Et là, dernier piège de la série :

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3
... this package depends on a framework that could not be found.
Provide the framework "Microsoft.WindowsAppRuntime.1.4" ...

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3
... this package depends on a framework that could not be found.
Provide the framework "Microsoft.WindowsAppRuntime.1.4" ...

C’est exactement le warning qu’on avait eu en générant le CIM. Notepad++ packagé en MSIX a besoin du Windows App Runtime 1.4, qui n’est pas présent sur la VM. Il faut l’installer à part.

Le réflexe Invoke-WebRequest sur aka.ms m’a donné un fichier corrompu (« The file or directory is corrupted and unreadable »), et le lien GitHub direct s’est fait couper par le réseau de la VM. Ce qui a marché du premier coup, c’est encore winget :

[CODE : install_runtime.ps1]

powershell

winget install Microsoft.WindowsAppRuntime.1.4 --source winget

winget install Microsoft.WindowsAppRuntime.1.4 --source winget

60,6 Mo téléchargés, installé. Je relance l’install du package, et cette fois Notepad++ apparaît dans le menu Démarrer et se lance comme une app native.

Pour le désinstaller après ton test :

[CODE : uninstall_local.ps1]

powershell

Get-AppxPackage -Name "NotepadPlusPlus" | Remove-AppxPackage

Get-AppxPackage -Name "NotepadPlusPlus" | Remove-AppxPackage

À retenir pour la suite : sur tes session hosts AVD, ce runtime devra aussi être présent, soit dans le golden image, soit poussé par Intune ou GPO avant l’attachement. Une dépendance manquante côté host, et ton app refusera de démarrer même parfaitement packagée.

Ce que je retiens

Le packaging MSIX en lui-même n’est pas compliqué. L’assistant fait le job. Ce qui coince, c’est la chaîne de confiance et les dépendances, et aucun de ces points n’est mis en avant dans les tutos « trois clics ».

Si tu ne devais retenir que quatre choses :

1. Force --source winget sur les VMs Azure, la source msstore est cassée.
2. Le Publisher name = le subject du cert, au caractère près, sinon la signature saute.
3. Le cert auto-signé va dans TrustedPeople ET Root, sinon msixmgr sort un 0x8bad0001 et te génère un CIM vide en te faisant croire que tout va bien.
4. Le Windows App Runtime est une dépendance à installer séparément, sur la VM de test comme sur les session hosts.

À ce stade tu as un .msix signé, testé et validé, et un CIM prêt à être attaché. C’est tout ce dont tu as besoin pour la suite.

Et la suite, justement, c’est l’attachement réel : monter le CIM sur un Azure Files, gérer les permissions SMB quand tes session hosts sont hors domaine AD classique, et faire la registration App Attach côté host pool. Ça, ça mérite son propre guide, parce que c’est un autre niveau de pièges. Je le détaillerai dans un article séparé.

A bientôt Louis 🐇 🤜 🤛 🐰

Soyons clairs dès le départ : je n’utilise pas ElevenLabs au quotidien. La qualité est au sommet du marché, le clonage de voix est bluffant, et le multilingue tient parfaitement le français. Difficile de faire mieux côté rendu. Mais pour mon usage, l’abonnement est tout simplement trop cher au regard de ce que j’en ferais réellement.

Le souci, c’est qu’il m’arrive ponctuellement d’en avoir besoin. Une voix off propre pour une vidéo, un test de clonage, une narration pour un article. Et là, deux choses bloquent. La première, c’est le modèle économique. ElevenLabs fonctionne par abonnement avec un plafond de crédits, et le clonage de voix professionnel, celui qui donne le meilleur résultat, démarre à 22 dollars par mois sur le plan Creator. Le plan gratuit, lui, interdit tout usage commercial et impose une mention ElevenLabs dans tes productions, ce qui le rend inutilisable pour de la monétisation YouTube. Payer un abonnement mensuel pour un besoin occasionnel, ça n’a aucun sens.

La deuxième, c’est la confidentialité. Pour cloner ma propre voix, je dois envoyer un échantillon de ma voix sur les serveurs d’une société américaine. Or ta voix, c’est une donnée biométrique. C’est ce qu’il y a de plus personnel, au même titre qu’une empreinte digitale.

Alors j’ai fait ce que je fais à chaque fois : j’ai décidé de rapatrier la capacité sur ma propre machine. L’objectif est simple. Avoir à disposition, à tout moment, une synthèse vocale française avec clonage de voix de qualité, sans abonnement, sans plafond, et sans que ma voix ne quitte mon réseau local. Je te préviens tout de suite : sur une carte Blackwell comme la RTX 5070 Ti, l’installation par défaut plante. Et le contournement n’est documenté nulle part en français. Voici donc le parcours complet, pièges compris.

I. La quête de la souveraineté vocale

Pourquoi se compliquer la vie quand un service à 22 dollars par mois fait le travail ? La réponse tient en deux mots : maîtrise et confidentialité. En produisant mes voix sur ma propre station, je ne dépends plus d’un quota de crédits, d’une connexion internet ou d’une politique de conservation que je ne contrôle pas. Et mon échantillon vocal reste chez moi, sur mon disque.

Le moteur de tout ça, c’est XTTS, le modèle de synthèse vocale de Coqui. Il fait du clonage de voix zero-shot multilingue, français inclus. Tu lui donnes 10 à 30 secondes d’un échantillon, il génère ensuite n’importe quel texte avec cette voix. Pour le piloter, j’utilise AllTalk, un serveur qui enrobe XTTS avec une API compatible OpenAI, une interface web, et la gestion de plusieurs moteurs. C’est le projet d’erew123 sur GitHub.

Ma configuration repose sur le matériel de ma Tazmen Station : un processeur AMD Ryzen 9 9900X épaulé par une carte NVIDIA GeForce RTX 5070 Ti avec 16 Go de VRAM. Bonne nouvelle, XTTS en inférence ne mobilise qu’environ 4 Go de VRAM. Tu as donc largement la place de le faire cohabiter avec un modèle de langage ou de la génération d’images sur la même carte.

Le hic, c’est que la 5070 Ti est une carte Blackwell. Et c’est exactement là que l’aventure commence.

II. Le piège Blackwell

C’est le point qui fait abandonner la moitié des gens, alors autant l’attaquer en premier.

L’installation d’AllTalk pose du PyTorch compilé pour CUDA 12.1. Ce build connaît les architectures GPU jusqu’à sm_90, c’est-à-dire la génération Hopper. Il ne connaît pas le sm_120 de Blackwell. Résultat concret : au premier chargement du modèle sur le GPU, c’est le crash immédiat.

Le contournement consiste à remplacer PyTorch par une version CUDA 12.8, qui elle gère Blackwell. En pratique, torch 2.7.0 avec torchvision et torchaudio alignés sur la même version et le même canal cu128.

Attention au piège dans le piège. Si tu installes torch et torchaudio sans verrouiller les versions, pip te choisit un torchaudio incompatible et tu te manges une erreur de symbole au démarrage du type undefined symbol: torch_library_impl. Il faut imposer les trois versions ensemble, dans l’environnement Python d’AllTalk, une fois l’installation de base terminée :

[CODE : fix_blackwell_cu128.sh]

pip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu128

La vérification immédiate, et celle qui doit devenir un réflexe, c’est de confirmer que le GPU est bien vu :

[CODE : verif_gpu.sh]

python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Tu dois obtenir 2.7.0+cu128, True, et le nom de ta carte. Si tu as ça, le sm_120 est géré et le plus dur est derrière toi.

III. L’installation : attention à la branche

Première erreur que j’ai commise, et que tu vas éviter. Le git clone standard tire la branche master, qui correspond à AllTalk V1. La V1 n’a pas d’interface graphique complète, pas de RVC, et son API renvoie les URLs dans un format différent qui casse l’intégration avec certains outils. J’ai perdu un bon moment dessus avant de comprendre.

La version que tu veux, la V2, vit sur la branche alltalkbeta. La nuance n’est écrite nulle part de façon évidente, alors note la bien :

[CODE : install_alltalk_v2.sh]

git clone -b alltalkbeta https://github.com/erew123/alltalk_tts
cd alltalk_tts
chmod +x atsetup.sh
./atsetup.sh

Tu choisis l’option Standalone Application, puis l’installation de base. Le script crée un environnement Python isolé et tire toutes les dépendances. C’est long, laisse mouliner.

Deux avertissements qui m’ont coûté du temps. Au premier lancement, un compte à rebours de 60 secondes télécharge un modèle Piper par défaut. Si tu ne fais rien, tu te retrouves avec Piper, qui est un moteur correct mais sans clonage de voix. Choisis bien le moteur xtts dans le menu de démarrage. Et surtout, ne lance jamais AllTalk en root, sinon ton environnement Python se retrouve avec des fichiers root-owned et tu galères ensuite à chaque commande.

IV. Les correctifs de dépendances

Le remplacement de PyTorch chamboule l’arbre des dépendances. Trois ajustements à faire, et un bug propre à la branche beta à corriger.

Premier point, setuptools. La réinstallation de torch monte setuptools en version récente, qui a supprimé le module pkg_resources. Sauf que la version de librosa embarquée par XTTS en a encore besoin. Sans ça, crash au démarrage avec ModuleNotFoundError: No module named 'pkg_resources'. Le correctif tient en une ligne :

[CODE : fix_setuptools.sh]

pip install "setuptools<81"

Deuxième point, les dépendances système. Le log d’AllTalk te signale trois manques. Le plus important, c’est espeak-ng : XTTS s’en sert pour la phonémisation, ce n’est pas optionnel. Les deux autres relèvent du confort, ffmpeg pour le transcodage des sorties audio et libaio pour faire taire un avertissement :

[CODE : fix_deps_systeme.sh]

sudo apt install espeak-ng ffmpeg libaio-dev

Troisième point, un bug propre à la V2 beta. Quand tu changes de moteur depuis l’interface, le code tente un appel chaîné change_engine(...).save() qui plante avec une AttributeError, parce que la méthode ne renvoie pas l’objet attendu. On sépare proprement les deux appels :

[CODE : patch_change_engine.sh]

sed -i 's/tts_engines_config.change_engine(requested_engine).save()/tts_engines_config.change_engine(requested_engine)\n        tts_engines_config.save()/' ~/alltalk_tts/tts_server.py

Une note de dépannage utile. Sur la V1, j’avais aussi dû patcher le chargement des modèles à cause du passage de PyTorch 2.6 en weights_only=True par défaut, qui refuse les classes personnalisées de Coqui. Sur la V2, le fork de coqui-tts gère déjà ce cas et le modèle charge sans rien toucher. Si jamais tu vois une UnpicklingError au chargement, c’est ce point précis qu’il faut corriger.

V. Le modèle XTTS et le basculement de moteur

Si le moteur xtts est sélectionné mais que le modèle n’a jamais été téléchargé, AllTalk cherche le dossier models/xtts/ et ne trouve rien. Tu télécharges le modèle, soit depuis l’onglet TTS Engines Settings de l’interface, soit en ligne de commande depuis le dépôt officiel sur Hugging Face :

[CODE : telecharger_modele_xtts.sh]

mkdir -p ~/alltalk_tts/models/xtts/xttsv2_2.0.3
cd ~/alltalk_tts/models/xtts/xttsv2_2.0.3
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/model.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/config.json
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/vocab.json
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/speakers_xtts.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/dvae.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/mel_stats.pth

Compte environ 2 Go au total, le fichier model.pth faisant à lui seul près de 1,8 Go. Ensuite, dans l’interface, onglet Generate TTS, tu passes Available Engines sur xtts puis tu cliques Change Model.

L’interface web d’AllTalk est accessible sur le port 7852, et l’API sur le port 7851. C’est cette API compatible OpenAI qui te permettra ensuite de brancher XTTS sur tes propres scripts ou sur n8n.

Côté performance, sur ma RTX 5070 Ti, le modèle charge en 5 à 6 secondes. Et la génération tape entre 0,2 et 0,5 seconde pour une phrase courte. C’est largement sous le temps réel, et franchement comparable à ce que je constatais sur ElevenLabs, sans la latence réseau.

VI. Cloner sa voix : tout se joue sur l’échantillon

C’est le coeur du sujet, et c’est aussi là que tout le monde se plante. Le clonage XTTS est aussi bon que ton échantillon. Ni plus, ni moins. Un clone moyen vient presque toujours d’un sample bâclé, pas du modèle.

Les règles à respecter pour un bon échantillon :

1. Format mono, 22050 Hz, 16 bits.
2. Durée de 10 à 30 secondes. Au-delà de 60 secondes, la qualité ne s’améliore plus et l’encodage ralentit.
3. Voix francophone si tu veux du français propre. Un locuteur anglophone clone un accent anglais sur ton texte français.
4. Aucun bruit de fond, aucune respiration bruyante, aucun raclement de gorge, aucun silence en début ou en fin.
5. Ton naturel et neutre. Si ton sample est joyeux ou agressif, le clone le sera aussi.

Une parenthèse cybersécurité qui devrait te faire réfléchir, parce que ce chiffre n’est pas anodin. 10 à 30 secondes de voix suffisent à produire un clone convaincant. C’est exactement pour cette raison qu’il ne faut jamais parler en premier quand tu reçois un appel suspect ou un numéro inconnu. Un simple « allô, oui, qui est à l’appareil ? » peut donner à un escroc assez de matière pour cloner ta voix, et s’en servir ensuite pour piéger un proche au téléphone, par exemple en simulant un appel de détresse. Le réflexe à prendre : laisse l’interlocuteur se présenter d’abord, et ne meuble pas le silence. La technologie qui te sert dans cet article peut tout aussi bien servir contre toi.

Pour nettoyer un enregistrement, Audacity fait parfaitement le travail. Tu importes ton fichier, tu sélectionnes un passage de silence, puis Effect, Noise Reduction, Get Noise Profile, et tu appliques la réduction sur l’ensemble. Tu coupes les respirations à la souris, tu normalises à -3 dB, et tu exportes en WAV mono 22050 Hz 16 bits.

Si tu veux juste convertir un fichier existant au bon format, ffmpeg suffit :

[CODE : convertir_sample.sh]

ffmpeg -i source.mp3 -ar 22050 -ac 1 -sample_fmt s16 ~/alltalk_tts/voices/mavoix.wav

Tu déposes le fichier dans le dossier ~/alltalk_tts/voices/, tu cliques Refresh Settings dans l’interface, et ta voix apparaît dans la liste. Sélectionne la, tape une phrase de test, et écoute le résultat.dans l’interface, et votre voix apparaît dans la liste. Sélectionnez la, tapez une phrase de test, et écoutez le résultat.

Voici le résultat 😀

VII. Affiner le rendu

Si le clone n’est pas à la hauteur malgré un bon échantillon, deux réglages dans l’onglet Generate TTS.

La température. Plus elle est basse, entre 0,5 et 0,65, plus le rendu colle à ton sample. Plus elle est haute, entre 0,75 et 0,85, plus c’est expressif, mais ça peut dériver.

La repetition penalty. La valeur par défaut à 10 est extrême. Descends à 2 ou 3 pour un rendu nettement plus naturel.

Si ça ne suffit toujours pas, deux options plus lourdes existent. Le mode multi-sample, où tu fournis plusieurs fichiers WAV d’une même personne pour stabiliser le clone. Et le fine-tuning, où tu entraînes réellement XTTS sur ta voix avec 2 à 20 minutes d’audio propre, pour obtenir un modèle dédié bien supérieur au zero-shot. Sur une 5070 Ti, cet entraînement prend une demi-heure environ. Je détaillerai cette partie dans un article séparé, parce qu’elle mérite son propre guide.

VIII. Les cas d’usage concrets

Une fois XTTS en place, ça ouvre plusieurs workflows qui remplacent directement ce que je faisais sur ElevenLabs :

1. Voix off pour mes vidéos YouTube. J’écris le script, je génère les pistes avec ma voix clonée, je monte dans mon éditeur. Zéro crédit consommé.
2. Lecture audio de mes articles de blog. Via l’API d’AllTalk branchée sur n8n, je génère automatiquement une version audio de chaque article.
3. Génération de faux podcasts. Un modèle de langage local écrit un dialogue à deux voix, XTTS le synthétise avec deux échantillons différents.
4. Doublage de mes propres vidéos en français. C’est le pipeline le plus puissant. On chaîne une transcription avec Whisper, une traduction avec un modèle local, puis une régénération en français avec ma propre voix.
   

Chacun de ces workflows mérite son propre tutoriel, et j’y reviendrai dans la suite de cette série.

Voici un exemple en anglais:

en espagnole:

En allemand:

est ça entre très bien dans un workfload n8n

IX. Démarrage automatique avec systemd

Pour ne pas relancer le serveur à la main à chaque démarrage, un service systemd. Tu crées le fichier /etc/systemd/system/alltalk.service :

[CODE : alltalk.service]

[Unit]
Description=AllTalk TTS Server
After=network.target

[Service]
Type=simple
User=ton_user
WorkingDirectory=/home/ton_user/alltalk_tts
ExecStart=/home/ton_user/alltalk_tts/start_alltalk.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Puis tu l’actives :

[CODE : activer_service.sh]

sudo systemctl daemon-reload
sudo systemctl enable alltalk
sudo systemctl start alltalk

AllTalk démarre désormais au boot, en arrière plan, avec relance automatique en cas de crash. Un détail qui m’a piégé deux fois : à l’arrêt manuel, le sous-process moteur a tendance à survivre et à garder le port 7851 occupé, ce qui bloque le redémarrage. Avant de relancer, vérifie avec lsof -i:7851 que le port est libre, et au besoin libère le avec kill $(lsof -t -i:7851).

X. Conclusion : le bilan de la liberté

Après ce parcours de correctifs et de réglages, est-ce que le jeu en vaut la chandelle ? Pour moi, c’est un oui franc.

Soyons lucides, ElevenLabs garde une longueur d’avance sur la qualité brute, surtout sur les nuances émotionnelles les plus fines. Mais XTTS en local atteint un niveau largement suffisant pour de la voix off, du doublage et de la lecture d’articles. Et il le fait sans abonnement, sans plafond de crédits, et sans que ma voix ne quitte ma machine. Pour quelqu’un qui prend ses données au sérieux, c’est le point de rupture.

Voici comment je résume la comparaison après plusieurs jours d’utilisation :

L’installation n’est pas plug and play sur une carte Blackwell, je ne vais pas te mentir. Mais une fois les correctifs passés, c’est stable, rapide, et entièrement à toi. Le plus gros levier de qualité reste l’échantillon : un bon enregistrement propre vaut tous les réglages du monde.

Dans le prochain article de cette série, je détaille les workflows en profondeur : la voix off, la lecture d’articles via n8n, le faux podcast, et surtout le doublage de mes propres vidéos YouTube en chaînant Whisper, traduction et XTTS. La route vers l’IA locale est encore longue, et on continue à en dessiner les contours.

A bientôt Louis 🐇 🤜 🤛 🐰

Fais le tour des réseaux sociaux et tu tomberas vite sur le même argument, répété en boucle : « l’IA en local, c’est gratuit, tu ne paies pas les tokens ». C’est l’argument massue, celui qui fait briller les yeux et sortir la carte bleue.

Sauf que c’est faux. L’IA en local, tu la paies deux fois : une fois à l’achat du matériel, et une deuxième fois en consommation électrique, mois après mois, tant que la machine tourne. Le cloud te facture au token ; le local te facture en watts. Dans les deux cas, il y a un compteur qui tourne. Il est juste moins visible côté local, parce qu’il se planque dans ta facture EDF au lieu d’arriver par mail à la fin du mois.

Et tu risques d’être surpris par le montant. Plus loin dans l’article, je te montre ma propre facture sur douze mois, relevé fournisseur à l’appui. Spoiler : ce n’est pas anodin.

Ça ne veut pas dire que le local est une mauvaise idée. Au contraire, sur certains usages c’est imbattable, et tu gardes la main sur tes données et tes modèles sans dépendre d’une API qui peut changer ses CGU ou ses prix du jour au lendemain. Ça veut juste dire qu’il faut acheter en connaissance de cause, avec les deux factures en tête, pas une seule.

Donc avant de claquer un budget, posons les bases. Et la première règle, celle qui détermine tout le reste, tient en une phrase : en IA locale, tu n’achètes pas de la puissance de calcul, tu achètes de la mémoire.

La règle de base : la mémoire d’abord

Toute la littérature sérieuse 2026 dit la même chose. Tu choisis d’abord la quantité de mémoire (VRAM sur un GPU, ou mémoire unifiée sur un mini-PC / un Mac), et ensuite seulement le reste.

Les repères à garder en tête :

• 8–16 Go : modèles 7B en quantifié. Du RAG léger, des petits agents, de l’expérimentation.
• 24 Go : 32B utilisables en Q4/Q5 (Qwen 2.5-Coder 32B, Mistral Small). Le vrai point de bascule pour bosser sérieusement.
• 40 Go+ ou mémoire unifiée 64–192 Go : 70B quantifiés (Llama 3.3 70B, DeepSeek R1 distill 70B, Qwen 2.5 72B), voire du 120B en 4-bit.

Un détail qu’on oublie souvent : la bande passante mémoire détermine ta vitesse en tokens/seconde. Une RTX 3090 tape dans les ~936 Go/s, un boîtier AMD à mémoire unifiée plafonne souvent autour de ~120 Go/s, un Mac M4 Pro est à 273 Go/s. À mémoire égale, ça change tout sur le ressenti en inférence. Avoir 64 Go ne sert à rien si le modèle crache 4 tok/s.

Les familles de matériel

Avant les tranches de budget, il faut distinguer les formes de produit, parce qu’on compare souvent des trucs qui n’ont rien à voir.

GPU grand public (GeForce). Le meilleur rapport perf/prix pour du LLM + image classique. RTX 3060, 4060 Ti, 3090, 4090, 5090. Le marché de l’occasion est ton ami.

Mini-PC IA à mémoire unifiée. Ryzen AI Max (Strix Halo), Minisforum, GMKtec, Mac mini/Studio. Beaucoup de mémoire, faible conso, format compact. En contrepartie, une bande passante plus faible que les gros GPU (sauf Apple).

Cartes data center détournées. Tesla P100, T4, P4, V100 récupérées d’occasion et collées dans une tour ATX. Beaucoup de VRAM pour pas cher, mais c’est un truc de bricoleur Linux (cooling à ajouter, drivers data center, pas de sortie vidéo).

Edge / embarqué (Jetson). Orin Nano, AGX Orin, Thor. Conso ultra-basse, format NUC, parfait pour de l’always-on silencieux ou du RAG embarqué. Pas pour du gros LLM à la maison.

Stations IA compactes premium. DGX Spark, Mac Studio haut de gamme. 128 Go+ de mémoire unifiée, cher, mais redoutable en perf/watt.

Par tranche de budget

Petite précaution avant de lire : les prix ci-dessous sont des prix observés mi-2026 sur le marché français/européen (occasion comprise). Ça bouge vite, parfois dans le mauvais sens : les Jetson Orin Nano ont pris une grosse hausse ces derniers mois, et le marché de l’occasion réserve des absurdités (un Mac mini M1 d’occasion peut coûter plus cher qu’un M4 neuf… cherchez la logique).

Moins de 400 €

L’entrée de gamme. Tu vises du 7B quantifié et du RAG léger.

• RTX 3060 12 Go d’occasion : le classique. CUDA partout, ça marche, point.
• Tesla P4 8 Go ou P100 16 Go d’occasion (~150–250 €) : énormément de VRAM par euro, mais cooling DIY et drivers data center.
• Tesla V100 32 Go sur AliExpress (~350 €) : le vrai bon plan VRAM/prix du moment, mais c’est réservé aux bricoleurs. Voir l’encadré dédié plus bas, parce qu’il y a un piège électrique sérieux.
• Jetson Orin Nano (~350 €) : si tu veux un truc qui consomme 7 W et tourne en permanence. Attention, le prix a fortement grimpé ces derniers mois, ce n’est plus le kit à 99 $ avant.

À ce niveau, ne rêve pas de génération d’image lourde ni de 32B. C’est un terrain de jeu, pas une station de prod.

400 – 900 €

Le sweet spot pour débuter sérieusement. 16 Go de VRAM ou un mini-PC milieu de gamme.

• RTX 4060 Ti 16 Go ou RX 7600 XT 16 Go : 7–13B confortables et de l’image raisonnable (SDXL, Flux en presets corrects).
• Tesla T4 16 Go : 70 W, excellente en perf/watt, parfaite pour un serveur d’inférence allumé H24.
• Mini-PC Ryzen AI 32 Go : polyvalent, basse conso, mais attention au support GPU sous Linux (j’y reviens plus bas).

900 – 1 800 €

Là, tu passes en 24 Go et tu peux faire du ComfyUI sérieux + du 32B. C’est la tranche des GPU 24 Go d’occasion, et clairement la plus rentable.

• RTX 3090 24 Go d’occasion (700–1 000 €) : LE meilleur achat, toutes catégories confondues. 24 Go, ~936 Go/s, compatibilité parfaite. Le neuf ne sert à rien ici, prends de l’occasion. Si tu ne devais retenir qu’une carte, c’est elle.
• RTX 4090 24 Go d’occasion (1 000–1 100 €) : même VRAM que la 3090 mais plus de patate, notamment en image. Là aussi le neuf est inutile.
• Tesla P100 32 Go : encore plus de VRAM pour pas cher, mais idle médiocre (voir section conso).
• Mini-PC à mémoire unifiée 64 Go type Minisforum AI X1 Pro (~1 100 $) : tu charges des modèles jusqu’à ~50B en Q4 sans GPU dédié. Le piège : ~120 Go/s de bande passante, donc compte 15–25 tok/s sur un Qwen 14B Q4. C’est lent mais ça tient en RAM ce qu’un GPU 24 Go ne tiendra jamais.

1 800 – 3 000 €

La tranche de la mémoire unifiée compacte et de l’edge costaud. Beaucoup de mémoire, faible conso, format de bureau, mais on troque la vitesse des gros GPU contre la capacité.

• Beelink SER9 (HX-370, ~2 300 €) : mini-PC Ryzen AI, basse conso (~7–9 W idle).
• Minisforum Strix Halo 64 Go (~2 300 €) : le modèle 128 Go n’est toujours pas dispo, on est cantonné au 64 Go pour l’instant. TDP modulable 45–120 W.
• Mac mini M4 64 Go (~2 800 €) : 70B quantifiés accessibles, idle dérisoire (~4–8 W), perf/watt imbattable. L’option la plus propre pour un nœud LLM always-on costaud.
• Jetson AGX Orin 64 Go (~2 400 € avec boîtier) : si tu fais de l’edge sérieux ou du RAG embarqué.

Plus de 3 000 €

Le haut du panier. C’est là que le 70B confortable, le 120B en 4-bit et l’image lourde deviennent vraiment fluides, mais le ticket d’entrée fait mal.

• RTX 5090 32 Go (3 500–5 000 €) : la puissance brute. 32 Go GDDR7, ~575 W rien que pour la carte. Réserve-la si tu fais de l’image lourde ou du training.
• Mac Studio M4 (à partir de ~4 400 € selon config) : jusqu’à 192 Go unifiée, 70B quantifiés + vidéo + IA, idle ridicule. Le compromis perf/watt le plus propre pour une station.
• DGX Spark (~5 000 €) : 128 Go unifiée (GB10), écosystème CUDA natif dans un format de bureau.
• Multi-GPU 4× 3090 en rack : 96 Go de VRAM totale pour qui veut du 70B+ sans compromis. C’est plus un labo qu’une machine perso, et la facture électrique suit (voir plus bas).

Le prix de la mémoire : la variable qui va tout chambouler

Tous les prix ci-dessus sont une photo à l’instant T, et cette photo va se dégrader. On a passé l’article à répéter que tu achètes de la mémoire avant tout : il faut donc parler du fait que la mémoire est en pleine crise de prix.

Depuis fin 2025, la DRAM et la NAND flambent. Les tarifs ont été multipliés par 3 à 4 en moins d’un an. La cause tient en trois lettres : la HBM, cette mémoire ultra-rapide qui équipe les accélérateurs IA des data centers (NVIDIA H100/H200/B200, AMD MI300…). Les trois seuls fabricants mondiaux (Samsung, SK Hynix, Micron) ont réorienté leurs capacités vers cette HBM à forte marge, au détriment de la DDR4, DDR5, LPDDR5 et de la NAND grand public. Résultat : moins d’offre, des stocks tendus, des prix qui s’envolent. Et ça ne s’arrête pas à la RAM système : la GDDR des cartes graphiques est touchée par le même effet, donc les GPU sont aussi concernés.

Et ce n’est pas fini. Micron annonce +50 à 60 % sur la DRAM dès le premier trimestre 2026, TrendForce table sur +58 à 63 % de plus au deuxième trimestre. Pour résorber la pénurie, il faudrait augmenter la production de 12 % par an d’ici 2027 ; les plans industriels actuels ne prévoient que 7,5 %. L’écart ne se comble pas par magie : une nouvelle usine de semi-conducteurs met des années à monter en cadence. Les prévisions convergent vers une tension qui dure au moins jusqu’en 2027, avec un plateau des prix cette année-là et une éventuelle détente seulement à partir de 2028. Les plus pessimistes (Counterpoint) évoquent 2030.

Donc oui, il y a eu de légères respirations sur certains tarifs, mais la tendance de fond est haussière, et elle va le rester un moment. Ça a deux conséquences très concrètes pour toi.

D’abord, les configs gourmandes en mémoire vont coûter de plus en plus cher. Un mini-PC 128 Go de mémoire unifiée ou une carte à grosse VRAM, c’est exactement ce que le marché s’arrache. Si ton projet en dépend, le surcoût ne fera que grimper.

Ensuite, et c’est là que je vais à contre-courant du discours ambiant : dans pas mal de cas, le calcul honnête, c’est de ne pas acheter maintenant. À ces prix-là, monter une vraie config locale revient cher, et on sait que la mémoire restera tendue jusqu’en 2027-2028. Une stratégie tout à fait défendable, c’est donc : j’attends deux ans que le marché se détende, et en attendant j’utilise les API. Tu paies au token sur la période, mais tu n’immobilises pas 3 000 ou 5 000 € dans une machine achetée au pic, qui aura perdu de la valeur quand les prix mémoire seront retombés. Pour un usage modéré, l’addition API sur deux ans peut largement rester sous le coût d’achat + électricité d’une grosse config.

Si malgré tout tu veux du local tout de suite, l’occasion est ta meilleure protection. Une RTX 3090 ou 4090 d’occasion, avec sa VRAM déjà soudée et payée au prix d’hier, te met à l’abri de la flambée. C’est l’arbitrage à faire : soit tu passes par l’occasion maintenant, soit tu encaisses le coût API quelque temps et tu investis quand le marché aura soufflé. Ce qui n’a pas de sens, c’est d’acheter du neuf gourmand en mémoire en plein pic.

Dernier point à connaître : à partir de 2026, la disponibilité risque de devenir un problème avant même le prix. Si tu choisis la voie « j’achète maintenant », garde en tête que trouver le composant pourra être plus compliqué que le payer.

Inférence vs diffusion : ce que ça change

On mélange trop souvent les deux usages, alors qu’ils ne sollicitent pas le matériel pareil.

Inférence LLM. C’est dominé par la bande passante mémoire. Le modèle doit être lu en entier à chaque token généré. D’où l’importance de la VRAM (pour faire rentrer le modèle) ET de la bande passante (pour le lire vite). Une P100 à 16 Go fera tourner un 32B Q4, mais ses ~550 Go/s la rendent plus lente qu’une 3090.

Diffusion / génération d’image. Là, l’architecture du GPU compte davantage. Les Tensor Cores modernes (FP8, etc.) accélèrent énormément. C’est pour ça qu’une Pascal (P100) fait tourner ComfyUI mais reste sensiblement plus lente qu’une 3090/4090/5090 sur le même workflow. En image, l’ancienneté de l’archi se paie cash.

Conclusion pratique : si ton truc c’est le LLM, optimise la mémoire et la bande passante. Si c’est l’image, oriente-toi vers une archi récente (Ampere minimum, idéalement Ada/Blackwell).

La consommation : le truc que personne ne regarde

C’est l’angle mort des tableaux VRAM/prix. Si ta machine tourne H24 pour Ollama, n8n ou ComfyUI, deux chiffres comptent : la conso idle (machine allumée, modèle pas chargé) et la conso en calcul.

Attention, point crucial : les chiffres ci-dessous sont pour la carte seule. C’est toute la config qui consomme. CPU, carte mère, RAM, ventilation, alim avec son rendement : ajoute facilement 100 à 250 W sous charge par-dessus le GPU. Une config autour d’une RTX 5090 dépasse le plus souvent 1 000 W à pleine charge. Donc quand tu lis « 575 W » pour la 5090, lis plutôt « 1 000 W au mur » pour la machine complète.

Côté boîtiers compacts, l’intérêt c’est que les chiffres sont système complet (pas de tour à ajouter autour) :

C’est aussi là que les boîtiers compacts à mémoire unifiée prennent leur revanche sur les gros GPU : un Mac mini ou un Strix Halo te fait tourner un 70B en consommant ce qu’une tour avec 5090 brûle au repos. Si ton usage c’est l’always-on, le perf/watt écrase la perf brute.

Le truc à retenir, qui n’apparaît jamais dans un tableau prix/VRAM : une P100 ou une V100 est souvent bloquée en état de perf élevé au repos, donc son idle est mauvais. Géniale pour bricoler et calculer, beaucoup moins pour un serveur domestique qui passe sa vie à attendre. Ça se rattrape sous Linux en réglant les p-states (voir l’astuce dans l’encadré V100 plus bas), mais c’est un réglage à faire, ce n’est pas automatique. À l’inverse, une T4, un Jetson ou un Mac mini sont imbattables pour de l’always-on sans rien toucher.

Règle simple de lecture :

• Tu calcules souvent : 3090/4090/5090, peu importe l’idle.
• Tu veux un nœud IA allumé toute la journée : Mac mini, Jetson, T4. La sobriété prime.

Rien n’est gratuit : la facture, en vrai

Petite parenthèse vécue, parce que c’est facile de raisonner en watts sans jamais regarder la note. Voici ma conso réelle sur 12 mois (relevé fournisseur, en € par mois) :

J’ai commencé à utiliser ma 5070 mi-octobre, et la courbe grimpe à partir de là. En mai, je suis passé sur des API pour une partie du travail, et la facture retombe à 86 €, exactement le niveau d’avant la 5070.

Et là, pas d’échappatoire : je me chauffe au bois :D. Le pic hivernal n’est donc pas un artefact du chauffage électrique. Le seul gros changement sur la période, c’est la machine qui s’est mise à tourner pour faire de l’IA. La corrélation est limpide : GPU allumé mi-octobre, la facture décolle ; bascule sur API en mai, elle redescend à son niveau de départ. Il reste bien quelques variations saisonnières mineures (éclairage, jours plus courts), mais elles ne pèsent pas 100 € par mois. Le coupable, c’est le calcul local.

Mais le message de fond tient : rien n’est gratuit. La machine locale a un coût électrique réel et récurrent, et l’API a un coût au token. L’IA locale n’est pas « gratuite » par opposition au cloud : tu déplaces juste la dépense de la facture API vers la facture EDF. À toi de voir laquelle correspond à ton usage et à ton volume.

Encadré bricoleur : la Tesla V100 32 Go (~350 €)

C’est le meilleur ratio VRAM/prix du moment, mais ça se mérite. Avant de cliquer sur AliExpress, tu dois savoir trois choses :

• L’alimentation est piégeuse. Le connecteur n’est pas un PCIe standard, il y a une modif/adaptateur à faire. Mal branchée, tu risques de cramer la carte mère. Les adaptateurs se trouvent en ligne, mais c’est une manip à ne pas rater.
• Ventilation passive. Comme toutes les cartes data center, pas de ventilo intégré. Il faut ajouter un shroud + ventilateur sinon ça monte en température.
• Idle à programmer sous Linux. Par défaut elle reste bloquée en état de perf élevé (P0), donc elle tire 40 W et plus au repos pour ne rien faire. Sans réglage des p-states, ton idle est catastrophique pour du 24/7.

Astuce : dompter les p-states. Le problème touche toutes les cartes data center (P100, V100, T4…) : par défaut elles ne redescendent pas en basse conso au repos. Deux approches.

D’abord, active le persistence mode pour fiabiliser le comportement des clocks :

bash

sudo nvidia-smi -pm 1

Ensuite, le plus simple et le plus propre : le démon nvidia-pstated (open-source, dispo sur GitHub). Il surveille l’utilisation du GPU et force la carte en p-state bas (P8) dès qu’elle est inactive, puis la repasse en P0 sous charge, automatiquement, sans bricoler tes clocks à la main. Sur une P100/V100, ça fait tomber l’idle de ~40 W à une dizaine de watts. Tu le lances en service systemd et tu n’y penses plus.

Alternative manuelle si tu veux verrouiller les fréquences toi-même (nvidia-smi -lgc), mais tu plafonnes alors les perfs et c’est moins souple que le démon. Pour un serveur allumé en permanence, nvidia-pstated est de loin la meilleure option : c’est lui qui transforme une carte « mauvais idle » en carte 24/7 acceptable.

En clair : 350 € pour 32 Go, c’est imbattable, mais c’est un projet Linux à part entière, pas un achat plug-and-play. Si tu n’es pas à l’aise avec le tuning matériel, reste sur une 3090 d’occasion.

Compatibilité : le piège PyTorch / CUDA

C’est là que beaucoup se font avoir. Avoir 64 Go de mémoire unifiée ne sert à rien si ta stack logicielle ne sait pas l’exploiter au GPU. Petit tour par écosystème.

NVIDIA / CUDA. Le standard de fait. PyTorch, vLLM, Ollama, ComfyUI : sur de l’Ampere ou de l’Ada (3090, 4090…), tout marche nativement, builds officiels, zéro galère. C’est la raison numéro un pour rester sur du NVIDIA si tu fais du dev ou du training, pas juste de l’inférence.

Sauf qu’il y a une grosse exception, et elle est contre-intuitive : la série RTX 5000 (Blackwell) est aujourd’hui le moins bon choix CUDA. Ces cartes utilisent une nouvelle compute capability, sm_120, et les versions stables de PyTorch ne sont compilées que jusqu’à sm_90 (Hopper). Concrètement, sur une 5070 / 5080 / 5090 fraîchement montée, tu te prends souvent un CUDA error: no kernel image is available for execution on the device, ou pire, un fallback silencieux sur le CPU. Le seul moyen d’en tirer quelque chose, c’est de passer par les builds nightly (cu128/cu129, Python 3.13 conseillé) ou de compiler PyTorch depuis les sources. Ça fonctionne, mais ce n’est pas une version stable définitive.

Et ça dure. La série 50 est sortie début 2025 ; on est mi-2026 et le support officiel de sm_120 dans le PyTorch stable n’est toujours pas là. Les demandes côté PyTorch (dont une qui cite nommément la 5070 Ti) sont encore ouvertes. Plus d’un an à bricoler du nightly pour faire tourner une carte vendue, entre autres, pour l’IA : c’est le monde à l’envers. Et le plus cocasse, c’est qu’on parle déjà de la suite : les fuites (Kopite7kimi, relayé par Wccftech) annoncent une génération RTX 60 sous architecture Rubin pour le second semestre 2027. Autrement dit, NVIDIA prépare déjà la relève alors que la génération actuelle n’est toujours pas correctement prise en charge par la stack logicielle. Bref, si tu veux du NVIDIA sans prise de tête logicielle, une 3090 ou 4090 d’occasion t’évitera ces galères ; la 5090 ne se justifie que si tu as vraiment besoin de sa puissance brute et que le tuning logiciel ne te fait pas peur.

AMD / ROCm. Sur les gros GPU AMD dédiés, ROCm progresse et PyTorch a ses builds. Mais sur les iGPU Ryzen AI récents (Strix Halo compris), le support ROCm reste partiel en 2026. Ollama tourne très bien en CPU+RAM, mais sans accélération GPU complète. Donc le mini-PC AMD 64 Go que tu lorgnes : il chargera de gros modèles, mais souvent en s’appuyant sur le CPU. À garder en tête avant d’acheter.

Apple / Metal / MLX. PyTorch a un backend MPS qui fonctionne, mais tous les ops ne sont pas couverts. Pour Apple Silicon, le vrai chemin c’est MLX (le framework d’Apple) ou Ollama/llama.cpp. La bonne nouvelle : la grosse bande passante mémoire (273 Go/s sur M4 Pro) compense, et le perf/watt est excellent.

Pascal (P100/V100). CUDA-capable, donc Ollama/vLLM/ComfyUI tournent. Mais c’est de l’archi ancienne : pas de FP8, pas de Tensor Cores modernes, et il faut surveiller que les versions récentes de PyTorch ne lâchent pas le support des vieilles compute capabilities (sm_60/sm_70). Plus les drivers data center (pas GeForce) et le cooling DIY. C’est jouable, mais ce n’est clairement pas plug-and-play.

Jetson. Écosystème Linux embarqué (JetPack), pas Windows. CUDA présent mais parfois plus limité que sur GPU desktop côté bibliothèques. Parfait pour de l’edge, pas pour reproduire ta station de dev.

En résumé : quel matériel pour quel besoin

• Découvrir, RAG léger, 7B, petit budget. RTX 3060 12 Go d’occasion, ou une Tesla P4/T4 si tu acceptes le bricolage. T4 si c’est pour du H24 sobre. Et si tu es à l’aise avec le tuning matériel, la V100 32 Go à ~350 € est imbattable en VRAM/prix.
• Bosser sérieusement, 32B, ComfyUI, le meilleur rapport qualité/prix. La RTX 3090 24 Go d’occasion (700–1 000 €). Sans hésiter. CUDA natif, 24 Go, bande passante correcte. Le neuf ne sert à rien.
• Charger de gros modèles 70B sans exploser le budget GPU. Un mini-PC à mémoire unifiée 64–128 Go (Minisforum, Strix Halo, ~2 300 €). En acceptant la lenteur et le support GPU partiel sous Linux.
• Nœud IA allumé en permanence, basse conso. Mac mini M4 (~2 800 € en 64 Go) ou Jetson. Conso de N100, moteur IA en plus.
• 70B confortable, perf/watt propre, format bureau. Mac Studio M4 (~4 400 €) ou DGX Spark (~5 000 €), si le budget suit.
• Image lourde, puissance brute, training. RTX 4090 d’occasion (~1 000–1 100 €) ou 5090 (3 500–5 000 €), archi récente obligatoire, sans oublier que la config 5090 complète tape dans les 1 000 W.

Le bon réflexe : pars de ton usage réel (inférence ? image ? always-on ?), déduis la mémoire dont tu as besoin, vérifie que ta stack supporte le matériel au GPU, et seulement après regarde le prix. Dans cet ordre. La machine la plus tape-à-l’œil sur le papier n’est pas forcément celle qui tournera le mieux chez toi.

Et garde en tête les deux factures et le calendrier. À l’achat, la mémoire est en pleine flambée et la tendance reste haussière jusqu’en 2027-2028 : à ces prix-là, le calcul le plus malin n’est pas forcément d’acheter aujourd’hui. Pour beaucoup, attendre deux ans que le marché se détende et tenir avec les API entre-temps coûte moins cher que d’immobiliser plusieurs milliers d’euros dans une machine achetée au pic. Si tu veux quand même du local maintenant, passe par l’occasion, pas par du neuf gourmand en mémoire. En consommation, un GPU qui tourne, c’est une centaine d’euros par mois sur ta facture, chiffre réel à l’appui. L’IA en local n’est pas gratuite. Elle peut valoir largement le coup, mais en connaissance de cause, les deux factures posées sur la table, et parfois la meilleure décision c’est juste d’attendre.

Je fais tourner un agent autonome (Hermes Agent de Nous Research) sur un mini PC dédié à la maison. Jusqu’à cette semaine, toutes ses requêtes LLM passaient par OpenRouter, avec DeepSeek V4 Flash comme modèle par défaut.

OpenRouter, c’est pratique : une seule clé, des dizaines de modèles, paiement à l’usage. Mais le paiement à l’usage a un défaut quand on laisse tourner un agent : on ne sait jamais à l’avance ce qu’on va payer.

J’ai regardé mes chiffres. Ils m’ont décidé.

Les chiffres qui font mal

Sur 2 jours d’utilisation, voici ce que mon dashboard OpenRouter affichait :

Deux choses sautent aux yeux.

D’abord, 3,71 $ en deux jours. Si je projette ça sur un mois, je tourne autour de 55 $. C’est beaucoup pour un agent perso.

Ensuite, le détail qui m’a le plus surpris : DeepSeek V4 Pro. 13 requêtes seulement, mais 1,40 $ soit près de 40 % de ma facture pour 1,5 % de mes appels. Ces quelques requêtes lourdes que l’agent décide de router vers un gros modèle, on ne les voit pas venir. Et c’est exactement là que le paiement à l’usage devient imprévisible.

OpenCode Go : le coût fixe

OpenCode Go, c’est un abonnement à 10 $/mois (5 $ le premier mois) qui donne accès à une douzaine de modèles open source curatés : DeepSeek V4 Flash et Pro, Qwen3, Kimi K2, GLM-5, MiniMax, MiMo.

Le point clé pour moi : l’endpoint est compatible OpenAI. Pas besoin d’utiliser l’outil OpenCode lui-même. On branche la clé sur n’importe quel agent qui parle à une API LLM/Hermes dans mon cas.

La migration, étape par étape

Bonne surprise : Hermes supporte OpenCode Go nativement. La section est déjà prévue dans le fichier de config. La bascule m’a pris cinq minutes.

1. Récupérer la clé OpenCode Go

Après abonnement sur opencode.ai/go, la clé API se récupère depuis le dashboard. Elle commence par sk-.

2. Ajouter la clé dans le .env

Le fichier d’environnement de Hermes se trouve dans ~/.hermes/.env. On y décommente la ligne dédiée à OpenCode Go et on colle la clé :

bash

OPENCODE_GO_API_KEY=sk-votre-cle-ici

À noter : on peut laisser l’ancienne clé OpenRouter en place. Hermes utilise le provider défini dans la config, pas celui dont la clé est présente. Pratique pour revenir en arrière sans rien réécrire.

3. Pointer Hermes sur OpenCode Go

Trois commandes suffisent. On change le provider, l’URL de base, et le modèle par défaut :

bash

hermes config set model.provider opencode-go
hermes config set model.base_url https://opencode.ai/zen/go/v1
hermes config set model.default opencode-go/deepseek-v4-flash

Je garde le même modèle (DeepSeek V4 Flash), je change juste le tuyau qui y mène.

4. Vérifier depuis Telegram

Mon Hermes est piloté en partie via Telegram. La commande /model affiche la configuration courante et permet de changer de provider à la volée. C’est le moyen le plus rapide de confirmer que la bascule a pris.

Et le résultat une fois le modèle sélectionné :

C’est fait. L’agent tourne désormais entièrement sur OpenCode Go.

Le calcul, sans enjoliver

Sur le papier, c’est 80 % d’économie. Mais je veux être honnête sur deux nuances, parce que c’est facile de vendre du rêve avec ce genre de tableau.

Nuance 1 : mes deux jours étaient atypiques. J’étais en plein build de mon serveur d’automation, avec des sessions très denses. Mon usage courant est plus léger. Donc les 55 $ projetés sont un plafond, pas une moyenne.

Nuance 2 : OpenCode Go n’est pas illimité. Les limites sont exprimées en valeur dollar, pas en nombre de requêtes, et elles se rechargent toutes les 5 heures. Les modèles plus légers durent plus longtemps que les gros. Si vous balancez du DeepSeek V4 Pro en continu, vous taperez le plafond. Pour un usage agent normal sur un modèle Flash, ça passe largement.

Autrement dit : l’économie est réelle, mais elle suppose un usage qui rentre dans les limites du forfait. Ce n’est pas une licence pour consommer sans compter.

Ce que je retiens

Le vrai gain, ce n’est pas seulement le prix. C’est la prévisibilité. Je sais que je paie 10 $ ce mois-ci, point. Plus de facture qui dérape à cause de quelques requêtes routées vers un modèle premium sans que je l’aie demandé.

Pour un agent qui tourne 24/7 sur du matériel perso, c’est exactement ce que je cherchais : un coût plat, une seule clé, et assez de modèles pour ne jamais être bloqué.

Je n’abandonne pas OpenRouter pour autant

Important : OpenCode Go remplace OpenRouter pour le cerveau texte de mon agent, pas pour tout le reste. Je garde OpenRouter en parallèle, et il garde tout son sens pour des usages plus spécialisés : le TTS, la génération d’image et la génération de vidéo. C’est devenu un vrai hub multimodal, là où le paiement à l’usage reste le bon modèle, on ne génère pas une vidéo toutes les cinq minutes.

En vidéo justement, je travaille beaucoup en local sur ma machine principale (ComfyUI, GPU dédié). LTX et Wan sont d’excellents modèles open source, largement suffisants pour la plupart de mes besoins, et gratuits une fois le matériel amorti.

Mais soyons honnêtes : quand je veux le résultat au-dessus du lot, un Seedance 2.0 reste exceptionnel. C’est là que le cloud garde l’avantage pour ces générations ponctuelles où la qualité prime sur le coût. D’où l’intérêt de garder une porte ouverte sur OpenRouter, qui donne accès à ce genre de modèle sous la même clé.

La bonne architecture, pour moi, n’est donc pas « tout cloud » ni « tout local ». C’est : OpenCode Go pour le LLM de l’agent (coût fixe, prévisible), le local pour le gros du multimodal (LTX, Wan), et OpenRouter en appoint pour le TTS et les générations haut de gamme comme Seedance 2.0.

En résumé

Si votre conso OpenRouter en LLM dépasse régulièrement 10 $/mois, basculer le cerveau de votre agent vers OpenCode Go est vite rentable. En dessous, restez sur le paiement à l’usage vous paierez moins. Et dans les deux cas, gardez OpenRouter sous la main pour ce qu’il fait désormais très bien : le multimodal à la demande.

Depuis quelques mois, je vois passer beaucoup de publications et de vidéos YouTube qui expliquent qu’il faut un Mac mini ou un VPS pour faire tourner un agent autonome comme OpenClow ou Hermes Agent. 700€ la machine, ou un abonnement mensuel qui part indéfiniment. Et en y réfléchissant bien, à ce qu’on leur demande concrètement : tourner 24h/24, attendre des messages Telegram, exécuter des workflows la nuit pendant qu’on dort. Pas de l’inférence lourde, pas de rendu 3D. Juste orchestrer et déléguer.

Je vais te montrer une autre voie : un mini PC à 130€, moins gourmand, moins cher, qui fait exactement le même boulot.

Cette machine tourne sans écran ni clavier depuis plusieurs semaines chez moi. Elle reçoit mes ordres par Telegram, exécute des tâches en arrière-plan, et s’appuie sur ma machine principale ou OpenRouter quand elle a besoin de compute. C’est le control plan permanent du setup, pas la brute de calcul.

Voilà comment j’ai fait, brique par brique, avec les détails d’installation que j’aurais aimé trouver en un seul endroit.

1. Le matos et pourquoi pas autre chose

Le mini PC : MLLSE G2 Pro

Intel N150, 12 Go de LPDDR5, 512 Go de SSD, WiFi 5, Bluetooth 5.0. Windows 11 Pro pré-installé, que j’ai remplacé par du Linux en dix minutes.

Le N150 est un quad-core basse consommation. Il ne va pas faire tourner un Llama 70B en local. Ce n’est pas son rôle. Son rôle, c’est d’être sobre et toujours allumé. Sous charge normale de serveur, il tire 9W. C’est ridicule. Une ampoule LED de bureau en consomme davantage. Ramené à l’année entière, ça représente environ 8€ d’électricité pour un serveur qui tourne 24h/24, à comparer aux 180€ d’un VPS entrée de gamme sur la même période, rien qu’en abonnement. Le chassis est conçu pour un usage permanent : pas de batterie qui gonfle, pas de ventilo qui s’encrasse.

Pourquoi pas un VPS cloud ?

5€/mois, ça paraît rien. Sur trois ans, tu as payé 180€ pour une machine qui n’est pas chez toi, qui ne voit pas ton réseau local, et qui te facture chaque byte de trafic sortant. Mon agent IA a besoin de parler à Ollama sur ma machine principale, à ComfyUI, à SearXNG. Avec un VPS, tout ça passerait soit par internet (latence plus coût), soit par un tunnel VPN. Avec un mini PC sur le LAN, c’est une simple requête HTTP sur le réseau interne. Pas de souci.

Le mini PC coûte plus cher le premier jour. Il est moins cher dès le quatorzième mois, et il reste sur ton réseau.

Pourquoi pas un vieux laptop ?

Un laptop qui tourne 24h/24, c’est une batterie qui gonfle dans les douze mois, un ventilo qui accumule de la poussière, et une consommation 3 à 5× supérieure au mini PC. La machine n’est pas faite pour ça. Le mini PC, si.

Pourquoi pas le Mac mini M4 à 700€ ?

Parce que le gros calcul, je l’ai déjà : Ryzen 9 + RTX 5070 Ti sur ma machine principale. Ce que je cherche ici, c’est un orchestrateur sobre et permanent qui sait déléguer. La même logique headless que partout ailleurs : mettre le bon outil au bon endroit, ne pas gâcher la ressource. Le Mac mini ferait la même chose six fois plus cher.

2. La stack : ce qu’on installe et pourquoi chaque brique

Avant le détail de l’installation, une vue d’ensemble de l’architecture cible.

[SCHÉMA : tazmenworld ↔ autoserver ↔ Telegram ↔ internet]

Le control plan (autoserver) décide et orchestre. Le compute (tazmenworld) calcule. La seule sortie cloud : les appels LLM vers OpenRouter. C’est du pay-per-use, pas un abonnement fixe. À l’usage courant, quelques dizaines de requêtes par jour sur DeepSeek V4, ça se chiffre en centimes. Tout le reste reste sur le réseau local.

3. Ubuntu Server 26.04 LTS : le socle headless

Pas d’interface graphique. C’est un serveur, il vit en console. On choisit Ubuntu Server 26.04 LTS « Resolute Raccoon », supporté jusqu’en 2031 (2036 avec Ubuntu Pro, gratuit jusqu’à 5 machines personnelles).

Créer la clé USB depuis tazmenworld

bash

cd ~/Downloads
wget https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso

# Identifier la clé USB
lsblk

# Écrire l'image (remplace /dev/sdX, ATTENTION : tout sera effacé)
sudo dd if=ubuntu-26.04-live-server-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync
sync

Options d’installation qui comptent

On démarre sur la clé (touche F7 ou Del au boot pour le menu), puis dans l’installeur Subiquity :

Une fois installé, on retire la clé USB, on redémarre. La machine boote en console texte. C’est normal, c’est voulu.

Mise à jour complète et outils de base

bash

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

sudo apt install -y \
  curl wget git nano htop net-tools \
  ca-certificates gnupg lsb-release \
  ufw fail2ban unattended-upgrades \
  tree jq ncdu

sudo reboot

IP statique via Netplan

Un serveur ne peut pas changer d’IP à chaque redémarrage. On configure une IP fixe via Netplan, mais avant d’écrire quoi que ce soit, on vérifie la vraie adresse de la passerelle. Sur ton réseau, elle n’est pas forcément 192.168.1.1. La vérifier d’abord sur tazmenworld :

bash

ip route | grep default
# Exemple : default via 192.168.1.254 dev enp14s0
#                       ↑ c'est cette IP qu'on met dans netplan

Puis on identifie l’interface réseau sur autoserver :

bash

ip link show
# Exemple : enp2s0 (Ethernet), préférer l'Ethernet au WiFi pour un serveur

On édite la config :

bash

sudo nano /etc/netplan/00-installer-config.yaml

yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:                        # adapter à ton interface
      addresses:
        - 192.168.1.20/24
      routes:
        - to: default
          via: 192.168.1.254       # ta vraie passerelle, pas une supposée
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      dhcp4: false

On applique et on vérifie :

bash

sudo netplan apply
ip addr show enp2s0        # l'IP 192.168.1.20 doit apparaître
ping -c 3 1.1.1.1          # si ça ne répond pas → passerelle incorrecte
ping -c 3 tazmenworld      # joignabilité réseau local

Synchronisation horaire

bash

sudo timedatectl set-timezone Europe/Paris
timedatectl status
# "System clock synchronized: yes" doit apparaître

Sécurisation SSH

On génère une paire de clés ed25519 sur tazmenworld :

bash

ssh-keygen -t ed25519 -C "tazmenworld→autoserver" -f ~/.ssh/autoserver_key

On copie la clé publique sur autoserver (avec le mot de passe temporaire) :

bash

ssh-copy-id -i ~/.ssh/autoserver_key.pub <votre_user>@192.168.1.20

On teste la connexion par clé :

bash

ssh -i ~/.ssh/autoserver_key <votre_user>@192.168.1.20

Puis on durcit la config SSH sur autoserver :

bash

sudo nano /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers <votre_user>
X11Forwarding no

Spécificité Ubuntu 26.04, deux points à ne pas rater :

1. X11Forwarding en double. Le fichier par défaut contient souvent X11Forwarding yes plus haut. Commente cette ligne, sinon ta ligne no en bas sera ignorée.

2. Socket activation. Ubuntu 26.04 gère le port SSH via ssh.socket. Un simple restart ssh ne suffit pas :

bash

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

⚠️ Teste depuis un deuxième terminal avant de fermer ta session actuelle :

bash

# Depuis tazmenworld, nouveau terminal
ssh -i ~/.ssh/autoserver_key -p 2222 <votre_user>@192.168.1.20

Si ça passe, on peut fermer l’ancienne session. On configure ensuite un profil SSH sur tazmenworld pour ne plus jamais taper l’IP :

bash

nano ~/.ssh/config

Host autoserver
    HostName 192.168.1.20
    Port 2222
    User <votre_user>
    IdentityFile ~/.ssh/autoserver_key
    ServerAliveInterval 60

Désormais : ssh autoserver. C’est tout.

Pare-feu UFW et Fail2ban

bash

# Règles UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment "SSH"
sudo ufw allow 5678/tcp comment "n8n"
sudo ufw allow from 192.168.1.0/24 comment "Réseau local"
sudo ufw enable
sudo ufw status verbose

bash

# Fail2ban, bannissement auto des tentatives de brute-force
sudo nano /etc/fail2ban/jail.local

ini

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 3

[sshd]
enabled  = true
port     = 2222
logpath  = /var/log/auth.log

bash

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Mises à jour automatiques de sécurité

bash

sudo dpkg-reconfigure --priority=low unattended-upgrades
# → Yes

Le serveur se patche tout seul sur les failles de sécurité. On n’a plus à y penser.

4. Docker : l’isolement propre

Pour n8n, on containerise. Docker isole le service, simplifie les mises à jour, et évite de polluer le système hôte.

Note Ubuntu 26.04 : Resolute Raccoon a supprimé le support de cgroup v1. Docker le gère nativement depuis la v20.10, mais il faut impérativement passer par le dépôt officiel Docker, pas le paquet docker.io des dépôts Ubuntu qui est souvent en retard.

Installation Docker CE (méthode officielle)

bash

# Supprimer d'éventuelles vieilles versions
sudo apt remove -y docker docker-engine docker.io containerd runc 2>/dev/null

# Clés GPG et dépôt officiel Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
                    docker-buildx-plugin docker-compose-plugin

Si apt update échoue avec une erreur sur le codename resolute : le dépôt Docker n’a peut-être pas encore indexé 26.04. Solution : forcer le codename noble (24.04), les paquets sont compatibles.

bash

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Ajouter l’utilisateur au groupe docker

bash

sudo usermod -aG docker <votre_user>

Piège sur install minimized : newgrp n’est pas disponible. Le groupe ne s’active pas dans la session en cours. Tu dois te déconnecter et te reconnecter, sans message d’erreur explicite, juste un permission denied silencieux sur docker run si tu oublies ce détail.

bash

exit
# puis : ssh autoserver

# Tester depuis la nouvelle session
docker run --rm hello-world
docker compose version

Configurer le daemon Docker

bash

sudo nano /etc/docker/daemon.json

json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-address-pools": [
    {"base": "172.20.0.0/16", "size": 24}
  ]
}

bash

sudo systemctl restart docker
docker info | grep -i "log driver"
# Attendu : Logging Driver: json-file

5. Structure des répertoires

bash

sudo mkdir -p /opt/autoserver/{n8n,hermes,shared,backups}
sudo chown -R <votre_user>:<votre_user> /opt/autoserver

/opt/autoserver/
├── n8n/
│   ├── docker-compose.yml
│   ├── .env
│   └── data/            ← volume persistant n8n
├── hermes/
│   └── data/
├── shared/              ← fichiers échangés entre services
└── backups/             ← sauvegardes automatiques

6. n8n : le moteur de workflows

n8n, c’est le chef d’orchestre des automatisations que tu as câblées. Il sait : « à 7h chaque matin, lance cette recherche ; si tel webhook arrive, déclenche ce traitement ». Interface visuelle, scriptable, il se connecte à des centaines de services.

Fichier d’environnement

bash

nano /opt/autoserver/n8n/.env

env

# Réseau
N8N_HOST=0.0.0.0
N8N_PORT=5678
N8N_PROTOCOL=http
WEBHOOK_URL=http://192.168.1.20:5678/

# Sécurité
N8N_ENCRYPTION_KEY=<générer_avec_openssl_rand_-hex_16>
GENERIC_TIMEZONE=Europe/Paris
NODE_ENV=production

# Indispensable en HTTP local, voir section "pièges"
N8N_SECURE_COOKIE=false

# Désactiver la télémétrie (évite des erreurs réseau parasites dans les logs)
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false

# Connexion Ollama sur tazmenworld
OLLAMA_BASE_URL=http://192.168.1.100:11434

Pour générer une clé d’encryption solide :

bash

openssl rand -hex 16

Docker Compose n8n

bash

nano /opt/autoserver/n8n/docker-compose.yml

yaml

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    env_file:
      - .env
    volumes:
      - ./data:/home/node/.n8n
      - /opt/autoserver/shared:/shared
    networks:
      - autoserver_net
    extra_hosts:
      - "tazmenworld:192.168.1.100"

networks:
  autoserver_net:
    name: autoserver_net
    driver: bridge

Le extra_hosts permet d’appeler http://tazmenworld:11434 depuis les workflows n8n au lieu d’une IP brute : plus lisible, et ça survit à un changement d’IP sans tout recâbler.

Fix permissions du volume (indispensable)

n8n tourne dans son container sous l’utilisateur node (UID 1000). Si le dossier data appartient à root, il ne peut pas écrire et crashe en boucle dès le démarrage sans message clair.

bash

sudo chown -R 1000:1000 /opt/autoserver/n8n/data

Autoriser Docker à sortir sur internet (UFW)

Par défaut, UFW bloque le forwarding des containers. n8n démarre correctement, mais tout appel HTTP externe échoue en silence : les workflows ne peuvent pas joindre d’API extérieure.

bash

sudo nano /etc/default/ufw
# Changer cette ligne :
# DEFAULT_FORWARD_POLICY="DROP"  →  DEFAULT_FORWARD_POLICY="ACCEPT"

sudo ufw reload

Lancer n8n

bash

cd /opt/autoserver/n8n
docker compose up -d
docker compose logs -f     # Ctrl+C pour quitter

Quand tu vois n8n ready on ::, port 5678, l’interface est accessible depuis tazmenworld via http://192.168.1.20:5678.

7. Hermes Agent : l’IA qui décide seule

C’est la brique qui fait passer le setup d’un serveur d’automatisation classique à un agent IA autonome. Hermes Agent est un projet open-source de Nous Research (licence MIT) : mémoire persistante entre les sessions, génération de ses propres skills, terminal sandboxé sous Docker, et gateway Telegram intégré. Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif et se débrouille.

Installation

bash

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Le script gère tout : Python 3.11, Node.js 22, ripgrep, ffmpeg. Il lance ensuite automatiquement le wizard de configuration.

Prérequis : internet doit être accessible depuis autoserver. Si curl -I https://github.com répond No route to host, tu as un problème de passerelle dans Netplan. Voir la section sur l’IP statique.

Configuration via le wizard

Les choix qui importent :

Configurer le bot Telegram

1. Ouvre Telegram, cherche @BotFather → /newbot
2. Donne un nom et un identifiant à ton bot
3. Récupère le token : 123456789:AAH-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4. Cherche @userinfobot → note ton User ID numérique
5. Renseigne le token et l’User ID dans le wizard
6. Réponds Y pour le Home Channel (DM direct avec le bot)
7. Réponds Y pour installer comme service en arrière-plan

Activer le linger : le détail qui rend le setup vraiment autonome

Le gateway Telegram tourne en user service systemd. Sans cette configuration, il ne démarre pas au boot si aucune session utilisateur n’est ouverte. Résultat : après une coupure de courant à 3h du matin, ton agent reste silencieux jusqu’à ce que quelqu’un se connecte en SSH.

bash

sudo loginctl enable-linger <votre_user>

# Vérifier
loginctl show-user <votre_user> | grep Linger
# Attendu : Linger=yes

Une fois activé, le serveur peut redémarrer seul : le gateway Telegram revient en ligne sans intervention de ta part.

Vérification et commandes utiles

bash

# Statut du gateway
systemctl --user status hermes-gateway

# Test CLI interactif
source ~/.bashrc
hermes
> Bonjour, que peux-tu faire sur ce serveur ?

# Changer de modèle à chaud, sans redémarrage
hermes setup model

# Mettre à jour
hermes update

# Diagnostic complet
hermes doctor

8. Intégration avec la stack de tazmenworld

Depuis n8n ou Hermes sur autoserver, tous les services de tazmenworld sont accessibles directement par IP locale :

Ollama        → http://192.168.1.100:11434
Open WebUI    → http://192.168.1.100:3000
ComfyUI       → http://192.168.1.100:8188
SearXNG       → http://192.168.1.100:8080
n8n principal → http://192.168.1.100:5678

Pour centraliser ça proprement :

bash

nano /opt/autoserver/.env.global

env

TAZMENWORLD_IP=192.168.1.100
AUTOSERVER_IP=192.168.1.20

OLLAMA_URL=http://192.168.1.100:11434
OPENWEBUI_URL=http://192.168.1.100:3000
COMFYUI_URL=http://192.168.1.100:8188
SEARXNG_URL=http://192.168.1.100:8080
N8N_TAZMEN_URL=http://192.168.1.100:5678

OPENROUTER_BASE_URL=https://openrouter.ai/api/v1
OPENROUTER_API_KEY=sk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Et les deux instances n8n peuvent se parler : depuis autoserver, un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<ton-webhook-id> déclenche un workflow sur tazmenworld. Les deux instances bossent ensemble.

9. Hermes en action : la démo Telegram

Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif en langage naturel et se débrouille pour l’atteindre. Sa mémoire persistante lui permet de se souvenir des échanges précédents et d’ajuster son comportement au fil du temps.

Exemple concret, hier soir depuis le téléphone :

Moi :    Fais une veille sur les modèles open-weight sortis cette semaine.
         Résume les 5 plus intéressants en 3 lignes chacun et dépose
         le résumé dans /shared/veille.md

Hermes : Je lance les recherches. Je te préviens quand c'est déposé.

[quelques minutes plus tard]

Hermes : ✅ Résumé déposé dans /shared/veille.md, 5 modèles couverts.

Le fichier était là le matin. Je n’avais pas rouvert l’app entre les deux messages.

Ce qui rend ça possible, c’est le linger activé plus haut. L’agent tourne en fond, il n’a pas besoin que tu sois connecté en SSH, il n’attend pas que l’écran soit allumé. Il fait son boulot, prévient, et attend le prochain ordre.

10. Les trois pièges que j’ai rencontrés

Piège 1 : La passerelle réseau qu’on suppose à tort

En configurant l’IP statique, j’ai mis 192.168.1.1 comme passerelle sans vérifier. Résultat : ping local OK, accès internet mort. Impossible d’installer Hermes : curl -I https://github.com répondait No route to host.

La règle : ne jamais supposer l’IP de la passerelle. La vérifier en amont avec ip route | grep default sur une machine qui marche, reporter la vraie valeur dans Netplan. Vingt secondes de vérification qui évitent une heure de debug.

Piège 2 : Les permissions Docker sur trois fronts

Trois problèmes distincts, tous liés aux permissions, tous bloquants à leur façon.

Le groupe docker ne s’active pas immédiatement. Après usermod -aG docker, sur une install minimized newgrp n’est pas disponible. Le groupe ne prend effet qu’après déconnexion/reconnexion, sans message d’erreur explicite, juste un permission denied sur docker run.

n8n crashe en boucle au démarrage. Le container tourne sous l’UID 1000 (node). Si le dossier data appartient à root, n8n ne peut pas écrire et redémarre toutes les trente secondes. Fix : sudo chown -R 1000:1000 /opt/autoserver/n8n/data. C’est la première chose à faire avant de lancer le container.

n8n ne sort pas sur internet. UFW bloque par défaut le forwarding des containers. Les workflows se déclenchent, mais tout appel HTTP externe échoue en silence. Fix : passer DEFAULT_FORWARD_POLICY de "DROP" à "ACCEPT" dans /etc/default/ufw, puis sudo ufw reload.

Piège 3 : Le cookie n8n qui bloque la connexion

Tu ouvres l’interface, tu entres tes identifiants, ça ne passe pas. Aucun message d’erreur clair. n8n exige par défaut un cookie sécurisé qui ne fonctionne qu’en HTTPS. En HTTP sur le réseau local, c’est l’impasse.

Une ligne dans le .env règle l’affaire :

env

N8N_SECURE_COOKIE=false

Redémarre le container, l’interface s’ouvre. À ne configurer qu’en local sur un réseau de confiance. Dès qu’on expose vers l’extérieur, on passe par un reverse proxy HTTPS.

11. Ce qu’on peut faire avec

Le setup une fois en place, voilà ce qui tourne concrètement.

Veille techno automatique. Chaque matin à 7h, n8n déclenche une recherche via SearXNG sur tazmenworld, envoie les résultats à l’agent, et m’expédie un digest propre sur Telegram. J’ouvre le téléphone au réveil avec un résumé au lieu de vingt onglets à scroller.

Tâches longues en arrière-plan. Je donne un objectif à Hermes le soir (un comparatif de solutions, une analyse de logs, une rédaction), il découpe, cherche, rédige, et dépose le fichier dans /shared/. Au matin, c’est prêt. Le « pendant que tu dors » du titre, c’est littéralement ça.

Délégation au GPU. L’agent reçoit une demande de génération d’image, mais le N150 n’a pas de GPU sérieux. Pas de souci : il envoie le job à ComfyUI sur tazmenworld via http://192.168.1.100:8188, récupère le résultat, me le renvoie. Le control plan décide, le compute exécute.

Webhooks inter-machines. Un workflow sur autoserver peut déclencher un workflow sur le n8n de tazmenworld via un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<id>. Les deux instances se parlent sans passer par internet.

Sauvegarde automatique à 3h du matin. Un cron sauvegarde les volumes Docker et garde les 7 dernières copies. Un alias as-status donne en deux secondes l’état des containers, la RAM, le disque, et la connectivité vers tazmenworld. Le serveur se surveille tout seul.

Conclusion

Il y a six mois, monter ce genre de setup demandait une connaissance pointue de Docker, des agents IA, et du self-hosting Linux. Aujourd’hui, l’installation tient en une soirée, et le résultat c’est un control plan IA permanent sur ton réseau local, piloté depuis ton téléphone, qui bosse sans te demander la permission.

Le Mac mini n’est pas mauvais. Il est juste disproportionné pour ce rôle. Et le vrai problème d’un VPS, ce n’est pas le prix : c’est qu’il ne voit pas ton réseau local. Un agent IA qui ne peut pas parler à tes services, c’est un outil à moitié aveugle.

Le mini PC à 130€ règle les deux problèmes : il est sur ton LAN, il est sobre, il ne s’arrête pas. Le calcul lourd, il a juste à savoir l’adresse de ta vraie machine pour le déléguer. C’est la même logique qu’on applique partout ici : ne pas gâcher la ressource, mettre le bon outil au bon endroit.

Matériel : MLLSE G2 Pro (Intel N150, 12 Go LPDDR5, 512 Go SSD). Stack : Ubuntu Server 26.04 LTS, Docker, n8n, Hermes Agent (Nous Research, licence MIT), DeepSeek V4 via OpenRouter. Les tokens, clés API et mots de passe dans les exemples sont des espaces réservés, génère les tiens avec les commandes indiquées.