Ce serait quand même bien quand on réinstalle Linux from scratch pour la énième fois, qu’il y ait un moyen rapide de résinstaller tous nos outils préférés sans avoir à se retaper toutes les commandes d’installation une par une.

Et bien, si vous avez le même rêve que moi, vous allez adore Nixite , un petit outil qui va faire plaisir aux linuxiens.

Le principe est simple. Vous cochez les logiciels que vous voulez installer sur une interface web , et Nixite vous génère un script bash prêt à l’emploi. Ce script gère automatiquement l’installation de tous vos programmes, que vous soyez sur Ubuntu ou Arch Linux.

Ce qui est vraiment cool, c’est que Nixite ne se contente pas d’enchaîner bêtement des commandes apt ou pacman. L’outil choisit intelligemment la meilleure méthode d’installation pour chaque logiciel. Si un programme est mieux maintenu sur Flatpak, il utilisera Flatpak. Si c’est un snap qui est plus à jour, il partira sur snap. Et pour les cas particuliers, il peut même exécuter des commandes bash personnalisées.

L’interface web propose déjà une belle collection de logiciels organisés par catégories : navigateurs web, outils de communication, développement, gaming, productivité… Vous avez Discord, Zoom, VS Code, Steam, GIMP, VLC et des dizaines d’autres. En gros, tout ce dont vous avez besoin pour transformer une installation Linux toute fraîche en un système fonctionnel pour votre boulot.

Chaque logiciel est défini dans un simple fichier TOML dans le dépôt GitHub et vous pouvez spécifier des instructions communes pour toutes les distributions ou des commandes spécifiques pour Ubuntu et Arch. Par exemple :

install_system = "firefox" # Utilisera apt sur Ubuntu, pacman sur Arch

[ubuntu]
install_system = "firefox-esr" # Version spécifique pour Ubuntu

[arch]
install_system = "firefox-developer-edition" # Version pour Arch

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

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

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

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

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

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

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

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

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

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

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

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

from bytebot import ByteBotClient

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

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

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

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

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

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

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

Ça y est, c’est la rentrée et votre YouTubeur préféré a sorti 15 vidéos pendant vos vacances… Ouin !!! va tout falloir rattraper ! Ou pire, le gars a supprimé ses anciennes vidéos sans prévenir ! Heureusement, c’est le genre de problème que Subarr vient résoudre, et de manière plutôt chouette, vous allez voir.

L’idée derrière Subarr, c’est en fait de transposer la philosophie de Sonarr (qui automatise le téléchargement de séries TV) au monde chaotique de YouTube. Le développeur Derek Antrican a d’ailleurs tellement poussé le concept qu’il a même repris l’interface utilisateur de Sonarr pour que les habitués s’y retrouvent immédiatement. Et après avoir hésité avec le nom “YouTubarr”, il a même opté pour “Subarr”, un clin d’œil aux flux RSS sur lesquels repose tout le système.

Le principe est donc très simple puisqu’au lieu de scraper YouTube comme un bourrin (ce qui vous vaudrait un ban rapide), Subarr utilise les flux RSS officiels que YouTube met à disposition pour chaque playlist et chaîne. Ces flux sont limités aux 15 derniers items, mais Subarr construit sa propre base de données au fil du temps, en gardant une trace de tout ce qui passe. Une fois qu’une nouvelle vidéo est détectée, vous pouvez alors déclencher n’importe quelle action comme envoyer une notification Discord, lancer yt-dlp pour télécharger la vidéo, ou même exécuter un script custom de votre création.

Contrairement à des solutions comme TubeArchivist qui nécessite 4GB de RAM minimum, Subarr est très léger et peut tourner tranquillement sur un Raspberry Pi avec quelques centaines de MB. Le développeur insiste d’ailleurs sur ce point : Il l’a voulu volontairement minimaliste ! Pas de gestion de métadonnées complexes, pas d’interface de lecture intégrée, juste de la surveillance et du déclenchement d’actions.

L’installation se fait en trois commandes :

git clone https://github.com/derekantrican/subarr.git
cd subarr
npm install && npm run start-server

Boom, vous avez votre instance qui tourne sur le port 3000. Par contre, attention, il n’y a aucune authentification intégrée, donc si vous l’exposez sur internet, pensez à mettre un reverse proxy avec auth devant, ou utilisez quelque chose comme Cloudflare Tunnel.

Certains l’utilisent pour archiver automatiquement les chaînes de vulgarisation scientifique avant qu’elles ne disparaissent. D’autres s’en servent pour créer leur propre bibliothèque de tutoriels techniques hors ligne. Et puis il y a ceux qui veulent juste être sûrs de ne jamais rater un épisode de leur podcast vidéo favori, même quand ils partent en vadrouille sans connexion.

Le projet a quand même ses limites, qu’il faut garder en tête. D’abord, si Subarr est down pendant que 20 vidéos sont publiées sur une chaîne, vous allez en louper 5 (rappelez-vous, les flux RSS sont limités à 15 items). Ensuite, c’est vraiment conçu pour du monitoring de nouveautés, pas pour aspirer l’intégralité d’une chaîne existante. Pour ça, yt-dlp en ligne de commande reste plus adapté.

Voilà, entre ArchiveBox qui archive tout le web, les diverses interfaces web pour yt-dlp, et maintenant Subarr qui fait le pont avec l’univers *arr, on a vraiment l’embarras du choix maintenant pour construire son propre “Netflix personnel” alimenté par YouTube.

