30 projets open source récemment étoilés sur GitHub

L’open source est redevenu bruyant. Très bruyant.

Entre les agents IA, les scanners de vulnérabilités, les outils anti-crawlers, les dashboards de monitoring et les apps self-hosted, on peut remplir un serveur en une soirée et le regretter pendant six mois. Le vrai travail n’est plus de trouver des projets. Le vrai travail, c’est de trier. Je mets beaucoup trop d’étoiles sur GitHub. Pas parce que je compte tout installer. Ce serait le meilleur moyen de transformer un homelab en brocante numérique impossible à maintenir. Mais parce qu’une étoile GitHub, bien utilisée, est un marque-page technique. Elle dit : “ce projet répond peut-être à un problème que j’ai déjà rencontré, ou à un problème que je vais rencontrer bientôt”

Dans un homelab, le plus dur n’est pas d’installer un projet open source. C’est de savoir s’il mérite encore d’être là dans six mois. C’est exactement pour ça que je garde une veille GitHub : pas pour tout déployer, mais pour repérer les signaux faibles.

Cette sélection part donc de mes 30 stars GitHub publiques les plus récentes, récupérées depuis mon profil GitHub foudreclair et plus précisément depuis mes stars publiques. Je ne les présente pas comme un classement, ni comme une recommandation de production. Et surtout, je ne les ai pas tous testés. C’est une photographie de veille : ce qui a attiré mon attention à un moment donné, et ce que ces projets racontent de mes sujets actuels.

On y retrouve des thèmes nets : IA, sécurité, infra légère, self-hosting, dev tools, Fediverse, publication web et données personnelles. Ce qui m’intéresse, ce n’est pas la hype. C’est ce que ces projets disent des problèmes que les admins, devs et self-hosters essaient vraiment de résoudre aujourd’hui.

Cet article s’adresse surtout aux personnes qui maintiennent un homelab, un petit VPS, un site statique, ou une veille technique personnelle. Anubis m’intéresse particulièrement dans ce contexte, parce qu’il répond à un problème récent et très concret : les petits sites qui subissent le trafic de crawlers automatisés. Je ne l’ai pas encore testé ; je veux justement le faire proprement avec Pangolin, puis en tirer un article dédié sur le duo Pangolin + Anubis.

Cette liste est datée : 21 avril 2026. Elle correspond aux 30 dépôts publics les plus récemment étoilés sur mon profil GitHub au moment de la rédaction. Si je change mes stars, l’ordre public sur GitHub peut évoluer, et c’est normal. L’objectif n’est pas de figer un classement, mais de documenter une veille à un instant donné.

En bref

#

Si vous n’avez que cinq minutes, voilà mon avis :

• Le meilleur signal : la sécurité open source devient plus opérationnelle. Nuclei, Trivy, DefectDojo, OpenVAS et WAF Checker ne vendent pas du rêve, ils aident à réduire l’angle mort.
• La surprise utile : Beszel. Un monitoring léger et lisible m’intéresse plus qu’une stack gigantesque qui demande son propre monitoring.
• Le projet que je veux vraiment creuser : Anubis, parce que les petits sites subissent de plus en plus le trafic automatisé.
• La fausse bonne idée à surveiller : les agents IA. opencode et OpenClaw sont prometteurs, mais je refuse de confondre autonomie et boîte noire.
• Le rappel salutaire : Pagefind. Parfois, le meilleur outil est celui qui fait une seule chose, sans serveur, sans cluster, sans cérémonie.

Le fil rouge de l’article est simple : une étoile GitHub n’est pas une adoption. C’est le début d’un test.

À lire donc comme une veille commentée, pas comme un comparatif. Certains outils me sont déjà familiers, d’autres sont seulement repérés, et quelques-uns feront peut-être l’objet d’un vrai test documenté.

Les tendances que je vois

#

Cette liste raconte quelque chose d’assez clair : l’open source se déplace vers l’exploitation concrète.

Première tendance : la sécurité devient une routine, pas un événement. Les outils qui m’attirent ne promettent pas “la cybersécurité en un clic”. Ils aident à scanner, trier, prioriser, suivre. C’est moins sexy qu’un dashboard marketing, mais beaucoup plus utile.

Deuxième tendance : l’IA open source cherche sa place sur le poste de travail. Les agents de code et assistants personnels arrivent vite. Je suis curieux, mais méfiant. Un agent que je ne peux pas comprendre ou limiter n’a rien à faire dans mon flux de travail sérieux.

