L’expérience de sécurité IA de Zero
Dans une récente vidéo tech japonaise, le créateur Zero Noichi a mené une expérience fascinante : il a utilisé deux ordinateurs ZimaBoard 2 pour simuler une bataille de cybersécurité entre un défenseur IA et un attaquant IA. Une machine hébergeait un système de gestion client interne vulnérable, tandis que l’autre tentait de le pirater à l’aide d’un agent IA autonome. Le défenseur, également piloté par IA, surveillait, enquêtait, patchait et bloquait en continu les activités suspectes en temps réel.
En tant que ZimaSpace, nous remercions la chaîne de Zero d’avoir mis en avant ZimaBoard 2 dans une démonstration de cybersécurité aussi créative et stimulante. Cet article transforme la transcription vidéo en un billet de blog structuré en anglais pour les lecteurs intéressés par les serveurs homelab, agents IA, cybersécurité, laboratoires Docker et infrastructures auto-hébergées.
Note importante : Le créateur original précise clairement que l’expérience a été réalisée à des fins de divertissement et d’éducation. Certains tableaux de bord, états de service et vulnérabilités ont été intentionnellement dramatisés ou laissés exposés pour la démonstration. Cet article conserve les concepts techniques, les données et le déroulement de l’expérience, mais évite de fournir des instructions offensives exploitables.
Pourquoi cette expérience est importante maintenant
La question clé derrière la vidéo est simple : que se passe-t-il lorsque des agents IA peuvent continuer à attaquer et défendre sans se fatiguer ?
Zero ouvre la vidéo en présentant un sujet que de nombreux spectateurs japonais attendaient : une bataille simulée équipe de sécurité vs équipe de hackers utilisant deux ordinateurs. Les machines utilisées dans l’expérience étaient des appareils ZimaBoard 2 — des ordinateurs x86 compacts adaptés pour exécuter des services, agents, tableaux de bord et charges serveur légères.
L’inspiration vient des discussions récentes autour des agents de sécurité IA avancés, y compris des systèmes capables d’inspecter des logiciels, d’identifier des vulnérabilités, de valider si ces vulnérabilités sont exploitables, puis de proposer ou appliquer des correctifs. Zero décrit cela comme quelque chose qui pourrait remodeler le concept même de cybersécurité.
Son objectif n’était pas de reproduire exactement un système propriétaire réel. Au lieu de cela, il a construit une expérience imaginaire pour prévisualiser l’idée plus large :
« L’IA peut déjà agir à la fois comme un hacker et un défenseur à ce niveau. »
Cette seule idée anime toute la vidéo.
Le matériel : Deux appareils ZimaBoard 2 comme stations de combat IA
Pour l'expérience, Zero a utilisé deux ordinateurs ZimaBoard 2. L'un a été assigné au rôle de défenseur, l'autre est devenu l'attaquant.
ZimaBoard 2 est bien adapté à ce type de laboratoire pratique car il est petit, silencieux, basé sur x86 et conçu pour des services 24/7.
Du point de vue de ZimaSpace, c'est précisément là que ZimaBoard 2 excelle. Il est conçu pour les utilisateurs qui souhaitent exécuter de véritables charges de travail à domicile ou en laboratoire, notamment :
- Serveurs multimédias Plex
- Filtrage réseau Pi-hole
- Virtualisation Proxmox
- Configurations Debian ou TrueNAS
- Routage pfSense
- Laboratoires Docker
- Conteneurs IA
- Services de sauvegarde
- Clusters de laboratoire à domicile
- Environnements de développement légers
Le design matériel du produit est également pertinent pour l'expérience. ZimaBoard 2 inclut un support natif SATA et PCIe, ce qui signifie que les utilisateurs peuvent brancher des disques durs ou SSD 2,5 pouces, ajouter une carte réseau 10G, utiliser un adaptateur NVMe ou étendre l'appareil pour des besoins personnels de stockage et de réseau. Le double Ethernet 2,5G le rend aussi attractif pour un NAS local rapide, un accès distant à faible latence et un routage domestique multi-services.
Comme le montre la vidéo de Zero, ce type d'appareil compact peut devenir bien plus qu'un « mini-ordinateur ». Il peut devenir une plateforme pratique pour l'IA, le réseautage, l'auto-hébergement et l'apprentissage de la cybersécurité.

