Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.

Hammer, l'outil dont je vais vous parler aujourd'hui, est né d'un manuscrit perdu. En septembre 2020, son développeur Adam Brown vivait dans un van et écrivait dans des coins souvent très isolés, avec un logiciel gratuit qui se présentait comme fonctionnant hors ligne. Mais malheureusement, au bout d'une semaine sans réseau, le soft a cessé de fonctionner.

De retour en ville quelques jours plus tard, il a alors remis la main sur une connexion, et le logiciel est reparti, mais son manuscrit avait disparu !

Alors, dégoûté, il s'est dit qu'il allait coder son propre éditeur offline pour éviter que ça se reproduise, car hé, on n'est jamais aussi bien servi que par soi-même ! Et c'est pourquoi quand vous écrivez avec Hammer , chaque scène est un fichier texte enregistré sur votre disque dans le répertoire que vous avez spécifiquement choisi. Et c'est pareil pour tout ce qui est contenu annexe comme les notes et les fiches d'encyclopédie qui accompagnent les scènes.

Grâce à Hammer, qui est un logiciel gratuit sous licence MIT, vos idées sont rassemblées sous la forme d'un projet d'écriture avec tout ce qu'il faut pour prendre des notes, mettre des tags, faire des liens...etc.

L'éditeur de Hammer, avec la scène, son plan et ses notes sur le même écran.

Pour autant ce n'est pas un bloc-notes déguisé. Les scènes se réordonnent au glisser-déposer, ce qui est pratique quand vous décidez que deux personnages doivent se croiser trois chapitres plus tôt. L'encyclopédie catalogue les personnages, les lieux et les événements avec leurs images, et Hammer lit vos scènes pour repérer tout seul qui apparaît où.

La synchronisation entre vos appareils, elle, est totalement optionnelle. Et depuis la dernière version, le serveur de sync a une image Docker officielle . Un petit docker compose up -d et c'est en route, avec un volume pour vos données et le PostgreSQL embarqué directement dans le conteneur.

Si vous débutez en auto-hébergement , sachez quand même que le serveur ne parle que HTTP en local alors que les clients Hammer exigent du HTTPS, donc il faudra mettre en place un reverse proxy ou un certificat devant.

Et si vous n'avez pas envie de gérer un serveur, sachez que l'instance officielle hammer.ink est utilisable si vous êtes abonné au Patreon du projet. Vous pouvez aussi vous en passer et poser le dossier dans Syncthing ou Dropbox, mais ça ne marchera qu'entre vos ordinateurs, car les clients mobiles (Android / iOS) Hammer supportent uniquement le protocole intégré.

Bref, un super outil pour les écrivains, les journalistes et autres producteurs de contenu qui aiment bosser offline. Et si Hammer s'arrête de fonctionner un jour, votre roman sera encore avec vous.

Un import qui affiche "terminé" et qui a mangé une partie de vos mails au passage, c'est le genre de bug qu'on ne voit jamais venir... Hé bien Open Archiver vient d'en corriger quatre d'un coup.

Open Archiver c'est une plateforme d'archivage d'emails auto-hébergée développée par Weishest, dont la seule et unique mission est d'aspirer vos boîtes et de les stocker en .eml sur votre serveur.

Mais attention, le mot "archivage" a son importance, parce que ce n'est pas un backup. Je m'explique... l'idée c'est de garder un dépôt consultable et inaltérable de tout ce qui est passé par vos boîtes, ce qui intéresse surtout les structures ou les personnes comme moi qui doivent pouvoir retrouver un échange trois ans plus tard parce qu'on leur demande tout un tas de trucs tout le temps ^^.

Côté sources, il avale de l'IMAP, du Google Workspace, du Microsoft 365, des fichiers PST, des .eml zippés et du mbox. Ensuite, vos mails archivés finissent chez vous, sur votre disque ou dans un bucket S3, chacun accompagné de son empreinte SHA256 pour repérer une altération.

La grosse news de cette nouvelle release, c'est la recherche avancée. En effet, un panneau de filtres est apparu à côté du champ de mots-clés. Vous restreignez à une source d'ingestion, à une boîte précise, à une fenêtre de dates, aux mails qui ont une pièce jointe ou à ceux qui n'en ont pas et expéditeurs et destinataires s'excluent autant qu'ils s'incluent.

Le panneau de filtres de la recherche avancée, ajouté en v0.5.2

Le mot-clé, lui, peut viser une partie précise du message. Chercher "facture" dans les noms de pièces jointes ne remonte plus tous les mails qui prononcent le mot, juste ceux qui transportent un fichier facture.pdf. Et comme la recherche entière vit dans l'URL, une requête se met en favori et se rejoue à l'identique. L'API suit, avec un GET /v1/search qui accepte les mêmes paramètres que l'interface.

Attention quand même si vous faites la MAJ, faudra relancer un reindex . Et comme les mails existants sont marqués "déjà indexés" à la montée de version, c'est une reconstruction complète qu'il vous faut, pas le simple rattrapage des trous.

Puis surtout, ces notes de version annoncent que plusieurs correctifs "ferment des chemins où un import pouvait sauter ou dupliquer des messages tout en signalant un succès". Le cas le plus vicieux vient d'un composant qui découpe le fichier en messages et qui rendait la main trop tôt. Node recollait alors les morceaux et plusieurs mails arrivaient soudés et finissaient archivés comme un seul. Les imports PST, eux, fabriquaient des messages malformés que les lecteurs affichaient de travers, et une simple re-synchronisation ré-archivait le fichier entier en doublons.

Le plus spectaculaire reste quand même le nom de pièce jointe trop long. Au-delà de 255 octets, l'écriture sur le disque échouait et emportait l'email complet avec elle. Bref, beaucoup de soucis quoi...

Donc si vous tournez déjà dessus, la question à se poser, c'est de savoir si votre archive est déjà foireuse ou pas car un reindex ne la réparera pas. Comme il reconstruit l'index de recherche à partir de ce qui est sur le disque, un message jamais écrit ne réapparaîtra pas. Mais bon, voilà, le découpeur de mbox journalise maintenant son nombre de messages, ce qui rend l'écart visible entre le fichier source et l'archive. Pour le reste, il faudra réimporter ce qui manque

Pour le faire fonctionner, comptez 4 Go de RAM, ou 2 Go si vous branchez PostgreSQL, Valkey et Meilisearch en externe. Le cœur est en AGPL, ça se lance avec un docker compose up, et une démo publique tourne en ligne si vous voulez tâter le truc avant. Pour ma part, je pense que c'est intéressant en entreprise, mais clairement, une usine à gaz, si vous avez juste un compte Gmail à archiver. A la place, je vous avais déjà montré Eonvelope et Bichon , qui sont deux archiveurs autrement plus légers !

Et si c'est pour faire de la recherche, ce que je vous conseille, c'est de faire comme moi, c'est-à-dire un RAG qui indexe tous vos emails en local et qui vous permet de chercher dedans facilement avec n'importe quel LLM qui supporte les outils MCP. Moi je fais ça avec LEANN et ça marche très bien .

Open Archiver est à découvrir ici !

Si vous avez un Navidrome qui tourne dans un coin et un serveur Ollama qui passe ses journées à ne rien faire, vous ne vous êtes jamais dit que les deux pourraient bosser ensemble ? C'est en tout cas ce qu'a flairé Parminder Klair qui a branché l'un sur l'autre et en a sorti une vraie station de radio, avec un DJ qui parle entre les morceaux.

Son DJ baptisé Subwave ne fait pas de la lecture aléatoire. À chaque tour, le modèle utilise des outils qui lui permettent de fouiller la bibliothèque, regarder ce qui vient de passer, consulter la grille des programmes, lire la météo. Il choisit le titre suivant avec une raison, écrit une intro courte, la synthèse vocale la lit, et Liquidsoap baisse la musique sous la voix.

Gérer un serveur à la main, c'est nginx à configurer, les certificats à renouveler, les sauvegardes à planifier et les conteneurs à surveiller... C'est beaucoup de travail. Mais vous allez avoir de l'aide grâce à DockPanel, d'Ovidiu Drobotă, qui met tout ça derrière une jolie interface web tenant dans 19 Mo de RAM.

L'installation se colle en une ligne sur un VPS frais et vous récupérez un panneau d'admin sur le port 8443. Ubuntu, Debian, Rocky, Fedora ou Amazon Linux, en x86_64 comme en ARM64.

À partir de là vous créez des sites en PHP, Node ou Python, avec nginx configuré tout seul et les certificats Let's Encrypt qui se renouvellent sans y penser. Les bases MySQL et PostgreSQL vont avec, navigateur SQL intégré et restauration à un instant T via les journaux binaires.

Ensuite, c'est surtout le catalogue Docker qui fait le gros du travail. Environ 150 modèles en un clic répartis sur 14 catégories, WordPress, Postgres, Grafana, n8n ou Immich, et le reverse proxy, le SSL et le réseau se câblent automatiquement derrière. Les conteneurs inactifs peuvent même se mettre en veille tout seuls pour libérer la machine.

Je vous parlais l'an dernier de Coolify pour le déploiement en self-hosted , et avant ça de aaPanel, le clone gratuit de cPanel mais aucun des deux ne couvre autant de terrain.

Côté déploiement, vous poussez votre code et ça part en production, avec bascule atomique par lien symbolique et retour arrière en un clic quand le déploiement du vendredi tourne mal. Nixpacks reconnaît plus de 30 langages, donc pas de Dockerfile à écrire, et chaque branche peut avoir son environnement de préversion.

Il y a aussi un serveur mail complet, Postfix, Dovecot et DKIM, avec Roundcube en webmail et Rspamd contre le spam. La partie DNS pilote Cloudflare et PowerDNS, avec vérification de propagation, DNSSEC et les tunnels Cloudflare. Un module CDN gère BunnyCDN et Cloudflare, purge du cache comprise.

Pour la surveillance, des sondes HTTP, TCP et ping, une gestion d'incidents avec chronologie et post-mortem, une page de statut publique à laquelle vos utilisateurs peuvent s'abonner, et des alertes qui partent sur Slack, Discord ou PagerDuty. Un point de collecte Prometheus est dispo, avec un tableau Grafana prêt à importer.

La sécurité est activée par défaut avec pare-feu applicatif ModSecurity par site, Fail2Ban, durcissement SSH en un clic, connexion par passkey ou 2FA, et chaque image Docker déployée peut être scannée à la recherche de CVE avec grype, avec refus de déploiement au-dessus du seuil que vous fixez. Les sauvegardes passent par Restic, chiffrées et dédupliquées, vers S3, SFTP, B2 ou GCS, avec vérification de restauration.