Troisième tendance : le self-hosting veut redevenir léger. Beszel, Pagefind, Zerobyte ou Anubis m’intéressent parce qu’ils répondent à des problèmes précis sans forcément imposer une plateforme complète. C’est exactement la direction que je préfère.

Quatrième tendance : la donnée personnelle revient au centre. Budget, alias email, archives Mastodon, sauvegardes : on sent une envie de reprendre la main, mais avec des outils plus propres qu’il y a quelques années.

Ma méthode de veille

#

Je ne choisis pas un projet uniquement parce qu’il a beaucoup de stars. Les stars aident à détecter un signal, mais elles racontent mal la réalité opérationnelle. Un projet très populaire peut être trop lourd, mal adapté à un petit serveur, ou simplement hors sujet pour mon usage. À l’inverse, un projet discret peut résoudre parfaitement un problème précis.

Quand je tombe sur un dépôt intéressant, je regarde d’abord le problème qu’il prétend résoudre. Si le problème est flou, la solution le sera souvent aussi. Ensuite je regarde la documentation, les exemples de déploiement, les issues ouvertes, les releases, la licence, la présence d’images Docker, et la facilité à sauvegarder ou exporter les données. Cela ne remplace évidemment pas un test réel : c’est seulement le filtre qui me donne envie d’aller plus loin.

Ma grille de lecture ressemble à ça :

• utilité réelle : le projet répond-il à un problème que j’ai déjà ?
• charge d’exploitation : combien de services, volumes, ports et secrets faut-il gérer ?
• réversibilité : peut-on exporter les données et revenir en arrière ?
• sécurité : quel est le niveau d’exposition réseau et de surface d’attaque ?
• maturité : le projet est-il documenté, maintenu et compréhensible ?
• coût matériel : est-ce raisonnable sur un VPS, un mini-PC ou une VM modeste ?

Je préfère un outil imparfait mais simple à comprendre à une plateforme brillante qui exige une demi-journée de maintenance à chaque mise à jour.

Les 5 que je testerais vraiment

#

Sur ces 30 projets récents, certains sont plus proches d’un test réel que d’autres. Si je devais ouvrir seulement cinq chantiers, je commencerais par ceux-là.

1. Nuclei : parce que mes services exposés méritent des contrôles réguliers, reproductibles et relus à la main.
2. Zerobyte : parce qu’une sauvegarde non restaurée est une croyance, pas une protection.
3. Beszel : parce qu’un monitoring léger, lisible et adapté aux petits serveurs colle bien à mon usage.
4. Pagefind : parce qu’un moteur de recherche statique peut améliorer directement ce blog Hugo.
5. Anubis : parce que la protection contre les crawlers agressifs devient un vrai sujet pour les petits sites.

Ce top 5 n’est pas un podium absolu. C’est un ordre de test personnel, basé sur mes besoins actuels : sécurité, sauvegarde, monitoring, publication et défense d’un petit site.

Surprises et déceptions

#

La bonne surprise, c’est Beszel. Je ne cherche pas toujours le plus puissant ; je cherche souvent le plus maintenable. Sur le papier, Beszel coche cette case.

La surprise plus inattendue, c’est SuperTuxKart. Il ne sert à rien dans mon infra, et c’est précisément pour ça qu’il a sa place ici : l’open source, ce n’est pas seulement des YAML et des CVE.

La déception relative, c’est DefectDojo. Le projet est sérieux, mais pour mon usage immédiat il sent la plateforme trop lourde. Je comprends son intérêt, je ne suis juste pas pressé de l’héberger.

L’autre réserve concerne les agents IA. Je veux les tester, mais je ne leur fais pas encore confiance. Tant qu’un agent ne sait pas expliquer clairement ce qu’il fait, je le garde loin des dépôts sensibles.

Ma stack de test minimale

#

Je ne teste pas ce genre de projet directement sur mon infrastructure principale. C’est tentant, mais c’est aussi comme ça qu’on se retrouve avec des volumes oubliés, des ports ouverts et des services qu’on n’ose plus supprimer.

Pour un premier essai, je partirais plutôt sur :

• une VM ou un VPS dédié au test ;
• un sous-domaine de lab ;
• un reverse proxy séparé de la production ;
• aucune donnée personnelle réelle au premier lancement ;
• des volumes faciles à supprimer ;
• une note d’installation écrite pendant le test, pas trois semaines plus tard.

