Le navigateur 3D de Jurassic Park, vous savez, celui avec lequel Lex hackait le parc en 1993 pendant que les vélociraptors grattaient à la porte... bah quelqu'un vient de le recréer, mais pour Kubernetes.

Le projet s'appelle k8s-unix-system et c'est exactement ce que vous imaginez. Vos namespaces deviennent des îles flottantes roses, vos pods des blocs 3D colorés et vous naviguez dans le tout en vue FPS avec WASD + souris. Genre comme Quake, mais pour surveiller vos pods.

Les pods Kubernetes version Jurassic Park ( Source )

Un pod vert c'est un pod qui tourne, jaune c'est en attente, et rouge c'est erreur ou CrashLoopBackOff, bref le truc que personne n'aime voir. Le truc sympa, c'est que la hauteur des blocs augmente avec le nombre de restarts. Du coup, le pod qui galère depuis ce matin, c'est celui qui ressemble à une tour bien haute. Par contre, attention, les pods en erreur tremblent carrément (pas nerveux hein, c'est voulu) et les pods running bougent doucement... c'est plutôt zen je trouve.

Les nodes, eux, ne sont pas mélangés avec les namespaces. Ils ont leur propre île bleu foncé à part, avec des cubes cyan pour ceux qui sont Ready et rouge pour les NotReady. Survolez un node et hop, vous avez son nom, son statut, sa capacité CPU et sa RAM affichées dans un tooltip. Les services, eux, sont visualisés sous forme d'arcs cyan semi-transparents qui connectent les pods entre eux en topologie étoile. Tout fonctionne, suffit de demander, on l'a ! (reeeef ^^)

Les namespaces et nodes, chacun sur leur île ( Source )

Pour lancer le truc, un Docker one-liner suffit (attention quand même, ça monte votre kubeconfig en lecture seule dans le conteneur, donc à réserver au cluster de dev) :

docker run --rm -it -v ~/.kube/config:/root/.kube/config:ro -p 8080:8080 ghcr.io/jlandersen/k8s-unix-system:main

Vous ouvrez localhost:8080 dans Chrome et vous volez à travers votre cluster avec la barre espace pour monter, Ctrl pour descendre, Shift pour accélérer. Tout est en temps réel grâce à la Watch API K8s, du coup si un pod tombe pendant que vous survolez son île, vous le voyez passer au rouge direct. Finalement, c'est kubectl get pods mais en 100 fois plus fun.

C'est codé en Go côté serveur et Three.js pour la 3D dans le navigateur. Le dev derrière bosse chez LEGO (ça ne s'invente pas). Et d'ailleurs si vous êtes du genre à recycler vos smartphones en cluster , ça ferait un combo d'enfer pour frimer devant les collègues.

Bref, vous allez pouvoir enfin lâcher un « Je connais ce système... il fonctionne sous Unix ! » sans mentir.

Ce tutoriel explique comment créer des conteneurs Docker sur Proxmox VE, que ce soit via une machine virtuelle dédiée ou des conteneurs LXC optimisés.

Le post Proxmox VE : comment créer des conteneurs Docker ? a été publié sur IT-Connect.

yt-dlp, tout le monde connaît. C'est l'outil parfait pour télécharger des vidéos depuis à peu près n'importe quel site. Sauf que bon, la ligne de commande, c'est pas le truc de tout le monde. Du coup, les interfaces graphiques pour habiller tout ça, y'en a un paquet... mais trouver celle qui est jolie ET sous licence libre, c'est pas gagné.

Heureusement, VidBee est un nouveau venu qui coche pas mal de cases. L'appli tourne sur Windows, macOS et Linux, elle est sous licence MIT, et l'interface est plutôt clean. On colle une URL, on choisit le format MP4 ou MKV, on sélectionne la qualité entre 720p et 8K et hop, ça télécharge.

Fastoche !

Interface principale de VidBee

Bon, jusque-là, vous allez me dire que Stacher7 fait déjà ça. Sauf que VidBee a un petit truc en plus qui vaut le détour : un système de flux RSS intégré. En gros, vous vous abonnez à vos chaînes YouTube préférées via RSS, et l'outil télécharge automatiquement les nouvelles vidéos en arrière-plan. Comme ça, y'a plus besoin de vérifier manuellement si votre créateur favori a sorti un truc. Attention par contre, prévoyez du stockage parce que ça peut vite remplir un disque dur si vous suivez plusieurs chaînes...

