Si vous utilisez des LLM dans vos projets, vous savez que le plus flippant c'est pas de les faire fonctionner (quoique..lol) mais c'est de vérifier qu'ils ne disent pas n'importe nawak ! Et pour cela, il y a Promptfoo , un outil CLI open source qui permet de tester vos prompts, comparer les modèles et scanner les vulnérabilités de vos apps IA, le tout avec un simple fichier YAML.

Ça s'installe en une commande (npx promptfoo@latest init) et vous voilà avec un fichier promptfooconfig.yaml où vous définissez vos prompts, les modèles à tester et les assertions à vérifier.

Genre, vous voulez que votre traduction contienne bien "Bonjour le monde", Hop, un petit tour dans le YAML, assertion contains, et c'est terminé. Plus besoin de relire 200 outputs à la main en plissant les yeux ! Par contre, attention : le YAML peut vite devenir un plat de spaghetti si vous testez 15 prompts sur 8 modèles en parallèle. Commencez donc petit.

La matrice d'évaluation de promptfoo, sobre mais efficace

L'outil supporte plus de 60 providers différents comme OpenAI, Claude, Gemini, Llama via Ollama, Mistral... vous mettez tout ça dans le même fichier de config et promptfoo les fait tourner côte à côte. Vous voyez alors directement lequel hallucine le moins, lequel répond le plus vite, lequel coûte une blinde pour un résultat bof bof. Le tout avec des assertions typées : contains, llm-rubric (où un autre LLM note la réponse), javascript pour vos critères custom, et même cost et latency pour garder un œil sur la facture.

Après tester si votre chatbot traduit correctement, c'est sympa, mais vérifier qu'il se fait pas jailbreaker par un "ignore toutes tes instructions", c'est quand même plus critique ! Et c'est pourquoi Promptfoo embarque un scanner de vulnérabilités qui couvre plus de 50 types d'attaques : injections de prompts directes et indirectes, fuites de données personnelles, biais, contenu toxique, escalade de privilèges sur les outils...

Il utilise pour cela des techniques comme le Tree of Attacks with Pruning, un algo qui explore plusieurs chemins d'attaque en parallèle pour trouver les failles sans brute force. Si vous voulez creuser le sujet du red teaming LLM, DeepTeam est un bon complément côté Python.

Le dashboard red teaming de promptfoo avec les vulnérabilités détectées

C'est surtout cette intégration CI/CD qui fait la différence. Vous pouvez brancher promptfoo dans votre pipeline GitHub Actions ou GitLab et chaque pull request qui touche un prompt est automatiquement testée. Bah oui, on a des tests unitaires pour le code depuis 30 ans, mais pour les prompts, jusqu'ici c'est même plutôt le far west !

Bon après, faut pas se mentir non plus, écrire des assertions pour du texte non-déterministe, c'est un autre sport que du assertEqual. Le llm-rubric qui utilise un LLM pour juger un autre LLM, c'est pas con mais ça ajoute aussi une couche de "flou" donc à vous de trouver le bon dosage dans vos tests.

L'équipe a annoncé rejoindre OpenAI début mars ce qui est plutôt une bonne nouvelle pour le développement du projet... mais pas forcément pour l'indépendance quand on évalue les modèles OpenAI avec un outil OpenAI (on verra bien hein ^^ lol).

L'orchestration tourne en local sur votre machine (les prompts partent chez les providers pour l'évaluation, mais vos fichiers YAML, vos logs et résultats JSON restent sur votre disque dur), c'est sous licence MIT, et y'a déjà plus de 300 000 utilisateurs, ce qui est quand même pas mal !

Voilà, comme ça plutôt que de croiser les doigts à chaque déploiement, en espérant ne pas vous faire virer, autant tester ses prompts comme on teste son code.

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

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

Les pods Kubernetes version Jurassic Park ( Source )

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

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

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

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

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

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

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

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

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.