Pour chaque outil, je veux mesurer les mêmes choses : temps d’installation, RAM au repos, ports exposés, volumes à sauvegarder, méthode de mise à jour, méthode de suppression, et qualité des logs quand quelque chose casse.

Ce cadre peut sembler strict, mais il évite de confondre “ça démarre” avec “je peux l’exploiter”.

Carte rapide des projets

#

Voici la carte courte de cette veille, dans l’ordre des stars récentes. Elle sert surtout à visualiser les familles de projets et les tests que je ferais en premier. La colonne “Priorité” ne veut pas dire que l’outil est validé ; elle indique seulement mon envie de le tester ou de le creuser.

Le piège, avec une liste de 30 projets, c’est de vouloir tout installer. Je préfère choisir un scénario, écrire ce que j’attends du test, puis décider si le projet mérite une place durable.

Cartographie de la veille

#

La sélection peut aussi se lire comme une architecture de lab. Certains projets servent à coder, protéger, observer, publier ou reprendre le contrôle sur les données.

flowchart LR
  A[GitHub stars] --> B[Lab tests]
  B --> C[AI agents]
  B --> D[Security]
  B --> E[Monitoring]
  B --> F[Web publishing]
  B --> G[Personal data]
  B --> H[Fediverse]

  C --> C1[opencode]
  C --> C2[OpenClaw]
  C --> C3[Dexter]
  C --> C4[PicoClaw]

  D --> D1[Nuclei]
  D --> D2[Trivy]
  D --> D3[DefectDojo]
  D --> D4[OpenVAS]
  D --> D5[WAF Checker]
  D --> D6[Anubis]

  E --> E1[Beszel]
  E --> E2[LogLynx]
  E --> E3[PatchMon]
  E --> E4[Turing Screen]

  F --> F1[Pagefind]
  F --> F2[Postiz]
  F --> F3[Prowlarr Indexer]

  G --> G1[Zerobyte]
  G --> G2[Actual]
  G --> G3[Sure]
  G --> G4[SimpleLogin]

  H --> H1[Phanpy]
  H --> H2[MARL]

AI et dev tools

#

Les agents open source se multiplient. Certains veulent remplacer des assistants de code, d’autres automatiser des tâches plus générales, d’autres encore se spécialisent dans un domaine. Je les regarde avec curiosité, mais aussi avec prudence : un agent utile doit être compréhensible, contrôlable et réversible.

anomalyco/opencode

#

opencode est un agent de code open source. Ce qui m’intéresse ici, c’est moins la promesse de “coder à ma place” que la possibilité d’avoir un outil auditable, scriptable et potentiellement connectable à différents modèles.

Je le testerais sur un dépôt sans enjeu, avec des tâches limitées : lire un projet, proposer un refactor mineur, expliquer un bug, générer un test. Le critère important serait la qualité de l’interaction avec le code existant, pas la quantité de lignes produites.

Point de vigilance : un agent de code doit rester un assistant. S’il pousse à accepter des changements trop vite, il devient dangereux.

sipeed/picoclaw

#

PicoClaw est présenté comme un outil d’automatisation léger et déployable partout. Il m’intéresse pour cette promesse de petite brique autonome : automatiser des tâches répétitives sans forcément installer une grosse plateforme.

Dans un lab, je le testerais sur des tâches simples : surveiller un état, déclencher une action, manipuler un workflow local, ou automatiser une opération qui finit habituellement dans un script oublié.

Point de vigilance : l’automatisation devient vite opaque si elle n’est pas documentée. Un outil léger doit rester lisible.

virattt/dexter

#

Dexter est un agent orienté recherche financière. Ce n’est pas une brique infra, mais il est intéressant comme exemple d’agent spécialisé : collecte d’information, synthèse, raisonnement sur un domaine précis.

Je le vois comme une source d’inspiration pour concevoir des agents métiers. Un bon agent spécialisé doit citer ses sources, structurer son raisonnement et montrer ses limites.

Point de vigilance : dès qu’on touche à la finance, il faut éviter la confusion entre aide à l’analyse et conseil. Un agent peut explorer, pas décider.

openclaw/openclaw

#

OpenClaw se présente comme un assistant personnel IA multiplateforme. Ce qui m’intéresse ici, c’est l’approche poste de travail augmenté : un outil local, extensible, capable de s’intégrer à plusieurs contextes.

