Vous en avez marre de jongler entre différents clients VPN selon vos appareils ?

Alors ça tombe bien puisque je viens de tomber sur TailGuard , un projet open source qui est une application Docker, mise au point par un certain Juho Vähä-Herttua qui sert de passerelle entre WireGuard et Tailscale .

Si vous n’avez jamais entendu parler de ces deux technologies, laissez-moi vous faire un petit récap rapide… WireGuard, c’est LE protocole VPN moderne ultra-rapide dans le vent, et Tailscale, c’est LA solution mesh VPN qui fait un carton en ce moment.

Et le truc chouette avec TailGuard, c’est qu’il résout ce casse-tête des appareils qui ne peuvent pas faire tourner Tailscale nativement. Vous savez, ces vieux routeurs, ces IoT un peu bizarres ou ces environnements restreints où installer un client VPN moderne c’est plus compliqué que d’avoir un Premier Ministre décent. Mais avec TailGuard, vous créez ainsi un pont entre votre infrastructure WireGuard existante et le réseau mesh de Tailscale. Pas besoin de tout refaire de zéro, c’est plutôt bien pensé.

Alors, comment ça marche ?

Et bien en gros, vous avez un serveur WireGuard qui tourne quelque part, avec ses configurations et ses clés et TailGuard, lui, vient se greffer dessus via Docker et expose automatiquement vos sous-réseaux WireGuard sur Tailscale. Du coup, tous vos appareils Tailscale peuvent accéder à vos ressources WireGuard, et inversement. C’est du routage bidirectionnel automatique, avec support IPv4 et IPv6.

Pour l’installation, c’est un jeu d’enfant. Vous téléchargez votre config WireGuard client, vous la sauvegardez en wg0.conf, vous créez un réseau IPv6 Docker et vous lancez le container avec les bons volumes.

docker network create --ipv6 ip6net
docker run -it \
 -v ./wg0.conf:/etc/wireguard/wg0.conf -v ./state:/tailguard/state \
 --cap-add NET_ADMIN --device /dev/net/tun \
 --sysctl net.ipv4.ip_forward=1 --sysctl net.ipv6.conf.all.forwarding=1 \
 --sysctl net.ipv4.conf.all.src_valid_mark=1 \
 --network ip6net -p 41641:41641/udp \
 --name tailguard juhovh/tailguard:latest

Vous saviez que Claude d’Anthropic avait lancé sa fonction Computer Use et OpenAI son Operator ? Eh bien, pendant que ces géants se livrent une bataille sans merci, un projet open source du nom de ByteBot propose de faire tourner un agent IA autonome sur votre machine. Le tout, avec une approche qui devrait rassurer les plus paranoïaques d’entre nous puisque tout se déroule dans Docker.

Le concept c’est qu’au lieu d’accorder un accès direct à votre système à une IA (ce qui pourrait rapidement virer au cauchemar), ByteBot fait tourner un Ubuntu 22.04 complet avec environnement graphique XFCE dans un conteneur. Ainsi, l’IA peut interagir avec cet environnement isolé via VNC et WebSockets, capturer des images d’écran, cliquer, taper du texte… En somme, elle peut faire tout ce que vous feriez, mais dans sa petite bulle sécurisée.

Il faut donc lui donner vos instructions en langage naturel… par exemple, vous pouvez lui demander de créer un nouveau repository GitHub ou de rechercher des informations spécifiques sur le web. ByteBot analyse alors votre demande, la décompose en étapes et se met au boulot. Il peut même naviguer sur le web, remplir des formulaires, gérer des mots de passe (stockés de manière sécurisée), et bien sûr exécuter des scripts bash ou Python.

Le truc cool, c’est également le mode “takeover”. Si jamais ByteBot galère sur une tâche ou que vous voulez reprendre la main, vous pouvez directement prendre le contrôle du desktop virtuel. C’est comme faire du pair programming avec une IA, sauf que c’est vous qui corrigez ses bêtises au lieu de l’inverse. Et une fois que vous avez montré comment faire, ByteBot apprend et peut reproduire la tâche plus tard.