VirtualBox, le bon vieux logiciel de virtualisation d'Oracle, vient de franchir un cap plutôt inattendu. Le code de développement supporte désormais KVM comme backend sur Linux ! En gros, au lieu de s'appuyer uniquement sur son propre module noyau (qui, soyons honnêtes, a toujours été un poil galère à maintenir), l'outil de virtualisation peut maintenant utiliser l'hyperviseur natif de Linux.

Et c'est pas rien quand on sait que le logiciel d'Oracle et KVM se marchaient dessus depuis des années. C'était impossible de faire tourner les deux en même temps... Du coup, plutôt que de continuer à se battre, Oracle a décidé de faire copain-copain avec KVM. C'est pas bête !

L'idée vient à l'origine de Cyberus Technology qui avait pondu une implémentation open source en 2024. Et aujourd'hui, c'est Oracle qui intègre le truc directement dans le code officiel. Alors pour l'instant, c'est dispo uniquement en version de dev dans les dépôts Git et les builds de test et ça fonctionne "à peu près".

Vous pouvez dès à présent activer le backend KVM quand le module noyau classique de VirtualBox refuse de coopérer. C'est pratique mais attention par contre, si vous avez besoin du réseau NAT avancé ou du mode pont avec VLAN, ça passera pas encore via KVM... faudra rester sur le module maison.

Notez aussi que l'hyperviseur maison d'Oracle garde quand même des avantages notamment pour tout ce qui est modes réseau avancés, émulation précise pour les vieux OS, et émulation fine de périphériques.

Mais n'empêche, la tendance est claire, tout le monde converge vers l'hyperviseur du noyau Linux. Faut dire que QEMU/KVM c'est devenu tellement solide ces dernières années que ça n'a plus trop de sens de réinventer la roue dans son coin.

Voilà, donc pour ceux qui utilisent l'outil d'Oracle au quotidien sur Linux, c'est une bonne nouvelle. Moins besoin de jongler avec le module vboxdrv, moins de conflits avec d'autres solutions de virtualisation , et surtout des mises à jour noyau qui cassent moins souvent.

Bref, gardez un œil sur les prochaines releases car Oracle a l'air d'y aller sérieusement. Le support KVM final et officiel devrait atterrir pour tous dans une version stable courant 2026. J'ai hâte !

Source

Brice, un lecteur de Korben, m'a bel et bien scotché. Il y a quelques semaines, je vous parlais du Pineapple Pager et ça a visiblement réveillé une fibre nostalgique chez certains d'entre vous. Donc merci à Brice pour l'info, car il a carrément passé sa soirée à coder un truc énoooOOOooorme (et super utile) qui s'appelle MonitorBox .

Parce qu'on va pas se mentir, on croule tous sous les notifications. Entre Slack, les emails, et les alertes de sécurité, notre cerveau a fini par développer un mécanisme de défense radical : il ignore TOUT !!! C'est ce qu'on appelle la "fatigue de l'alerte". J'avoue que pour un admin sys en astreinte, c'est le début de la fin. Le jour où le serveur de prod tombe vraiment, on swipe la notif comme si c'était une pub pour des croquettes bio... Pas terrible donc pour la continuité de service.

L'interface de MonitorBox - sobre mais efficace ( Source )

Et c'est là que Brice intervient justement avec son idée de génie : Ressusciter le bon vieux pager des années 90. Au début je pensais que c'était juste pour le fun (un délire de vieux geek quoi), mais en réalité c'est un vrai outil de surveillance pro.

MonitorBox est conçu pour tourner sur un vieux PC recyclé (genre un vieux Dell Optiplex GX270 ou un ThinkPad T60) sous Debian 12 Bookworm et l'idée, c'est de sortir l'alerte critique du flux continu de votre smartphone pour l'envoyer sur un appareil qui ne sert qu'à ça. Ainsi, quand le beeper à votre ceinture se met à gueuler sur la fréquence 466.975 MHz, vous savez que la maison brûle, sans même regarder l'écran.

Et techniquement, c'est hyper propre !!! Le système utilise une vue Terminal (parfaite pour un vieil écran CRT qui traîne) et un dashboard web moderne sous JavaScript pour le suivi. L'arme secrète reste ensuite le support du protocole POCSAG.