Je le testerais avec un périmètre volontairement limité : quelques notes Markdown, des documents techniques, et une question simple à résoudre. L’objectif serait de vérifier où sont stockées les données, comment l’outil interagit avec les modèles, et si l’expérience reste fluide.

Point de vigilance : les assistants IA accumulent vite les connecteurs. Il faut savoir précisément ce qui reste local et ce qui sort.

Infra sécurité

#

La sécurité utile dans un homelab ne doit pas devenir une usine à alertes. Elle doit aider à répondre à des questions concrètes : qu’est-ce qui est exposé ? qu’est-ce qui est vulnérable ? qu’est-ce qui a changé ? qu’est-ce qui mérite une correction ?

Le test sécurité le plus rentable serait simple : Nuclei + Trivy sur un périmètre réduit, avec des résultats relus à la main et une note de correction pour chaque vrai signal.

hhftechnology/crowdsec_manager

#

CrowdSec Manager propose une interface web et mobile pour visualiser et gérer une pile CrowdSec. Le projet m’intéresse parce que CrowdSec est utile, mais peut devenir difficile à lire quand on empile scénarios, décisions, bouncers et intégrations.

Je le testerais avec un reverse proxy et quelques services exposés. La question centrale serait : est-ce que cette interface m’aide vraiment à comprendre ce que CrowdSec bloque, ou ajoute-t-elle seulement une surface d’administration ?

Point de vigilance : une interface de sécurité est elle-même un service sensible. Elle doit être protégée sérieusement.

PAPAMICA/waf-checker

#

WAF Checker teste un WAF avec un ensemble de payloads. J’aime bien ce type d’outil parce qu’il force à valider une configuration au lieu de faire confiance à une case cochée.

Je l’utiliserais uniquement contre mes propres services, dans un environnement contrôlé. L’objectif serait de comparer des règles par défaut, des règles durcies et les faux positifs.

Point de vigilance : un WAF n’est pas une correction applicative. Il peut réduire l’exposition, pas réparer le code.

projectdiscovery/nuclei

#

Nuclei est un scanner basé sur des templates. Son intérêt est la reproductibilité : on peut versionner des contrôles, les rejouer, puis documenter les résultats.

Dans mon usage, je le vois comme un outil de vérification régulière sur les services publics : endpoints, headers, erreurs de configuration, expositions involontaires, versions sensibles.

Point de vigilance : il faut sélectionner les templates. Tout scanner sans stratégie produit surtout du bruit.

DefectDojo/django-DefectDojo

#

DefectDojo centralise la gestion des vulnérabilités. C’est le genre d’outil qui devient intéressant quand on a plusieurs sources de scan : Nuclei, Trivy, OpenVAS, audits manuels, résultats CI.

Je ne le déploierais pas pour trois alertes isolées, mais je le garde en tête comme brique de consolidation. Dès que l’on veut suivre l’état des corrections dans le temps, un simple fichier Markdown atteint vite ses limites.

Point de vigilance : la plateforme ne remplace pas le processus. Si personne ne qualifie les résultats, elle devient un stockage d’alertes.

aquasecurity/trivy

#

Trivy est un scanner très pratique pour containers, systèmes de fichiers, configurations et dépendances. C’est probablement l’un des projets sécurité les plus directement testables de cette liste.

Je l’intégrerais d’abord dans un workflow simple : scanner les images Docker que j’utilise, repérer les vulnérabilités critiques, puis décider si une mise à jour est nécessaire.

Point de vigilance : toutes les vulnérabilités remontées ne sont pas exploitables dans le contexte réel. Il faut trier.

jumpserver/jumpserver

#

JumpServer est une plateforme PAM open source, orientée gestion des accès privilégiés. Le sujet est très sérieux : SSH, RDP, Kubernetes, bases de données, traçabilité des accès.

Pour mon usage, ce serait plutôt un projet d’étude qu’un déploiement immédiat. C’est utile pour comprendre comment structurer les accès dans une infra plus large.

Point de vigilance : un PAM devient critique. S’il est mal déployé, il concentre beaucoup de risques.

greenbone/openvas-scanner

#

OpenVAS Scanner est la brique de scan de Greenbone Community Edition. C’est plus lourd que Nuclei ou Trivy, mais intéressant pour une vision réseau plus large.

Je le testerais dans un lab isolé, sur un réseau que je contrôle entièrement. L’objectif serait de voir la qualité des résultats et la charge d’exploitation.