IA conversationnelle vs agents IA : le concept derrière le test
Zero prend le temps d'expliquer la différence entre une IA conversationnelle ordinaire et les agents IA.
Une IA conversationnelle standard — comme ChatGPT ou Gemini — est principalement conversationnelle. Vous posez une question, elle répond. Elle peut être très intelligente, mais elle ne continue généralement pas à travailler vers un objectif de manière autonome.
Un agent IA est différent. Un agent IA reçoit un objectif, le décompose en tâches, boucle à travers les actions, vérifie les progrès et continue jusqu'à ce que la tâche soit accomplie. Dans la vidéo, Zero le décrit comme un système qui continue de travailler jusqu'à atteindre l'objectif.
Les termes techniques utilisés dans cette partie incluent :
- IA conversationnelle : un système d'IA qui répond sous forme de conversation.
- Agent IA : un système d'IA qui peut enchaîner des tâches vers un objectif défini.
- Agent autonome : un agent capable d'agir avec moins d'intervention humaine directe.
- Boucle d'objectif : le cycle répété de planification, d'action, de vérification et d'amélioration.
Zero note que beaucoup de ses vidéos précédentes se concentraient sur les agents IA. Un exemple qu'il mentionne est un système d'IA qui enquête sur un NAS et organise les fichiers. Une autre expérience précédente utilisait un ordinateur à carte unique pour créer une IA autonome sans objectif clairement défini.
Ce concept d'IA autonome antérieur est devenu la base de cette nouvelle expérience.
Réinventer la sécurité IA : Défenseur contre Attaquant
L'expérience transforme la cybersécurité en un concours en direct entre deux systèmes IA fonctionnant en continu.
Zero explique l'IA défensive en utilisant une analogie avec une maison. Imaginez un service comme une maison contenant une clé importante. S'il y a une grande porte ouverte, un attaquant peut simplement entrer et prendre la clé. Dans ce cas, l'IA défenseur doit identifier le problème, tester si l'ouverture est dangereuse et la fermer.
Mais toutes les ouvertures ne peuvent pas être complètement fermées. Zero donne l'exemple d'un trou d'inspection de 10 cm. Ce trou peut être nécessaire à l'administrateur pour vérifier si la clé est toujours là. Le fermer briserait une fonction légitime. L'IA doit donc raisonner plus prudemment :
- Le trou est-il réellement dangereux ?
- Un attaquant pourrait-il l'exploiter avec un outil ?
- Le système peut-il préserver la visibilité tout en bloquant l'intrusion ?
- Quelle défense fonctionne le mieux ?
- La correction peut-elle être testée contre l'attaque imaginée ?
Dans l'analogie, la solution finale pourrait être une grille solide : personne ne peut entrer, mais l'administrateur peut toujours voir à travers.
Voici l'idée centrale de l'IA défensive dans la vidéo : non seulement trouver les faiblesses, mais les vérifier, tester les attaques possibles et appliquer des contre-mesures.