Via le port série (type /dev/ttyS0 ou un adaptateur FTDI), MonitorBox pilote un émetteur radio qui se charge de balancer les infos sur les ondes. Et toudoum, voilà comment votre vieux Tatoo ou Tam-Tam reprend du service !

⚠️ Attention quand même, émettre sur des fréquences radio est ultra-réglementé. Vérifiez donc bien la législation avant de jouer les apprentis sorciers, car pas moyen de plaider l'ignorance si les mecs de l'ANFR débarquent chez vous avec leur camionnette de détection Agence Tous Risques...

J'adore perso son approche qui vise le "Zéro faux positif". En effet, le script s'appuie sur Shell, curl et espeak pour la synthèse vocale locale, et intègre une logique de "Retry" comme ça si un service ne répond pas, l'outil vérifie à nouveau avant de vous réveiller en pleine nuit. Ça réduit drastiquement les fausses alertes, contrairement aux outils de monitoring habituels qui hurlent parfois au loup pour une micro-latence passagère de rien du tout.

MonitorBox est léger (pas besoin de base de données SQL compliquée, juste un fichier servers.conf), souverain, et permet de redonner vie à du matos qu'on croyait bon pour la déchetterie.

Brice nous propose en gros un mix parfait entre low-tech et haute performance. Et si vous voulez tester le bousin, tout le code est open source (licence MIT) et disponible sur GitHub . Seul petit bémol, il vous faudra bel et bien un vrai câble DB9 ou DB25 et un adaptateur qui tient la route, sinon votre VM va juste vous envoyer bouler violemment. Aaaah ces drivers USB chinois, je vous jure...

Bref, merci Brice pour l'inspiration et pour ce beau projet à la fois rétro et moderne !

Vous développez un truc en local et vous avez besoin de le montrer à quelqu'un au travers d'Internet, genre pour tester un webhook, faire une démo rapide, ou juste impressionner votre collègue à distance ? Hé bien au lieu de vous farcir une config nginx + certificats SSL + ouverture de ports sur le routeur (Beurk !), y'a Tunnl.gg qui fait tout ça en une SEULE ligne de commande.

Vous tapez une commande SSH, et hop, vous avez une URL publique qui pointe vers votre serveur local. Pas de client à installer, pas de compte à créer, pas de token à configurer, juste SSH, que vous avez forcément déjà sur votre machine.

Donc pour exposer votre app qui tourne sur le port 8080, vous faites :

ssh -t -R 80:localhost:8080 proxy.tunnl.gg

Et c'est parti ! Le service vous file une URL avec un sous-domaine aléatoire, genre abc123.tunnl.gg, et tout ce qui arrive dessus est redirigé vers votre localhost:8080. Et magie magie, HTTPS est automatique, donc pas besoin de vous soucier des certificats.

Du coup, si vous connaissez déjà ce genre d'outils, vous pensez peut-être à Bore que j'ai présenté il y a pas longtemps, ou Portr qui fait sensiblement la même chose, ou encore Chisel pour les amateurs de tunnels TCP/UDP via HTTP. Tous ces outils font du tunneling, mais Tunnl.gg se distingue par son approche "zéro friction" sans binaire à télécharger, et sans compte à vous créer.

Pour le moment, le service est gratuit pour un usage personnel mais les développeurs prévoient des plans payants plus tard avec des features comme les domaines personnalisés, les sous-domaines persistants et des limites de débit plus élevées. On verra bien mais en attendant, pour tester un truc vite fait ou faire une démo, la version gratuite suffira largement.

Bon, y'a quand même quelques trucs à savoir. Primo, ça ne marche qu'avec du trafic HTTP/HTTPS pour l'instant. Deuxio, le TLS est côté serveur, donc techniquement ils peuvent voir votre trafic même s'ils disent ne pas l'inspecter. Donc pour des données vraiment sensibles, gardez ça en tête. Et tertio, comme tout service de ce type, y'a des limites de fair-use pour éviter les abus.

Bref, si vous cherchez un moyen rapide d'exposer un port local sans vous prendre la tête avec la config, Tunnl.gg fera le taf. Au pire vous aurez découvert une alternative de plus à ngrok , au mieux ça deviendra votre outil par défaut pour les démos express...