Point de vigilance : les rapports de vulnérabilités doivent être interprétés. Un score ne remplace pas le contexte.

TecharoHQ/anubis

#

Anubis vise à freiner les crawlers agressifs, notamment ceux qui pèsent sur les petits sites. C’est un sujet de plus en plus concret : un site statique ou un petit serveur peut être fortement sollicité par des robots qui n’apportent aucune valeur au site.

Je le testerais devant un service peu critique, en observant trois choses : la baisse de charge, l’impact sur les visiteurs légitimes, et la lisibilité des logs. Le but n’est pas de bloquer Internet, mais de reprendre un peu de contrôle sur le trafic subi.

Je ne l’ai donc pas encore validé en conditions réelles. Le test que j’ai en tête est précis : placer Anubis devant une ressource exposée via Pangolin, mesurer le comportement côté visiteurs légitimes, vérifier les logs, puis documenter l’ensemble dans un article séparé sur Pangolin + Anubis.

Point de vigilance : toute protection anti-crawler peut gêner des usages légitimes si elle est trop agressive. Il faut mesurer, pas seulement activer.

Infra et observabilité

#

Une infrastructure personnelle doit rester observable. Pas forcément avec une plateforme gigantesque, mais avec assez de signaux pour comprendre ce qui casse. Les projets suivants parlent de santé système, logs, patchs et visibilité.

mathoudebine/turing-smart-screen-python

#

Ce projet permet d’utiliser de petits écrans USB de type Turing Smart Screen comme afficheurs de monitoring. C’est très homelab : pas indispensable, mais utile pour rendre visible l’état d’une machine.

Je le testerais sur un mini-PC ou un serveur local, avec quelques métriques simples : CPU, RAM, disque, température, réseau. Le but n’est pas de remplacer un monitoring centralisé, mais d’avoir un signal immédiat.

Point de vigilance : le gadget ne doit pas devenir plus fragile que le service qu’il surveille.

PatchMon/PatchMon

#

PatchMon se présente comme une plateforme de suivi des patchs Linux. C’est un sujet moins spectaculaire que l’IA, mais beaucoup plus proche de l’exploitation quotidienne.

Je le regarderais pour suivre l’état de mises à jour sur plusieurs machines. Dans un petit parc, savoir quelles machines sont à jour, lesquelles ne le sont pas, et pourquoi, fait gagner du temps.

Point de vigilance : le suivi des patchs doit rester simple. Si l’outil demande plus d’effort que les mises à jour elles-mêmes, il perd son intérêt.

K0lin/loglynx

#

LogLynx est orienté analyse de logs pour reverse proxies comme Traefik et Caddy. Le sujet est intéressant parce que les logs de proxy contiennent beaucoup d’information : trafic, erreurs, pays, clients, comportements étranges.

Je le testerais derrière un reverse proxy de lab, avec un trafic modéré. L’objectif serait de voir si les tableaux de bord aident vraiment à comprendre l’activité ou s’ils se contentent d’être jolis.

Point de vigilance : les logs peuvent contenir des données sensibles. Il faut penser rétention, anonymisation éventuelle et accès.

henrygd/beszel

#

Beszel propose un monitoring léger avec historique, stats Docker et alertes. C’est exactement le type d’outil que je regarde pour un homelab : assez simple pour être maintenu, assez utile pour éviter de voler à l’aveugle.

Je le testerais sur deux ou trois machines : un VPS, un mini-PC local, peut-être un service Docker. Les critères seraient simples : consommation faible, installation claire, alertes utiles, historique lisible.

Point de vigilance : un monitoring doit être fiable sans devenir central dans toute l’infra. S’il tombe, il ne doit pas empêcher le reste de fonctionner.

Self-hosting et données personnelles

#

Les données personnelles sont la partie la moins spectaculaire, mais souvent la plus importante. Budget, alias email, sauvegardes, documents : si ces outils cassent, l’impact est très concret.

Le vrai test d’un outil de sauvegarde n’est pas la sauvegarde. C’est la restauration sur une machine propre, sans raccourci, avec une documentation assez courte pour être relue sous stress.

nicotsx/zerobyte

#

Zerobyte automatise des sauvegardes autour de restic. Le projet m’intéresse beaucoup parce qu’il part d’une bonne base : restic est robuste, mais son exploitation régulière peut rester un peu brute.