Le reste ensuite, c'est que du confort. Terminal web avec enregistrement de session, gestionnaire de fichiers, palette de commandes en Ctrl+K, 6 thèmes, boîte à secrets chiffrée, passerelle à webhooks et une ligne de commande. La configuration complète s'exporte en YAML pour être rejouée ailleurs. Si vous gérez plusieurs machines, un seul panneau les pilote toutes, avec des comptes revendeur en marque blanche pour ceux que ça intéresse.

Deux choses à savoir avant de lancer l'installation quand même... En mars, une injection de commande dans le formulaire de création de site a permis à un visiteur de passer root sur la machine de l'auteur. C'est corrigé depuis, mais l'agent tourne en root par conception puisque c'est lui qui touche à Docker, à nginx et aux certificats.

L'autre point, c'est la licence. DockPanel est en Business Source License 1.1, ce qui n'est pas de l'open source même si la page d'accueil le présente comme ça. L'usage est libre et gratuit sur vos propres serveurs, mais la revente en service hébergé est interdite. Une bascule en MIT est quand même programmée pour mars 2030.

Voilà, je me suis dit que ça pourrait vous intéresser.

Source

Votre Nextcloud sait tout de vous. L'admin du serveur (vous, ou pire, quelqu'un d'autre) peut ouvrir n'importe quel fichier stocké dessus, parce que le chiffrement de bout en bout reste une option planquée dans un plugin.

C'est pourquoi Hoodik , un projet de Tibor Hudik, prend le problème à l'envers. Parce que chez lui, le chiffrement, ce n'est pas une case à cocher, c'est l'architecture au complet.

Grâce à sa solution, vos fichiers sont chiffrés dans votre navigateur, avant même de partir sur le réseau, et à aucun moment le serveur ne voit vos fichiers en clair, ni ne reçoit les clés de chiffrement.

Votre clé privée ne quitte donc pas votre machine, et comme ça, même une intrusion sur le serveur ou un vol ne livrera jamais vos fichiers en clair.

L'interface web, sobre et sans fioritures

Et là où beaucoup d'outils chiffrés deviennent pénibles à l'usage, celui-ci garde les trucs du quotidien super pratiques. Y'a du partage entre comptes avec des rôles (lecture, édition, co-propriétaire), des notes Markdown chiffrées avec historique de versions, et même des aperçus photo et vidéo sans rien déchiffrer côté serveur, HEIC de l'iPhone compris.

La recherche fonctionne aussi alors que le serveur ne voit rien… En fait, votre navigateur découpe les noms de fichiers en petits morceaux, les hashe, et le serveur ne compare que ces empreintes, et jamais de texte en clair. Quant au partage public, la clé de déchiffrement voyage dans le fragment de l'URL, cette partie après le # que votre navigateur n'envoie jamais au serveur.

Au niveau de la crypto, le boulot se divise en deux, il y a d'un côté une paire RSA 2048 qui ne sert qu'à faire circuler les clés, et de l'autre, AEGIS-128L qui chiffre vos données, calculé en direct par le navigateur grâce à WebAssembly (du code quasi natif quoi...). Et avant que vous leviez un sourcil sur ce cipher au nom de Pokémon, AEGIS-128L est finaliste de CAESAR, un concours international de crypto, et est en cours de standardisation à l'IETF. Vous pouvez par exemple le retrouver implémenté dans libsodium . C'est du sérieux, donc.

L'autre bonne surprise, c'est le poids plume de l'app. Le serveur est écrit en Rust (Actix-web) avec un front en Vue 3 et il tourne autour de 20 Mo de RAM au repos, alors que votre Nextcloud réclame ses 200 à 500 Mo pour afficher 3 photos de vacances.

Hoodik est dispo sous la forme d'une image docker pour AMD64 et ARM donc vous pouvez l'installer sur n'importe quoi, un Raspberry Pi , un vieux NAS, un vieux PC, ce que vous voulez...

docker run --name hoodik -d \
-e DATA_DIR='/data' \
-e APP_URL='https://my-app.example.com' \
--volume "$(pwd)/data:/data" \
-p 5443:5443 \
hudik/hoodik:latest

Pour vos téléphones, il y a également des applications Android et iOS dont le chiffrement tourne en Rust compilé dans l'appli elle-même (et pas une page web déguisée en application, on a assez donné...). Par contre elles passent en payant après 30 jours d'essai, sans tarif affiché publiquement sur le site... c'est le modèle économique du projet.

Autrement, c'est sous licence Creative Commons, le code est dispo sur GitHub , mais par contre notez bien que l'usage commercial est interdit sans l'accord de l'éditeur. Ajoutez à ça un projet encore jeune et aucun audit de sécurité indépendant publié, contrairement à Cryptomator qui est en GPLv3 et audité. Après ma comparaison s'arrête là par contre, parce que Cryptomator chiffre par-dessus un cloud existant alors que Hoodik c'est vous qui l'hébergez.

Quoi qu'il en soit, pour votre dossier de photos de famille, vos sauvegardes ou vos documents sensibles, le compromis se défend largement. Et si vous voulez explorer d'autres pistes, jetez un œil à OpenCloud pour du Nextcloud-like allégé, ou à Picocrypt pour chiffrer des fichiers à l'unité.

Allez, y'a plus qu'à ressusciter le vieux NAS qui prend la poussière et suivre le guide d'installation pour lancer votre docker compose up.

Votre nuage perso vous attend !

Merci à Camille Roux pour le lien !

On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

Installation en une commande

L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

La commande minimale ressemble à ça :

docker run -d \
--name=firefox \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Paris \
-e LC_ALL=fr_FR.UTF-8 \
-p 3001:3001 \
-v $HOME/firefox-config:/config \
--shm-size=1gb \
--restart unless-stopped \
lscr.io/linuxserver/firefox:latest

Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

La version docker-compose, plus propre

Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

---
services:
firefox:
image: lscr.io/linuxserver/firefox:latest
container_name: firefox
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Paris
- LC_ALL=fr_FR.UTF-8
- CUSTOM_USER=korben
- PASSWORD=changezmoi
- HARDEN_DESKTOP=true
- HARDEN_OPENBOX=true
volumes:
- ./firefox-config:/config
ports:
- 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

Le hardening qu'il faut absolument activer

Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

SealSkin, le bonus qui change tout

SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

Et sur tablette ou mobile ?

J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.

Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.

Pour en profiter, tapez la commande suivante :

wsl --update --pre-release

Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.

WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.

Monter une vraie IA à la maison, c'est vite une galère. Vous achetez une super machine puis vous collez dessus toute votre liste au père Noël (Chat local, reco vocale, génération d'image, RAG et compagnie) et vous voilà à empiler des dockers à n'en plus finir. Eh bien Light Heart Labs en a eu marre de ces bricolages et nous a pondu Dream Server, un outil qui câble tout ce petit monde à votre place !

Une seule commande et c'est parti mon kiki (Linux et macOS) :

curl -fsSL https://raw.githubusercontent.com/Light-Heart-Labs/DreamServer/main/dream-server/get-dream-server.sh | bash

Ou Windows :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
git clone https://github.com/Light-Heart-Labs/DreamServer.git
cd DreamServer
.\install.ps1

Ça va lancer le script qui va ensuite tout paramétrer tout seul et choisir le modèle d'IA qui collera le plus à votre matériel, et cela que vous ayez une RTX 4090, un Mac M4 avec mémoire unifiée ou encore une puce AMD Strix Halo voire un vieux PC sans GPU.

Edit : un lecteur m'a remonté un piège si vous êtes sous Linux configuré en français (ou n'importe quelle locale qui écrit les décimales avec une virgule). Le script génère tout seul les valeurs de votre fichier .env en suivant le format de nombres de votre système, et il vous colle des 16,0 au lieu de 16.0. Du coup l'install se vautre avec une erreur dans le genre COMFYUI_CPU_LIMIT: expected number, got '16,0'. La parade, confirmée par un des auteurs, c'est de relancer l'installeur en forçant la locale C (celle qui met des points à la place des virgules) :

LC_ALL=C ./install.sh

Ensuite, pendant que le LLM se télécharge à fond les ballons, un autre petit modèle de 1,5 milliards de paramètres en backup afin que vous puissiez quand même "discuter" avec votre Dreamserver.

Le rôle de Dreamserver c'est donc juste de prendre toutes les briques de l'IA pour vous en faire un truc clé en main. Open WebUI pour le chat, llama-server pour l'inférence, Whisper et Kokoro pour la voix, ComfyUI pour les images, Qdrant pour le RAG, SearXNG pour la recherche web sans mouchard, et bien sûr n8n pour brancher tout ça à vos automatisations.

Et une fois que c'est en route, suffit de lancer la commande dream et là vous pourrez tout faire.

Par exemple dream status pour visualiser l'état des services et du GPU, dream model swap T3 pour changer de "palier" sur votre matos, dream enable n8n pour activer une extension ou encore dream mode hybrid pour avoir de l'inférence en local avec possibilité de basculer sur une IA dans le cloud via une API.

Dreamserver reste un orchestrateur, et pas un moteur IA magique, donc si vous adorez tout assembler vous-même, vous n'avez clairement pas besoin de ça. Par contre, si vous vous en foutez, et que vous voulez juste votre IA qui tourne ce soir, ça vous fera gagner des heures de bidouille.

Faut dire qu'à mesure que l'IA devient une infrastructure de base, dépendre à 100% d'un abonnement cloud qui peut tripler ses tarifs ou couper votre accès du jour au lendemain, ça craint un peu. Donc je pense qu'on est tous bien contents d'avoir des solutions clé en main comme celle-ci.

Si ça vous tente, c'est sur le dépôt de Dream Server .

Quand on est habitué à Linux et qu'on se retrouve avec un Mac, même si c'est une base unix, c'est déroutant. Heureusement, Apple est de plus en plus ouvert au monde du libre et vient de publier la version 1.0 de Container , avec dedans des "container machines" qui ressemblent furieusement à WSL. Et ça nous permet comme ça d'avoir le meilleur des deux mondes : un macOS pour le quotidien, et un vrai Linux pour vos folles bidouilles.

Vous vous souvenez forcément de mon article où je vous présentais Apple Container , cet outil écrit en Swift qui fait tourner des conteneurs Linux dans des petites machines virtuelles. Et bien un an plus tard, le projet passe en 1.0, pile pour la WWDC, et la grosse nouveauté c'est donc ce mode "machine".

Le CLI container en action, sobre comme un terminal qui bosse ( Source )

Il s'agit d'un environnement qui vous permet de faire tourner de vraies distributions Linux comme Ubuntu, Debian ou Alpine, et pas juste un conteneur modelé sur une application. La machine lance le système d'init de l'image, donc un systemctl start postgresql fonctionnera comme sur un vrai serveur.