Construction de l'environnement de test
Zero a ensuite créé un service commercial fictif pour l'expérience. Le service agissait comme un système interne de gestion client, similaire à un CRM.
Le système comprenait plusieurs fonctionnalités commerciales réalistes:
- Dossiers clients
- Informations sur les affaires ou projets
- Tickets de support
- Listes de contrats
- Notes internes
- Journaux d'activité
- Fonctionnalité de recherche
- Un blog public
- Gestion des utilisateurs
- Informations internes sensibles, y compris des clés API intentionnellement exposées pour la démonstration
Il explique que de nombreuses entreprises disposent d'outils de gestion internes similaires. Si un tel système est compromis, les données clients, les notes internes, le contenu du blog, les permissions des utilisateurs et les enregistrements opérationnels pourraient être affectés.
Cela rendait l'environnement de test suffisamment réaliste pour montrer pourquoi la défense pilotée par l'IA peut être importante pour les systèmes d'entreprise quotidiens.
Le tableau de bord du défenseur a été intentionnellement conçu de manière visuellement dramatique et cyberpunk pour la vidéo. Il affichait le statut des services, les alertes, les actions de récupération, les notifications de falsification et plusieurs agents travaillant simultanément. Zero mentionne que jusqu'à environ cinq agents IA pouvaient opérer ensemble du côté défenseur.
Le système attaquant était également contrôlé par un flux de travail de type agent, essayant continuellement différentes voies pour trouver une entrée.
Pourquoi ZimaBoard 2 convient à ce type de scénario homelab IA
Un projet comme celui-ci nécessite une plateforme serveur compacte capable de fonctionner en continu, de gérer différentes piles logicielles et de supporter des expériences réseau. C'est pourquoi ZimaBoard 2 est un choix naturel.
Pour les créateurs DIY et les passionnés de technologie, ZimaBoard 2 peut agir comme un mini serveur qui semble simple mais exécute des charges sérieuses.
Le positionnement original du produit correspond particulièrement bien à la vidéo :
« Petit, hackable et plutôt mignon. Beaucoup l'appellent un mini serveur qui ressemble à un jouet mais fonctionne comme une bête. »
Avec ZimaBoard 2, les utilisateurs peuvent tester des systèmes d'exploitation tels que ZimaOS, TrueNAS, Proxmox, Debian et pfSense. Ils peuvent exécuter des conteneurs Docker, des services auto-hébergés, des serveurs médias, des systèmes de stockage et des expériences IA. Dans cette vidéo, la carte devient un cyber range compact — un environnement contrôlé pour observer comment des agents IA pourraient se comporter dans des simulations d'attaque et de défense.
Pour les lecteurs intéressés par la construction d'un homelab, ZimaBoard 2 offre plusieurs avantages :
- Faible consommation d'énergie pour un fonctionnement 24/7
- Performance silencieuse et fraîche
- Double Ethernet 2,5G pour les charges réseau
- SATA natif pour l'extension de stockage
- Support PCIe pour cartes réseau, GPU ou adaptateurs NVMe
- Compatibilité avec plusieurs systèmes d'exploitation serveur
- Un format compact qui s'adapte aux petits espaces de travail
C'est pourquoi un homelab ZimaBoard 2 peut supporter non seulement le stockage et le streaming média, mais aussi des expériences pratiques en automatisation IA et surveillance en cybersécurité.
Lancement du Défenseur en Premier
Zero explique que, dans le monde réel, la défense devrait idéalement être prête avant que les outils d'attaque ne se répandent. Il fait référence à l'idée que les gouvernements et les organisations pourraient vouloir renforcer les banques, les services et les infrastructures avant que des systèmes d'IA puissants ne deviennent généralement accessibles.
Dans la vidéo, il lance d'abord le défenseur.
Le défenseur commence par inspecter le service, vérifier les problèmes et tenter de réparer ce qui peut l'être. Au début, aucune attaque visible n'est détectée. Le service continue de fonctionner normalement.
Après environ une minute et demie, Zero décide que l'attaquant doit débuter. Il note que si le défenseur dispose de trop de temps pour se préparer, la vidéo pourrait devenir moins équilibrée. Il souhaite que la simulation ressemble à un monde où les attaquants apparaissent avant que les défenseurs n'aient complètement terminé leur travail.
Puis l'attaquant commence.