Je le testerais avec un scénario strict : un dossier applicatif, une base exportée, un dépôt distant, puis une restauration complète sur une machine vierge. Tant que cette étape n’est pas réussie, l’outil n’a pas vraiment été testé.

Point de vigilance : le projet reste jeune. Je ne lui confierais pas l’unique stratégie de sauvegarde sans période de double validation.

we-promise/sure

#

Sure est une application de finance personnelle. Ce type d’outil m’intéresse parce qu’il touche à des données sensibles et très quotidiennes : budget, dépenses, organisation financière.

Je le testerais avec des données fictives ou anonymisées, surtout pour comprendre le modèle de données, les exports, les imports et la facilité de sauvegarde.

Point de vigilance : un outil financier doit permettre de récupérer ses données. Sans export propre, je passe mon chemin.

qeeqbox/social-analyzer

#

Social Analyzer permet de rechercher et analyser la présence d’un profil sur de nombreuses plateformes. C’est typiquement un outil à classer dans l’OSINT défensif : comprendre ce qu’un pseudonyme, une marque ou une identité publique laisse apparaître.

Je le testerais uniquement sur mes propres identifiants publics. Le but serait de mesurer l’exposition, repérer les recoupements trop faciles, et nettoyer ce qui mérite de l’être.

Point de vigilance : ce type d’outil doit rester dans un cadre éthique clair. L’OSINT défensif aide à réduire sa surface publique, pas à surveiller des personnes.

simple-login/app

#

SimpleLogin permet de gérer des alias email. C’est une brique privacy très utile : réduire l’exposition de son adresse principale, compartimenter les usages, couper proprement un alias compromis.

Je ne suis pas certain de vouloir l’auto-héberger, car l’email est un domaine exigeant. Mais le projet mérite clairement une place dans une veille privacy.

Point de vigilance : l’auto-hébergement email demande SPF, DKIM, DMARC, réputation, délivrabilité et supervision. Ce n’est pas un petit service comme les autres.

actualbudget/actual

#

Actual est une application de budget local-first. Je l’avais déjà dans ma veille, et sa présence dans les stars récentes confirme que le sujet reste pertinent.

Je le testerais avec des imports manuels pour commencer. Le but serait de voir si l’outil est assez simple pour être utilisé régulièrement, pas seulement installé un dimanche soir.

Point de vigilance : la connexion bancaire automatique est pratique, mais je commencerais toujours par comprendre le modèle de données.

Web, publication et dev tools

#

Cette famille est particulièrement liée au blog. Publier, planifier, chercher, indexer, observer les lecteurs : ce sont des sujets très concrets pour un site statique comme Cryptolab.

gitroomhq/postiz-app

#

Postiz est une plateforme de planification de contenu social avec une dose d’IA. Je le regarde surtout sous l’angle publication : comment annoncer des articles, préparer des posts, adapter un message à plusieurs réseaux.

Pour Cryptolab, l’usage serait simple : planifier quelques publications autour d’un article, sans tomber dans l’automatisation marketing lourde.

Point de vigilance : publier plus ne veut pas dire publier mieux. Un outil de scheduling doit garder un ton humain.

JigSawFr/lacale-prowlarr-indexer

#

Ce projet est plus niche : un indexer Prowlarr pour La-Cale. Il illustre bien le genre de dépôt que l’on étoile parce qu’il répond à un besoin précis, pas parce qu’il parle à tout le monde.

Je le garde comme marqueur d’écosystème : Prowlarr, indexation, automatisation de médiathèque, petits connecteurs communautaires.

Point de vigilance : les projets très spécialisés dépendent souvent d’un service tiers ou d’un usage précis. Il faut accepter leur fragilité potentielle.

ikatyang/emoji-cheat-sheet

#

emoji-cheat-sheet est une référence Markdown pour les emojis. Ce n’est pas une brique infra, mais c’est typiquement le petit dépôt pratique que l’on garde sous la main.

Je l’inclus parce que la veille GitHub n’est pas composée uniquement de plateformes lourdes. Il y a aussi des ressources de documentation, des pense-bêtes, des fichiers utiles.

Point de vigilance : aucun enjeu ici, si ce n’est de ne pas transformer un article technique en collection d’accessoires.

Pagefind/pagefind

#

Pagefind est l’un des projets les plus pertinents pour ce blog. Il fournit une recherche statique légère, adaptée aux sites générés, sans imposer une grosse dépendance serveur.