Côté technique, ça gère les résolutions jusqu'à la 8K (si votre écran suit), l'extraction audio seule en MP3, les sous-titres dans plus de 50 langues au format SRT, et même le téléchargement de playlists entières ou de contenus privés si vous êtes connecté à votre compte. Y'a aussi un support proxy pour contourner les restrictions géographiques (genre si votre FAI bloque certains sites) et une extension navigateur pour lancer les téléchargements en un clic.

File de téléchargement VidBee

Et pour les plus bidouilleurs d'entre vous, VidBee propose carrément un mode serveur avec une API Fastify et une interface web, le tout déployable en Docker. Perso, c'est ça que je trouve le plus malin. Un docker compose up -d, l'API écoute sur le port 3100, l'interface web sur le 3000, et vous avez votre propre service de téléchargement accessible depuis n'importe quel appareil du réseau local. Attention quand même à pas le rendre accessible publiquement non plus, hein... sauf si vous voulez des ennuis ^^.

Le projet est plutôt actif, codé en TypeScript et basé sur Electron pour le desktop. D'ailleurs, le monorepo inclut aussi une extension navigateur et un site de doc complet. Par contre, c'est encore en développement très actif, du coup y'a forcément des bugs qui traînent par-ci par-là et des trucs qui cassent de temps en temps mais vu la qualité du service rendu, c'est pas bien grave !

Bref, c'est gratuit, c'est open source, et ça marche sur Windows, macOS et Linux. Allez voir !

Merci à Lorenper pour le partage !

Aujourd’hui, je vous propose un guide rapide pour installer et utiliser Dockhand sur votre NAS Synology. Dockhand est une alternative à Container Manager de Synology. Il propose une interface légère et directe, pensée pour ceux qui veulent garder la main sans se noyer dans une multitude d’options. Entrons immédiatement dans le vif du sujet…

Synology et Dockhand

Suite à mon article « Dockhand, Arcane ou Portainer : quelle interface Docker en 2026 ?« , je vous propose de découvrir comment installer facilement et rapidement Dockhand. Inutile de désactiver Container Station, vous pourrez parfaitement profiter de Dockhand en parallèle. Mieux encore, tous vos conteneurs existants seront automatiquement visibles.

Dockhand s’adresse aux utilisateurs déjà à l’aise avec Docker et qui recherchent une interface rapide et efficace. Si la ligne de commande ne vous fait pas peur, mais que vous appréciez d’avoir une vue d’ensemble claire de ce qui tourne sur votre serveur, Dockhand coche beaucoup de cases. L’approche est volontairement minimaliste, il n’y a pas de menus interminables, pas de concepts propriétaires obscurs. Vous gérez les containers, vous regardez les logs, vous redémarrez un service si besoin. L’outil est plus complet que Container Manager par défaut, tout en restant simple à prendre en main.

Installer sur un NAS Synology

Pour cette installation, j’ai simplement suivi le tuto officiel de Dockhand.

Préparation des dossiers

1. Ouvrez File Station
2. Allez dans le dossier docker
3. Créez un sous-dossier nommé dockhand

Création du conteneur Docker

1. Ouvrez Container Manager
2. Allez dans Projet → Créer
3. Renseignez les informations suivantes :
   • Nom du projet : dockhand
   • Chemin : docker/dockhand
   • Source : Créer un fichier docker-compose.yml

Collez ensuite le contenu suivant :

services:
  dockhand:
    image: fnsys/dockhand:latest
    container_name: dockhand
    restart: unless-stopped
    ports:
      - 3075:3000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./:/app/data

Le port 3000 sur mon NAS est déjà utilisé. J’ai donc fait le choix du 3075…
Voici ce que vous devriez avoir :

Cliquez sur Suivant, puis sur Effectué… et patientez quelques minutes le temps que le conteneur démarre. C’est terminé !

Pour y accéder, tapez dans l’adresse suivante dans un nouvel onglet de votre navigateur : http://AdresseIPduNAS:3075

Première connexion

Lors de la première connexion, un message d’accueil s’affiche. Cliquez sur Got it. Dockhand vous demandera ensuite de créer un environnement…

Créer votre environnement

Appuyez sur le bouton Go to Settings puis…

le bouton bleu  + Add environment Dans mon cas, je l’ai nommé Production Synology, mais vous pouvez évidemment choisir le nom que vous souhaitez.