Et à la reconnexion, à partir du même terminal ou d'un autre, l'état de la machine n'est pas perdu. Surtout, elle mappe automatiquement votre utilisateur et votre répertoire home. Votre repo vit ainsi dans le $HOME de macOS, du coup vous éditez avec votre IDE côté Mac et vous compilez côté Linux, sans étape de copie entre les 2.

Pour la prise en main, entrez les commandes suivantes en prenant soin de remplacer alpine par la distrib de votre choix :

container machine create alpine:latest --name dev
container machine run -n dev whoami # votre user, pas root
container machine run -n dev # shell interactif

Les avions en vol, les cargos, les satellites espions, les zones de brouillage GPS... Imaginez tout ce bordel, à l'échelle de la planète, visible sur une seule carte sombre directement chez vous. Ce serait fou non ? Hé bien c'est ce que nous propose BigBodyCobain qui a sorti ShadowBroker , un tableau de bord OSINT gratuit et open source qui agrège plus de 60 flux de renseignement public, rafraîchis en continu.

Pour l'installer, un git clone, et on entre dans le dossier. Suffit ensuite de lancer un docker compose up (faut juste Docker, et ça tourne sous Linux, Mac ou Windows), vous ouvrez localhost:3000 et la carte se remplit toute seule ! Ça marche même sur un Raspberry Pi 5. C'est donc largement plus simple que la moitié des trucs que je vous présente ici en général.

Y'a qu'une seule clé API qui est vraiment obligatoire, c'est celle d'aisstream.io pour le trafic des bateaux, et c'est une inscription gratuite. Le reste tourne sans rien, sauf qu'une clé OpenSky (gratuite aussi) est chaudement recommandée pour une couverture aérienne correcte, + quelques couches secondaires qui acceptent leur propre clé pour avoir de la meilleure info.

L'interface principale de ShadowBroker : une carte du globe qui empile en temps réel avions, navires et satellites, chat MESH à gauche et fil Global Threat Intercept à droite

Pour ceux qui débarquent, l'OSINT c'est le renseignement à partir de sources ouvertes, c'est à dire toutes ces données déjà publiques que personne ne prend le temps d'aller croiser. Donc cet agrégateur ne pirate rien... il ramasse juste ce qui traîne déjà en accès libre.

Et là, vous vous demandez ce qu'il y a dedans en détails ?

Hé bien accrochez-vous parce qu'on y retrouve les avions civils via OpenSky, les militaires via adsb.lol, l'ADS-B étant le signal que tout avion crache en vol, avec Air Force One bien visible dès le décollage. Et les bateaux sont suivis en AIS, l'équivalent radio côté maritime.

Y'a aussi les satellites dont la trajectoire est calculée depuis leurs paramètres orbitaux, les séismes de l'USGS, les feux repérés par la NASA, les conflits agrégés depuis GDELT, la ligne de front ukrainienne via DeepState et même un tracker pour suivre les porte-avions américains (c'est une position estimée à partir de l'actu publique, et pas du temps réel).

Du coup ça va loin ! Les zones de brouillage GPS probable sont même déduites quand le signal de navigation des avions se dégrade et on y retrouve aussi plus de 11 000 caméras de circulation aussi, de Londres à Singapour en passant par les États-Unis et l'Espagne.

Le panneau Data Layers (séismes, satellites, brouillage GPS, lignes de front) ouvert sur une zone de conflit, avec le détail des reports terrain

Il y a même un tuner d'ondes courtes intégré, branché sur des centaines de récepteurs radio partagés par des amateurs (les SDR, des radios pilotées par logiciel). Et les scanners de la police américaine sont aussi en écoute directe.

Et en faisant un clic droit n'importe où sur le globe, ce radar mondial vous sortira un dossier du pays, avec le type de gouvernement, le chef d'État tiré de Wikidata, un résumé Wikipédia et la dernière image satellite Sentinel-2 disponible.

Côté bidouille, vous pouvez aussi brancher votre propre dongle RTL-SDR, une clé radio à pas cher, en plus du flux distant pour choper les bateaux à portée de votre antenne. Et avec une clé Shodan, un overlay optionnel ajoute les objets connectés visibles depuis Internet, tels que les caméras, les systèmes industriels, les bases de données et j'en passe.

Ça rejoint ce bon vieux moteur de recherche d'objets connectés dont je vous parlais il y a quelques années. Et si l'OSINT vous gratte vraiment, y'a aussi de quoi vous entraîner sérieusement avec ce site aussi.

La légende de cet outil veut que l'idée soit partie d'une envie de pister les déplacements d'Elon Musk avec une interface cyberpunk. Le nom, lui, vient du Shadow Broker de Mass Effect (rien à voir avec le groupe de hacker Shadow Brokers ). D'après le créateur, GitHub aurait même fait retirer le dépôt d'origine à cause de ce nom, d'où un petit détour par GitLab avant de revenir à Github.

Bref, ce truc agrège une quantité hallucinante de données publiques mondiales...

Après, au niveau du code, tout n'est pas non plus très clair car même si l'OSINT c'est légal, le code du scrapeur d'une carte de guerre contourne volontairement la protection Cloudflare Turnstile, ce qui pose une vraie question légale côté CFAA, la loi américaine contre l'intrusion informatique. C'est une zone grise...

Et y'a aussi des failles puisque plusieurs endpoints ne sont pas authentifiés, dont un qui laisse n'importe qui envoyer des messages APRS (le réseau de positionnement des radioamateurs) sous n'importe quel indicatif, ce qui est une infraction pure et simple aux règles radio.

Quant à la messagerie soi-disant chiffrée ne l'est pas de bout en bout, mais juste obfusquée donc ne faites rien transiter de sensible dessus.

Voilà si je vous dis tout ça, c'est pour que vous gardiez cet outil bien au chaud en local et que vous ne l'exposiez pas sur le net.

Zoom sur la côte de Floride : chaque marqueur est un avion suivi en direct via l'ADS-B, façon radar ( Source : GIGAZINE )

Mais bon, ça fait une belle salle de crise gratuite, open source sous licence AGPL, installable par exemple sur un Raspberry Pi. Grâce à ça, le monde n'a jamais été aussi "lisible" depuis votre canapé !

Un grand merci François pour le lien !

Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur ffmpeg-over-ip qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.

Le principe c'est que le client reçoit les commandes ffmpeg de Jellyfin (ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).

Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.

L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :

curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh

ln -s ffmpeg-over-ip-client ffprobe

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 !

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

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 !

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

L'autre jour, je voulais juste exposer un petit service tournant sur mon NAS pour y accéder à distance quand je suis en déplacement. Alors je me suis dit "Allez, je vais faire ça propre avec Traefik" mais bon, debugger du fichier YAML parce qu'on oublie des indentations à un moment ça casse la tête. J'ai +40 balais et pas que ça à foutre.

Si vous hébergez vos propres services à la maison (self-hosting powaaaah !) et que vous êtes un peu bordélique comme moi, vous installez un truc, puis un autre, et vous finissez avec une collection de ports impossible à mémoriser du genre monip:8080, monip:32400, monip:9000… Aarrgh, l'enfer !!!

Et ne me lancez pas sur la gestion des certificats SSL !! Si vous voulez faire ça bien, faut générer des certificats Let's Encrypt à la main pour chaque service, modifier les fichiers de conf Nginx en priant pour ne pas oublier un point-virgule… et j'en passe et des pas mûres… Alors je sais, oui ça nous occupe et pendant ce temps là, on n'est pas dehors en train de voler des voitures mais j'sais pas vous, moi j'ai mieux à faire.

Hé bien, figurez-vous les copains, qu'il existe un outil qui transforme ce cauchemar en promenade de santé. Ça s'appelle Nginx Proxy Manager, et une fois que vous aurez lu mon article et testé vous penserez : "Mais pourquoi je me suis emmerdé la vie pendant tout ce temps, mortecouille ?!".

Nginx Proxy Manager, c'est quoi ce truc ?

En gros, c'est une interface graphique super propre pour gérer Nginx. Au lieu de taper des lignes de commandes et d'éditer des fichiers de config obscurs, vous avez un beau tableau de bord pour :

1. Rediriger vos domaines (ex: plex.mondomaine.fr) vers vos conteneurs Docker.
2. Gérer vos certificats SSL (HTTPS) automatiquement.
3. Sécuriser l'accès à certains services avec un mot de passe.