Le début de l’attaque : sondage continu
Une fois que l’attaquant commence, le nombre de tentatives augmente rapidement. Zero observe le compteur grimper à partir de la trentaine alors que l’IA attaquante teste différents points d’entrée possibles.
L’attaquant essaie de nombreuses méthodes générales car il n’a pas reçu de détails complets sur le service cible. Zero explique que si l’attaquant disposait de plus d’informations spécifiques, il concentrerait probablement ses efforts plus efficacement. Mais dans cette expérience, l’attaquant sonde largement tout ce qui semble plausible.
Les termes techniques apparaissant dans cette section incluent :
- API : une interface qui permet à un logiciel d’envoyer des commandes ou des requêtes à un service.
- SQL : un langage de requête de base de données souvent associé à l’accès aux bases et aux risques d’injection.
- JWT : JSON Web Token, un format de jeton couramment utilisé pour l’authentification.
- GraphQL : un langage de requête API utilisé pour demander des données structurées.
- Point de terminaison administrateur : une URL ou une route API destinée aux fonctions administratives.
Zero souligne pourquoi l’IA change la donne :
« Jusqu’à présent, c’était mécanique. Maintenant, c’est de l’IA, et c’est effrayant. »
L’IA peut raisonner, varier ses tentatives et tester des schémas avec aléa. Cela rend le comportement moins statique qu’un script et plus comme un opérateur adaptatif.
Le défenseur détecte l’attaquant
Au début, le tableau de bord du défenseur reste calme. Puis, l’attaquant découvre des zones exposées, y compris des chemins intentionnellement vulnérables. Zero voit des découvertes liées à l’exposition du contrôle de source, des aperçus d’API, des fuites de données GraphQL et des clés API.
Bientôt, le défenseur commence à réagir.
Un des moments les plus importants de la vidéo est lorsque le défenseur identifie l’IP de l’attaquant et commence à enquêter sur l’activité.
L’agent défensif détecte des schémas d’accès suspects. Il semble remarquer des tentatives contre les API administratives et un comportement possible lié aux JWT. Le système commence à signaler des alertes, des journaux d’investigation et des actions défensives.
Zero décrit la scène comme les deux camps qui « se battent » enfin.
Le défenseur prend également des mesures pratiques. Un exemple est la désactivation ou le verrouillage du compte administrateur prévisible. Zero teste cela manuellement plus tard en essayant un schéma de connexion administrateur courant et confirme que le compte a été verrouillé, avec la raison affichée.
Cela illustre un principe défensif clé : les comptes privilégiés prévisibles sont dangereux et doivent être protégés, renommés, désactivés ou renforcés.
Arrêt et récupération du service
Un autre moment dramatique survient lorsque le service tombe.
Zero remarque que le tableau de bord signale un problème critique impliquant des mots de passe d'utilisateurs généraux stockés en clair dans une base SQL, ce qui signifie qu'ils ont été sauvegardés sans chiffrement. Le service semble s'arrêter temporairement.
Il interprète cela comme une action défensive délibérée. En d'autres termes, le défenseur a peut-être mis le service hors ligne pour éviter une exposition supplémentaire tout en appliquant des modifications.
Puis le service redémarre.
Zero confirme que l'écran de connexion est à nouveau accessible. Le tableau de bord indique qu'une défense a été appliquée. Il n'explique pas tous les détails techniques, mais résume qu'une vulnérabilité a été trouvée et corrigée.
Ce moment montre un compromis pratique en cybersécurité : parfois, une interruption temporaire est plus sûre que de laisser un service vulnérable en ligne.
Pour les entreprises réelles, c'est pourquoi la planification de la réponse aux incidents est importante. Un système ne doit pas seulement détecter les problèmes, mais aussi savoir quand isoler, corriger, redémarrer ou restaurer les services.
Les chiffres : tentatives, découvertes et coût de l'IA
La vidéo inclut plusieurs points de données utiles issus de l'expérience :
- L'attaquant a effectué environ 1 000 tentatives d'attaque.
- Environ 5 zones sensibles qui n'auraient pas dû être exposées ont été découvertes.
- Le défenseur a signalé environ 3 alertes ou rapports à un moment donné.
- L'expérience a duré assez longtemps pour que les deux parties entrent dans un cycle d'aller-retour.
- Zero avait facturé environ 4 000 yens pour l'utilisation de l'IA, mais le budget a été rapidement consommé.
- Il note qu'il a utilisé un modèle relativement performant, ce qui a augmenté le coût.
- Plusieurs processus d'IA fonctionnaient rapidement, le commentaire final suggérant que de nombreux agents étaient actifs à grande vitesse.
La leçon pratique la plus mémorable est peut-être le coût. Même en utilisant une option d'IA moins coûteuse, les boucles continues d'agents peuvent consommer les crédits très rapidement.
Zero arrête l'expérience lorsque les demandes de l'IA dépassent le budget.
« L'argent est épuisé. »
Cette phrase capture une des réalités souvent négligées des systèmes d'IA autonomes : l'autonomie est puissante, mais le raisonnement continu peut devenir coûteux.