Profitez en pour aller sur l’onglet Updates pour gérer la vérification des mises à jour (Enable scheduled update check) et changer la Timezone pour mettre Europe/Paris. Je vous déconseille d’activer l’option de mise à jour automatique des conteneurs (trop risqué).

Scan des vulnérabilités

Dans l’onglet Security (toujours lors de la création de l’environnement), vous pouvez activer le scan automatique des vulnérabilités. À chaque installation ou mise à jour d’un conteneur, Dockhand analysera l’image afin de détecter d’éventuelles failles de sécurité.

Authentification

Par défaut, l’interface ne propose pas d’identification, mais il est possible de mettre en place un authentification facilement (identifiant + mot de passe, SSO, LDAP…).

Allez dans le menu de gauche Settings puis sur l’onglet Authentication. Vous cliquerez sur le bouton off en face de Authentication pour activer l’authentification (voir capture ci-dessus). A noter qu’il faut d’abord créer un utilisateur (Users) avant d’activer l’authentification.

En synthèse

Dockhand propose une interface plus complète que Container Manager sur un NAS Synology, tout en étant plus simple à prendre en main que Portainer. L’installation ne prend que quelques minutes et permet de gérer facilement ses conteneurs Docker. Si vous possédez un NAS QNAP, Asustor, TerraMaster ou Ugreen, sachez que la configuration présentée ci-dessus fonctionnera également

Si vous auto-hébergez déjà des services chez vous, y'a un truc qui revient tout le temps c'est l'authentification. Chaque app a son propre login, ses propres mots de passe, et du coup vous finissez avec une ribambelle de comptes différents pour des trucs qui tournent sur le même serveur. Nextcloud par-ci, Jellyfin par-là, Gitea en prime... C'est con hein, mais c'est comme ça !

Pocket ID , c'est un provider OpenID Connect (OIDC) qui fait UNE chose et qui la fait bien : vous authentifier avec vos passkeys. Pas de mot de passe, pas de TOTP, pas de SMS... juste votre empreinte digitale via Touch ID, Face ID, Windows Hello, ou votre clé physique type YubiKey. Le projet tourne en Go côté serveur (un seul binaire de ~15 Mo) et SvelteKit pour l'interface, le tout sous licence BSD-2-Clause.

Bon, vous allez me dire "y'a déjà Keycloak pour ça". Sauf que Keycloak, c'est un monstre. Genre, vous voulez juste centraliser l'auth de votre Nextcloud et de votre Jellyfin, et vous vous retrouvez à configurer 47 fichiers XML. Pocket ID, c'est donc l'inverse... un simple docker compose up -d et hop, c'est lancé sur localhost:1411 ! En fait l'interface web est tellement propre que vous créez vos clients OIDC en 3 clics, plutôt que de passer 2 heures dans la doc.

D'ailleurs, le truc cool c'est la liste des intégrations. Il y a plus de 80 services compatibles, documentés avec des procédures pas à pas : Nextcloud, Immich, Grafana, Portainer, Proxmox, Vaultwarden, GitLab, Jellyfin... en gros tous les classiques du self-hosting. Si vous avez déjà mis en place Authelia pour protéger vos services derrière un reverse proxy , Pocket ID c'est le complément idéal côté SSO.

Attention par contre, y'a un prérequis : HTTPS obligatoire. C'est pas un caprice hein, c'est une contrainte technique de WebAuthn (le standard derrière les passkeys ). Du coup si votre homelab tourne en HTTP sur le réseau local genre http://192.168.1.x ... faudra d'abord passer par un reverse proxy avec certificat TLS. Caddy fait ça carrément bien avec ses certificats Let's Encrypt auto-gérés sur le port 443, c'est même plutôt facile à déployer. Il y a aussi Nginx Proxy Manager qui est génial pour tout ce qui est reverse proxy facile à implémenter !

Ensuite, côté installation, Pocket-ID vous donne le choix : Docker (le plus simple), standalone, Proxmox, Unraid, Kubernetes ou même NixOS.

Y'a aussi un système de groupes d'utilisateurs et des options de suivi pour savoir qui s'est connecté quand, depuis quelle IP. Pas mal hein, pour un outil qui tient dans un conteneur Docker de 50 Mo !