Merci à Lorenper pour le partage !

Si vous utilisez des conteneurs Docker au quotidien, vous allez sauter de joie car Docker vient d'annoncer que ses Docker Hardened Images (DHI), ces fameuses images ultra-sécurisées qui étaient réservées aux entreprises prêtes à cracher le pognon, sont maintenant gratuites pour tout le monde. Et c'est pas encore un truc limité avec des restrictions à la noix, non non... C'est du vrai open source sous licence Apache 2.0.

Ils proposent donc plus de 1 000 images conteneur prêtes à l'emploi, construites sur Debian et Alpine et ces images sont "durcies", c'est-à-dire qu'elles ont été débarrassées de tous les composants inutiles qui traînent habituellement dans les images de base et qui ne servent qu'à augmenter la surface d'attaque. Du coup, ça leur permet d'annoncer une réduction des vulnérabilités de plus de 95% par rapport aux images classiques. C'est pas maaaal, hein ?

Vous avez déjà passé des heures à éplucher des fichiers de logs de plusieurs millions de lignes pour trouver ce qui cloche ? Genre une pauvre erreur bizarre qui se produit une fois sur 100 000, noyée dans un océan de messages répétitifs et d'infos inutiles ? Moi, oui plein de fois !

Mais ça c'était avant de tomber sur Cordon !

Cordon est un outil en Python qui utilise des modèles de transformers et du scoring k-NN pour détecter les anomalies sémantiques dans vos logs. En gros, au lieu de chercher des mots-clés comme un bourrin avec grep, Cordon comprend le sens des messages et repère ce qui sort de l'ordinaire.

Les patterns répétitifs sont alors considérés comme du bruit de fond normal, même si ce sont des erreurs parce que si vous avez la même erreur FATALE qui se répète 10 000 fois, c'est probablement un problème connu. Et vous, ce que vous voulez trouver, c'est l'événement rare, celui qui se produit une seule fois et qui est sémantiquement différent du reste.

L'installation est simple comme bonjour. Un petit pip install cordon et c'est réglé. Pour l'utilisation de base, vous balancez juste votre fichier de logs en argument :

cordon system.log

Et hop, Cordon va analyser tout ça et vous sortir uniquement les trucs intéressants. Par défaut, il garde les 10% les plus "anormaux" sémantiquement. Vous pouvez ajuster ce pourcentage avec --anomaly-percentile 0.05 pour être plus sélectif (top 5%).

Sous le capot, ça utilise le modèle all-MiniLM-L6-v2 de sentence-transformers pour vectoriser les logs. Le fichier est découpé en fenêtres de N lignes (4 par défaut), chaque fenêtre est transformée en vecteur, puis un score de densité k-NN est calculé. Les fenêtres qui ont des vecteurs très différents du reste sont marquées comme anomalies.

Et si vous avez un GPU, Cordon peut l'utiliser automatiquement avec l'option --device cuda. D'après les benchmarks, ça donne un speedup de 5 à 15x sur le scoring pour les gros datasets. Sur des logs HDFS de 1 à 5 millions de lignes, l'outil arrive à réduire le volume de 98%. Autant dire que ça filtre sévère.

Y'a aussi un mode "range" qui est pratique pour explorer par tranches. Genre si vous voulez exclure le top 5% (trop bizarre, probablement du garbage) mais garder le top 5-15%, vous faites :

cordon --anomaly-range 0.05 0.15 app.log

Ça permet d'affiner l'investigation de manière itérative.

Pour les environnements conteneurisés, Cordon propose également une image Docker avec un backend llama.cpp au lieu de sentence-transformers. Pratique si vous voulez utiliser des modèles GGUF ou si vous êtes dans un contexte où les dépendances PyTorch posent problème.

L'outil peut aussi s'utiliser comme bibliothèque Python si vous voulez l'intégrer dans vos propres scripts :

analyzer = SemanticLogAnalyzer()
output = analyzer.analyze_file(Path("system.log"))