Je le testerais directement sur Cryptolab ou sur une copie locale. Le critère serait simple : index léger, recherche rapide, intégration Hugo propre, pas de service additionnel à maintenir.

Point de vigilance : la recherche doit rester sobre. Si elle alourdit fortement le site, elle rate son objectif.

Fediverse, communautés et archives

#

Le Fediverse reste très présent dans ma veille. Ce n’est pas seulement une alternative aux plateformes fermées, c’est aussi un terrain d’expérimentation sur l’identité, l’archive, les clients et la modération.

cheeaun/phanpy

#

Phanpy est un client web Mastodon minimaliste et très soigné. Il montre qu’un client Fediverse peut avoir sa propre personnalité au lieu de copier l’interface officielle.

Je le testerais comme interface principale pendant quelques jours : lecture, rédaction, notifications, listes, recherche, conversations longues. C’est seulement dans l’usage quotidien qu’un client révèle ses qualités.

Point de vigilance : il faut distinguer les limites du client de celles de l’API ou de l’instance.

s427/MARL

#

MARL, Mastodon Archive Reader Lite, permet d’explorer une archive Mastodon dans une application légère. J’aime beaucoup l’idée : reprendre possession de ses propres données sociales, même hors de la plateforme.

Je le testerais avec une archive exportée, en regardant la navigation, la recherche, la lisibilité et la confidentialité locale.

Point de vigilance : une archive sociale peut contenir des données sensibles. Elle doit rester locale et bien protégée.

Jeux et projets atypiques

#

Tous les projets d’une veille ne doivent pas forcément devenir des services. Certains servent à observer des communautés, des architectures, des choix techniques ou simplement à sortir de l’infra pure.

supertuxkart/stk-code

#

SuperTuxKart est un projet de jeu open source mature, mais il est surtout dans cette liste pour une raison plus personnelle : je l’ai découvert et j’y ai joué pendant l’after party du FOSDEM 2026.

Ce n’est donc pas un outil de homelab, ni une brique que je vais déployer quelque part. C’est plutôt un rappel très concret que l’open source ne se limite pas aux serveurs, aux scanners de vulnérabilités et aux dashboards. Il y a aussi des jeux, des projets créatifs, des communautés qui se retrouvent, et des moments où un dépôt GitHub devient simplement un bon souvenir de conférence.

Point de vigilance : ici, l’intérêt est surtout culturel, communautaire et technique, pas opérationnel.

Recherche vectorielle et bases de connaissance

#

L’IA locale devient vraiment utile quand elle est reliée à de la connaissance. D’où l’intérêt des bases vectorielles, des exemples multi-vecteurs et des moteurs capables de retrouver le bon contexte.

antas-marcin/weaviate-multi-vector-example

#

Ce dépôt est un exemple autour de Weaviate, de modèles vision/langage et de recherche multi-vecteur. Les exemples de qualité sont précieux : ils montrent comment assembler les briques, pas seulement ce que chaque outil promet.

Je le testerais comme support d’apprentissage, pour comprendre les compromis entre plusieurs représentations d’un même contenu.

Point de vigilance : un exemple ne doit pas être confondu avec une architecture de production.

weaviate/weaviate

#

Weaviate est une base vectorielle open source. Elle stocke objets et vecteurs, et permet de combiner recherche vectorielle et filtrage structuré.

Je la comparerais à une recherche plus classique sur un corpus de notes ou d’articles. Le but n’est pas de prouver que la recherche sémantique est magique, mais de voir où elle apporte vraiment quelque chose.

Point de vigilance : une base vectorielle n’améliore pas un mauvais corpus. Découpage, métadonnées et ingestion comptent autant que le moteur.

Ce que je ne mettrais pas en production tout de suite

#

Certains projets sont passionnants, mais pas prioritaires en production pour mon usage.

• JumpServer : très intéressant pour comprendre le PAM, mais trop structurant pour un petit lab sans besoin clair.
• OpenVAS : puissant, mais lourd ; je commencerais par Nuclei et Trivy.
• DefectDojo : utile dès qu’il y a plusieurs sources de vulnérabilités, excessif pour quelques scans isolés.
• Dexter : intéressant comme agent spécialisé, pas comme brique infra.
• PicoClaw : prometteur, mais à tester sur un workflow très limité avant d’automatiser quoi que ce soit.