Bon, c'est pas non plus parfait hein. Le fait de n'accepter QUE les passkeys, ça veut dire que si un de vos utilisateurs n'a pas de device compatible (vieux navigateur, OS ancien), il sera coincé. Et si vous perdez votre YubiKey 5 NFC (lien affilié) sans avoir enregistré de passkey de secours sur un iPhone ou un Android... bah bon courage. C'est un choix délibéré des devs, mais faut quand même le savoir avant de migrer toute votre infra dessus.

Bref, simple, efficace, et ça fait pas semblant d'être autre chose. Ah et y'a une démo ici pour tester avant de tout casser sur votre serveur ^^.

J'avoue que faire tourner un agent IA en mode YOLO sur votre machine, y'a de quoi flipper un peu. Un mauvais prompt et hop, votre répertoire home part en fumée.

Mais heureusement, pour ça y'a Yolobox , un outil en Go qui fait tourner vos agents IA dans un conteneur Docker isolé. En gros, l'agent a les pleins pouvoirs dans son bac à sable par défaut comme ça, votre répertoire home reste intouchable. Claude Code, Codex, Gemini CLI, GitHub Copilot, tout est compatible, préconfiguré et prêt à l'emploi.

En fait avec Yolobox, seul votre dossier projet est monté en lecture-écriture avec le même chemin que sur votre machine et comme ça, l'agent bosse comme si de rien n'était. Sauf que tout le reste (vos clés SSH, vos credentials, vos photos de vacances à la plage naturiste et j'en passe...) est inaccessible depuis le conteneur. L'agent peut faire sudo, installer ce qu'il veut, déglinguer sa config... en fait RIEN ne s'échappe.

L'installation tient en une ligne :

brew install finbarr/tap/yolobox

Par contre, faut Docker Desktop qui tourne derrière, car sans ça, rien ne démarre. Ensuite c'est yolobox claude pour lancer Claude Code, yolobox codex pour Codex, yolobox gemini pour le CLI Google. Ou yolobox run suivi de n'importe quelle commande si vous avez un agent custom...

Côté sécu, y'a 4 niveaux qui vont du basique au parano. Le mode par défaut avec isolation conteneur standard. Un cran au-dessus avec --no-network et --readonly-project pour couper le réseau et passer le projet en lecture seule. Ensuite du Podman rootless. Et le niveau max avec isolation VM complète, parce que des fois faut pas déconner. Ça supporte aussi le runtime Apple Container pour ceux qui veulent rester full macOS.

Et les outils de dev sont déjà embarqués dans l'image : Node.js 22, Python 3, Go, Bun, ripgrep, fzf, jq... Les volumes persistants gardent également vos installations entre les sessions, donc pas besoin de tout réinstaller à chaque lancement.

Attention quand même, ça ne marche pas contre un escape de conteneur délibéré car hé, Docker reste Docker. Mais si vous utilisez Claude Code en mode autonome et que vous faites du vibe coding, c'est le minimum vital pour éviter qu'un agent aille fouiller là où il faut pas .

Bref, allez voir ça et merci à Lorenper pour le partage !

Après avoir ouvert à tous l'accès à ses images durcies (DHI) en décembre dernier, Docker annonce le lancement des "Docker Hardened System Packages".

Le post Après les images durcies, Docker veut étendre la sécurité au niveau des paquets a été publié sur IT-Connect.

Ce tutoriel explique comment installer et configurer Dozzle, un outil open source pour visualiser les journaux de Docker en temps réel et recevoir des alertes.

Le post Visualiser les logs Docker en temps réel avec Dozzle a été publié sur IT-Connect.

Article édité le 4 mars. Merci à Nicolas.

π RuView: WiFi DensePose , c'est un projet GitHub qui affiche fièrement ses 25 800 stars et qui promet de transformer les ondes WiFi de votre box en détecteur de corps humains... à travers les murs. Rythme cardiaque, respiration, posture, tout y passe. Sur le papier, c'est dingue. Sauf que voilà, après vérification (merci Nicolas)... c'est du vent.

Le concept de base est pourtant bien réel. Votre routeur WiFi émet des ondes radio en permanence et quand ces ondes traversent ou rebondissent sur un corps humain, elles sont perturbées d'une façon mesurable. En analysant le CSI (Channel State Information, c'est-à-dire les données de chaque sous-porteuse du signal), on peut en déduire la position de 17 points du corps. C'est prouvé par les chercheurs de Carnegie Mellon et ça marche vraiment. Un peu comme la vision WiFi dont je vous parlais déjà ici .