Pour l’installer, plusieurs options s’offrent à vous. La plus simple reste Docker Compose. Vous clonez le repo, vous créez un fichier .env avec votre clé API (Anthropic, OpenAI ou Google Gemini au choix), et vous lancez le tout avec un docker-compose up. ByteBot se charge de builder les images, de configurer le réseau bridge pour l’isolation, et de monter les volumes persistants pour garder vos données entre les sessions.

git clone https://github.com/bytebot-ai/bytebot.git
cd bytebot
# Ajoutez votre clé de fournisseur d'IA (choisissez-en une)
echo "ANTHROPIC_API_KEY=sk-ant-..." > docker/.env
# Ou : echo "OPENAI_API_KEY=sk-..." > docker/.env
# Ou : echo "GEMINI_API_KEY=..." > docker/.env
docker-compose -f docker/docker-compose.yml up -d
# Ouvrez http://localhost:9992

Pour les amateurs de Kubernetes, des charts Helm sont également disponibles. Et si vous voulez tester sans vous prendre la tête, Railway propose aussi un déploiement en un clic. Mais franchement, pour un usage perso, Docker Compose fera parfaitement le job.

L’architecture technique est d’ailleus plutôt bien foutue puisque le backend Python gère la communication avec les LLMs et l’orchestration des tâches. Et le frontend React vous donne une interface web pour interagir avec ByteBot et voir ce qu’il fabrique en temps réel. Le tout communique via WebSockets pour une latence minimale. Et le conteneur desktop tourne avec un serveur VNC modifié qui permet à ByteBot de capturer l’écran et d’envoyer des événements souris/clavier.

Ce qui distingue vraiment ByteBot des solutions cloud comme Claude Computer Use, c’est surtout le côté self-hosted et privacy-first. Vos données restent chez vous, l’IA ne peut pas fouiner dans vos vrais fichiers système, et vous gardez un contrôle total sur ce qui se passe. En plus, comme c’est open source, vous pouvez auditer le code, contribuer des améliorations, ou même forker le projet si l’envie vous prend.

Les cas d’usage sont très nombreux : Automatisation de tâches répétitives, tests d’interfaces web, scraping de données complexes, ou même apprentissage par démonstration pour créer vos propres workflows automatisés. J’imagine déjà les possibilités pour automatiser des installations de logiciels, des configurations système, des processus de CI/CD un peu tordus ou juste faire ma compta.. ^^

Niveau limitations, ByteBot reste dépendant de la qualité du modèle IA que vous utilisez. Claude 4 Sonnet semble donner les meilleurs résultats pour l’instant, mais GPT-4 et Gemini Pro fonctionnent aussi. Les tâches nécessitant beaucoup de contexte visuel ou de manipulation précise peuvent encore poser problème. Et évidemment, faire tourner un desktop complet dans Docker consomme pas mal de ressources.

Si vous voulez pousser plus loin, ByteBot expose aussi une API REST complète. Vous pouvez donc créer des tâches programmatiquement, récupérer les logs, gérer les sessions, et même étendre les capacités avec des plugins custom. La doc est bien fournie avec des exemples en Python, JavaScript et même cURL pour les puristes.

from bytebot import ByteBotClient

client = ByteBotClient(api_key="your-key")
task = client.create_task("Effectue une recherche web")
result = client.wait_for_completion(task.id)
print(result.output)

Et pour la sécurité, ByteBot implémente plusieurs garde-fous . Les conteneurs sont isolés du réseau host par défaut, les capabilities Docker sont limitées au strict minimum, et un système de permissions permet de restreindre ce que l’agent peut faire. Vous pouvez même configurer des règles pour bloquer l’accès à certains sites ou empêcher l’exécution de commandes spécifiques.

Un aspect que j’apprécie particulièrement, c’est la gestion des erreurs. Quand ByteBot se plante (et ça arrive !), il génère des rapports détaillés avec captures d’écran, logs des actions tentées, et suggestions pour résoudre le problème. C’est super pratique pour debugger et améliorer vos prompts.

Une bonne petite communauté commence à se former autour du projet. Un Discord actif, des contributions régulières sur GitHub, et même quelques extensions communautaires qui ajoutent le support pour d’autres LLMs ou des intégrations avec des outils comme Zapier ou n8n. Bref, c’est un projet qui évolue vite, avec des releases toutes les deux semaines environ.