Mais en vrai, c'est plus riche que ça. Dans la barre du haut, vous avez tout ce qu'il faut pour piloter votre reverse proxy comme un adulte responsable : des hosts (proxy, redirections, streams, 404), des certificats (Let's Encrypt ou certifs locaux), des utilisateurs, des règles d'accès (Access Lists), et même des logs d'audit pour savoir qui a fait quoi (au cas où un de vos potes "teste un truc vite fait" et casse tout).

C'est le reverse proxy pour ceux qui veulent que ça marche, tout de suite, sans devenir ingénieur réseau bac+12 ou devoir se taper 2h d'explications IRL d'un barbu qui pue de la gueule ^^.

Installation en 3 minutes chrono (avec Docker)

Bon, on ne va pas y passer la nuit. La méthode la plus propre, c'est évidemment Docker Compose. Si vous ne l'avez pas, installez-le (allez, un petit apt install docker-compose et on n'en parle plus).

Créez un dossier nginx-proxy-manager et collez-y ce fichier docker-compose.yml :

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 restart: unless-stopped
 ports:
 - '8080:80' # Port HTTP public
 - '8181:81' # Port d'administration (à garder pour vous)
 - '8443:443' # Port HTTPS public
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt
 db:
 image: 'jc21/mariadb-aria:latest'
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: 'npm'
 MYSQL_DATABASE: 'npm'
 MYSQL_USER: 'npm'
 MYSQL_PASSWORD: 'npm'
 volumes:
 - ./mysql:/var/lib/mysql

Petit piège à éviter : Faites gaffe si vous avez déjà un serveur web (Apache ou Nginx) qui tourne sur la machine hôte. Il va falloir couper le service ou changer les ports, sinon Docker va vous jeter une erreur parce que le port 80 est déjà pris. Du coup, vérifiez bien avec un petit netstat -tulpn | grep 80 avant de lancer la sauce.

Ah oui, et si vous utilisez un pare-feu comme UFW (ce que je vous recommande chaudement), n'oubliez pas d'ouvrir le port 81 : ufw allow 81. Sinon, vous allez pleurer devant une page blanche et vous demander pourquoi ça marche pas.

Ensuite, lancez la bête :

docker-compose up -d

Et voilà ! C'est tout. Votre serveur tourne. Si vous avez des erreurs, c'est probablement parce que vos ports sont déjà utilisés. Ou que les dossiers data, Let's Encrypt et MySQL n'existent pas encore. Moi j'ai ça sur mon NAS :

La configuration que même ma grand-mère pourrait le faire

Ouvrez votre navigateur et allez sur http://votre-ip:8181 et créez vous un compte.

Une fois dedans, pour exposer un service, c'est ridicule tellement c'est easyyyy

1. Cliquez sur "Add Proxy Host".
2. Entrez votre nom de domaine (ex: nextcloud.mondomaine.fr).
3. Indiquez l'IP de la machine et le port du service (ex: 8080).
4. Allez dans l'onglet "SSL", cochez "Request a new SSL Certificate" et "Force SSL".
5. Sauvegardez.

En fait, le seul truc qui peut coincer, c'est la propagation DNS. Si vous venez d'acheter votre nom de domaine il y a 5 minutes, pas de panique si Let's Encrypt refuse de générer le certificat. Attendez une petite heure et réessayez. C'est classique.

Et hop, fini. Votre service est accessible en HTTPS, avec le petit cadenas vert qui va bien. Nginx Proxy Manager s'occupe de discuter avec Let's Encrypt et de renouveler le certificat tout seul. C'est carrément magique.

Tour d'horizon des fonctionnalités qui sauvent des week-ends

Parce que oui, Nginx Proxy Manager ne fait pas "juste" proxy + "cadenas". Dans le menu Hosts, vous avez plusieurs types de trucs à créer, et chacun sert à un usage bien précis. Et côté Certificats et sécurité, il y a de quoi faire sans sortir le marteau-piqueur.

Certificats Let's Encrypt (HTTP et DNS) + certifs locaux

On va commencer par le sujet qui donne des boutons : les certificats. Dans l'onglet Certificates, vous pouvez gérer tout ça au même endroit :

• Let's Encrypt en HTTP-01 : le classique. NPM ouvre la voie, répond au challenge, et basta. Pratique pour un service.mondomaine.fr exposé "normalement".
• Let's Encrypt en DNS-01 : là, c'est le mode "j'ai compris la vie". Vous pouvez valider le certificat via votre DNS (donc sans dépendre d'un port 80 accessible), et surtout ça permet les wildcards du style *.mondomaine.fr. Donc un seul certif et roule ma poule, même si vous ajoutez 12 sous-domaines demain à 3h du mat.
• Certificats locaux : vous pouvez aussi importer un certificat existant (genre un certif de votre boîte, un truc interne, un CA maison, ou même un self-signed si vous aimez vivre dangereusement). Ça évite de dépendre de Let's Encrypt si vous êtes en mode "tout en local, rien sur Internet".

Et le meilleur c'est que NPM gère le renouvellement automatique. Donc plus de rappel calendrier "renouveler les certifs" tous les 2 mois, sinon c'est le drame et tout le monde vous écrit "ça marche plus ton truc".

Plusieurs comptes, parce que tout le monde n'est pas "admin"

Dans Users, vous pouvez créer plusieurs comptes pour accéder à l'interface. Typiquement :

• un compte admin pour vous, le chef, le patron, le seigneur des reverse proxies.
• un compte "moins dangereux" pour quelqu'un qui doit juste consulter ou bidouiller un truc sans toucher à toute l'infra.

Et ça, couplé aux Audit Logs (j'y reviens juste après), c'est très pratique quand plusieurs personnes mettent les mains dedans. Parce que "c'est pas moi, j'ai rien touché" est une phrase universelle, on la retrouve dans toutes les cultures.

Access Lists, le videur à l'entrée

Alors ça, c'est une des fonctions les plus sous-cotées. Les Access Lists permettent de mettre en place des règles d'accès et de les réutiliser partout :

• Basic Auth (login/mot de passe) : parfait pour protéger une appli pas prévue pour être publique, ou un petit outil d'admin que vous ne voulez pas exposer "en clair".
• Allow/Deny par IP : le top pour dire "seulement depuis mon IP / mon VPN / mon réseau". Et là, même si quelqu'un devine votre URL, il se prend un mur.

Vous créez une Access List une fois, et ensuite vous l'appliquez à vos Proxy Hosts. Du coup, pas besoin de refaire 50 fois la même conf. C'est propre, c'est net, c'est carré.

Les redirections propres (HTTP -> HTTPS, domaine A -> domaine B, etc.)

Besoin de rediriger un vieux domaine vers un nouveau ? Ou de faire un joli http:// qui part systématiquement en https:// ? Les Redirection Hosts servent exactement à ça. C'est bête mais ça évite d'aller trifouiller des règles Nginx à la main.

Exemples typiques :

• mondomaine.fr -> www.mondomaine.fr
• ancientruc.mondomaine.fr -> nouveautruc.mondomaine.fr
• http -> https (pour les retardataires)

Streams - Quand ce n'est pas du HTTP mais que vous voulez quand même un reverse proxy

Le web, c'est bien, mais tout n'est pas en HTTP. Certaines applis parlent en TCP/UDP (bases de données, services réseau, protocoles chelous, etc.). C'est là que Streams entrent en jeu. Cette fonctionnalité vous permet de proxyfier des flux réseau, genre "ce port externe pointe vers ce port interne".

Alors oui, c'est plus "brut" que les Proxy Hosts, mais ça dépanne vraiment quand vous avez un service qui n'a rien à faire derrière un vhost HTTP. Et ça se configure aussi en 2 clics, sans incantations démoniaques.

404 Hosts - La sortie de secours

Les 404 Hosts, c'est la petite finition qui fait plaisir (non, rien à voir avec votre salon de massage préféré). Vous pouvez définir un "host poubelle" qui répond proprement quand quelqu'un tape un domaine qui n'existe pas chez vous, ou quand un bot scanne votre serveur en espérant trouver /phpmyadmin par magie.

Au lieu de laisser traîner une réponse moche ou ambiguë, vous renvoyez une 404 nette, propre, assumée. C'est pas de la sécurité absolue, mais c'est une bonne hygiène, et ça évite de donner trop d'infos aux curieux.

Audit Logs

Dans Audit Logs, vous avez l'historique des actions effectuées dans l'interface : création/modif de hosts, changements de certifs, etc. C'est le genre de truc dont on se fout… jusqu'au jour où on en a besoin. Et là, vous êtes content de pouvoir remonter le film de l'horreur.

Et enfin, mon bonus : Le mode "je sais ce que je fais" (les options avancées Nginx)

Et si un jour vous voulez aller un cran plus loin, NPM permet aussi d'ajouter des réglages plus "Nginx pur jus" par host (headers, règles, conf custom). Donc vous commencez en mode clic-clic, et si vous devenez un peu psycho sur l'optimisation, vous pouvez aussi affiner. Sans tout casser, normalement.

2/3 conseils de daron pour éviter les boulettes

• Ne laissez pas l'admin ouvert au monde : le port 8181 (ou votre port d'admin) c'est "pour vous". Si possible, limitez-le via pare-feu / VPN / IP autorisées. C'est le panneau de commande de votre château, pas un distributeur de bonbons.
• Utilisez les Access Lists pour tout ce qui est sensible : dashboards, outils d'admin, services pas prévus pour Internet, etc.
• Pensez au DNS-01 si vous voulez des wildcards ou si vous n'avez pas envie d'exposer le port 80.

Et par rapport aux autres ?

Je vous vois venir les puristes : "Oui mais Traefik c'est mieux car c'est dynamique". C'est vrai. J'ai testé Traefik, et c'est une tuerie pour les environnements qui bougent tout le temps. Mais sa config en YAML peut vite devenir une usine à gaz si vous débutez. Caddy est top aussi (un seul fichier de conf), mais il faut quand même mettre les mains dans le cambouis.

Perso, je pense que Nginx Proxy Manager est un excellent choix pour un homelab par exemple. C'est un peu le choix du confort, celui des grosses feignasses comme moi parce que c'est visuel, c'est du clic-bouton clic clic, et pour un petit serveur perso, c'est franchement imbattable.

Bref, si vous galérez encore avec vos vhosts Nginx, arrêtez de vous faire du mal. Installez ça, et profitez de la vie (et de vos week-ends).

Nginx Proxy Manager c'est par ici !

Vous utilisez WSL sous Windows mais vous en avez marre de devoir jongler avec les commandes PowerShell dès qu'il s'agit de gérer vos distributions ?

C'est vrai que taper du wsl --import ou du wsl --unregister à chaque fois qu'on veut tester une nouvelle instance, ça finit par être un peu lourd.

Heureusement, y’a un dev, Eric Trenkel (alias bostrot), qui a eu la bonne idée de sortir WSL Manager (qu'on connaissait aussi sous le nom de WSL2 Distro Manager), une interface graphique complète pour piloter tout ça sans se faire mal au terminal.

Cette application, développée avec Flutter offre une vue d'ensemble sur toutes vos instances WSL installées. Ainsi, en un clic, vous pouvez les démarrer, les arrêter, les renommer ou même changer leur version.

Mais là où l'outil excelle, c'est dans sa capacité à importer de nouveaux environnements. Pour ceux qui se demandent comment ça se passe pour récupérer des distributions exotiques, sachez que WSL Manager permet de télécharger et d'utiliser n'importe quelle image Docker comme base pour une instance WSL, et ce, sans même avoir besoin d'installer Docker Desktop sur votre machine.

Par exemple si vous voulez un Alpine minimaliste pour du test ou un Kali pour du pentest, vous l'importez direct depuis les registres Docker et hop, vous avez un nouveau système prêt à l'emploi.

C'est d'ailleurs un excellent complément à des outils comme DockStation si vous voulez garder une approche visuelle de vos conteneurs, ou même WinBoat pour faire tourner du Windows dans Docker. L'application propose aussi des "Quick Actions", qui sont en gros des petits scripts prédéfinis que vous pouvez exécuter directement sur vos instances pour automatiser les tâches répétitives. Vous pouvez également lancer directement Windows Terminal ou VS Code dans la distribution de votre choix en un seul clic.

Si ça vous branche, plusieurs options s'offrent à vous pour l'installer. Comme le projet est open source sous licence GPL-3.0, vous pouvez récupérer les exécutables gratuitement sur la page GitHub du projet.

Il existe aussi une version sur le Microsoft Store et notez aussi que bien que des paquets winget ou Chocolatey existent, ils sont souvent maintenus par la communauté et pas forcément à jour, donc privilégiez le téléchargement direct ou le Store pour être tranquille.

Voilà, si vous passez vos journées sous Linux tout en restant dans l'écosystème Microsoft, WSL Manager c'est le feu et ça permet de se concentrer sur son boulot plutôt que sur la syntaxe des commandes de gestion système.

Merci à Lorenper pour la découverte !

Vous en êtes encore à utiliser des sites tout pourris de conversion en ligne qui vous bombardent de pubs et qui font on ne sait quoi avec vos fichiers ?

Bouuuuh ! Allez, on va jeter un oeil à cette alternative auto-hébergeable qui s'appelle ConvertX et qui supporte plus de 1000 formats différents !!

Vous l'hébergez chez vous via Docker et vous avez accès à une interface web propre pour convertir à peu près tout ce qui existe. Images, vidéos, audio, documents, ebooks, modèles 3D... Le truc gère vraiment un paquet de formats différents.

En back, ConvertX utilise ImageMagick pour les images, FFmpeg pour le multimedia, et une tripotée d'autres outils (Pandoc, LibreOffice, Calibre, Inkscape...) pour gérer le reste. Au total, ça donne plus de 1000 combinaisons possibles entre formats d'entrée et de sortie.

Pour l'installer, c'est hyper fastoche, vous lancez :

docker run -p 3000:3000 -v ./data:/app/data ghcr.io/c4illin/convertx

et vous avez l'interface accessible sur localhost:3000. Vous pouvez aussi passer par Docker Compose si vous préférez avoir un truc plus propre à maintenir.

Y'a aussi pas mal d'options pratiques. Vous pouvez par exemple convertir plusieurs fichiers en même temps (batch processing), protéger l'accès par mot de passe, gérer plusieurs comptes utilisateurs, et garder un historique de vos conversions. Y'a aussi un mode sans authentification si vous voulez l'utiliser juste pour vous sur votre réseau local.

Côté config, vous pouvez régler pas mal de trucs via les variables d'environnement, notamment la durée de rétention des fichiers (par défaut 24h avant suppression auto), le nombre de conversions simultanées autorisées, ou encore désactiver HTTPS si vous êtes en local.

Ce projet est développé en TypeScript avec Bun comme runtime et Elysia comme framework web. C'est sous licence AGPL-3.0, donc si vous modifiez le code et que vous l'utilisez en production, faudra publier vos modifs. Mais pour un usage perso, ça change rien.

Bref, si vous en avez marre de filer vos fichiers à des services louches pour les convertir, testez ConvertX , ça permet de garder le contrôle !

Merci à Letsar pour la découverte !

Benjamin, lecteur de korben.info, m’a envoyé un email pour me parler d’ Ackify , son nouveau projet open-source. L’idée avec Ackify c’est de pouvoir confirmer qu’un document a bien été lu !

Je parle pas de signature électronique, hein. Pour ça y’a déjà DocuSign, Adobe Sign, HelloSign…etc. Non, je vous parle des cas où vous avez juste besoin de prouver que Thérèse de la compta a bien reçu, ouvert et lu le PDF de la nouvelle procédure RGPD. Et pour ça, les solutions du marché sont soit surdimensionnées, soit inexistantes, du coup, les boîtes bidouillent avec des Google Forms pourris ou des macros Excel qui traînent dans le coin depuis 2003.

Ackify tourne en Docker distroless, s’installe en 5 minutes avec un script, et fonctionne sur PostgreSQL 16. L’authentification se fait via Magic Link sans mot de passe, ou OAuth 2 si vous préférez Google, GitHub ou GitLab. Ensuite, une fois connecté, vous lisez le document, vous cliquez sur “J’ai lu”, et c’est terminé. Une signature cryptographique Ed25519 est générée, le checksum SHA-256 du document est vérifié, et tout part dans un audit trail immuable.

Le principe est donc super solide et chaque utilisateur ne peut signer qu’une seule fois par document. Ensuite, vous en tant qu’admin, vous avez un dashboard pour tracker qui a lu quoi. Il y a également des rappels automatiques par email pour ceux qui traînent et des widgets que vous pouvez intégrer dans votre intranet si ça vous amuse !

Sans oublier que c’est multi-lingue !

Bref, que ce soit pour obtenir des attestations de lecture de politiques de sécurité, des formations internes avec validation, la prise en compte de directive RGPD, des procédures de conformité…etc, Ackify pourra vous aider sans avoir à sortir l’artillerie lourde de la signature électronique traditionnelle.

Voilà, c’est gratuit, open source et vous pouvez avoir tous les détails sur le site officiel du projet : ackify.eu .

Vous vous souvenez de la dernière fois où vous avez dû redémarrer un container Docker en urgence depuis votre téléphone, planqué dans les chiottes du resto un jour de St Valentin ?

Le minuscule clavier, la connexion SSH qui rame, les commandes qu’on tape mal parce que l’autocorrect veut absolument transformer “docker ps” en “docker pas”, l’écran trop petit pour lire les logs… Bref, la grosse merde !!

Heureusement, Docker Manager débarque pour transformer ce cauchemar en expérience qui fait plaisir aux yeux. C’est une app Android qui gère vos containers Docker à distance, et c’est tellement bien foutu que vous allez enfin arrêter d’ouvrir votre laptop n’importe où juste pour faire un simple restart.

C’est vrai que faire du SSH depuis un smartphone, ça a toujours été possible. Y’a même plein d’apps terminal mobiles, de clients fait pour ça, même des bidouilles pour se connecter à vos serveurs. Mais “possible” et “agréable”, c’est pas vraiment la même chose.

Grâce à Docker Manager ce sera donc possible ET agréable ! Vous gérez déjà Docker, vous connaissez déjà les commandes, vous savez ce que vous faites mais au lieu de vous faire taper des commandes dans un terminal de 5 pouces, l’app vous offre une interface utilisateur carrée avec des boutons, des statistiques en temps réel, des logs lisibles, et même un shell interactif quand vous en avez vraiment besoin !

Vous connectez donc vos serveurs via SSH (mot de passe ou clé, comme d’hab), et hop, vous aurez accès à tout. Start/stop/restart de containers, inspection des images, gestion des volumes et des networks, stats CPU/RAM en direct… Tout ce que vous feriez normalement en SSH, mais sans vous arracher les yeux sur un terminal mobile.

Autre truc sympa, l’app supporte plusieurs serveurs, donc vous pouvez switch entre votre VPS perso, votre homelab, et votre serveur de prod en deux tapotages ^^. Elle gère aussi les VPN comme Tailscale, donc si vos serveurs sont derrière un réseau privé, pas de problème. Elle propose même des thèmes light/dark, parce que oui, même en pleine nuit à 3h du matin quand un container plante, vous avez le droit à votre petit confort visuel.

L’app supporte aussi Podman. Vous configurez juste votre CLI Docker custom, et ça marche ! Et en plus, c’est open source ! Vous pouvez même faire du cleanup système pour virer les images et containers qui traînent histoire de faire un peu de ménage.

L’app est dispo sur le Play Store et sur GitHub pour ceux qui veulent build depuis les sources ou juste regarder le code. Testez, vous verrez, ça change la vie.

Merci à Friendly_0day pour le partage !

Bon, si vous me lisez depuis loooongtemps, vous connaissez forcément le risque que représentent les métadonnées contenues dans les images que vous partagez en ligne. Oui, je parle bien des fameux EXIFs qui contiennent aussi bien le modèle d’appareil photo utilisé, l’heure précise à la seconde près où vous avez pris le cliché, les réglages de l’objectif, parfois même l’altitude, et surtout les coordonnées GPS exactes de l’endroit où vous étiez.

Et toutes ces données, si vous mettez vos photos en ligne par exemple, chez Google ou Apple, et bien eux les récupèrent et les utilisent. C’est dommage, surtout que ce sont des données qui sont quand même utiles pour peu qu’on garde ça en local sur sa machine.

Alors que faire ?

Hé bien, il existe un logiciel open source sous licence MIT qui s’appelle ChronoFrame . C’est une galerie photo que vous pouvez héberger vous-même, qui va parser automatiquement toutes les données exif de vos clichés, extraire la géolocalisation, faire du reverse géocoding pour identifier le lieu exact et afficher tout ça sur une espèce de carte interactive sur laquelle vous pouvez naviguer pour revoir vos souvenirs de voyage.

En gros c’est comme Google Photo sauf que c’est vous qui gérez vos données et vous contrôlez qui accède à quoi.

L’intérêt de ChronoFrame, c’est qu’il rend visible l’invisible. Vous uploadez une image, ChronoFrame lit les métadonnées, extrait les coordonnées GPS si elles existent, et lance un appel à l’API Mapbox ou MapLibre pour faire du reverse geocoding. Ça, ça veut dire transformer des coordonnées GPS (48.8584, 2.2945) en adresse lisible (“Tour Eiffel, Paris, France”).

Et surtout, ChronoFrame supporte les Live Photos d’Apple ET les Motion Photos de Google. La génération de miniatures, quand à elle, utilise ThumbHash , un algorithme de placeholder ultra-compact créé par Evan Wallace (cofondateur de Figma). Ainsi au lieu de générer plusieurs tailles de miniatures (100x100, 200x200, 400x400…etc), ThumbHash encode une version floue de l’image dans moins de 100 bytes et comme ça, les vignettes se chargent instantanément, et l’affichage est ensuite progressif (flou -> net) jusqu’à ce que l’image full résolution arrive.

L’interface est bien sûr responsive, supporte le touch et la navigation par gestes, et donne une expérience proche d’une app native. Pour la déployer, vous devez créer un fichier .env avec vos variables d’environnement (email admin, mot de passe, provider de stockage, token Mapbox…etc), vous lancez docker pull ghcr.io/hoshinosuzumi/chronoframe:latest, et hop, ça tourne direct.

Le guide de démarrage détaille tout le process et ça vous prendra 5 minutes chrono.

Voici un exemple de configuration minimale :

CFRAME_ADMIN_EMAIL=admin@chronoframe.com
CFRAME_ADMIN_PASSWORD=VotreMotDePasse
NUXT_PUBLIC_MAP_PROVIDER=maplibre
NUXT_PUBLIC_MAP_MAPLIBRE_TOKEN=votre_token_maptiler
NUXT_STORAGE_PROVIDER=local
NUXT_PROVIDER_LOCAL_PATH=/app/data/storage
NUXT_SESSION_PASSWORD=$(openssl rand -base64 32)

NUXT_STORAGE_PROVIDER=s3
NUXT_PROVIDER_S3_ENDPOINT=https://s3.amazonaws.com
NUXT_PROVIDER_S3_BUCKET=votre-bucket
NUXT_PROVIDER_S3_REGION=eu-west-1
NUXT_PROVIDER_S3_ACCESS_KEY_ID=votre_key
NUXT_PROVIDER_S3_SECRET_ACCESS_KEY=votre_secret

Les Linuxiens ont beau dire que Linux peut TOUT faire, ils gardent presque tous un dual-boot ou une VM Windows planquée quelque part pour lancer Photoshop ou remplir une page web administrative qui plante sous Firefox. C’est ça la définition du déni, les amis ^^.

Alors bien sûr, y’a Wine qui existe depuis plus de 20 ans, mais bon faut bidouiller des préfixes, installer des DLL manquantes, fouiller sur WineHQ et au final, c’est toujours du rafistolage à se taper.

Alors comme le fait Winapps , il y a aussi WinBoat , un outil capable de faire tourner un Windows dans un container Docker. Pas d’émulation, pas de traduction d’API, pas de prière à saint Wine pour que votre app se lance. Ça lance de vraies apps Windows !

Techniquement, WinBoat utilise donc Docker et KVM pour faire tourner Windows dans un container. Electron gère l’interface, FreeRDP se connecte à Windows via le protocole RemoteApp, et vos apps Windows apparaissent comme des fenêtres normales sur votre bureau Linux.

Vous cliquez sur une icône, hop, l’app se lance, et vous oubliez qu’il y a une VM qui tourne en arrière-plan.

L’installation de Windows est également automatisée. Vous lancez WinBoat, ça télécharge et configure tout, tout seul, et après c’est prêt. L’intégration filesystem permet d’accéder vos fichiers Linux depuis les apps Windows et le passthrough USB et smartcard fonctionne, ce qui règle le problème des signatures électroniques pour les démarches administratives dont je parle un peu plus haut.

Photoshop, Illustrator, InDesign, c’est clair que ces apps ne tourneront jamais correctement sous Wine parce qu’Adobe n’a jamais pensé son code pour être portable alors qu’avec WinBoat, elles tournent. Office 365 aussi, pour les boîtes qui imposent Teams et SharePoint. Ah et Affinity Photo pareil ça roule impecc aussi.

WinBoat assume quand même ses limites dès le départ car y’a pas de passthrough GPU pour le moment, donc les apps lourdes en 3D rameront. Pas de support non plus des jeux avec anti-cheat, mais le Steam Deck fait ça mieux de toute façon. Et notez qu’il vous faudra minimum 4 Go de RAM rien que pour WinBoat, parce qu’un Windows léger ça n’existe pas !

Le projet est open source sous licence MIT, gratuit, dispo en AppImage, .deb, .rpm, ou via AUR pour Arch. Docker CLI est obligatoire, mais pas Docker Desktop et FreeRDP 3.x.x avec le support son aussi. KVM aussi doit être activé sur votre système.

Bref, WinBoat c’est comme Winapps, très sympa à tester car ça marche très bien même si les perfs ne seront jamais celles d’un Windows natif. C’est dispo sur GitHub avec toute la doc si ça vous chauffe.

Merci à Lorenper pour le soft.

Si vous faites partie des anciens qui continuent à collectionner les liens sympa que vous trouvez sur le net, j’sais pas comment vous les gérez, mais j’ai peut-être un truc pour vous. Ça s’appelle Linkding (rien à voir avec le site rempli de teubés en costard qui parlent comme des IA nulles) et c’est un gestionnaire de bookmarks qu’on installe chez soi !

Hé oui, les champions de l’auto-hébergement, Linkding ne cherche pas à réinventer la roue… Il stocke juste vos liens, vos tags, vos notes en Markdown, et basta ! L’interface est sobre, lisible, et surtout elle ne vous balance pas des suggestions sponso à la con entre deux articles que vous vouliez lire plus tard.

Ce projet est open source sous licence MIT, et repose sur Django et SQLite. Donc c’est du solide ! SQLite pour la base de données, ça veut dire zéro configuration serveur et pas de grosse maintenance.

Vous installez le truc dans un container Docker, et ça tourne sur n’importe quoi. Ensuite, vous ajoutez un bookmark, et Linkding va automatiquement chercher le titre de la page, sa description, son icône, même une image de preview.

Autre truc cool prévu dans l’outil, c’est la possibilité de faire de l’archivage web car oui, Linkding peut créer des snapshots de chaque page que vous bookmarkez, soit en local sous forme de fichier HTML, soit via Internet Archive.

Parce que oui, il arrive parfois que les liens meurent dans d’atroces souffrances. Les sites ferment, les articles disparaissent, et dans 5 ans vous vous retrouvez avec une liste bourrée d’erreurs 404.

Alors que là, au moins, avec cet outil, vous avez une copie.

L’extension navigateur est aussi indispensable pour ajouter des bookmarks vite fait ! Elle est disponible pour Firefox et Chrome, et elle vous permet de les tagger à la volée, et même de chercher dans votre collection directement depuis la barre du navigateur. Ça ressemble un peu à ce qu’on avait avec Del.ici.ous à l’époque, en mieux.

Linkding gère aussi le multi-utilisateurs donc vous pouvez partager certains bookmarks avec d’autres personnes, ou les garder privés. C’est super pratique si vous l’installez pour toute la famille ou une petite équipe. Il y a même une API REST, donc si vous voulez automatiser des trucs ou créer vos propres outils autour, c’est possible !!

Y’a aussi une version PWA installable aussi donc vous pouvez l’ajouter à votre écran d’accueil sur mobile et l’utiliser comme une app native !

Une fois que vous y aurez goûté, difficile de revenir en arrière !

Pour tester, y’a une démo en ligne et l’installation prend moins de 10 minutes ! Ce serait dommage de s’en priver

Vous voulez regarder une vidéo YouTube avec des potes qui habitent à l’autre bout du monde sans que ça rame ? Ou vous devez faire une démo produit à un client sans avoir à lui envoyer 50 captures d’écran ? Ou mieux vous avez besoin d’un navigateur jetable qui ne laisse aucune trace après utilisation ?

Et bien pour tout ça et plus encore, voici Neko , un navigateur virtuel auto-hébergé qui tourne dans Docker et utilise WebRTC pour streamer l’écran à plusieurs utilisateurs en même temps. C’est un outil développé par m1k1o et ça permet de créer très facilement des sessions de navigation partagées avec une latence inférieure à 300 millisecondes.

Vous lancez donc Neko sur votre serveur Docker, vous accédez à l’interface web, et vous avez un navigateur complet qui tourne dans le cloud. Plusieurs personnes peuvent se connecter à la même session et voir exactement le même écran en temps réel. L’hôte de la session peut également donner ou retirer le contrôle aux participants. Un peu comme quand on partage son écran sur Zoom, mais en mieux parce que tout le monde voit le même flux avec une qualité parfaite.

D’ailleurs, la technologie derrière est plutôt intéressante puisque ça utilise du WebRTC. Ainsi, le flux média ne transite pas par un serveur centralisé mais directement en peer-to-peer entre les navigateurs. Les médias circulent via SRTP et les données via SCTP, du coup, vous avez un streaming ultra-fluide avec synchronisation audio et vidéo impeccable.

Neko affiche sur son site plusieurs cas d’usage assez pratiques. Vous pouvez par exemple organiser des watch party pour regarder des films ou séries ensemble. Vous pouvez aussi pourquoi pas faire des présentations interactives où tout le monde voit la même chose en direct. Vous pouvez l’utiliser pour du support technique à distance en montrant exactement sur quoi cliquer. Ou tout pour du debugging collaboratif quand vous galérez sur un bug avec un collègue.

Le projet supporte aussi l’automatisation avec Playwright ou Puppeteer, donc vous pouvez scripter des actions dans le navigateur virtuel. Pratique si vous devez faire des tests automatisés ou des interactions complexes sur des sites web.

Niveau sécurité et vie privée, Neko propose deux modes. Le mode persistent browser garde les sessions entre les connexions, donc vous pouvez retrouver vos onglets et votre historique. Et le mode throwaway browser qui crée une session isolée qui est détruite après utilisation, sans historique, cookies ou cache. Zéro trace !

Vous pouvez aussi l’utiliser comme jump host (hôte relais quoi…) pour accéder à des ressources internes de votre réseau sans exposer directement ces ressources. Ou pour protéger la propriété intellectuelle en permettant à des gens de consulter des documents sensibles sans pouvoir les télécharger ou les copier.

L’installation se fait via Docker avec plusieurs images disponibles puisque vous avez le choix entre Firefox, Chrome, Brave et d’autres navigateurs. Le projet est d’ailleurs assez complet avec des projets satellites comme Neko Rooms pour gérer plusieurs salles, Neko Apps pour créer un environnement virtuel complet dans le navigateur, et Neko VPN pour des connexions sécurisées. Vous pouvez même broadcaster sur Twitch, YouTube ou n’importe quel service compatible RTMP directement depuis Neko.

Notez que Neko ne se limite pas qu’aux navigateurs puisque vous pouvez faire tourner n’importe quelle application Linux dedans, comme VLC par exemple. C’est en réalité plutôt une machine virtuelle streamée qu’un simple navigateur.

Le projet est sous licence Apache 2.0, donc c’est complètement open source et il y a aussi un serveur Discord actif pour échanger avec la communauté.

Bref, si vous cherchez une alternative aux solutions propriétaires pour le partage d’écran ou les watch party, Neko fera le job. Et comme c’est auto-hébergeable et hyper flexible, vous gardez le contrôle sur vos données tout en ayant une grande liberté sur l’usage que vous en ferez ! A tester donc !

Merci à Lorenper pour le partage.

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.

Je vous ai fait une vidéo tuto dessus ! Et c’est grâce aux Patreons qui me soutiennent, alors merci à eux !

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

Vous saviez que des milliers de caméras de surveillance sont accessibles sans mot de passe sur Internet ? Et bien Cameradar est l’outil qui vous aidera à trouver ces caméras vulnérables en quelques secondes. Et bien sûr, comme je suis super sympa, je vais vous montrer comment ça marche (pour tester VOS caméras, bien sûr).

Développé par Ullaakut, Cameradar est un scanner RTSP open source écrit en Go qui fait trois trucs essentiels : il détecte les flux RTSP sur un réseau, identifie le modèle de caméra, et lance des attaques par dictionnaire pour trouver les identifiants. En gros, c’est l’outil parfait pour vérifier si vos caméras sont bien sécurisées.

Voici un truc vraiment cool qui va plaire aux fans d’auto-hébergement. Vous le savez, moi j’adore les petits outils pratiques, mais j’en ai marre de devoir uploader mes fichiers sur des services tiers qui vont ensuite les analyser, les stocker et probablement entraîner une IA dessus. Et bien figurez-vous que j’ai trouvé LA solution : Omni Tools.

En gros, c’est une collection d’outils web que vous hébergez vous-même et qui fait tout le traitement directement dans votre navigateur. Mais genre vraiment tout sans que vos fichiers ne quittent jamais votre machine. En plus, c’est léger puisque l’image Docker ne pèse que 28 MB !

Sorry Docker, y’a un nouveau sheriff en ville ! Apple vient de lâcher un bombe à la WWDC 2025 avec son outil de containerisation natif pour macOS 26, et franchement, ça sent le roussi pour Docker. Fini les galères de performance, les ressources qui partent en vrille et les contournements foireux pour faire tourner vos containers Linux sur machine Apple ! Cool, hein ?

Si vous développez sous Mac, vous connaissez le refrain : Docker Desktop qui bouffe la RAM comme un goret (facilement 4-5 Go en idle), des performances de container dignes d’un Pentium II sous Windows ME, et cette sensation permanente que votre MacBook M3 Ultra à 4000 balles se comporte comme un Raspberry Pi dès qu’il s’agit de faire du container.

Google Photos, c’est super pratique, mais est ce vraiment bien raisonnable de confier 15 ans de souvenirs à une entreprise américaine en ce moment ? Surtout qu’ils changent de conditions d’utilisations encore plus souvent que vous ne changez de slip, c’est dire !! (parce oui, vous n’en changez pas assez souvent.)

Dans ce cas, si vous préférez adopter la vibe “auto-hébergement” pour vos photos, je vous invite à découvrir Lychee qui débarque en version 6 cette année ! Il s’agit d’une solution de gestion de photos qui fait enfin jeu égal avec les géants du logiciel et en plus c’est totalement open source.

Vous en avez marre de la valse des emails pour planifier une simple réunion ? Bienvenue au club ! Heureusement, j’ai déniché un petit bijou open source qui va vous changer la vie : Rallly.

Rallly (avec 3 L), c’est l’outil parfait pour organiser vos événements sans prise de tête. Son concept est simple mais diablement efficace. Vous créez un sondage avec les dates et heures qui vous conviennent, vous invitez les participants et hop, chacun vote pour son créneau préféré. Comme ça, terminé le casse-tête pour trouver un moment qui arrange tout le monde !

Sous son interface épurée, Rallly cache une machinerie bien huilée. Développé en Next.js, Prisma et tRPC, le backend assure un service aux petits oignons et côté front, TailwindCSS apporte une touche d’élégance sans sacrifier la performance.

Mais la cerise sur le gâteau, Rallly est entièrement open source ! Vous pouvez donc héberger votre propre instance en un clin d’œil grâce à Docker. Clonez le dépôt GitHub, configurez vos variables d’environnement, lancez Docker Compose et voilà, votre Rallly personnel est prêt à l’emploi.

L’installation se fait en quelques commandes :

git clone https://github.com/lukevella/rallly.git
cd rallly
cp sample.env .env (et éditer le fichier pour la config)
yarn
yarn db:setup (ou "yarn dx" si vous n'avez pas de base postgres qui tourne)
yarn dev

Et si vous voulez passer à la vitesse supérieure, suivez le guide pour déployer votre instance avec Docker Compose. Bien sûr, vous pouvez garder le contrôle sur qui peut accéder à votre instance. Il suffit de renseigner les adresses email autorisées dans votre fichier de configuration et vous pouvez même utiliser des wildcards (*) pour autoriser des domaines entiers.

Une fois votre serveur opérationnel, créer un sondage devient alors un jeu d’enfant. Choisissez vos options de date et d’heure, envoyez le lien à vos invités et laissez la magie opérer. Vous pouvez par exemple restreindre le nombre de votes par participant, histoire d’éviter les abus. Ou encore clôturer un sondage quand bon vous semble. Et comme ça, plus besoin de relancer les retardataires ou de jongler entre les agendas.

La plupart des options sont gratuites mais quelques fonctionnalités avancées nécessitent quand même un compte payant. Quoiqu’il en soit, c’est un super outil que je vous recommande !

Theme Park est une méga collection de thèmes CSS pour donner un coup de pep’s à tous vos outils chouchous : Deluge, Emby, Flood, Jackett, Jellyfin, Lidarr, Nzbget, Nzbhydra2, Ombi, Organizr, Overseerr, Plex, Portainer, Prowlarr, Qbittorrent, Radarr, Readarr, Rutorrent, Sabnzbd, Sonarr, Tautulli, Transmission, Unraid, Whisparr, et une tripotée d’autres.

Y’en a pour tous les goûts, du plus classieux au plus funky. Avec juste quelques lignes de code, vous allez pouvoir affirmer votre style unique.

Adieu la grisaille, bonjour les couleurs flashy et les designs innovants !

Et le kif, c’est que c’est hyper simple à mettre en place. Vous avez l’embarras du choix niveau installation : Docker, scripts personnalisés, Nginx, Apache… Bref, que vous soyez un newbie ou un pro du terminal, vous allez pouvoir en profiter en deux temps trois mouvements. Et si vous avez besoin d’un coup de main, la doc est là pour vous guider pas à pas.

Un exemple avec Plex :

Ou encore une personnalisation de Bitwarden :

Mais attendez, c’est pas fini ! Le vrai plus de Theme Park, c’est sa communauté de passionnés. On parle de vrais artistes qui partagent leurs créations avec générosité. Vous allez pouvoir piocher dans un catalogue de thèmes toujours plus étoffé, ou même proposer vos propres chefs-d’œuvre.

Si ça vous intéressez, rendez-vous sur https://theme-park.dev/ et vous pourrez commencer à bidouiller et personnaliser vos apps pour les rendre unique.

Concocté par le français Kévin Dunglas, contributeur de longue date à l’écosystème PHP et membre de la Core Team Symfony, FrankenPHP va peut-être dépoussiérer un peu votre bon vieux serveur LAMP tout fatigué.

Il s’agit d’un serveur d’applications PHP moderne développé en Go qui s’appuie sur le serveur web de pointe Caddy. D’après son auteur, tous vos projets PHP, y compris Laravel, Symfony, Drupal, WordPress, Sulu et API Platform, seront optimisés comme jamais grâce à l’intégration native du mode worker.

Moins de lenteurs, plus de perf, et surtout pas mal de fonctionnalités avancées telles que les Early Hints pour un affichage éclair, la prise en charge d’HTTP/2 et HTTP/3 pour une navigation optimale, la compression Brotli, Zstandard et Gzip, les logs structurés, le support de Prometheus pour les métriques, et même du temps réel avec Mercure. Que vous soyez accro à Symfony, fan d’API Platform ou un inconditionnel de Laravel, FrankenPHP s’occupera de tout et d’après les benchmarks visibles sur le site officiel, il booste même les performances jusqu’à 3,5 fois plus vite que FPM sur les applications de type API Platform.

Conçu dans un souci de simplicité, ce serveur PHP n’a besoin que d’un seul service et d’un seul binaire. Pas besoin de PHP-FPM, il utilise son propre SAPI (Server API) spécialement conçu pour les serveurs web Go. Il peut être déployé facilement comme une application Cloud Native via une image Docker, et est compatible avec Kubernetes et toutes les plateformes Cloud modernes. Vous pouvez même packager votre application PHP comme un binaire statique autonome et auto-exécutable.

Si vous voulez le tester, vous pouvez soit lancer le binaire, soit utiliser Docker comme ceci :

docker run -v $PWD:/app/public -p 80:80 -p 443:443 -p 443:443/udp dunglas/frankenphp

En deux temps trois mouvements, vous voilà avec un serveur web + PHP 8.2 aux petits oignons ! Y’a plus qu’à mettre votre PHP dans le répertoire de Franken et tadaaa…

Si c’est le binaire que vous récupérez, vous pouvez servir le contenu du répertoire courant avec la commande suivante :

./frankenphp php-server

Ou lancer vos scripts en ligne de commande comme ceci :

./frankenphp php-cli /chemin/vers/votre/script.php

Bref, vous démarrez votre app une fois, et hop, elle reste en mémoire, prête à faire tourner votre site. Caddy gère l’HTTPS automatiquement avec génération, renouvellement et révocation des certificats. Il sert aussi les assets, pendant que PHP fait ce qu’il fait de mieux : exécuter votre code sans faillir. Vous pouvez même intégrer PHP dans n’importe quelle application Go en mode bibliothèque.

Et pour démarrer un serveur Caddy en prod avec FrankenPHP sans utiliser Docker, il suffit de cette configuration ultra simple:

{
    # Activer FrankenPHP 
    frankenphp
    order php_server before file_server
}

localhost {
    # Activer la compression (optionnel)
    encode zstd br gzip  
    # Exécuter les fichiers PHP dans le répertoire courant et servir les ressources
    php_server
}

Ça change un peu !

En tout cas, c’est à tester ! Bravo Kévin, j’ai hâte de voir comment ça va évoluer pour la suite !

Vous pensiez que vos secrets étaient en sécurité dans vos images Docker ? Détrompez-vous ! Une étude de l’Université d’Aix-la-Chapelle a révélé que près de 10% des images publiques sur DockerHub contenait des secrets (donc des identifiants, des clés API, des mots de passe, des endpoints sensibles…Etc).

Ça fait froid dans le dos.

On parle de plus de 50 000 clés d’API et d’identifiants accessibles publiquement. Et ce n’est que la partie émergée de l’iceberg puisque les chercheurs de Redhunt Labs ont aussi trouvé plus de 46 000 Dockerfiles exposant des infos sensibles. Bref, c’est la fête du slip côté sécurité !

Mais comment ces secrets se retrouvent-ils à fuiter comme une passoire ? Et bien c’est souvent, c’est à cause d’opérations de fichiers trop permissives, de secrets mis en dur dans les Dockerfiles…etc

Par exemple, beaucoup de tutos et même la doc officielle de Docker suggèrent d’utiliser COPY . . pour copier tout le répertoire courant dans l’image. Sauf que ça inclut aussi les fichiers sensibles comme .env ou l’historique Git. Pas top pour la confidentialité.

Et même si vous supprimez ces fichiers sensibles après le COPY, ils restent présents dans les couches précédentes de l’image. Un attaquant pourra donc toujours y accéder. Merci les layers 🙂

Autre coup classique : mettre directement les secrets dans le Dockerfile ou les passer en argument au build. Là encore, c’est cadeau pour les hackers. Un simple docker history --no-trunc et hop, vos secrets sont à nu.

Heureusement, il existe des solutions pour sécuriser tout ça. Par exemple, les builds multi-stages permettent d’isoler les secrets dans une étape intermédiaire qui ne sera pas conservée dans l’image finale. Et depuis peu, BuildKit propose une option --secret pour injecter les secrets sans les stocker dans l’image, mais attention aux pièges ! Si votre app log le secret qu’elle utilise, il finira quand même dans l’image. Les builds multi-stages restent donc plus safe de ce côté là.

Bref, vous l’aurez compris, la gestion des secrets dans Docker, c’est pas de la tarte mais en suivant les bonnes pratiques, vous pourrez limiter les risques.

Bref, pensez builds multi-stages, utilisez .dockerignore, oubliez les secrets en dur et n’abusez pas des arguments de build. Et surtout, ayez le réflexe d’auditer vos images avec des outils comme TruffleHog. Parce qu’un secret qui fuite, c’est votre réputation qui coule.

Vous voulez envoyer des emails chiffrés de bout en bout avec votre client mail favori, mais sans vous prendre la tête ? J’ai ce qu’il vous faut les amis : le projet open source ProtonMail Bridge pour Docker de mon gars sûr DaTux, un fidèle lecteur de Korben.info que je croise souvent sur mon live Twitch.

Ce mec a passé plus de temps à rédiger le README.md de son projet qu’à le coder, mais le résultat est là : une version dockerisée de l’interface en ligne de commande de ProtonMail Bridge qui crée un serveur SMTP local. Comme ça, vos autres conteneurs Docker peuvent envoyer des mails via votre compte ProtonMail. La classe, non ?

Bon par contre, petit bémol : pour l’instant, il faut un compte payant (Mail Plus, Proton Unlimited ou Proton Business) pour se connecter. Ça marchera pas avec les comptes gratuits. Mais vu le niveau de confidentialité et de sécurité que ça apporte à vos échanges d’emails pro, ça les vaut !

Pour commencer, récupérez la dernière image Docker avec :

docker pull ghcr.io/videocurio/proton-mail-bridge:latest

Ou la version allégée basée sur Alpine Linux :

docker pull ghcr.io/videocurio/proton-mail-bridge-alpine:latest

Ensuite, lancez le conteneur en exposant les ports TCP 12025 pour SMTP et 12143 pour IMAP sur votre interface réseau locale.

docker run -d --name=protonmail_bridge -v /path/to/your/volume/storage:/root -p 127.0.0.1:12025:25/tcp -p 127.0.0.1:12143:143/tcp --network network20 --restart=unless-stopped ghcr.io/videocurio/proton-mail-bridge:latest

N’oubliez pas de fournir un volume pour la persistance des données (mkdir /path/to/your/volume/storage).

Maintenant, ouvrez un terminal dans le conteneur en cours d’exécution et utilisez l’interface de commande interactive de ProtonMail Bridge :

docker exec -it protonmail_bridge /bin/bash

À l’intérieur, killez d’abord l’instance de bridge par défaut car une seule peut tourner à la fois :

pkill bridge

Puis connectez-vous à votre compte ProtonMail (rappel : faut un compte payant) :

/app/bridge --cli

Suivez les instructions à l’écran, renseignez votre nom d’utilisateur, mot de passe et code 2FA. Une synchro de votre compte va commencer. Prenez un café en attendant ! Si vous utilisez plusieurs domaines ou adresses email, passez en mode « split » qui va vous permettre de définir des identifiants pour chaque adresse du compte.

Ensuite re-faite ceci pour resynchroniser encore un petit coup :

change mode 0

Quand c’est fini, tapez info pour récupérer les infos de connexion SMTP/IMAP générées par ProtonMail Bridge. Copiez bien l’username ET le mot de passe (différent de celui de votre compte ProtonMail !!). Vous pouvez maintenant configurer votre client mail favori avec ces identifiants, en précisant les ports SMTP 12025 et IMAP 12143 qu’on a exposés au lancement du conteneur Docker.

Et voilà, vous pouvez envoyer des emails chiffrés de bout en bout dans la plus grande des discrétion ! Évidemment, le destinataire devra aussi avoir un compte ProtonMail pour les déchiffrer de son côté.

Pour aller plus loin, j’vous conseille de jeter un œil au README hyper complet de DaTux, avec tous les détails d’install et d’utilisation. Il a même prévu une version optimisée pour tourner sur un serveur TrueNAS Scale, le bienheureux.

En soutien, n’hésitez pas à lui mettre une petite étoile sur son repo GitHub et à partager ce tuto autour de vous !

A la prochaine !

Les amis, aujourd’hui, je vais vous parler d’un projet très intéressant qui devrait ravir les utilisateurs de Discord et les amateurs de flux RSS : FeedCord. Ce lecteur RSS ultra simple s’intègre parfaitement avec Discord et vous permet de disposer d’un fil d’actualité directement dans votre serveur Discord.

Je suis depuis toujours un grand défenseur du format RSS et c’est quand même dommage que ça ait presque disparu.

Parmi les principales fonctionnalités de FeedCord, il y a donc l’intégration avec Discord, qui permet d’envoyer directement les mises à jour de vos flux RSS dans un canal Discord via un simple webhook. Côté config, c’est un jeu d’enfant puisque tout se fait dans un simple fichier JSON. Vous y ajoutez votre URL Webhook et vos flux RSS et en avant Guingamp !! FeedCord dispose également une prise en charge via Docker, ce qui facilite grandement le déploiement. C’est d’ailleurs la méthode d’install recommandée par les dev du projet.

Alors, comment installer FeedCord avec Docker ?

Tout d’abord, il vous faudra créer un webhook Discord.

Ensuite, il faudra mettre en place FeedCord en créant un dossier FeedCord à l’emplacement souhaité, puis en créant un fichier de configuration appsettings.json à l’intérieur de ce dossier avec le contenu approprié. Vous trouverez toutes les informations nécessaires et des exemples de configuration dans la documentation du projet.

{
  "RssUrls": [
    "YOUR",
    "RSS URLS",
    "HERE"
  ],
  "YoutubeUrls": [
    "YOUR",
    "YOUTUBE CHANNEL URLS",
    "HERE",
    "eg. https://www.youtube.com/@IGN"
  ],
  "DiscordWebhookUrl": "https://discordapp.com/api/webhooks/1139357708546478200/ncB3dshJOPkQhthwOFQibeNt6YI-1_DiFbg0B3ZecfxchnbCGQNdG-m3PxqDdDSvt5Kk",
  "RssCheckIntervalMinutes": 3,
  "EnableAutoRemove": true,
  "Username": "FeedCord",
  "AvatarUrl": "https://i.imgur.com/1asmEAA.png",
  "AuthorIcon": "https://i.imgur.com/1asmEAA.png",
  "AuthorName": "FeedCord",
  "AuthorUrl": "https://github.com/Qolors/FeedCord",
  "FallbackImage": "https://i.imgur.com/f8M2Y5s.png",
  "FooterImage": "https://i.imgur.com/f8M2Y5s.png",
  "Color": 8411391,
  "DescriptionLimit": 200
}

Une fois ces étapes réalisées, il vous faudra déployer FeedCord avec Docker en créant un fichier docker-compose.yaml dans le dossier FeedCord et en y ajoutant le contenu adéquat.

version: "3.9"

services:
  myfeedcord:
    image: qolors/feedcord:latest # for amd64 architecture
    # image: qolors/feedcord:latest-arm64  # For arm64 architecture (Uncomment this line and comment the above if using arm64)
    container_name: FeedCord
    restart: unless-stopped
    volumes:
      - ./PATH/TO/MY/JSON/FILE/appsettings.json:/app/config/appsettings.json

Notez qu’il faudra remplacer les chemins vers votre fichier appsettings.json et adapter l’image Docker utilisée en fonction de l’architecture de votre système. Enfin, il vous suffira d’exécuter la commande

docker-compose up -d

dans votre terminal, depuis le répertoire FeedCord, pour récupérer l’image FeedCord la plus récente à partir de Docker Hub et lancer le service.

Et voilà, avec ces quelques étapes simples, FeedCord devrait maintenant être opérationnel et publier les mises à jour de vos flux RSS directement dans votre canal Discord. Pensez à rajouter le flux RSS de Korben.info pour ne manquer aucune de mes actus : https://korben.info/feed

Pour en savoir plus sur FeedCord, n’hésitez pas à vous rendre sur le dépôt GitHub à l’adresse suivante : https://github.com/Qolors/FeedCord.

Merci à Lorenper

Je ne sais pas si vous trainez sur Twitter, depuis qu’Elon en a pris la (mauvaise) direction, mais en ce qui me concerne, j’étais là avant lui, et je serai là après lui. Donc je reste sur Twitter malgré sa faune parfois un peu glauque.

Mais ça ne m’empêche pas d’être également présent sur Bluesky et Mastodon, même si je ne les utilise pas vraiment. J’essaye quand même d’y partager mes articles. D’ailleurs, pour Bluesky, je me suis fait une moulinette en python, qui me permet d’y automatiser le post de mes articles de blog avec l’aide de ChatGPT pour que ce soit encore plus naturel.

Mais si vous ne voulez pas trop vous prendre la tête, y’a Louis Grasset qui a mis en ligne Touitomamout (Jeu de mots ^^ : Tweet To Mammouth). Il s’agit d’un outil qui peut s’installer sur votre machine / serveur / docker et qui permet de faire du cross-post depuis Twitter vers Mastodon et / ou Bluesky. En plus des messages textes, des images, des vidéos ou encore des gifs animés, l’outil permet même si vous le désirez de synchroniser l’entièreté de votre profil (nom, avatar, bannière, description).

Pour le faire tourner dans Docker, c’est easy. Il vous suffit de créer un docker-compose.yml et de mettre ça dedans :

version: '3.9'

services:
  touitomamout:
    container_name: "touitomamout"
    image: louisgrasset/touitomamout:latest  # Or "ghcr.io/louisgrasset/touitomamout:latest"
    restart: unless-stopped
    environment:
      - ENV_FILE=/data/.env
      - STORAGE_DIR=/data
    volumes:
      - ./data:/data

Puis de lancer la commande suivante :

docker-compose up -d

Et voilà de beaux comptes de réseaux sociaux bien synchronisés. Bravo Louis !

Vous êtes vous déjà demandé pourquoi tous vos projets partaient en couille ?

C’est probablement parce que vous n’avez pas encore trouvé le bon outil pour les planifier ! C’est pourquoi aujourd’hui, je tiens à vous présenter un projet open source à autohéberger qui s’appelle Plane !

Oui, comme l’avion. Bien qu’encore en développement, cet outil, est déjà suffisamment cool pour vous donner envie de l’utiliser afin de suivre vos tâches, vos sprints et autres feuilles de route.

L’interface est plutôt agréable et vous permettra d’afficher les projets, d’y ajouter des pièces jointes, de créer des workflows maison, mais également d’importer toutes les tâches directement depuis d’autres outils comme Github ou Jira. Et bien sûr recevoir des notifs dans Slack, Discord et vos propres outils puisqu’il y a même une API.

Vous pouvez également utiliser des cycles pour planifier des sprints, diviser les projets en modules et créer des filtres personnalisés pour trier les informations comme bon vous semble. Plane offre également la possibilité de faire de la documentation directement au fur et à mesure du développement de votre projet et tout s’intègre parfaitement à Github pour conserver à la fois votre code et vos issues synchronisées avec Plane.

Vous verrez, Plane est assez plaisant à prendre en main puisqu’il y a même Command K, un genre d’interface rapide à Spotlight pour chercher des tâches, créer de nouvelles actions….etc. sans oublier un petit bloc-notes propulsé à base de ChatGPT pour les grosses feignasses qui n’aiment pas écrire.

Si ça vous branche, il n’y a plus qu’à découvrir Plane et kiffer la vie de projets ! Pour apprendre à l’installer avec Docker, c’est par ici.