Sauf que CE repo n'implémente rien de tout ça. Le parseur CSI génère des données aléatoires (np.random.rand() partout dans le code), les modèles de deep learning n'ont aucun poids entraîné, et le dashboard Docker sert des données simulées par défaut. Le seul utilisateur qui a branché du vrai matériel (un ESP32) a constaté que la démo affichait une figure immobile avec des mesures bidons . Pas exactement le "54 000 frames par seconde" annoncé...

Et les 25 800 stars ? Probablement gonflées artificiellement. Une issue accusant le dev de fake stars a été supprimée par le mainteneur , tout comme un audit technique complet qui détaillait chaque ligne de code bidon. Un commit de l'auteur est même titré "Make Python implementation real - remove random data generators"... aveu involontaire que le cœur du projet était du pipeau.

Bref, c'est ce qu'on appelle du "vibe coding" combiné à du "portfolio padding". On génère un beau repo avec de l'IA, une doc léchée, des tests qui passent (forcément, ils testent des nombres aléatoires...), on achète quelques milliers de stars à 1-2$ pièce et hop, un profil GitHub qui en jette pour décrocher des contrats. C'est pas dangereux (pas de malware, pas d'arnaque financière), mais c'est sacrément trompeur.

Côté vie privée, le vrai sujet reste entier. Voir à travers les murs via WiFi, c'est réel et prouvé par Carnegie Mellon. Quand de vrais outils fonctionnels arriveront (parce que ça viendra), ça va poser de sacrées questions...

Merci à Florian pour le lien et surtout à Nicolas pour le fact-check ! Si le sujet vous intéresse vraiment, allez lire le vrai papier de recherche de CMU ... et méfiez-vous des repos GitHub avec trop de stars et pas assez d'utilisateurs réels.

Ce tutoriel explique comment installer et configurer Watchtower pour gérer de façon automatique les mises à jour de Docker sur un NAS Synology (ou sur Linux).

Le post Automatiser la mise à jour des conteneurs Docker avec Watchtower sur Synology a été publié sur IT-Connect.

MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

Hey mais on dirait bien que c'est Red Hat qui débarque sur le marché des apps desktop pour conteneurs... mais lol ! Car oui, pendant que Docker Desktop trône depuis des années et qu'OrbStack séduit de plus en plus d'utilisateurs macOS, Red Hat se réveille ENFIN avec sa propre version Enterprise de Podman Desktop .

Bah mieux vaut tard que jamais !

Pour ceux qui débarquent (bouuuuh) Podman Desktop, c'est un outil open source qui existe depuis des années pour gérer vos conteneurs, images et pods via une interface graphique. C'est dispo sous Linux, macOS, Windows et le projet a même rejoint la CNCF (rien à voir avec les trains... lool) en janvier 2025 en même temps que d'autres briques Red Hat (Buildah, Skopeo, bootc, Composefs... chacun en projet séparé).

Interface de Podman Desktop

Et donc Red Hat a décidé de lancer sa propre "build" enterprise de cette app de conteneurs. En gros, c'est la même base que Podman Desktop, mais avec une couche admin par-dessus. Les responsables IT peuvent donc verrouiller des paramètres au niveau de la flotte tels que les registry mirrors, proxies HTTP, certificats custom... On est dans une ambiance un peu plus corporate quoi.

Côté Kubernetes, c'est également plutôt bien pensé. Vous créez vos pods en local, l'outil génère le YAML correspondant, et hop, déploiement sur Kind, Minikube ou directement sur OpenShift, les doigts dans le nez.

Pour ceux qui se demandent si ça remplace Docker Desktop, bah, ça dépend en fait. Podman tourne sans daemon et en rootless, du coup c'est un vrai plus côté sécurité. Mais par contre, le support Docker Compose passe par un système d'aliasing... ça marche bien, sauf si vous avez des configs Docker très exotiques... là faudra tester avant de tout basculer comme le early adopter fifou que vous êtes.

D'ailleurs, si vous êtes sur RHEL, Podman est déjà inclus dans votre abonnement et Red Hat a aussi bossé sur des extensions pour les images bootable OCI et le mode image RHEL.

Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.

La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.

D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.

Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)

Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.

Méthode 1 : Normalisation simple (single-pass)

C'est la méthode la plus rapide, parfaite pour du traitement à la volée :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav

ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4

pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le