Comparé à ses concurrents, ByteBot se positionne vraiment sur le créneau open source et self-hosted là où OpenAI et Anthropic proposent des solutions cloud propriétaire. C’est, si vous préférez, le Nextcloud des agents IA autonomes.

Après pour ceux qui s’inquiètent des implications éthiques et de sécurité de laisser une IA contrôler un ordinateur, ByteBot apporte à cela des réponses pragmatiques. L’isolation Docker, le mode takeover pour reprendre la main, et la possibilité d’auditer chaque action effectuée permettent de garder un œil sur ce que fait l’agent. C’est bien sûr loin d’être parfait, mais c’est un bon compromis entre automatisation et contrôle.

Donc si vous êtes du genre à automatiser tout ce qui peut l’être, ByteBot mérite vraiment le coup d’oeil. C’est encore un peu but sur les bords, mais le potentiel est énorme. Pour aller plus loin, je vous invite à consulter la documentation complète ici , et le code source sur GitHub .

J’ai déniché un truc sympa pour tous ceux qui passent leur vie dans Docker. Ça s’appelle DCV (Docker Container Viewer) et c’est développé par tokuhirom sur GitHub. En gros, imaginez que quelqu’un ait pris toutes les commandes Docker que vous tapez 50 fois par jour et les ait transformées en une interface accessible via le terminal super classe avec tous vos raccourcis Vim préférés.

Comme ça au lieu de vous taper docker ps, docker logs, docker exec et compagnie en boucle, vous avez tout sous les yeux dans une seule interface TUI (Terminal User Interface). Et le plus beau, c’est que c’est développé avec Bubble Tea , un framework Go qui cartonne pour faire des interfaces terminal qui déchirent (jetez y un oeil à l’occasion..).

Alors oui, je sais ce que vous allez me dire. Il existe déjà Lazydocker , Portainer et une chiée d’autres outils mais DCV a quelques atouts dans sa manche qui le rendent particulièrement intéressant.

D’abord, contrairement à Portainer qui nécessite un serveur web et tout le tralala, DCV reste dans votre terminal. C’est léger, ça démarre instantanément, et ça fonctionne partout où vous avez SSH. Pas besoin d’ouvrir des ports ou de configurer quoi que ce soit de compliqué.

Par rapport à Lazydocker, DCV mise sur une interface encore plus minimaliste et des raccourcis clavier inspirés de Vim. Du coup, si vous êtes du genre à ne jamais toucher votre souris, vous allez kiffer. Le truc cool aussi, c’est qu’il gère nativement Docker-in-Docker, ce qui peut être super pratique pour certains workflows de CI/CD.

L’outil vous permet donc de visualiser :

• Tous vos containers Docker (standalone ou gérés par Compose)
• Les images Docker disponibles
• Les réseaux et volumes
• Les logs en temps réel avec streaming
• L’intérieur des containers (navigation dans les fichiers)

Mais là où ça devient vraiment intéressant, c’est que vous pouvez exécuter des commandes shell directement depuis l’interface. Plus besoin de copier l’ID du container pour faire un docker exec -it. Vous sélectionnez, vous appuyez sur une touche, et bam, vous êtes dans le container.

Pour l’installer, si vous êtes sur macOS ou Linux avec Homebrew :

brew tap tokuhirom/tap
brew install dcv

go install github.com/tokuhirom/dcv@latest

initial_view = "compose"

dcv -debug dcv.log

Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer CronMaster .

Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.

CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.

CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.

L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.

CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.

Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.

Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.

Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.

L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.

Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.

Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !

Il suffit parfois d’un simple scan nmap pour tomber sur une faille monumentale. Et c’est pile poil ce qui est arrivé à Félix Boulet, un chercheur en sécurité qui farfouillait dans le réseau privé de Docker et qui a découvert que l’API interne du Docker Engine traînait tranquillement à l’adresse http://192.168.65.7:2375/, sans aucune authentification. Oui, accessible depuis n’importe quel conteneur qui tourne sur votre machine.

Du coup, la CVE-2025-9074 qui en découle a reçu une note de 9.3 sur l’échelle CVSS, ce qui en fait une vulnérabilité critique. En fait, le problème, c’est que cette API exposée permet à un conteneur malveillant de communiquer directement avec le moteur Docker sans avoir besoin de monter le socket Docker. En gros, deux petites requêtes HTTP POST suffisent pour compromettre entièrement le système hôte. La première crée un conteneur privilégié avec le disque C: monté, et la seconde démarre ce conteneur malveillant…