Ce que l'expérience a prouvé
La principale leçon est que la cybersécurité pilotée par l'IA peut devenir un concours en temps réel de découverte, défense, adaptation et coût.
Zero conclut que l'expérience est devenue une sorte de jeu du chat et de la souris. L'attaquant trouvait des failles, le défenseur réagissait, et les deux systèmes continuaient à fonctionner à grande vitesse.
Il fait aussi un point plus large : les humains seuls pourraient ne pas être capables de suivre ce rythme. Si les attaquants utilisent l'IA pour automatiser les tentatives de sondage et d'exploitation, les défenseurs pourraient également avoir besoin de systèmes de surveillance, de correction et de réponse assistés par IA.
Cependant, il souligne aussi que le monde actuel voit plus d’expérimentations d’IA du côté des attaquants que de systèmes du côté des défenseurs. Les attaquants peuvent apparaître en grand nombre, pas seulement un à la fois. Dans la vidéo, un seul attaquant a produit environ 1 000 tentatives. Si cela devenait 100 ou 1 000 attaquants, l’échelle changerait radicalement.
Cette observation est l’un des points forts de la vidéo. La cybersécurité ne concerne pas seulement un attaquant intelligent. Il s’agit de volume, d’automatisation, de persistance et d’asymétrie.
Leçons sûres pour les utilisateurs et constructeurs de homelab
Bien que la vidéo soit divertissante, elle offre aussi des leçons pratiques pour toute personne gérant un homelab, un NAS, un service auto-hébergé ou un serveur pour petite entreprise.
Un homelab ZimaBoard 2 est un excellent endroit pour apprendre ces leçons en toute sécurité dans un environnement contrôlé.
Voici les points clés sûrs et défensifs :
-
Ne exposez pas de services inutiles
Si un point d’entrée n’a pas besoin d’être public, gardez-le fermé. -
Évitez les comptes administrateurs prévisibles
Les noms d’utilisateur administrateur par défaut ou évidents créent un risque inutile. -
Ne stockez jamais les mots de passe en clair
Les mots de passe doivent être hachés de manière sécurisée, pas stockés en texte lisible. -
Protégez soigneusement les routes API
Les API deviennent souvent des cibles de grande valeur car elles peuvent modifier les utilisateurs, les données ou les paramètres. -
Surveillez les journaux en continu
Les journaux d’activité peuvent révéler des sondages, des échecs répétés, des accès inhabituels et des automatisations suspectes. -
Utilisez la segmentation
Gardez les services expérimentaux séparés des systèmes de production importants. -
Ayez un plan de récupération
Redémarrer, isoler ou revenir en arrière sur un service doit être planifié avant qu’un incident ne survienne. -
Prévoyez un budget pour les charges de travail IA
Les boucles d’IA autonomes peuvent consommer des jetons et des crédits plus rapidement que prévu. -
Utilisez les laboratoires de manière responsable
Les expériences de sécurité doivent être réalisées uniquement sur des systèmes que vous possédez ou que vous êtes autorisé à tester.
Ce sont des leçons pratiques pour toute personne gérant des laboratoires Docker, des nœuds Proxmox, des systèmes NAS personnels ou des conteneurs IA sur ZimaBoard 2.
Pourquoi c’est un cas d’usage fort pour les utilisateurs de ZimaSpace
Les appareils ZimaSpace sont conçus pour les utilisateurs qui aiment construire, tester, casser, réparer et apprendre. Cette vidéo correspond parfaitement à cette culture.
ZimaBoard 2 n’est pas seulement une carte pour le stockage ou le streaming média ; c’est une plateforme x86 flexible pour la curiosité technique réelle.
Par exemple, les utilisateurs peuvent créer :
- Un pare-feu domestique avec pfSense
- Un NAS personnel avec TrueNAS ou ZimaOS
- Un laboratoire de services basé sur Docker
- Un environnement local de test d’agents IA
- Un serveur Plex
- Un nœud de filtrage DNS Pi-hole
- Un mini hôte de virtualisation Proxmox
- Un bac à sable de développement privé
- Un petit laboratoire de surveillance en cybersécurité
Parce que ZimaBoard 2 supporte le SATA natif, l’extension PCIe et le double Ethernet 2,5G, il peut évoluer avec les idées de l’utilisateur. Vous voulez du stockage local ? Ajoutez des SSD. Vous voulez un réseau plus rapide ? Ajoutez une carte réseau 10G. Vous voulez expérimenter l’accélération IA ou le stockage NVMe ? Utilisez l’extension PCIe.
C’est la valeur d’un serveur domestique x86 compact : il offre aux créateurs et développeurs un terrain de jeu physique pour l’informatique moderne.
La vision d’ensemble : l’IA transformera les deux côtés de la sécurité
Zero termine la vidéo en réfléchissant à l’avenir. Si des systèmes IA puissants deviennent largement accessibles, certaines personnes en feront un mauvais usage. Les cibles pourraient se trouver partout dans le monde. La meilleure réponse est de comprendre le risque, protéger ce qui peut l’être et reconnaître que les outils défensifs continueront aussi à s’améliorer.
Il ajoute aussi une note très humaine :
« Les humains doivent rester en bonne santé. La santé est importante. »
C’est une fin drôle et réaliste après une bataille IA rapide et intense.
Le message plus large est clair : la sécurité IA évolue rapidement. Les attaquants peuvent utiliser l’automatisation, mais les défenseurs aussi. La question est de savoir si les individus, les entreprises et les créateurs sont prêts à tester, comprendre et sécuriser leurs systèmes avant que les problèmes ne surviennent.
Le rôle de ZimaBoard 2 dans la sécurité assistée par IA
L’expérience de Zero utilisant deux appareils ZimaBoard 2 offre un aperçu passionnant de l’avenir de la cybersécurité assistée par IA. Une carte jouait le rôle de défenseur, inspectant et renforçant continuellement un service CRM simulé. L’autre jouait l’attaquant, générant environ 1 000 tentatives de sondage et découvrant plusieurs zones sensibles intentionnellement exposées. Le défenseur détectait l’activité, bloquait les comptes à risque, appliquait des correctifs et semblait même mettre temporairement le service hors ligne pour le protéger.
Pour ZimaSpace, c’est un parfait exemple de ce qui rend les appareils x86 compacts précieux. Une carte petite, silencieuse et à faible consommation peut devenir un serveur multimédia, un NAS, un routeur, un hôte Docker, une plateforme de conteneurs IA ou un laboratoire de cybersécurité.
Si vous êtes un bricoleur, un passionné de homelab, un développeur ou un apprenant en sécurité, ZimaBoard 2 vous offre une plateforme pratique pour explorer l’avenir de l’auto-hébergement et de l’automatisation pilotée par l’IA—de manière sûre, responsable et créative.
Encore une fois, merci à la chaîne de Zero pour cette démonstration imaginative et pour montrer tout ce qui peut être fait avec du matériel compact, des agents IA et un esprit expérimental fort.
Centre de campagne Zima
À lire aussi

IA locale sur le ZimaCube 2 — Extension PCIe, Ollama et pérennisation de votre homelab
Le ZimaCube 2 est livré avec 4 emplacements NVMe, un slot d'extension PCIe et de la RAM DDR5 — prêt à l'emploi pour Ollama,...

Guide de surveillance du laboratoire domestique ZimaCube : de Uptime Kuma aux agents IA
Surveillez votre serveur domestique avec Uptime Kuma, Pulse, Proxmox Data Center Manager ou un agent IA pour suivre le temps de fonctionnement, les sauvegardes,...

De Sparcstation à ZimaBlade : le parcours d’auto-hébergement d’un geek de 57 ans
Un professionnel administratif français a remplacé son Raspberry Pi 4 défaillant par un ZimaBlade 7700, fonctionnant sous Debian 13, XFS et BorgBackup. La construction...