Ce tutoriel explique comment installer et utiliser Dockhand pour gérer les conteneurs Docker : une solution gratuite pour votre Homelab et très complète.

Le post Dockhand : mon nouvel allié pour administrer les conteneurs Docker a été publié sur IT-Connect.

Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

Les NAS Synology sont bien plus que de simple unité de stockage en réseau… ce sont de mini-serveur polyvalent capable d’héberger toute une gamme de services Docker. Grâce à Container Manager (le gestionnaire Docker intégré à DSM), il est possible d’ajouter rapidement des applications auto-hébergées et d’exploiter pleinement la puissance de votre NAS.

Dans cet article, je vous présente ma sélection des 10 conteneurs Docker incontournables en 2026 pour étendre les fonctionnalités de votre Synology.

Pourquoi Docker sur NAS Synology (ou autre) ?

Docker apporte l’isolation, la portabilité et la flexibilité nécessaires pour exécuter des applications sans alourdir le système principal de votre NAS. Contrairement à la virtualisation traditionnelle, Docker ne nécessite pas de système d’exploitation complet par application : chaque service tourne dans un conteneur léger et indépendant, ce qui simplifie la gestion et réduit l’utilisation des ressources.

Docker pour les nuls – la révolution du conteneur

Attention, tous les NAS ne supportent pas Docker nativement. Les modèles avec processeurs Intel ou ARM récents et suffisamment de mémoire RAM (2 Go minimum) restent recommandés pour une expérience fluide.

Mes 10 conteneurs Docker préférés

Il y a un an, je vous partageai mes 10 conteneurs Docker préféré en 2025… voici un rafraichissement avec quelques changements.

1. AdGuard Home – Filtrage réseau global

Un bloqueur de publicités et traqueurs à l’échelle de votre réseau. Installé en tant que DNS local, il protège tous vos appareils sans configuration individuelle. (alternative : PiHole)

2. Vaultwarden – Gestionnaire de mots de passe auto-hébergé

Version légère et performante de Bitwarden écrite en Rust. Compatible avec les applications natives et les extensions navigateurs.

3. Immich – Gestion de photos privées

Un gestionnaire de bibliothèque photo local avec reconnaissance faciale et organisation intelligente des albums… une solution vraiment respectueuse de votre vie privée.

4. Odoo – ERP/CRM modulaire

Odoo est une suite d’applications professionnelles complète (CRM, gestion de projet, facturation, etc.). Flexible, interopérable et capable de remplacer plusieurs outils en silo.

5. Jellyfin – Media server open source

Alternative gratuite et open source à Plex ou Emby, Jellyfin permet d’organiser, streamer et partager une bibliothèque multimédia sans abonnement. Fonctionne sur la plupart des lecteurs et appareils modernes. Utile depuis la suppression des fonctions de transcodage côté Synology.

6. Scrutiny – Surveillance SMART et disque

Un outil complet de surveillance de l’état des disques (S.M.A.R.T.), idéal pour anticiper les défaillances et préserver l’intégrité de vos données. Je l’utilise depuis la désactivation du suivi S.M.A.R.T. natif dans DSM

7. Uptime Kuma – Monitoring de services

Surveille la disponibilité de vos sites et services personnels ou professionnels et vous alerte en cas d’indisponibilité.

8. OmniTools – Boîte à outils web auto‑hébergée

OmniTools regroupe une collection d’outils web auto‑hébergés pour accomplir des tâches courantes (images, PDF, texte, données, etc.) directement depuis le navigateur, sans publicité ni suivi, avec une image Docker légère pour un déploiement facile.

9. Komga – Gestion de bandes dessinées et mangas

Application web qui vous permet d’organiser, de lire et de gérer vos bandes dessinées, mangas, BD, magazines et livres électroniques. Vous pouvez utiliser le lecteur web intégré, l’extension Mihon, n’importe quel lecteur OPDS…

10. Homepage – Dashboard de services

Un tableau de bord personnalisable qui centralise l’accès à tous les services auto-hébergés ici. Parfait pour organiser vos conteneurs, URLs et statuts d’applications.

Et ensuite ?

Cette liste reflète mes services Docker préférés en 2026… Tous ne sont pas listés, car certains ne sont encore en phase de test ou leur utilité est très spécifique (Authentik, Cloudflared…). Je pense qu’en 2026, il va y avoir de nombreux changements sur mon NAS et cette liste n’est pas figée.