Sous Windows, la situation est particulièrement préoccupante car le Docker Engine fonctionne via WSL2, ce qui signifie qu’un attaquant pourrait monter l’intégralité du système de fichiers en tant qu’administrateur. À partir de là, il pourrait lire n’importe quel fichier sensible et même remplacer une DLL système pour obtenir des privilèges administrateur complets sur l’hôte. Philippe Dugre, un autre chercheur, a confirmé qu’il pouvait créer des fichiers dans le répertoire home de l’utilisateur sous Windows, chose qu’il n’a pas réussi à faire sur macOS grâce aux protections supplémentaires du système d’Apple.

Ce qui rend cette vulnérabilité encore plus vicieuse, c’est que même la fonction Enhanced Container Isolation (ECI) de Docker ne la bloque pas. Cette protection censée isoler les conteneurs est complètement inefficace face à cette faille et les conteneurs peuvent toujours accéder à l’API et lancer d’autres conteneurs sans restriction. Ça la fout mal…

Sur macOS, l’impact est heureusement plus limité grâce aux mécanismes de sécurité intégrés. L’application Docker Desktop conserve une bonne couche d’isolation et demande la permission à l’utilisateur quand un conteneur tente de monter un répertoire utilisateur. Par défaut, l’application macOS n’a pas accès au reste du système de fichiers et ne s’exécute pas avec des privilèges administratifs, ce qui rend l’hôte beaucoup plus sûr que dans le cas de Windows.

Docker a rapidement réagi (youpi !) et publié la version 4.44.3 de Docker Desktop qui corrige cette vulnérabilité. Donc si vous utilisez Docker Desktop sur Windows ou macOS, installez cette mise à jour immédiatement. Aucune exploitation dans la nature n’a été signalée pour l’instant, mais avec une vulnérabilité aussi simple à exploiter et aux effets potentiellement dévastateur, mieux vaut ne pas traîner.

Pour info, Docker a également mentionné une autre vulnérabilité, la CVE-2025-23266, qui affectait le NVIDIA Container Toolkit en mode CDI jusqu’à la version 1.17.7 . Docker Desktop inclut maintenant la version 1.17.8 qui n’est pas touchée, mais les anciennes versions de Docker Desktop pourraient être affectées si le mode CDI était activement activé. C’est une raison de plus pour mettre à jour vers Docker Desktop 4.44 ou ultérieur.

Bravo Félix !

Source

Une faille critique dans Docker Desktop, associée à la référence CVE-2025-9074, affecte les installations sur Windows et macOS. Voici comment se protéger.

The post CVE-2025-9074 : cette faille critique dans Docker Desktop permet de pirater Windows first appeared on IT-Connect.

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Apprenez à désactiver l’auto-démarrage des conteneurs Docker au boot de la machine physique et à gérer leur redémarrage automatique selon vos besoins.

The post Comment gérer et désactiver le démarrage automatique des conteneurs Docker ? first appeared on IT-Connect.

Découvrez 3 méthodes simples pour transférer vos fichiers depuis votre machine hôte vers un conteneur Docker. Tutoriel avec des exemples concrets.

The post Docker : 3 méthodes pour copier des fichiers de l’hôte vers un conteneur first appeared on IT-Connect.

Source

Avec Neko, créez facilement des navigateurs web virtuels éphémères pour naviguer de façon isolée avec Docker. Compatible Chrome, Firefox, Tor Browser, et Edge.

The post Comment utiliser Neko pour naviguer dans un environnement isolé ? first appeared on IT-Connect.

Self-Hosted : avec ce tutoriel, apprenez à auto-héberger n8n, la solution d'automatisation et de workflows, sur votre NAS Synology à l'aide de Docker.

The post Comment auto-héberger n8n sur votre NAS Synology ? first appeared on IT-Connect.

Ce tutoriel explique comment installer n8n avec Docker sur une machine Linux (Debian) et comment publier l'application en HTTPS avec un reverse proxy Nginx.

The post Automatisation et workflows : comment installer n8n avec Docker sur Linux ? first appeared on IT-Connect.

Source

Source