Dire “pas maintenant” fait partie de la veille. Le vrai luxe dans un homelab, ce n’est pas d’installer 30 outils. C’est de savoir lesquels ne pas installer.

Les tests que je ferais en priorité

#

Je ne vais pas installer ces 30 projets en bloc. La bonne approche consiste à choisir quelques scénarios utiles, avec des critères de sortie clairs.

Scénario 1 : sécurité continue légère

#

Objectif : vérifier régulièrement mes services publics sans créer une usine à alertes.

Projets concernés :

• Nuclei pour les contrôles par templates ;
• Trivy pour les images et configurations ;
• WAF Checker pour tester certaines règles ;
• CrowdSec Manager pour mieux visualiser les décisions.

Critères de réussite :

• scans reproductibles ;
• peu de faux positifs ;
• résultats compréhensibles ;
• aucune cible externe non autorisée ;
• documentation des corrections.

Scénario 2 : monitoring homelab sobre

#

Objectif : mieux voir l’état de mes machines sans déployer une grosse stack.

Projets concernés :

• Beszel pour la supervision légère ;
• LogLynx pour les logs de reverse proxy ;
• PatchMon pour le suivi des mises à jour ;
• turing-smart-screen-python pour un affichage local.

Critères de réussite :

• faible consommation ;
• installation simple ;
• alertes utiles ;
• logs lisibles ;
• suppression propre si le test ne donne rien.

Scénario 3 : publication et recherche sur Cryptolab

#

Objectif : améliorer la découverte du contenu et la diffusion des articles.

Projets concernés :

• Pagefind pour la recherche statique ;
• Postiz pour planifier des annonces ;
• Anubis pour protéger un petit site contre le trafic automatisé agressif.

Critères de réussite :

• pas de lourdeur côté lecteur ;
• intégration simple avec Hugo ;
• gain réel pour la recherche ou la protection ;
• maintenance minimale.

Scénario 4 : sauvegardes vérifiables

#

Objectif : ne plus jamais confondre “backup configuré” et “backup restaurable”.

Projets concernés :

• Zerobyte pour l’orchestration restic ;
• Actual ou Sure comme exemples de données sensibles ;
• SimpleLogin uniquement comme sujet privacy à évaluer prudemment.

Critères de réussite :

• sauvegarde chiffrée ;
• rétention compréhensible ;
• restauration testée sur une machine propre ;
• export possible hors de l’application.

Les absents volontaires

#

Cette liste n’est pas une liste des “meilleurs outils open source”. Elle est basée sur mes stars récentes. C’est pour ça que certains classiques ne sont pas au centre de l’article : Prometheus, Grafana, Portainer, Nextcloud, Home Assistant ou Docker ne sont pas absents parce qu’ils seraient moins bons, mais parce qu’ils ne correspondent pas à cette photographie précise.

Je préfère assumer ce cadrage plutôt que produire une liste générique. L’intérêt, ici, est de voir ce qu’une veille récente raconte d’un moment, pas de refaire un annuaire.

Conclusion

#

Ce que cette veille me dit de l’open source aujourd’hui est assez simple : la valeur revient aux outils qui réduisent la charge mentale.

Je suis moins impressionné par les plateformes qui veulent tout faire que par les projets qui savent rester à leur place : scanner une image, chercher dans un site statique, surveiller trois serveurs, ralentir des crawlers, restaurer une sauvegarde. C’est là que l’open source est fort : dans les briques que l’on peut comprendre, combiner, remplacer.

Ma vision pour la suite est donc assez tranchée : le bon open source n’est pas celui qui promet de remplacer un cloud entier. C’est celui qui me laisse garder le contrôle sans devenir mon nouveau travail à temps plein.

Une étoile GitHub ne devrait pas être une impulsion d’installation. Elle devrait être le début d’un test documenté. Et parfois, le meilleur résultat d’un test, c’est de décider de ne rien déployer.

Résumé court à republier

#

30 projets open source issus des stars récentes de mon profil GitHub foudreclair, avec un angle homelab : agents IA, sécurité, monitoring, sauvegardes, Fediverse, publication web et données personnelles. Ce n’est pas un comparatif après test complet : c’est une veille commentée. L’article insiste surtout sur la méthode : tester petit, documenter, vérifier la réversibilité, et ne pas confondre étoile GitHub avec adoption.

Je continue à publier mes découvertes sur GitHub et à documenter les tests qui valent le détour ici, sur Cryptolab.