En synthèse

Que vous soyez un utilisateur avancé ou un passionné d’auto-hébergement, Docker transforme votre NAS Synology en une plateforme polyvalente et personnalisable. Les conteneurs présentés ici couvrent des usages pratiques, du réseau à la gestion multimédia en passant par la productivité.

N’hésitez pas à partager vos propres découvertes en commentaires si vous utilisez d’autres conteneurs Docker intéressants en 2026 !

Vous connaissez tous Kali Linux , Metasploit et compagnie… Mais est-ce que vous avez déjà vu une IA faire un pentest toute seule ? Genre, VRAIMENT toute seule. Shannon , c'est un framework open source qui lâche un agent IA sur votre code, et qui enchaîne recon, analyse de vulns, et exploitation, tout ça sans intervention humaine.

En gros, vous lui filez une URL cible et l'accès à votre code source (faut que le repo soit accessible, c'est la base), et l'agent se débrouille. Il commence alors par analyser le code en statique… puis lance des attaques dynamiques sur l'app en live. Pour cela, il déploie plusieurs sous-agents spécialisés qui bossent en parallèle via Temporal, un moteur de workflow.

Un agent pour la reconnaissance, un pour chercher les injections SQL, un autre pour les XSS, un pour les SSRF, un pour les problèmes d'authentification… Bref, chacun fait son taf et tout remonte dans un rapport final au format JSON.

Le truc, c'est que Shannon ne se contente pas de scanner bêtement comme un Nessus ou un Burp. L'agent COMPREND votre code. Il lit les routes, les middlewares, les requêtes SQL, et il construit ses attaques en fonction. Du coup, il trouve des trucs que les scanners classiques loupent complètement, genre une injection NoSQL planquée dans un endpoint obscur ou un bypass d'auth via un cookie mal valide. Attention par contre, si votre app utilise un framework un peu exotique ou du code obfusqué, y'a des chances que l'agent passe à côté… comme tout scanner, hein.

Pour ceux qui se demandent combien coute un test d'intrusion classique, ça va de 3 000 € à plusieurs dizaines de milliers d'euros. Shannon, c'est open source et ça tourne sur Docker, par contre, faudra compter environ 50 dollars en tokens API Anthropic par run… c'est pas gratuit mais c'est quand même 60 fois moins cher qu'un audit humain.