Et pour ceux qui veulent aller plus loin, il est possible de synchroniser Subarr avec ytsubs.app pour importer automatiquement toutes vos souscriptions YouTube. Vous pouvez aussi utiliser des regex pour filtrer le contenu (pratique pour exclure les Shorts ou les vidéos sponsorisées), et même chaîner plusieurs post-processeurs pour créer des workflows complexes.

Au final, Subarr c’est top pour les accros au self-hosting qui souhaitent reprendre le contrôle sur leur consommation de contenu sans dépendre du bon vouloir de l’algorithme YouTube ou de la stabilité des serveurs de Google. Avec cet outil, vos vidéos préférées seront toujours chez vous, sur votre NAS, accessibles même quand internet flanche.

Merci à Letsar pour le partage.

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

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

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

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

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

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

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

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

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

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

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

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

C’est toujours marrant de voir des outils ultra populaires mettre des années à intégrer une fonctionnalité que tout le monde bricole depuis une éternité. Et aujourd’hui, c’est au tour de NGINX qui vient enfin de franchir le pas avec l’intégration native du protocole ACME !

Pour ceux qui ne seraient pas familiers avec cet acronyme, ACME (Automated Certificate Management Environment) c’est le protocole magique qui permet d’automatiser toute la gestion des certificats SSL/TLS. Développé à l’origine par l’Internet Security Research Group pour Let’s Encrypt, c’est donc lui qui vous évite de devoir renouveler manuellement vos certificats tous les 90 jours comme un moine copiste du Moyen Âge.

Le truc vraiment cool, c’est que NGINX a décidé de faire les choses en grand car plutôt que de bricoler une solution rapide, ils ont carrément développé un nouveau module baptisé ngx_http_acme_module qui s’appuie sur leur SDK Rust. Hé oui y’a du Rust dans NGINX ! Cette approche leur permet ainsi d’avoir un module dynamique disponible aussi bien pour la version open source que pour leur solution commerciale NGINX Plus.

Du coup, fini les scripts à la con avec Certbot qui tournent en cron et qui plantent au pire moment. Maintenant, vous configurez tout directement dans votre fichier NGINX comme ceci :

acme_issuer letsencrypt {
 uri https://acme-v02.api.letsencrypt.org/directory;
 state_path /var/cache/nginx/acme-letsencrypt;
 accept_terms_of_service;
}

server {
 listen 443 ssl;
 server_name .example.com;
 acme_certificate letsencrypt;
 ssl_certificate $acme_certificate;
 ssl_certificate_key $acme_certificate_key;
}

Simple, efficace, intégré, plus besoin de jongler entre différents outils, car tout se passe dans la configuration NGINX. Ensuite, les certificats se renouvellent automatiquement, s’installent tout seuls, et vous pouvez enfin dormir tranquille.

Mais attention, selon les discussions sur LWN.net, tout n’est pas rose au pays des bisounours… La communauté a quelques réserves, et pas des moindres. Leur plus gros point de friction c’est que NGINX a décidé de lancer cette première version avec uniquement le support du challenge HTTP-01. Pour les non-initiés, ça veut dire que votre serveur doit être accessible publiquement sur le port 80 pour prouver qu’il contrôle bien le domaine.

Les développeurs frustrés pointent aussi du doigt l’absence du challenge DNS-01. Et je trouve qu’ils ont raison d’être énervés car sans DNS-01, impossible de générer des certificats wildcard (*.example.com), et impossible de sécuriser des services internes qui ne sont pas exposés sur Internet. Donc pour tous ceux qui ont des homelabs ou des infrastructures privées, c’est relou.

Surtout que Caddy, le concurrent direct de NGINX, gère ça depuis des années sans problème. Bref, l’équipe NGINX promet que les challenges TLS-ALPN et DNS-01 arriveront dans le futur, mais pour l’instant, c’est motus et bouche cousue sur les délais.

Pour ceux qui veulent tester, sachez que le code est disponible sur GitHub et des packages précompilés sont déjà disponibles. La documentation officielle explique également bien le processus d’installation et de configuration. Notez que le module utilise une zone de mémoire partagée pour coordonner les renouvellements entre les différents workers NGINX, ce qui est plutôt malin pour éviter les conflits.

Au niveau technique, le workflow est assez classique… vous configurez votre serveur ACME (Let’s Encrypt ou autre), vous allouez la mémoire partagée nécessaire, vous configurez les challenges, et le module s’occupe du reste. Les variables $acme_certificate et $acme_certificate_key sont automatiquement remplies avec les chemins vers vos certificats.

Tout ceci permet de réduire également la surface d’attaque car vous n’avez plus besoin d’avoir Certbot et toutes ses dépendances Python qui traînent sur votre serveur ou plus de scripts externes qui doivent recharger NGINX. Tout est natif, et donc c’est forcément plus sécurisé.

Perso, je trouve que c’est un pas dans la bonne direction, même si l’implémentation actuelle est limitée. Et le faut qu’ils aient codé ça en Rust montre bien que NGINX prend au sérieux la modernisation de sa base de code. Du coup, pour ceux qui ont des besoins simples avec des domaines publics, foncez tester cette nouveauté. Plus d’excuses pour avoir des certificats expirés !