Cote installation, c'est Docker + Docker Compose, un fichier .env avec votre cle API Anthropic (la variable ANTHROPIC_API_KEY, classique), et hop, un docker compose up pour lancer le tout. Le workflow complet prend entre 1 h et 1 h 30 selon la taille de votre base de code. Vous pouvez suivre la progression en temps réel via l'interface web Temporal sur localhost:8233. (perso, j'aime bien voir les agents bosser en parallèle, ça a un côté satisfaisant).

Et attention, Shannon exécute de VRAIES attaques. C'est mutatif. Ça veut dire que si l'agent trouve une injection SQL, il va l'exploiter pour de vrai pour prouver que ça marche. Du coup, on le lance sur du code à soi, en local ou sur un environnement de test. Mais jamais en prod. JAMAIS !!!

Bon, sauf si vous aimez vivre dangereusement et que votre boss est en vacances… ^^

Les agents d'exploitation (Auth, SSRF, XSS, AuthZ) en parallèle sur la timeline Temporal

Pour en avoir le cœur net, je l'ai lancé sur une app Node.js/Express maison avec 27 endpoints d'API. 2 heures de scan, 287 transitions d'état, 7 agents qui ont bossé en parallèle… et une facture Anthropic qui pique un peu. Parce que oui, chaque agent consomme des tokens Claude à chaque étape d'analyse et d'exploitation, et ça s'additionne vite. Comptez une cinquantaine de dollars pour un run complet. Bref, c'est pas gratuit de se faire hacker par une IA.

Cote résultats par contre, plutôt parlant. Zero injection SQL exploitable, les 23 paramètres utilisateur ont été tracés jusqu'aux requêtes et Shannon a confirmé que tout était paramétré correctement. Bien joué. Par contre, il a détecté 6 failles SSRF liées à des contournements IPv6, des XSS stockées via innerHTML sans aucun échappement dans le frontend, et surtout… ZERO authentification sur les 27 endpoints. Genre, n'importe qui peut purger ma base ou cramer vos crédits API Claude sans se connecter. Bon après, c'est un outil que je me suis dev, qui est un proto local, donc c'est pas exposé sur internet.

Le rapport final est plutôt bien foutu, je trouve. Pour chaque vuln trouvée, vous avez la sévérité CVSS (critique, haute, moyenne), le vecteur d'attaque utilisé, une preuve d'exploitation avec les payloads, et surtout des recommandations de correction. Shannon va jusqu'à vous montrer la ligne de code fautive, expliquer pourquoi le bypass fonctionne, et proposer le fix. Si vous utilisez déjà des outils comme Sploitus pour votre veille secu, Shannon c'est le complément parfait pour passer de la théorie à la pratique sur votre propre code.

Le projet est encore jeune, c'est vrai, mais l'approche est intéressante. Plutôt que d'automatiser bêtement des scans, on a donc un agent qui raisonne sur le code et adapte sa stratégie. Ça change des outils qui balancent des milliers de requêtes à l'aveugle et qui vous noient sous les faux positifs.

Alors après, je vous vois venir, vous allez me dire : est-ce que ça vaut un vrai pentester qui connait votre infra par cœur et qui sait où chercher les trucs tordus ?

Pas vraiment, mais pour un premier audit à moindre coût, ça fait le taf.

Source

Coolify, c'est un PaaS open source que vous installez sur vos propres serveurs pour déployer vos apps, vos bases de données et vos services... sans vous farcir Docker à la main. En gros, un Heroku ou un Vercel, mais en version self-hosted sans enfermement propriétaire comme on pourrait dire en bon français.

La version auto-hébergée est donc TOTALEMENT gratuite. Pas de limite sur le nombre de serveurs, pas de restriction sur les features, pas de "ah pour les teams faut upgrader". Y'a R comme disait mon grand-père... Vous avez SSH sur une machine ? Ça suffit. VPS, Raspberry Pi, dédié, vieux laptop qui traîne dans un coin... Hop, une seule commande et c'est installé.

Côté déploiement, Coolify détecte automatiquement votre stack via Nixpacks (c'est-à-dire qu'il devine le langage et génère le build tout seul). Mais vous pouvez aussi balancer un Dockerfile, un Docker Compose ou un simple site statique. Du coup, que vous bossiez en Next.js, Django, Laravel, Rails, Phoenix ou SvelteKit, ça passe sans config particulière.

Pour les bases de données, c'est pas mal non plus : PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse... tout se déploie en quelques clics. Et au total, le catalogue compte plus de 280 services one-click (Plausible, Gitea, Minio, n8n, et j'en passe). Y'a de quoi monter une infra complète avant même d'ouvrir un terminal.

Le workflow Git est solide puisque c'est du push-to-deploy avec GitHub, GitLab, Bitbucket ou Gitea, avec en prime des déploiements de preview par pull request. Pratique pour tester une branche avant de tout péter en prod (ouais, je vous connais...). Vous avez aussi les webhooks, une API REST documentée, et un terminal temps réel directement dans le navigateur.

Côté ops, les certificats SSL sont automatiques via Let's Encrypt, les backups de vos bases partent vers du stockage S3 compatible , et vous avez du monitoring intégré avec alertes Discord, Telegram ou email. Ça permet de dormir tranquille le vendredi soir. Pour le multi-serveur, Coolify supporte aussi Docker Swarm, donc vous pouvez répartir la charge sur plusieurs machines sans trop de prise de tête.

Si vous voulez pas gérer l'instance Coolify vous-même, y'a Coolify Cloud à 5$/mois (2 serveurs inclus, +3$ par serveur supplémentaire). Vos apps tournent toujours sur VOS machines et c'est juste le dashboard qui est hébergé chez eux. Pour les allergiques à l'admin système, ça peut valoir le coup.

Prise en main rapide

Pour installer Coolify, il vous faut un serveur Linux (Ubuntu LTS recommandé, mais Debian, CentOS, Fedora, Alpine ou même Raspberry Pi OS 64-bit passent aussi), avec au minimum 2 coeurs, 2 Go de RAM et 30 Go de stockage. Un accès SSH root est requis.

L'install tient en une ligne :

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Ce tutoriel explique comment installer et configurer What's Up Docker, une alternative à Watchtower pour mettre à jour les images Docker des conteneurs.

Le post What’s Up Docker (WUD) : gérez vos mises à jour de conteneurs Docker facilement a été publié sur IT-Connect.