Vous ne le savez peut-être pas, mais le site sur lequel vous êtes actuellement est un site 100% statique. Je gère le contenu côté back avec un CMS en PHP (rédaction, édition, workflow), mais la partie publique n’exécute aucun PHP : pas de base de données, juste des fichiers HTML/CSS/JS et des images. Et tout ça est généré à partir de fichiers Markdown avec Hugo.

Et optimiser tout ça c’est pas de la tarte car si vos templates sont mal pensés, Hugo peut mettre une plombe à générer le site. Entre partiels recalculés pour rien, boucles trop larges et images retraitées à chaque passage, on flingue les perfs sans s’en rendre compte.

Et c’était mon cas au début. Je regardais avec envie les mecs qui sortaient un build en moins d’une seconde tout en restant réaliste car j’ai quand même environ 60 000 pages à générer. Au final, je suis passé de plusieurs heures de build à environ 5 minutes en optimisant les templates, le cache et le pipeline d’assets.

Car oui, Hugo sait générer la plupart des sites en quelques secondes si vos templates sont propres. Depuis la “million pages release”, les builds sont streamés et la mémoire mieux gérée. Alors si votre génération est lente, c’est qu’il y a (souvent) un souci côté templates.

Tout ceci est encore en cours de tests, et ce n’est pas parfait donc il est possible que ça change à l’avenir et vous faites peut-être autrement (dans ce cas ça m’intéresse !!). Bref, voici mon retour d’XP sous forme de conseils pour transformer, vous aussi, votre escargot en fusée 🚀.

Partials - Cachez-moi tout ça (bien)

Hugo sait mettre en cache le rendu d’un partial. Utilisez partialCached (alias de partials.IncludeCached) partout où la sortie est identique sur beaucoup de pages.

{{/* baseof.html - Template de base optimisé */}}
{{ partialCached "header.html" . }}
{{ partialCached "nav.html" . }}
{{ partialCached "footer.html" . }}

Le truc malin, c’est d’utiliser des variantes (clés) pour changer le cache selon le contexte. Attention quand même car ces arguments de variante ne sont pas passés au partial. En réalité, ils servent uniquement à nommer l’entrée de cache. Si vous devez passer plus de données au partial, mettez-les dans le context via un dict.

{{/* Sidebar: cache par section et par numéro de page */}}
{{ $variant := printf "%s|p%d" .Section (cond .Paginator .Paginator.PageNumber 1) }}
{{ partialCached "sidebar.html" . $variant }}

{{/* Pagination: on passe un contexte enrichi, et on varie par numéro de page */}}
{{ $opts := dict "showCounts" true }}
{{ partialCached "pagination-taxonomy.html" (dict "Page" . "Opts" $opts) .Paginator.PageNumber }}

{{/* Bannières: cache par langue */}}
{{ partialCached "article/patreon-support-banner.html" . .Lang }}

Gardez aussi vos variantes stables et petites (ex. .Lang, .Section, .Title, .Paginator.PageNumber), sinon, vous allez exploser le cache pour rien.

Réf. : partials.IncludeCached / partialCached.

Hugo Pipes - Minify, fingerprint, bundle (et JS qui dépote)

Pour le basique, pas besoin de Gulp/Webpack car Hugo a tout ce qu’il faut, et c’est très rapide. Voici mon bundle CSS unique :

{{/* head/css.html - Bundle CSS optimisé */}}
{{- $styles := slice
"css/reset.css"
"css/main.css"
"css/components/home-cards.css"
"css/components/patreon-card.css"
"css/components/article-content-images.css"
"css/components/lazy-loading.css"
"css/youtube-placeholder.css"
-}}
{{- $cssResources := slice -}}
{{- range $styles -}}
{{- with resources.Get . -}}
{{- $cssResources = $cssResources | append . -}}
{{- end -}}
{{- end -}}

{{/* Concat + minify + fingerprint */}}
{{- $cssBundle := resources.Concat "css/bundle.css" $cssResources | minify | fingerprint -}}

{{/* Preload + feuille finale avec SRI */}}
<link rel="preload" as="style" href="{{ $cssBundle.RelPermalink }}" integrity="{{ $cssBundle.Data.Integrity }}" crossorigin="anonymous">
<link rel="stylesheet" href="{{ $cssBundle.RelPermalink }}" integrity="{{ $cssBundle.Data.Integrity }}" crossorigin="anonymous">

Je regroupe tout avec resources.Concat, puis minify et fingerprint (SRI + cache-busting). Le preload déclenche le chargement au plus tôt, et le link classique prend le relais.

Côté JavaScript, j’utilise js.Build (esbuild) et je bascule les sourcemaps selon l’environnement :

{{/* assets/js/app.js est mon point d'entrée */}}
{{ $opts := dict
"minify" (not hugo.IsDevelopment)
"targetPath" "js/app.js"
"sourceMap" (cond hugo.IsDevelopment "inline" "") /* inline en dev, rien en prod */
}}
{{ $js := resources.Get "js/app.js" | js.Build $opts | fingerprint }}
<script src="{{ $js.RelPermalink }}" integrity="{{ $js.Data.Integrity }}" crossorigin="anonymous" defer></script>

Réfs : Minify, Fingerprint/SRI, js.Build (esbuild), resources.Concat.

Images - Cloudflare Image Resizing + lazy loading intelligent

J’ai également une approche hybride concernant la gestion des images. J’utilise Cloudflare Image Resizing qui génère les variantes côté CDN, et un partial Hugo prépare le srcset + LCP propre.

{{/* partials/responsive-image.html */}}
{{/* Paramètres attendus via dict:
- imageURL (string, chemin vers l'image d'origine dans /static)
- imgWidth, imgHeight (int)
- alt (string)
- class (string optionnelle)
- isLCP (bool) */}}

{{ $imageURL := .imageURL }}
{{ $imgWidth := .imgWidth }}
{{ $imgHeight := .imgHeight }}
{{ $alt := .alt | default "" }}
{{ $class := .class | default "" }}
{{ $isLCP := .isLCP | default false }}

{{ $widths := slice 320 640 960 1280 1920 }}
{{ $qualityMap := dict "320" 85 "640" 85 "960" 88 "1280" 90 "1920" 92 }}
{{ $srcset := slice }}

{{ range $w := $widths }}
{{ if or (eq $imgWidth 0) (ge $imgWidth $w) }}
{{ $q := index $qualityMap (printf "%d" $w) }}
{{ $srcset = $srcset | append (printf "/cdn-cgi/image/width=%d,quality=%d,f=avif%s %dw" $w $q $imageURL $w) }}
{{ end }}
{{ end }}

{{ if $isLCP }}
<img
src="/cdn-cgi/image/width=1280,quality=90,f=avif{{ $imageURL }}"
srcset="{{ delimit $srcset ", " }}"
sizes="(max-width: 1280px) 100vw, 1280px"
fetchpriority="high"
width="{{ $imgWidth }}" height="{{ $imgHeight }}"
alt="{{ $alt }}" class="{{ $class }}">
{{ else }}
{{/* LazySizes: placeholder + data-attrs et data-sizes='auto' */}}
<img
src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 {{ $imgWidth }} {{ $imgHeight }}'%3E%3C/svg%3E"
data-src="/cdn-cgi/image/width=1280,quality=90,f=avif{{ $imageURL }}"
data-srcset="{{ delimit $srcset ", " }}"
data-sizes="auto"
loading="lazy"
width="{{ $imgWidth }}" height="{{ $imgHeight }}"
alt="{{ $alt }}" class="lazyload {{ $class }}">
{{ end }}

Comme vous pouvez le voir, j’adapte la qualité selon la plateforme (85% pour mobile / 92% pour desktop), le format AVIF par défaut, et pour l’image LCP, je mets fetchpriority="high" et pas de lazy.

Voici un exemple d’appel :

{{ partial "responsive-image.html" (dict
"imageURL" .Params.featured_image
"imgWidth" 1280
"imgHeight" 720
"alt" .Title
"class" "article-cover"
"isLCP" true
) }}

Cache des ressources - Le secret des rebuilds rapides

Configurez aussi les caches pour éviter de retraiter à chaque build. Le plus important c’est le cache permanent pour les images et autres assets traités.

# hugo.toml
[caches]
[caches.getJSON]
dir = ":cacheDir/:project"
maxAge = "1h"
[caches.getCSV]
dir = ":cacheDir/:project"
maxAge = "1h"
[caches.images]
dir = ":resourceDir/_gen"
maxAge = -1 # NE JAMAIS expirer
[caches.assets]
dir = ":resourceDir/_gen"
maxAge = -1

Et en cas de besoin, pour forcer un refresh : hugo server --ignoreCache.

Réf. : Configure file caches.

Minifiez tout ce qui bouge (config complète)

J’ai aussi ajouté dans mon hugo.toml, une config de minification que voici :

# Minification HTML/CSS/JS/JSON/SVG/XML
[minify]
disableCSS = false
disableHTML = false
disableJS = false
disableJSON = false
disableSVG = false
disableXML = false
minifyOutput = true

[minify.tdewolff]
[minify.tdewolff.html]
keepWhitespace = false
[minify.tdewolff.css]
keepCSS2 = true
precision = 0
[minify.tdewolff.js]
keepVarNames = false
version = 2022
precision = 0

Avec hugo --minify, je gagne ~25% sur le HTML final (variable selon le site).

Réf. : Minify (config).

Organisation des templates - site.RegularPages est votre ami

En régle générale, c’est mieux d’éviter de boucler sur des pages inutiles (taxonomies, terms…). Utilisez aussi site.RegularPages plutôt que .Site.Pages.

{{/* sidebar/recent-posts.html - Articles récents optimisés */}}
{{ $recentPosts := first 6 (where site.RegularPages "Type" "posts") }}
{{ range $recentPosts }}
<li>
<a href="{{ .RelPermalink }}">
{{ $featuredImage := partial "get-image-optimized.html" (dict "page" .) }}
{{ if $featuredImage }}
<img src="{{ $featuredImage.RelPermalink }}" loading="lazy" width="80" height="60" alt="">
{{ else }}
<img src="/img/default-article-image.webp" loading="lazy" width="80" height="60" alt="">
{{ end }}
<h4>{{ truncate 40 .Title }}</h4>
</a>
</li>
{{ end }}

Réfs : site.RegularPages.

Et voici le petit helper image que j’utilise pour éviter les nil :

{{/* partials/get-image-optimized.html */}}
{{ $page := .page }}
{{ $imageName := .imageName | default $page.Params.featured_image }}

{{ $img := false }}
{{ if $imageName }}
{{ with $page.Resources.GetMatch $imageName }}
{{ $img = . }}
{{ end }}
{{ end }}

{{ return $img }}

Configuration globale - Chaque détail compte

Voici également quelques réglages utiles dans mon hugo.toml :

# Désactiver ce qu'on n'utilise pas
disableKinds = ["section"]

# Pagination moderne (Hugo ≥ 0.128)
[pagination]
pagerSize = 39 # 39 articles par page

# Traitement d'images
[imaging]
quality = 80
resampleFilter = "Lanczos"

# Optimisations de build
[build]
writeStats = false
noJSConfigInAssets = true
useResourceCacheWhen = "always"

# Mounts: exclure fichiers lourds
[module]
[[module.mounts]]
source = "content"
target = "content"
excludeFiles = ["**/*.zip", "**/*.log", "**/backup/**", "**/archives/**", "**/exports/**"]
[[module.mounts]]
source = "static"
target = "static"
excludeFiles = ["**/*.zip", "**/*.log", "**/backup/**", "**/archives/**"]

Je mets aussi un timeout large (timeout = "600s") et j’ignore certains warnings verbeux (ignoreLogs = ['warning-goldmark-raw-html']). Et pour la pagination, pagerSize a aussi remplacé les vieux réglages (bon à savoir si vous migrez).

Réf. : PagerSize, Pagination.

Les flags CLI utiles

Perso, j’utilise uniquement les flags suivants quand je lance Hugo :

• Nettoyage : hugo --gc --cleanDestinationDir pour virer l’obsolète et garder public/ clean.
• Dev rapide : gardez hugo server tel quel. --disableFastRender seulement si un glitch l’exige. --renderToMemory peut accélérer (au prix de la RAM).
• Profiler de templates : hugo --templateMetrics --templateMetricsHints liste les templates lents et où placer vos partialCached. C’est comme ça que j’ai vu que ma sidebar coûtait une plombe.

Conditionnez ce que vous chargez

Selon la page, j’adapte aussi mon code. L’image LCP avec fetchpriority="high" (pour éviter le lazy), le reste en lazy + placeholder SVG qui respecte les dimensions (zéro layout shift). Et pour le JS, defer partout et pas de scripts inutiles sur les pages qui n’en ont pas besoin.

Le pattern qui tue - partialCached + variantes calculées

Mon combo préféré, selon le contexte c’est celui-ci :

{{/* Home: variante par numéro de page */}}
{{ partialCached "pagination-home.html" . (cond .Paginator .Paginator.PageNumber 1) }}

{{/* Grilles d’articles: variante par (page, index de groupe) */}}
{{ partialCached "articles-grid.html"
(dict "articles" $groupArticles "Site" $.Site)
(printf "p%d|g%d" $paginator.PageNumber $groupIndex) }}

{{/* Éléments vraiment statiques: pas de variante */}}
{{ partialCached "footer.html" . }}

Il faut comme ça trouver le bon équilibre. C’est à dire avoir assez de variantes pour éviter les recalculs, mais pas trop, sinon votre cache devient inutile.

Et en bonus - Ma checklist express !

• Remplacer les partial chauds par partialCached + variantes propres (au minimum : header, footer, nav, sidebar).
• Pipeline assets : resources.Concat → minify → fingerprint (SRI).
• Images : Cloudflare Image Resizing (ou .Resize Hugo) + lazy intelligent + placeholder SVG.
• getJSON : config de cache (maxAge) et --ignoreCache en dev.
• --templateMetrics + --templateMetricsHints pour viser les pires templates.
• Pagination : passer à [pagination].pagerSize si vous migrez.
• Utiliser site.RegularPages au lieu de .Site.Pages dans les boucles.
• Module mounts avec excludeFiles pour éviter que Hugo scanne backups/archives.
• Prod : --gc + --cleanDestinationDir + --minify.
• Cache permanent pour images/assets (maxAge = -1).

Voilà. Avec tout ça, je suis passé de plusieurs heures à quelques minutes pour ~60 000 pages. Les clés : partialCached partout où la sortie ne bouge pas, un bundle CSS/JS propre avec fingerprint/SRI, et site.RegularPages pour ne pas trimbaler les taxonomies dans les boucles.

N’oubliez pas de lancer hugo --templateMetrics --templateMetricsHints pour trouver ce qui coûte cher lors de la génération. Vous verrez, dans 90% des cas c’est un partial appelé 10 000 fois non mis en cache, ou une boucle sur .Site.Pages trop large. Réparez ça, et votre build respira de nouveau.

Et si après tout ça votre build met encore plus de 10 s pour builder moins de 1000 pages, c’est qu’il y a un loup dans vos templates. Réduisez la surface des boucles, chassez les recalculs, et mettez partialCached partout où c’est pertinent !

Bon courage !

Vous savez qu’Unix n’aurait jamais dû exister ? Hé oui, tout a commencé parce que Ken Thompson voulait jouer à Space Travel, son petit jeu vidéo. Sauf que sur le mainframe de Bell Labs, chaque partie lui coûtait 75 dollars en temps machine. C’était complètement absurde, du coup, il a bricolé un système sur un vieux PDP-7 pour faire tourner son jeu gratos.

Car oui, les plus grandes révolutions informatiques naissent parfois des problèmes les plus cons, vous allez voir…

Vous pensez que Steve Jobs a révolutionné l’informatique ? Que nenni ! Il a surtout fait du super marketing. Les vrais héros, ceux qui ont posé les fondations de TOUT ce que vous utilisez aujourd’hui c’est-à-dire votre iPhone, Android, Linux, même Windows dans ses tripes profondes, s’appellent Dennis MacAlistair Ritchie et Kenneth Lane Thompson. Deux potes de Bell Labs qui ont littéralement inventé l’informatique moderne dans les années 70 en se marrant.

L’histoire que je vais vous raconter aujourd’hui, c’est donc celle de deux génies qui ont créé Unix et le langage C presque par accident, et croyez-moi, c’est bien plus épique que n’importe quel biopic hollywoodien avec Ashton Kutcher dedans.

Imaginez un endroit où on vous paye pour réfléchir et bidouiller sans qu’on vous emmerde avec des deadlines, des KPI ou des réunions PowerPoint interminables. Bienvenue à Bell Labs dans les années 60, le Disneyland de la recherche informatique. Ce temple de l’innovation, propriété d’AT&T, abritait les cerveaux les plus tordus de la planète. C’est là par exemple qu’on a inventé le transistor, le laser, la théorie de l’information, et j’en passe. Bref, tout ce qui fait tourner notre monde moderne.

Dennis MacAlistair Ritchie, né le 9 septembre 1941 à Bronxville dans l’État de New York, était le fils d’Alistair Ritchie, un scientifique de Bell Labs spécialisé dans les systèmes de commutation. Le gamin avait donc l’informatique dans le sang, avec un côté discret et un humour plus sec que le Sahara en plein été. Diplômé de Harvard en physique en 1963, puis docteur en mathématiques appliquées en 1967, il débarque à Bell Labs la même année. Sauf que sa thèse de doctorat, il ne la finira jamais, trop occupé à changer le monde.

Kenneth Lane Thompson, né le 4 février 1943 à La Nouvelle-Orléans, était le parfait opposé : un sale gosse qui avait traîné ses guêtres partout avant d’atterrir à Berkeley pour des études d’ingénierie électrique. Bachelor en 1965, master en 1966, et hop, direction Bell Labs. Obsédé par les jeux vidéo et les échecs, Ken était le genre de mec capable de coder 30 heures d’affilée sans dormir, juste alimenté par du café et de la passion pure. Ce gars ne tenait pas à la vie.

Le fameux PDP-7 (source)

En 1969, nos deux zigotos bossaient sur Multics (Multiplexed Information and Computing Service), un projet pharaonique censé révolutionner les systèmes d’exploitation. Le truc était tellement ambitieux qu’il en devenait inutilisable. Comme l’a dit Sam Morgan de Bell Labs : “C’était clair que Multics essayait de grimper trop d’arbres à la fois” et AT&T a fini par lâcher l’affaire en avril 1969, déclarant victoire tout en se barrant du projet, un peu comme les Américains au Vietnam.

Ken Thompson se retrouve donc sans projet officiel, avec juste un vieux PDP-7 qui traînait dans un coin du labo. Cette antiquité informatique de Digital Equipment Corporation, sortie en 1964, avait 8K de mémoire (oui, kilooctets, pas méga) et coûtait 72 000 dollars de l’époque. Pour vous donner une idée, c’est moins puissant qu’une calculatrice.

Ken et Dennis (source)

A l’époque, pour jouer à Space Travel, une simulation spatiale qu’il avait codée lui-même, Ken utilisait un autre ordinateur. Plus exactement un mainframe GE-645 avec lequel une partie lui coûtait 75 dollars en temps CPU. À ce prix-là, autant s’acheter une vraie fusée. Et là, c’est le destin qui frappe, car à l’été 1969, pendant que Neil Armstrong marchait sur la Lune, Bonnie Thompson (la femme de Ken) part en vacances chez les beaux-parents avec leur nouveau-né pour 3 semaines. Ken se retrouve donc célibataire temporaire avec un PDP-7, du temps libre et une seule mission : porter Space Travel sur cette machine pour pouvoir jouer sans se ruiner.

Space Travel (source)

Ce que Ken n’avait pas prévu, c’est qu’il allait devoir tout réécrire from scratch. Y’a pas de système d’exploitation sur le PDP-7, rien, nada, alors il s’y met : système de fichiers, éditeur de texte, assembleur, debugger, tout y passe. Il code comme un fou, et au bout de quelques semaines, il réalise qu’il vient de créer un système d’exploitation complet. Par accident. Pour un jeu vidéo.

Dennis Ritchie, qui suivait les bidouillages de son pote avec intérêt, lui file un coup de main et Brian Kernighan, un autre génie du labo, trouve le nom parfait : “Unics” (Uniplexed Information and Computing Service), une blague sur Multics. Parce que contrairement à ce monstre complexe, leur système ne supportait qu’un seul utilisateur à la fois. Le nom évoluera vite en “Unix” parce que c’était plus cool à prononcer.

En deux mois, pendant l’été 69, ils ont ainsi pondu les bases d’Unix. Thompson a même développé une philosophie qui guide encore l’informatique aujourd’hui : “Faire une chose et la faire bien”. Chaque programme Unix était conçu pour être simple, modulaire, et pouvoir communiquer avec les autres via des pipes. C’est tout con, mais c’est génial.

En 1970, pour avoir plus de ressources, ils expliquent à leur boss, qu’Unix pourrait servir pour du traitement de texte. Bell Labs leur file un PDP-11/20 tout neuf à 65 000 dollars. Cette machine, c’était la Rolls des mini-ordinateurs : 24K de mémoire, des disques durs, le grand luxe.

Ken invente alors le langage B, basé sur BCPL (Basic Combined Programming Language). Sauf que quand ils migrent Unix vers le PDP-11, B montre ses limites : pas de types de données, pas de structures, bref, c’était trop “basique”.

Dennis, pas du genre à lâcher l’affaire, se retrousse les manches et crée le langage C durant la période 1972-1973. Le nom ? Bah c’est la lettre après B, ils ne se sont pas cassé la tête. Le C, c’était révolutionnaire, car assez proche de l’assembleur pour être efficace et assez évolué pour être lisible par un humain normal. Les pointeurs, les structures, les types de données, tout y était.

Puis en 1973, Dennis fait un truc de ouf : il réécrit le kernel Unix entier en C. À l’époque, tout le monde pensait qu’un OS devait être écrit en assembleur pour être performant et ces deux mecs venaient de prouver le contraire. Unix devenait portable. On pouvait le faire tourner sur n’importe quelle machine avec un compilateur C. C’était fou !

En 1978, Dennis et Brian Kernighan publient “The C Programming Language”, surnommé le “K&R” par les geeks. Ce bouquin de 228 pages est devenu LA bible du C. La première édition contenait même le fameux programme “Hello, World!” qui est devenu le premier truc que tout programmeur écrit.

Petite anecdote marrante, quand Unix a commencé à se répandre dans les universités américaines durant les années 70, Ken distribuait personnellement les bandes magnétiques 9 pistes le contenant. Chaque envoi était même accompagné d’un petit mot manuscrit signé “Love, Ken”. Imaginez recevoir Unix avec un bisou du créateur ! C’était ça l’esprit de l’époque… du partage, de la bienveillance, et zéro marketing bullshit.

Dans le code source d’Unix Version 6, Dennis Ritchie a également écrit le commentaire de code le plus célèbre de l’histoire de l’informatique. Dans la fonction de context-switching (ligne 2238 du fichier slp.c), il a ajouté :

/* You are not expected to understand this */

Ce commentaire est devenu culte, et on le retrouve sur des t-shirts, des mugs, des posters dans tous les bureaux de devs du monde. Dennis expliquera plus tard dans un email que c’était dans l’esprit “ça ne sera pas demandé lors de l’examen” et pas du tout un défi arrogant contrairement à ce qu’on pourrait penser.

D’ailleurs, le code était buggé et même eux ne le comprenaient pas complètement à l’époque.

En 1984, Ken Thompson balance alors le hack le plus vicieux de l’histoire lors de sa conférence pour le prix Turing. Il montre comment il pourrait modifier le compilateur C pour injecter automatiquement une backdoor dans Unix. Le truc vraiment diabolique c’est que même en lisant tout le code source, impossible de détecter le piège. Le compilateur s’auto-infecterait à chaque compilation. Sa conclusion est sans appel : “You can’t trust code that you did not totally create yourself”.

Cette présentation, connue sous le nom de “Reflections on Trusting Trust”, a traumatisé toute une génération de développeurs.

Dennis, lui, était l’antithèse totale de Steve Jobs : discret, humble, fuyant les projecteurs comme un vampire fuit l’ail. Sa famille le décrivait comme “un frère incroyablement gentil, doux, modeste et généreux et évidemment un geek complet. Il avait un sens de l’humour hilarant et une appréciation aiguë des absurdités de la vie”. Rob Pike, son collègue, racontait : “Dennis était drôle d’une manière tranquille. Par exemple, il décrivait les erreurs dans son propre travail de manière hilarante”.

Un participant à une conférence Usenix racontera même un peu plus tard cette anecdote qui montre toute l’humilité de Dennis : “J’ai rencontré Dennis Ritchie sans le savoir. Il avait échangé son badge avec quelqu’un d’autre pour éviter d’être harcelé. J’ai passé 30 minutes à discuter avec lui en me disant “putain ce mec s’y connaît vraiment bien”. Puis l’autre type est arrivé et a dit “Dennis, j’en ai marre de gérer tes groupies, reprends ton badge”. Ils ont rééchangé les badges. J’ai regardé… c’était le mec qui avait non seulement écrit le livre que j’avais utilisé pour apprendre le C, mais qui avait inventé le langage lui-même.”

Contrairement aux rockstars de la Silicon Valley d’aujourd’hui, Dennis n’a jamais cherché la célébrité. Il préférait coder tranquille dans son coin à Bell Labs, peaufiner Unix et le C, et laisser son travail parler pour lui. Quand il croisait Steve Jobs ou Bill Gates dans des conférences, personne ne le reconnaissait. Pourtant, sans lui, ni l’iPhone ni Windows n’existeraient, car les deux systèmes reposent sur des fondations qu’il a posées.

Dennis Ritchie est mort le 12 octobre 2011, à 70 ans, seul dans son appartement de Berkeley Heights dans le New Jersey. Il vivait en ermite depuis la mort de ses frères et sœurs. Son corps a été découvert plusieurs jours après sa mort.

Dennis en 2011 (source)

Tandis que la mort de Steve Jobs le 5 octobre 2011 avait fait la une de tous les médias du monde, celle du créateur du C et d’Unix est passée quasi inaperçue.

Ken Thompson, lui, continue de nous étonner. À l’age de 82 ans en 2025, après sa retraite de Bell Labs en 2000, il continue de bosser chez Google depuis 2006 sur le langage Go avec Rob Pike et Robert Griesemer. Quand Google a voulu le recruter, ils lui ont demandé de passer un test de compétence en C. Sa réponse ? “Non merci, j’ai inventé le prédécesseur du C et Dennis a créé le C lui-même”. La classe absolue. Google l’a embauché direct.

Ken Thompson en 2019 (source)

Surtout que Ken a toujours été un passionné obsessionnel. Dans les années 80, il a créé Belle, l’ordinateur d’échecs le plus fort du monde, entièrement câblé en hardware. Cette machine a remporté le championnat du monde des ordinateurs d’échecs plusieurs fois. Le gouvernement américain l’a même temporairement confisqué quand Ken a voulu l’emmener en URSS pour un tournoi, de peur qu’elle tombe entre les mains des Soviétiques ! Belle était classée comme “munition” selon les lois d’exportation américaines. Du délire.

Parallèlement, Ken avait créé une base de données de 35 000 morceaux de musique dont il avait numérisé une bonne partie, stockés sur son système avec un algorithme de compression maison appelé PAC, bien avant l’arrivée du MP3. Quand les juristes de Bell Labs lui ont demandé s’il était dans la légalité, il a répondu avec son flegme habituel : “J’en collectionne beaucoup”. Ils lui ont répondu quelque chose comme : “Il y a du fair use pour la recherche, mais on n’ira pas en prison pour vous, alors vous devez arrêter”. Ken étant Ken, il a continué tranquille.

Ken et Rob Pike ont aussi inventé UTF-8 en 1992 lors d’un dîner dans un restaurant de New Jersey. Ils ont dessiné l’encodage sur une nappe en papier et aujourd’hui, UTF-8 représente 98% du web.

Ce qui rend cette histoire encore plus belle, c’est l’environnement unique de Bell Labs. Pas de daily standup, pas de sprint planning, pas de rétrospectives, pas de KPI, pas de OKR, pas de management toxique. Juste des génies qui se croisent dans les couloirs, discutent devant la machine à café, et imaginent les techno de demain. Cette culture collaborative a inspiré tout ce qu’on redécouvre aujourd’hui.

Le partage de code source ? Ils distribuaient Unix gratuitement aux universités. La review collaborative ? Ils se relisaient mutuellement sans process formalisé. L’amélioration continue ? Chaque version d’Unix apportait des innovations. L’open source ? Unix était fourni avec son code source complet. Tout ce qu’on pense avoir inventé avec Git, GitHub, et l’agile, ils le pratiquaient naturellement dans les années 70.

La philosophie Unix qu’ils ont créée tient en quelques principes simples mais géniaux. Comme je vous le disais plus haut, il y a d’abord “Faire une chose et la faire bien” où chaque programme Unix est spécialisé. “Tout est fichier”, une abstraction simple pour tout le système. “Les programmes doivent pouvoir communiquer”, d’où les pipes qui permettent de chaîner les commandes. “Privilégier la portabilité sur l’efficacité”, d’où le choix du C plutôt que l’assembleur.

Ces principes, on les retrouve partout aujourd’hui, de Docker aux microservices.

Et aujourd’hui, Unix et ses descendants font tourner absolument tout.

Linux, le clone d’Unix créé par Linus Torvalds en 1991 fait tourner 96.3% des 500 plus gros supercalculateurs du monde, 71% des smartphones (Android), et la majorité des serveurs web. MacOS et iOS basés sur Darwin, lui-même descendant de BSD Unix. FreeBSD, OpenBSD, NetBSD aussi sont des descendants directs d’Unix. Même Windows, avec son Windows Subsystem for Linux, est une reconnaissance de la supériorité du modèle Unix.

Le langage C reste lui aussi indétrônable pour tout ce qui touche au système. Le kernel Linux c’est 28 millions de lignes de C. Windows a son noyau est en C. MacOS en C et Objective-C (une extension du C). Les interpréteurs de Python, Ruby, PHP, Perl sont également écrits en C. Les bases de données MySQL, PostgreSQL, Redis, SQLite, c’est pareil. Sans parler des navigateurs web, des compilateurs, des machines virtuelles, de l’embarqué, de l’IoT, des systèmes critiques dans l’aviation, le spatial, le médical… Du C partout !!

Sans Dennis et Ken, pas de smartphone, pas d’Internet moderne, pas de cloud computing, pas d’intelligence artificielle (les frameworks de deep learning sont écrits en C/C++), pas de jeux vidéo modernes non plus (les moteurs de jeu sont en C++). Ils ont littéralement créé les fondations sur lesquelles repose toute notre informatique actuelle.

Quand Guido van Rossum a créé Python en 1989, il s’est inspiré de la syntaxe du C et Bjarne Stroustrup a créé C++ en 1979 comme une extension du C “avec des classes”. James Gosling s’est basé lui aussi sur la syntaxe du C pour créer Java en 1995. Brendan Eich a également repris la syntaxe du C pour JavaScript en 1995 (en 10 jours, le fou). Même les langages modernes comme Rust, Go, Swift, Kotlin, tous portent l’ADN du travail de Dennis.

Ken Thompson déteste d’ailleurs C++ avec passion : “Il fait beaucoup de choses à moitié bien et c’est juste un tas d’idées mutuellement exclusives jetées ensemble”. Avec Go, qu’il a co-créé chez Google, il a donc voulu revenir à la simplicité du C originel, mais adapté au monde moderne du multicore et des réseaux. Go compile en quelques secondes là où C++ prend des minutes. La simplicité, toujours la simplicité.

Dennis et Ken ont reçu pratiquement tous les prix possibles en informatique. Le prix Turing en 1983 (l’équivalent du Nobel en informatique), la National Medal of Technology en 1998 des mains du président Clinton, le Japan Prize en 2011 (400 000 dollars quand même). Ken a été élu à l’Académie Nationale d’Ingénierie en 1980 et à l’Académie Nationale des Sciences en 1985. Mais leur plus grande fierté c’est de voir leur création utilisée partout, par tout le monde, tous les jours.

L’histoire de Dennis et Ken nous enseigne plusieurs trucs cruciaux. Tout d’abord que l’innovation naît de la liberté créative. Pas de process, pas de roadmap, pas de framework agile, juste la liberté d’explorer et de se planter. C’est comme ça qu’Unix a réussi là où Multics a échoué, car la complexité tue l’innovation, toujours.

De mon point de vue, Dennis Ritchie mérite autant de reconnaissance que Steve Jobs ou Bill Gates, si ce n’est plus. Sans oublier Ken Thompson qui continue de coder à plus de 80 ans chez Google. Quand on lui demande pourquoi il continue, il répond simplement : “C’est fun”.

En tout cas, leur philosophie continue d’inspirer encore aujourd’hui avec l’open source, le partage de code, le principe du “faire une chose et la faire bien”… et ça c’est beau !

Voilà, maintenant vous savez pourquoi Unix c’est beau et Windows c’est… bah c’est Windows quoi. Allez, sortez votre terminal, tapez man unix et saluez ces deux génies. Et si vous voulez vraiment leur rendre hommage, apprenez le C, c’est moins chiant que vous pensez et ça vous fera comprendre comment les ordinateurs fonctionnent vraiment.

Et dire qu’à la base, c’était pour faire tourner un jeu vidéo débile…

Sources : Bell Labs - Dennis Ritchie Home Page, Wikipedia - Dennis Ritchie, Wikipedia - Ken Thompson, ACM Turing Award - Dennis Ritchie, ACM Turing Award - Ken Thompson, Brian Kernighan on Dennis Ritchie, Ken Thompson - Reflections on Trusting Trust

Imaginez. Vous êtes tranquillement en train de bosser sur votre PC, votre webcam Lenovo tranquillement posée sur votre écran, et vous ne vous doutez de rien. Sauf que pendant ce temps, un cybercriminel à l’autre bout du monde a trafiqué votre innocente caméra pour qu’elle tape des commandes sur votre clavier sans que vous ne voyiez rien. Et même si vous formatez votre PC, elle continuera son petit manège.

C’est exactement ce qu’ont réussi à démontrer les chercheurs d’Eclypsium lors de la DEF CON 33. Paul Asadoorian, Mickey Shkatov et Jesse Michael ont en effet découvert une faille monumentale dans les webcams Lenovo 510 FHD et Performance FHD. Le bug, baptisé BadCam et référencé sous la CVE-2025-4371, et permet de transformer à distance ces webcams en dispositifs BadUSB.

Pour ceux qui ne connaissent pas BadUSB, c’est une technique d’attaque qui fait croire à votre ordinateur qu’un périphérique USB est autre chose que ce qu’il prétend être. Dans ce cas, votre webcam peut soudainement se faire passer pour un clavier et commencer à taper des commandes, sauf qu’ici, c’est encore pire puisque l’attaque peut se faire entièrement à distance, sans que personne ne touche physiquement à votre webcam.

Le problème vient du fait que ces webcams tournent sous Linux avec un processeur ARM SigmaStar SSC9351D. Elles utilisent le USB Gadget subsystem de Linux, qui permet à un périphérique USB de changer de rôle. Normalement, c’est pratique pour faire du debug ou créer des périphériques multifonctions. Mais dans le cadre de cette exploitation de bug, c’est pas foufou.

Ainsi, un attaquant qui a déjà un accès distant à votre machine (via un malware classique par exemple) peut identifier votre webcam Lenovo connectée. Il pousse alors une mise à jour firmware malveillante vers la caméra. Puis la webcam devient alors un dispositif BadUSB qui peut injecter des commandes clavier, installer des backdoors, voler vos mots de passe… bref, tout ce qu’un clavier peut faire en fait.

Et le plus “drôle” c’est que la webcam continue de fonctionner normalement en tant que caméra. Vous pouvez donc toujours faire vos visios Zoom en slip, car elle filme toujours et rien ne laisse supposer qu’elle est compromise. Et comme le malware réside dans le firmware de la webcam et non sur votre disque dur, vous pouvez reformater votre PC autant de fois que vous voulez, la webcam restera infectée et réinfectera votre système à chaque redémarrage.

Les chercheurs ont aussi découvert un autre vecteur d’attaque encore plus vicieux. Un attaquant peut vous envoyer une webcam déjà backdoorée par la poste. Genre un “cadeau” d’entreprise ou une webcam d’occasion sur LeBonCoin. Vous la branchez, et hop, vous êtes compromis. La webcam peut alors recevoir des commandes à distance et compromettre votre système quand l’attaquant le décide.

Et c’est pas la première fois que des experts en sécurité démontrent qu’un périphérique USB Linux déjà connecté peut être transformé en cyberarme exploitable à distance. Avant, les attaques BadUSB nécessitaient un accès physique pour brancher un périphérique malveillant mais là, on peut “weaponiser” un périphérique légitime qui est déjà sur votre bureau.

Le cœur du problème c’est que ces webcams ne vérifient pas la signature du firmware qu’on leur envoie. N’importe qui peut pousser n’importe quel firmware, et la webcam l’accepte les yeux fermés. C’est comme si votre porte d’entrée acceptait n’importe quelle clé, même un cure-dent.

Bien sûr, Lenovo a été prévenu en avril dernier et a sorti un correctif (firmware version 4.8.0) en août, juste avant la présentation à la DEF CON. Ils ont bossé avec SigmaStar pour créer un outil d’installation qui vérifie maintenant les signatures. Mais comme pour Winrar, combien d’utilisateurs vont vraiment mettre à jour le firmware de leur webcam ? Personne ne fait ça, j’crois…

Et le problème va bien au-delà de ces deux modèles Lenovo car les chercheurs d’Eclypsium ont indiqué que n’importe quel périphérique USB qui tourne sous Linux avec le USB Gadget subsystem pourrait être vulnérable. On parle donc de milliers de modèles de webcams, mais aussi de dispositifs IoT, de hubs USB, et même de certains claviers gaming haut de gamme qui embarquent Linux.

Voilà, donc pour vous protéger, si vous avez une Lenovo 510 FHD ou Performance FHD, foncez sur le site de support Lenovo et installez la mise à jour firmware 4.8.0. Et pour les autres webcams, c’est pareil, méfiez-vous et mettez à jour, car peut-être qu’elle pourrait faire des trucs qu’elle ne devrait pas pouvoir faire.

A partir de maintenant, tout ce qui se connecte à un port USB est votre ennemi !! Oui, surtout ce petit ventilo acheté sur Temu la semaine dernière…

Parfois, je me demande ce que foutent les équipes de Google… Un mec tout seul vient de créer une version desktop de YouTube Music qui explose littéralement la version web officielle et son interface web basique qui balance des pubs toutes les trois chansons.

L’app s’appelle YouTube Music Desktop, et c’est un projet open source disponible sur GitHub qui fait exactement ce que Google devrait faire depuis des années. Le développeur a pris Electron, a wrappé l’interface web de YouTube Music dedans, et puis il a ajouté tout ce qui manque cruellement à la version officielle.

Du coup on obtient une app desktop qui tourne sur Windows, Mac et Linux, codée par un seul mec qui surpasse complètement le produit officiel d’une boîte qui pèse 2000 milliards de dollars. Ce truc bloque toutes les pubs et le tracking par défaut, vous pouvez télécharger vos morceaux en MP3 ou Opus pour les écouter offline. Et y’a des raccourcis clavier natif qui fonctionnent sur tous les OS. Il y a même un égaliseur et un compresseur audio intégrés pour améliorer le son.

Mais le meilleur c’est le système de plugins. On peut y ajouter des extensions en un clic pour ajouter exactement les fonctionnalités que vous voulez. Discord Rich Presence pour montrer à vos potes ce que vous écoutez, des lyrics synchronisées qui s’affichent en temps réel, un mode ambient qui change les couleurs de l’interface selon l’album, du backup local de playlists, l’ajout dans la touchBar sous Mac…etc et le tout sans avoir à fouiller dans du code ou des configs compliquées.

Pour l’installer, c’est super simple. Sur Windows, passez par Scoop ou Winget. Sur Mac, c’est Homebrew avec un simple brew install youtube-music. Sur Linux, vous avez des packages pour toutes les distros majeures.

L’app pèse moins de 100MB et consomme moins de RAM que l’onglet YouTube Music dans Chrome. D’ailleurs, il n’y a pas que cette version. YTMDesktop propose une alternative similaire avec une interface un peu différente et un focus sur l’intégration système. Après c’est une question de goût…

Bref, cette app montre exactement ce que YouTube Music pourrait être si Google se bougeait le cul. Ce sont des trucs basiques que les utilisateurs demandent depuis le lancement du service mais comme Google est plus concentré à faire payer un abonnement Premium à 11€ par mois qu’à proposer des fonctionnalités cools, bah voilà…

Évidemment, cette app pourrait arrêter de fonctionner du jour au lendemain si Google décide de changer son API ou d’en bloquer l’accès mais pour l’instant, ils laissent faire. Donc si vous en avez marre de YouTube Music dans le navigateur, ou que vous voulez stopper votre abonnement Spotify parce qu’il a encore augmenté, foncez. L’app est gratuite, open source, et fait tout mieux que la version officielle.

Merci à Lilian pour la découverte !

WinRAR, vous savez, le truc que tout le monde a sur son PC pour décompresser des fichiers et dont personne ou presque ne paye la licence ? Bah il vient de se faire trouer comme jamais. En effet un groupe de hackers russes exploite actuellement une faille zero-day pour installer des backdoors sur les machines et le pire dans tout ça, c’est que vous avez probablement WinRAR installé depuis des années sans jamais l’avoir mis à jour.

La faille en question, c’est la CVE-2025-8088, une vulnérabilité de type directory traversal qui a été découverte le 9 janvier dernier. En gros, quand vous ouvrez une archive RAR piégée, le malware peut s’installer où il veut sur votre système, notamment dans le dossier de démarrage de Windows. Résultat, à chaque fois que vous allumez votre PC, la backdoor se lance automatiquement.

Derrière cette attaque, on trouve le groupe RomCom, aussi connu sous les noms Storm-0978, Tropical Scorpius, Void Rabisu ou UNC2596. Ces mecs sont liés à la Russie et sont actifs dans le cyber-espionnage depuis plusieurs années. Leur mode opératoire est simple… Ils vous envoient des emails de phishing avec des pièces jointes RAR qui ont l’air légitimes. Genre un faux document de votre banque ou une facture bidon.

Ce qui rend cette vulnérabilité particulièrement vicieuse, c’est la méthode d’exploitation. Comme je vous l’expliquais en intro, les fichiers malveillants peuvent être placés directement dans le dossier Windows Startup sans aucune alerte de sécurité, permettant au malware de s’exécuter automatiquement à chaque démarrage. Vous décompressez le fichier, vous pensez que tout va bien, mais en réalité vous venez d’installer un backdoor qui donnera accès complet à votre machine aux hackers.

RARLAB, la société derrière WinRAR, a publié en urgence la version 7.02 le jour même de la découverte, sauf que voilà le problème : WinRAR n’a pas de système de mise à jour automatique. Ça veut dire que les 500 millions d’utilisateurs dans le monde doivent aller manuellement télécharger et installer la nouvelle version. Combien vont vraiment le faire ? On peut parier que dans 6 mois, 90% des gens auront toujours la version vulnérable.

D’ailleurs, c’est pas la première fois que WinRAR se fait avoir cette année. En juin 2025, une autre faille critique CVE-2025-6218 avec un score CVSS de 7.8 permettait l’exécution de code à distance. Et il y a aussi eu la CVE-2025-31334 qui permettait de contourner le Mark of the Web, cette protection Windows qui vous avertit quand vous ouvrez un fichier téléchargé d’Internet.

Les chercheurs en sécurité qui ont analysé les attaques RomCom ont découvert que le groupe cible principalement des organisations gouvernementales et militaires en Ukraine et dans les pays de l’OTAN. Selon Security Affairs, les attaquants utilisent des leurres très élaborés, comme de faux documents sur des exercices militaires ou des rapports de renseignement.

Le malware RomCom lui-même est une saloperie bien rodée. Une fois installé, il peut voler vos identifiants, enregistrer vos frappes clavier, faire des captures d’écran, et même activer votre webcam. Les hackers peuvent aussi l’utiliser comme point d’entrée pour déployer d’autres malwares, notamment des ransomwares qui chiffrent tous vos fichiers.

C’est quand même couillon cette absence totale de mise à jour automatique dans WinRAR. On est en 2025, et même ma cafetière se met à jour toute seule ! Alors comment un logiciel aussi répandu peut encore fonctionner comme dans les années 90 ? RARLAB justifie ça en disant qu’ils veulent éviter de “déranger” les utilisateurs. Mais là, le dérangement c’est de se faire pirater parce qu’on n’a pas pensé à vérifier manuellement les mises à jour.

Pour vous protéger, c’est simple mais chiant… Allez sur le site officiel de WinRAR (attention aux faux sites), téléchargez la version la plus récente, et installez-la par-dessus votre ancienne version. Vérifiez bien dans le menu Aide que vous avez la bonne version après installation. Et surtout, méfiez-vous des archives RAR que vous recevez par email ou que vous téléchargez. Si vous avez un doute, utilisez un sandbox ou une machine virtuelle pour les ouvrir.

Les entreprises sont particulièrement à risque parce qu’elles ont souvent des versions anciennes de WinRAR déployées sur des centaines de postes et avec le télétravail, c’est encore pire car les employés utilisent leurs PC perso avec des versions obsolètes pour ouvrir des fichiers pro. C’est la porte ouverte à toutes les fenêtres, comme dirait l’autre !

Bref, encore une fois, c’est souvent les trucs basiques qu’on néglige qui nous font tomber. Faites-vous une faveur et mettez à jour WinRAR maintenant, ou mieux, passez à 7-Zip qui est open source et se met à jour plus régulièrement.

Source

Nous sommes lundi matin, et vous garez votre bagnole dans le parking du boulot…. Et pendant que vous glandouillez devant korben.info avec un petit café, un mec à l’autre bout du monde déverrouille votre caisse, fouille dans vos données perso et suit vos trajet en temps réel. De la science-fiction ? Non, c’était possible jusqu’en février 2025 chez un constructeur automobile majeur qu’on ne nommera pas. Pas parce que je ne veux pas le dire mais parce que son nom a été tenu secret.

Le héros de cette histoire, c’est Eaton Zveare, un chercheur en sécurité chez Harness qui a trouvé LA faille de l’année. Lors de sa présentation au DEF CON 33, il a expliqué comment il a réussi à créer un compte “national admin” sur le portail concessionnaire d’un constructeur. Deux bugs API tout bêtes, et hop, accès total à plus de 1000 concessionnaires américains.

Le code buggé se chargeait directement dans le navigateur quand vous ouvriez la page de connexion et Zveare a juste eu à modifier ce code pour bypasser les contrôles de sécurité. Selon lui, “les deux vulnérabilités API ont complètement fait sauter les portes, et c’est toujours lié à l’authentification”. Bref, le B.A.-BA de la sécurité qui n’était pas respecté, une fois de plus.

Une fois connecté avec son compte admin fantôme, Zveare avait accès à un outil de recherche national complètement dingue. Il suffisait d’entrer un nom ou de relever un numéro VIN sur un pare-brise pour trouver n’importe quel véhicule du constructeur.

Le chercheur a testé ça sur un ami consentant (important, le consentement, hein !) et a transféré la propriété du véhicule sur un compte qu’il contrôlait, et bam, il pouvait déverrouiller la voiture à distance. Le portail demandait juste une “attestation”, en gros, une promesse sur l’honneur que vous êtes légitime. Super sécurisé, n’est-ce pas ?

Ce qui est flippant, c’est que ce n’est pas un cas isolé. Selon les chiffres de 2025, les cyberattaques sur les voitures ont augmenté de 225% en trois ans. 80% des nouvelles voitures ont une connexion internet, et 95% de toutes les voitures fabriquées en 2025 en auront une. Des millions de véhicules Kia et Subaru ont déjà été touchés par des vulnérabilités similaires permettant le contrôle à distance.

Mais le vrai délire, c’était la fonction “impersonation” du portail. Zveare pouvait se faire passer pour n’importe qui sans leurs identifiants et naviguer entre tous les systèmes interconnectés des concessionnaires. De là, c’était open bar : données perso et financières, tracking temps réel de TOUS les véhicules (perso, location, courtoisie, même ceux en livraison), contrôle de l’app mobile… Il pouvait même annuler des livraisons en cours…

Selon SecurityWeek, une vulnérabilité similaire dans le système Starlink de Subaru a été corrigée en 24 heures en novembre 2024. Cette faille permettait de démarrer, arrêter, verrouiller et déverrouiller des véhicules à distance. Le constructeur concerné par la découverte de Zveare a mis une semaine pour corriger les bugs après sa divulgation en février. Ils n’ont trouvé aucune preuve d’exploitation passée, ce qui suggère que Zveare était le premier à découvrir et signaler cette faille béante.

Ce qui est fou, c’est la simplicité du hack. Pas besoin d’être un génie du code ou d’avoir des outils sophistiqués. Juste deux bugs d’authentification mal gérés, et c’est open bar sur les données de milliers de clients et leurs véhicules. Les constructeurs automobiles doivent vraiment se réveiller sur la cybersécurité car avec 84,5% des attaques exécutées à distance et des API mal protégées partout, on est assis sur une bombe à retardement.

La morale de l’histoire c’est que si vous avez une voiture connectée, priez pour que votre constructeur prenne la sécurité au sérieux. Et si vous êtes développeur dans l’automobile, par pitié, sécurisez vos APIs d’authentification. C’est la base !

Source

J’ai découvert ce matin qu’on pouvait maintenant faire tourner un WordPress complet dans un navigateur. Sans serveur. Sans PHP installé. Sans MySQL. Juste votre navigateur et voilà, vous avez un WordPress fonctionnel. Ça s’appelle WordPress Playground et le truc de fou, c’est que tout ça tourne grâce à WebAssembly.

Pour ceux qui ne connaissent pas, WebAssembly c’est cette techno qui permet de faire tourner du code compilé directement dans le navigateur à une vitesse proche du natif. Les mecs de WordPress ont donc carrément compilé PHP en WebAssembly. Selon la documentation officielle, ils utilisent même SQLite à la place de MySQL, avec un driver qui intercepte toutes les requêtes MySQL pour les traduire en SQLite.

Concrètement, vous allez sur playground.wordpress.net, et hop, vous avez un WordPress qui se lance instantanément. Pas d’“installation en 5 minutes” comme avant. C’est direct. Vous pouvez même installer des plugins, des thèmes, créer du contenu, tout ça dans votre navigateur. Et le plus beau c’est que comme tout reste en local dans votre navigateur, et rien n’est envoyé sur un serveur distant.

Les dernières mises à jour ont ajouté un nouveau driver SQLite qui améliore les performances, et maintenant le CLI supporte le montage de votre répertoire de travail, ce qui vous pouvez bosser sur vos fichiers locaux directement depuis WordPress Playground. Plus besoin de jongler entre votre éditeur et un serveur local.

Pour les développeurs, c’est surtout la révolution, car si vous codez un plugin, vous créez un Blueprint (un fichier JSON de configuration) et vous pouvez générer instantanément un environnement de test avec votre plugin préinstallé, des données de démo, et même des utilisateurs de test déjà connectés. La documentation Blueprint explique comment créer ces configurations, et c’est super simple. C’est comme Docker Compose mais pour WordPress, sauf que ça tourne dans le navigateur.

Dans le même genre des trucs cools, il y a l’outil wp-now. Vous êtes dans le dossier de votre plugin ou thème, vous tapez npx @wp-playground/cli server --auto-mount, et vous obtenez un WordPress local qui tourne avec votre code monté automatiquement. Pas d’installation, pas de config Apache, pas de base de données à créer. C’est instantané.

Et puis il y a tout ce qui est démos interactives. Selon WordPress Developer Blog, vous pouvez créer des tutoriels interactifs où les gens peuvent tester votre plugin directement dans leur navigateur. Plus besoin de dire “installez WordPress, puis installez mon plugin, puis configurez ci et ça”. Vous leur envoyez juste un lien avec un Blueprint, et ils ont tout prêt à tester.

Le repository WordPress.org a même commencé à intégrer des previews live pour les plugins. Vous allez sur la page d’un plugin, et au lieu de juste lire la description, vous pouvez le tester direct. Il suffit de créer un fichier blueprint.json dans le dossier assets de votre plugin, et WordPress.org s’occupe du reste.

Pour ceux qui se demandent comment ça marche techniquement, c’est assez balèze. Ils ont un Service Worker qui intercepte toutes les requêtes HTTP et les passe à une instance PHP qui tourne dans un Web Worker séparé. Le PHP est compilé avec Emscripten (l’outil qui convertit du C/C++ en WebAssembly), et ils ont adapté toute la stack pour que ça fonctionne dans le navigateur. Et selon Platform Uno, avec l’arrivée de WASI 0.3, on va avoir des capacités async natives qui vont encore améliorer les performances.

Ce qui est vraiment cool aussi, c’est l’extension VS Code qu’ils ont sortie. Vous codez dans VS Code (ou Cursor pour les hipsters), et vous avez un WordPress Playground intégré directement dans l’éditeur. Ça évite de switcher entre l’éditeur et le navigateur pour tester. Ça change complètement le workflow de développement.

Alors oui, c’est encore expérimental. Oui, il y a des limitations (pas de support pour certaines extensions PHP, pas de persistance longue durée par défaut). Mais franchement, pour du prototypage rapide, des démos, ou même juste pour apprendre WordPress sans se prendre la tête avec l’installation, c’est parfait. Avec ça, vous pouvez même faire dess formations WordPress sans avoir à gérer 30 installations différentes pour vos étudiants.

Les développeurs parlent maintenant de faire tourner WordPress sur l’edge computing, d’avoir des sites WordPress décentralisés, et même de pouvoir développer des plugins depuis votre smartphone. Avec WebAssembly qui devient de plus en plus puissant, c’est vrai qu’on n’est qu’au début de ce qui est possible.

Donc si vous voulez tester, allez direct sur playground.wordpress.net. Et si vous êtes développeur, regardez la doc des Blueprints, c’est vraiment un génial pour créer des environnements de test reproductibles. Comme ça, plus d’excuses pour ne pas tester vos plugins dans toutes les configs possibles maintenant !

Si vous avez déjà ressenti ce petit pincement au cœur en laissant votre chat ou votre chien seul à la maison, l’Imou Pet Feeder PF1 4L est clairement conçu pour vous. Ce n’est pas juste un distributeur de croquettes, c’est un mélange entre un garde-manger intelligent et un petit agent secret équipé d’une caméra pour garder un œil sur votre compagnon. Je le teste depuis le début de l’été, et ça fonctionne super bien !

Une mangeoire qui pense à tout (et même plus)

Première bonne surprise : son réservoir de 4 litres. Concrètement, ça veut dire jusqu’à trois semaines de tranquillité selon la taille et l’appétit de votre animal. Les croquettes restent au sec, et la distribution est régulière grâce à un système motorisé fiable, protégé contre les bourrages. Si jamais il y a un souci, l’appli vous prévient. Cerise sur la gamelle : l’appareil fonctionne sur secteur, mais aussi sur piles en cas de coupure de courant.

Une caméra 2,5K qui voit tout

Là où l’Imou Pet Feeder se distingue vraiment, c’est avec sa caméra 4 MP intégrée juste au-dessus du bol. Vous avez quatre modes de vision, dont un panoramique à 360°, un mode “bol” pour zoomer sur l’action (comprendre : voir votre chat engloutir ses croquettes), un mode fisheye ultra-large et un mode VR qui permet de bouger le point de vue à la volée. Même de nuit, la qualité reste excellente.

Et comme voir ne suffit pas, vous pouvez aussi parler à votre animal grâce à la communication bidirectionnelle, ou enregistrer un petit message audio qui se déclenche à chaque repas. On est dans la personnalisation totale.

Une application bien pensée

Tout se pilote depuis l’application Imou Life, disponible sur Android et iOS, ultra simple à utiliser. Vous pouvez programmer jusqu’à 15 repas par jour, ajuster la taille des portions au gramme près, déclencher un repas manuellement ou même laisser l’IA décider en fonction des restes détectés dans le bol. Les statistiques sur les habitudes alimentaires sont précises, et un an de stockage cloud est inclus pour revoir photos et vidéos.

Bonus pratique : il accepte des croquettes de 2 à 12 mm, qu’elles soient sèches, lyophilisées ou mélangées. L’entretien est simple grâce à un bol en acier inox amovible et lavable.

C’est absolument génial, c’est fiable, bien équipé, simple à configurer, et surtout rassurant pour vous comme pour lui. On l’adopte sans hésiter. Comptez 120 euros sur Amazon.

Article invité publié par Vincent Lautier. Vous pouvez aussi faire un saut sur mon blog, ou lire tous les tests que je publie dans la catégorie “Gadgets Tech”, comme cette liseuse Android de dingue ou ces AirTags pour Android !

Bon, vous m’avez demandé que je démêle le vrai du faux dans cette histoire de Firefox qui se transforme en aspirateur à batterie, alors allons-y. Je vous spoile quand même, c’est à la fois pire et moins grave que ce qu’on raconte ^^.

D’abord, parlons de cette solution miracle que personne ne vous donne dans les articles alarmistes. Ouvrez about:config, cherchez browser.tabs.groups.smart.enabled et mettez-le à false. Pareil pour browser.ml.chat.enabled. Voilà, problème réglé. Il y a même une ribambelle d’autres paramètres liés si vous voulez vraiment tout virer mais attendez avant de tout désactiver, laissez-moi vous expliquer ce qui se passe vraiment.

Alors oui, Firefox 141 s’est vu ajouter des groupes d’onglets assistés par IA qui peuvent automatiquement regrouper vos tabs selon leur contenu. Et oui, plusieurs utilisateurs se sont plaints sur Reddit de voir leur CPU grimper en flèche et leur batterie fondre comme neige au soleil. Apparemment, le coupable serait un processus appelé “Inference” qui gère toute cette magie IA en local.

Mais, non, Mozilla ne vous espionne pas avec cette IA car tout le traitement se fait sur votre machine. Rien, absolument rien n’est envoyé dans le cloud. C’est d’ailleurs pour ça que ça bouffe autant de ressources… C’est votre pauvre ordinateur qui fait tout le boulot tout seul.

Maintenant, le problème technique que personne n’explique vraiment c’est que Mozilla a choisi d’utiliser le format ONNX de Microsoft au lieu du format GGUF. Pour faire simple, GGUF est spécialement optimisé pour faire tourner de l’IA sur CPUavec une meilleure quantization, tandis qu’ONNX est plus généraliste. Donc c’est pas optimal mais plus adapté à un logiciel qui sert à plein de choses comme Firefox.

Firefox essaie ainsi de rattraper Chrome et Edge qui ont déjà leurs propres fonctionnalités IA, mais en y allant avec les pieds dans le plat. L’idée de regrouper automatiquement les onglets n’est pas mauvaise en soi et le système peut même suggérer d’autres onglets à ajouter au groupe basé sur le contenu. C’est super pratique sur le papier, mais c’est la cata en pratique si votre machine n’est pas une bête de course.

Les problèmes de conso batterie de Firefox ne datent pas d’hier et cette controverse IA vient juste s’ajouter à une longue liste de plaintes sur la consommation excessive du navigateur. Certains utilisateurs rapportent même que chaque mise à jour empire la situation mais sans le prouver avec des benchmarks ou des mesures fiables. Tout ceci c’est un peu des retours au feeling et la grande méchante IA, c’est juste la goutte d’eau qui fait déborder le vase.

Mozilla a déjà eu des controverses avec l’IA en début d’année avec des changements de conditions d’utilisation qui avaient fait flipper tout le monde. Ils avaient alors dû clarifier qu’ils n’utilisaient pas les données des utilisateurs pour entraîner des modèles. Mais cette fois, c’est différent, car l’IA tourne bien en local, mais elle bouffe vos ressources au passage.

Donc ce que je peux vous dire c’est que toute cette controverse est à moitié justifiée. OUI, les fonctionnalités IA de Firefox 141 peuvent effectivement faire exploser votre consommation CPU et vider votre batterie mais NON, ce n’est pas une catastrophe universelle. Ça dépend juste de votre config et de votre usage. Si vous avez 50 onglets ouverts sur un laptop de 2018, oui, vous allez souffrir. Si vous avez une machine récente et que vous utilisez Firefox normalement, vous ne remarquerez peut-être même pas la différence.

Le vrai problème en fait, c’est que Mozilla a activé ces nouvelles fonctionnalités par défaut sans vraiment prévenir les utilisateurs ni optimiser correctement le code. Ils auraient pu utiliser GGUF, ils auraient pu rendre ça opt-in, ils auraient pu mieux communiquer. Mais au lieu de ça, ils ont balancé ça dans une mise à jour et maintenant ils se prennent une volée de bois vert.

Alors, que faire ?

Et bien si vous avez des problèmes de performance, désactivez les fonctions IA via about:config. Et si vous voulez tester mais que vous trouvez ça trop gourmand, attendez quelques versions, car Mozilla finira probablement comme d’hab par optimiser tout ça.

Et fuck Chrome et tous ses dérivés ! (Oui c’était gratuit !)

Source

Ah Facebook… Vous savez quoi ? J’ai arrêté d’y poster mes news il y a un moment déjà parce que les gens qui prennent encore le temps d’y commenter ne sont pas toujours très “fut-fut” comme on dit. Et manifestement, les escrocs l’ont bien compris parce qu’ils s’en donnent à cœur joie avec leurs nouvelles techniques de malware planqués notamment dans des images.

Car la dernière trouvaille des cybercriminels, c’est de cacher du code malveillant dans des fichiers SVG partagés via des posts Facebook à thématique adulte. C’est brillant, non ?

Le SVG, contrairement au JPEG de tata Ginette, c’est du XML qui peut embarquer du HTML et du JavaScript. Du coup, vous cliquez sur l’image de la fausse célébrité à oualpé, et vous voilà avec un petit Trojan.JS.Likejack qui force votre navigateur à liker des pages Facebook sans que vous vous en rendiez compte.

Le plus drôle dans tout ça c’est que les hackers utilisent une technique appelée “hybrid JSFuck” pour masquer leur code. C’est une forme d’obfuscation qui encode le JavaScript en utilisant seulement six caractères : “[ ] ( ) ! +”. Du grand art pour piéger les grands naïfs qui traînent encore sur la plateforme de Zuckerberg.

Mais attendez, ça devient encore mieux puisqu’une étude d’Harvard révèle que les escrocs utilisent l’IA générative pour créer de fausses images… et ça cartonne énormément sur Facebook. Je vous parle quand même de centaines de millions d’engagements. Par exemple, avec une seule image générée par IA, un escroc a récolté 40 millions de vues. QUARANTE MILLIONS SUR UNE FAUSSE IMAGE !!! Et le pire c’est que la plupart des utilisateurs ne se rendent même pas compte que ces images sont bidons.

Les commentaires sous ce genre de posts sont également à mourir de rire. Des gens félicitent des enfants générés par IA pour leurs peintures générées par IA. D’autres envoient leurs infos personnelles à des comptes d’arnaqueurs pour acheter des produits qui n’existent pas. C’est beau la crédulité humaine, vraiment.

Et devinez qui tombe le plus dans le panneau ?

Les utilisateurs plus âgés, évidemment. Ceux qui tapent encore “www” avant chaque URL et qui pensent que le bouton “J’aime” est une forme de cyber-politesse.

D’ailleurs, en parlant d’arnaque sophistiquée, il y a aussi cette campagne de fausses pubs Facebook pour Kling AI qui distribue un RAT (Remote Access Trojan) appelé PureHVNC. Les victimes cliquent sur une pub pour un outil d’IA, et hop, les hackers ont accès complet à leur système et peuvent voler leurs identifiants et leurs cryptos. Et toute cette merde est amplifiée par l’algorithme de Facebook lui-même.

Car oui, la plateforme recommande activement ces contenus bidons parce qu’ils génèrent de l’engagement. L’algorithme voit des clics, des likes, des commentaires de gens crédules, et amplifie automatiquement ce contenu. C’est le cercle vicieux parfait où la stupidité nourrit l’arnaque qui nourrit l’algorithme qui nourrit la stupidité…etc.

Concernant ces images SVG vérolées, les sites malveillants sur lesquels tombent les victimes sont souvent hébergés sur Blogspot / WordPress. Ils promettent ainsi des photos explicites de stars (générées par IA bien sûr) et utilisent ces appâts pour installer leurs saloperies de malware. Et comme Edge sous Windows ouvre automatiquement les fichiers SVG, même si vous avez un autre navigateur par défaut, c’est super pratique pour les hackers… et moins pour les victimes.

Donc, si vous êtes encore sur Facebook en 2025 et que vous cliquez sur des images de célébrités à poil ou des posts d’enfants miraculeux qui peignent des chefs-d’œuvre, vous méritez presque ce qui vous arrive. C’est devenu un repaire d’escrocs qui exploitent la naïveté des derniers utilisateurs encore actifs. Entre les boomers qui partagent des fake news et les arnaqueurs qui déploient des malwares sophistiqués, Facebook c’est vraiment devenu le fond de poubelle d’Internet.

Donc mon conseil c’est que si vous tenez absolument à rester sur cette plateforme moribonde, apprenez au moins à reconnaître une image générée par IA, à travailler votre esprit critique et méfiez-vous des fichiers SVG comme de la peste. Et surtout, arrêtez de cliquer sur tout ce qui brille et de croire tout ce qui y est écrit. Internet, ce n’est pas un sapin de Noël magique.

Source

Bon cet aprem, je vais vous raconter l’histoire d’un mec qui a littéralement réinventé le journalisme d’investigation en cybersécurité. Car Brian Krebs, c’est un peu le Woodward et Bernstein du cyberespace, sauf qu’au lieu de faire tomber un président, il fait tomber des réseaux entiers de cybercriminels. Et croyez-moi, son parcours est digne de figurer dans ma série de l’été !

Brian Krebs naît en 1972 en Alabama et contrairement à ce qu’on pourrait penser, le gamin n’est absolument pas un geek dans l’âme. En 1994, il décroche son diplôme en relations internationales à l’Université George Mason et l’informatique ? Il s’en fiche complètement ! Il avait bien programmé un peu en BASIC sur un Apple II au lycée, mais sans plus. À l’époque, Brian se destine plutôt à une carrière dans la diplomatie ou les affaires internationales. Personne, absolument personne, n’aurait pu prédire qu’il deviendrait la terreur des cybercriminels mondiaux.

En 1995, le jeune diplômé de 23 ans cherche du boulot et tombe un peu par hasard sur une annonce du Washington Post. Mais attention, pas pour un poste de journaliste star ! Non, il commence tout en bas de l’échelle, au service circulation. Son job c’est de gérer les abonnements et la distribution du journal. Il passe ses journées à traiter les plaintes de clients qui n’ont pas reçu leur journal. Pas vraiment glamour, mais c’est un pied dans la place.

Bref, de là, Brian fait preuve d’une détermination qui va caractériser toute sa carrière. Il obtient un poste d’assistant de rédaction dans la salle de presse du Post. Trier le courrier et prendre en dictée les papiers des reporters sur le terrain devient son quotidien. On est à la fin des années 90, les journalistes appellent depuis des cabines téléphoniques pour dicter leurs articles, et Brian tape frénétiquement sur son clavier pour tout retranscrire. C’est l’école du journalisme à l’ancienne ! Il apprend à écrire vite, à synthétiser, à capter l’essentiel d’une histoire.

Mais Brian ne se contente pas de ce rôle subalterne. Il observe, il apprend, il absorbe tout ce qu’il peut sur le métier de journaliste. En 1999, sa persévérance paie et il décroche un poste de rédacteur pour Newsbytes.com, le service d’actualités technologiques du Post. C’est le début de sa carrière de journaliste tech. Et il couvre tout : les fusions-acquisitions, les nouvelles technologies, la bulle internet qui gonfle… Mais toujours rien sur la sécurité.

L’événement qui va complètement changer sa vie survient en 2001. Brian a alors 29 ans et s’amuse à bidouiller avec Linux sur un vieux PC Hewlett-Packard qu’il a récupéré. Il veut apprendre, comprendre comment ça marche. Il a installé Red Hat Linux 6.2 avec l’idée de transformer cette machine en firewall pour protéger son réseau domestique. Le problème, c’est qu’il ne sait pas vraiment ce qu’il fait et laisse la configuration par défaut, avec tous les services activés et les mots de passe faibles.

Et là, c’est le drame : le Lion Worm, un ver informatique créé par un groupe de hackers chinois appelé la “Honker Union”, infecte sa machine et le verrouille complètement hors de son propre système. Brian est furieux ! Il réinstalle tout, remet Linux, et BAM, il se fait réinfecter. Deux fois de suite ! Cette humiliation va déclencher quelque chose en lui. “J’étais tellement énervé”, raconte-t-il. “Comment c’était possible qu’un truc pareil existe ? Comment ces types pouvaient-ils prendre le contrôle de MON ordinateur ?”

“C’est à ce moment-là que j’ai décidé d’apprendre tout ce que je pouvais sur la sécurité informatique et Internet”, expliquera-t-il plus tard. Il devient alors obsédé. Il lit absolument tout ce qu’il peut trouver sur le sujet : les bulletins du CERT, les forums underground, les analyses de malwares. Il passe ses nuits à comprendre comment fonctionnent les attaques, les vulnérabilités, les exploits. C’est une véritable renaissance intellectuelle.

Et cette nouvelle passion tombe à pic car en 2002, quand le Post vend Newsbytes, Brian utilise ses nouvelles connaissances en cybersécurité pour décrocher un poste de rédacteur à temps plein pour Washingtonpost.com. Il couvre les sujets tech avec un angle de plus en plus orienté sécurité. Il écrit sur les virus, les vers, les premières grandes brèches de données et ses articles deviennent de plus en plus techniques, de plus en plus profonds.

Mais Brian sent qu’il peut faire plus. En mars 2005, il lance alors Security Fix, un blog quotidien centré sur la sécurité informatique, la cybercriminalité et les politiques technologiques. C’est une première pour un grand média américain : un blog entièrement dédié à la cybersécurité, alimenté quotidiennement. Brian y développe un style unique car au lieu de simplement rapporter les faits, il mène de véritables enquêtes et va chercher l’info à la source.

Et c’est là que ça devient vraiment intéressant car Brian commence à infiltrer les forums de cybercriminels. Il apprend le russe, maîtrise l’argot des hackers, comprend leurs codes. Il passe des heures sur des forums comme Shadowcrew.com, Carderplanet, DarkMarket. Il observe, il apprend, il documente. “J’ai réalisé que pour vraiment comprendre la cybercriminalité, il fallait aller là où elle se passait”, dit-il.

Ainsi, là où la plupart des journalistes se contentent de relayer les communiqués de presse des entreprises victimes de piratage, Brian va gratter plus en profondeur. Il se construit un réseau de contacts dans le milieu de la sécurité informatique, mais aussi parmi les cybercriminels eux-mêmes. Et surtout, il gagne leur respect en montrant qu’il comprend vraiment leur monde.

En août 2008, Brian publie une série d’articles qui va faire date. Il révèle les activités illicites d’Intercage (aussi connu sous le nom d’Atrivo), un hébergeur basé en Californie du Nord qui abritait une quantité phénoménale de cybercriminels. Pédopornographie, phishing, malware, spam… Atrivo hébergeait tout. L’impact est immédiat car en septembre 2008, tous les fournisseurs d’accès coupent leurs liens avec Atrivo. L’hébergeur est littéralement débranché d’Internet.

Mais Brian ne s’arrête pas là. Il enquête sur EstDomains, l’un des plus gros clients d’Atrivo, et découvre que le président de la société, Vladimir Tšaštšin, a été condamné en Estonie pour fraude à la carte de crédit, falsification de documents et blanchiment d’argent. Deux mois après la publication de son enquête, l’ICANN révoque alors la licence d’EstDomains. Krebs 2, Cybercriminels 0, joli score, non ?

Pendant toute cette période au Washington Post, Brian publie plus de 1 300 billets de blog pour Security Fix, des centaines d’articles pour washingtonpost.com, huit articles en première page du journal papier, et même un article de couverture pour le Post Magazine sur les opérateurs de botnets. Il devient LA référence en matière de cybersécurité aux États-Unis.

Mais en 2009, comme beaucoup de journalistes de l’époque, Brian est licencié du Post dans le cadre de compressions budgétaires. Le journal perd de l’argent car Internet bouleverse le modèle économique des médias. Au lieu de chercher un autre job dans un média traditionnel, il prend alors une décision audacieuse et lance en décembre 2009, KrebsOnSecurity.com, son propre site d’investigation en cybersécurité.

C’est un pari risqué car à l’époque, peu de journalistes indépendants arrivent à vivre de leur blog. Mais Brian a un avantage : sa réputation et son réseau de sources sont déjà solidement établis. Très vite, KrebsOnSecurity devient LA référence en matière d’enquêtes cybersécurités. Les RSSI, les chercheurs en sécurité, même les cybercriminels lisent religieusement ses articles.

En 2010, Brian marque un grand coup : il est le premier journaliste à rapporter l’existence d’un malware super sophistiqué qui cible les systèmes industriels iraniens. “J’ai reçu un échantillon de ce truc bizarre”, raconte-t-il. “C’était différent de tout ce qu’on avait vu avant.” Ce malware sera plus tard connu sous le nom de Stuxnet, et on découvrira plus tard qu’il s’agit d’une cyberarme développée par les États-Unis et Israël pour saboter le programme nucléaire iranien. Rien que ça !

Mais c’est à partir de 2013 que la vie de Brian bascule vraiment dans quelque chose de complètement dingue. Le 14 mars 2013, à 22h15 précises, il devient l’une des premières victimes de “swatting” parmi les journalistes. Des cybercriminels appellent le 911 en utilisant un service de spoofing pour faire croire que l’appel vient de chez lui. L’appelant, imitant Brian, déclare à la police : “J’ai tiré sur ma femme. Je l’ai peut-être tuée. J’ai une arme. Si quelqu’un entre, je tire.” Résultat : une équipe du SWAT débarque chez lui en plein dîner, armes au poing !

“J’étais en train de manger tranquillement quand j’ai vu des lumières rouges et bleues partout”, se souvient Brian. “J’ai ouvert la porte et il y avait une douzaine de flics avec des fusils d’assaut pointés sur moi. Ils m’ont ordonné de lever les mains et de sortir lentement.” Heureusement, Brian avait prévenu la police locale qu’il était journaliste en cybersécurité et qu’il risquait ce genre d’attaque et les flics ont rapidement compris que c’était un swatting.

L’incident est orchestré par un groupe de hackers opérant le site Exposed.su, incluant Eric “CosmotheGod” Taylor et Mir Islam. Ces types n’apprécient pas que Brian expose leurs activités criminelles et décident de se venger. La veille, Brian avait publié un article révélant comment ils obtenaient les données personnelles de leurs victimes via un site russe appelé SSNDOB. 45 minutes après la publication, ils avaient lancé une attaque DDoS contre son site.

Mir Islam sera plus tard condamné à deux ans de prison pour avoir swatté plus de 50 personnalités publiques, incluant Michelle Obama, le directeur du FBI Robert Mueller, le directeur de la CIA John Brennan, et même Paris Hilton. Le mec était complètement taré !

Mais les cybercriminels ne s’arrêtent pas là et en avril 2013, Brian reçoit par courrier plus d’un gramme d’héroïne pure ! Le plan diabolique étant d’envoyer la drogue chez lui, puis appeler la police pour le faire arrêter pour possession de stupéfiants. Sauf que Brian avait été prévenu du plan par ses sources sur un forum underground et avait alerté le FBI trois jours avant l’arrivée du colis.

Le cerveau derrière cette tentative de coup monté est Sergey “Fly” Vovnenko, un cybercriminel ukrainien de 29 ans qui administrait le forum de fraude “thecc.bz”. Vovnenko avait lancé un “Krebs Fund” sur le forum, demandant des donations en Bitcoin pour acheter de l’héroïne sur Silk Road. “L’idée était simple”, expliquera Vovnenko plus tard. “Faire livrer la drogue chez lui, puis faire appeler la police par un complice en se faisant passer pour un voisin inquiet.”

Pour se venger, Fly publie aussi le dossier de crédit immobilier complet de Brian sur son blog Livejournal, avec des photos de sa maison et même une couronne mortuaire qu’il fait livrer chez lui avec un message menaçant pour sa femme. Vovnenko sera finalement arrêté à Naples en 2014 et condamné à 41 mois de prison en 2017. Dans une interview surréaliste en 2019, il expliquera à Brian lui-même pourquoi il avait tenté de le piéger, s’excusant pour ses actions !

Mais LE coup de maître journalistique de Brian, celui qui va définitivement établir sa réputation, c’est l’affaire Target. Le 18 décembre 2013, Brian publie sur son blog que Target enquête sur une possible brèche de sécurité “impliquant potentiellement des millions de données de cartes de crédit et de débit”. Target n’a encore rien annoncé publiquement. Brian a eu l’info via deux sources indépendantes dans le milieu bancaire qui avaient remarqué une hausse anormale de fraudes sur des cartes ayant toutes été utilisées chez Target.

Le lendemain, Target confirme : 40 millions de comptes ont été compromis entre le 27 novembre (Thanksgiving) et le 15 décembre 2013. Les hackers ont eu accès aux données des bandes magnétiques des cartes utilisées dans les 1 797 magasins Target aux États-Unis pendant la période la plus chargée de l’année. Plus tard, on apprendra que 70 millions de comptes supplémentaires ont été touchés, avec des données personnelles volées.

Et Brian ne s’arrête pas là. En février 2014, il révèle la source de la brèche : Fazio Mechanical, une petite entreprise de chauffage et climatisation de Pennsylvanie qui travaillait pour Target. Les hackers ont d’abord compromis Fazio via un email de phishing en septembre 2013, puis ont utilisé leurs accès au portail fournisseur de Target pour pénétrer le réseau. Une fois dedans, ils ont utilisé une technique appelée “Pass-the-Hash” pour obtenir des privilèges administrateur et installer leur malware sur les caisses.

Le malware contenait la signature “Rescator”, le pseudonyme du cybercriminel qui vendait les cartes volées sur son site rescator.la. Brian découvrira alors que Rescator vendait les cartes par lots géographiques (vous pouviez acheter toutes les cartes volées dans votre ville pour frauder localement sans éveiller les soupçons). Dix ans plus tard, en 2023, Brian publiera de nouveaux indices révélant que Rescator était probablement Mikhail Shefel, un résident de Moscou.

L’année 2014 est aussi marquée par la publication de son livre “Spam Nation: The Inside Story of Organized Cybercrime - from Global Epidemic to Your Front Door”. Le bouquin devient un best-seller du New York Times et remporte un PROSE Award en 2015. Brian y raconte l’histoire fascinante des spammeurs russes et de l’économie souterraine du cybercrime, basée sur des années d’infiltration des forums criminels.

Mais être le journaliste le plus craint des cybercriminels a un prix et le 20 septembre 2016, KrebsOnSecurity subit la plus massive attaque DDoS jamais vue à l’époque : 620 à 665 gigabits par seconde de trafic malveillant ! Pour vous donner une idée, c’est assez de bande passante pour faire crasher une petite ville entière. Martin McKeay d’Akamai confirme que leur précédent record était de 363 Gbps. L’attaque de Brian fait presque le double !

L’attaque est menée par le botnet Mirai, composé de centaines de milliers d’objets connectés piratés : caméras de surveillance, routeurs, moniteurs pour bébés, même des aquariums connectés ! Tous ces petits appareils IoT avec des mots de passe par défaut comme “admin/admin” ou “root/12345” sont transformés en arme de destruction massive du web. Cette offensive utilise principalement du trafic GRE (Generic Routing Encapsulation), impossible à falsifier, prouvant que les attaquants contrôlent réellement des centaines de milliers de machines.

Le cyber-assault est probablement une vengeance pour le travail récent de Brian sur vDos, un service de DDoS à louer qu’il avait contribué à faire tomber. Deux israéliens de 18 ans qui opéraient le service avaient été arrêtés peu avant l’attaque. Mais le problème, c’est que l’attaque est tellement massive qu’Akamai, qui fournissait une protection DDoS gratuite à Brian depuis 2012, lui demande de partir. “Désolé Brian, mais tu causes des problèmes à nos clients payants”, lui dit-on en substance.

“C’était un moment difficile”, admet Brian. “J’étais littéralement censuré d’Internet par des criminels.” Heureusement, Google’s Project Shield, un service gratuit de protection DDoS pour les journalistes et dissidents, vient à sa rescousse et le site est de nouveau en ligne en quelques heures.

Les créateurs de Mirai, Paras Jha (21 ans, alias “Anna-senpai”), Josiah White (20 ans, alias “Lightspeed”) et Dalton Norman (21 ans, alias “Drake”), seront par la suite identifiés en partie grâce au travail d’investigation de Brian. En janvier 2017, il publie “Who is Anna-Senpai, the Mirai Worm Author?”, un article de 8 000 mots détaillant ses quatre mois d’enquête. Les trois seront condamnés à cinq ans de probation et 2 500 heures de travaux d’intérêt général, évitant la prison en échange de leur coopération avec le FBI.

Selon ses propres données, entre juillet 2012 et septembre 2016, le blog de Brian a subi 269 attaques DDoS ! Les cybercriminels le détestent tellement qu’ils sont prêts à mobiliser des ressources considérables juste pour faire taire son site. Mais Brian ne se laisse pas intimider. “Si ils m’attaquent autant, c’est que je fais bien mon boulot”, dit-il avec un sourire.

Au fil des années, Brian accumule les scoops et les révélations. Il expose les brèches chez Home Depot (56 millions de cartes), Michaels, Neiman Marcus, P.F. Chang’s, Sally Beauty, Goodwill, UPS, Dairy Queen, Jimmy John’s, et des dizaines d’autres. L’affaire Ashley Madison en 2015 ? C’est lui qui révèle les détails techniques du hack. Capital One en 2019 ? Encore lui. À chaque fois, son réseau de sources lui permet d’avoir l’info avant tout le monde. Les entreprises apprennent parfois qu’elles ont été piratées en lisant KrebsOnSecurity !

Ce qui rend Brian unique dans le paysage journalistique, c’est sa méthodologie. Il ne se contente pas de rapporter les faits mais infiltre les forums criminels, analyse le code des malwares, trace les flux financiers, identifie les acteurs. Il parle russe couramment pour pouvoir lire les forums underground. Il comprend le code pour pouvoir analyser les malwares. Il connaît les systèmes bancaires pour pouvoir suivre l’argent. C’est un journaliste-hacker au meilleur sens du terme.

“Pour comprendre les cybercriminels, il faut penser comme eux”, explique Brian. “Il faut comprendre leurs motivations, leurs méthodes, leur culture. C’est pour ça que je passe autant de temps sur les forums underground. C’est là que tout se passe.” Cette immersion totale lui permet de développer des sources uniques, des criminels qui lui font parfois confiance parce qu’ils respectent ses compétences techniques.

Brian a aussi développé une philosophie particulière sur la transparence car contrairement à la majorité des journalistes qui gardent jalousement leurs scoops, il partage souvent ses données brutes avec d’autres chercheurs et journalistes. Il publie les IOCs (Indicators of Compromise) pour que les entreprises puissent se protéger et documente ses méthodes pour que d’autres puissent apprendre. “L’important, c’est de protéger les gens, pas d’avoir l’exclusivité”, dit-il.

Cette approche lui a valu de nombreuses récompenses : le Cisco Systems “Cyber Crime Hero” Award en 2009, le SANS Institute Top Cybersecurity Journalist Award en 2010, le National Press Foundation Chairman’s Citation Award en 2014, l’ISSA President’s Award for Public Service en 2017, et il a été nommé Cybersecurity Person of the Year par CISO MAG. En 2018, il reçoit le Lifetime Achievement Award de la société de renseignement sur les menaces Threatpost.

Mais au-delà des prix, c’est l’impact de Brian sur l’industrie qui est remarquable. Il a forcé les entreprises à être plus transparentes sur les brèches car avant lui, les entreprises cachaient souvent les incidents de sécurité pendant des mois. Maintenant, comme elles savent que Brian finira par le découvrir, alors autant être transparent dès le début.

Il a aussi inspiré toute une génération de journalistes spécialisés en cybersécurité. Des médias comme Ars Technica, Wired, Vice Motherboard ont développé des sections cybersécurité robustes, souvent en embauchant des journalistes formés à “l’école Krebs”. Bref, il a prouvé qu’on pouvait faire du journalisme d’investigation technique sans sacrifier la rigueur ou l’accessibilité.

Ce qui est fascinant avec Brian, c’est qu’il n’a aucune formation technique formelle. Pas de diplôme en informatique, pas de certifications CISSP ou CEH. Tout ce qu’il sait, il l’a appris par lui-même, motivé par la rage d’avoir été piraté en 2001. C’est la preuve vivante que la passion et la détermination peuvent vous mener plus loin que n’importe quel diplôme.

Aujourd’hui, KrebsOnSecurity est lu par des millions de personnes dans le monde entier… PDG de grandes entreprises, responsables de la sécurité, chercheurs, forces de l’ordre, et même cybercriminels lisent religieusement ses articles. Alors quand Brian publie quelque chose, toute l’industrie est à l’écoute. Et il n’y a pas de pubs sur son site mais juste quelques sponsors triés sur le volet et des dons de lecteurs reconnaissants.

Brian continue d’opérer depuis un lieu non divulgué en Virginie du Nord. Sa maison est équipée de caméras de sécurité, d’un système d’alarme sophistiqué, et il maintient des contacts étroits avec les forces de l’ordre locales. “C’est le prix à payer”, dit-il. “Mais je ne laisserai pas la peur dicter ma vie ou mon travail.”

En 2024, KrebsOnSecurity a fêté ses 15 ans et Brian continue aujourd’hui d’y publier presque quotidiennement, exposant les dernières arnaques, les nouvelles techniques des cybercriminels, les failles de sécurité critiques. Il a récemment exposé comment des criminels utilisent l’IA pour créer des deepfakes bancaires, comment ils exploitent les vulnérabilités dans les systèmes de paiement mobile, comment ils blanchissent l’argent via les NFTs.

Voilà, donc si vous cherchez un exemple de reconversion réussie, de détermination face à l’adversité, et de courage journalistique à l’ère numérique, Brian Krebs c’est LE modèle à suivre !

Sources : About the Author – Krebs on Security, Brian Krebs - Wikipedia, Men Who Sent Swat Team, Heroin to My Home Sentenced, Interview With the Guy Who Tried to Frame Me for Heroin Possession, Sources: Target Investigating Data Breach, Ten Years Later, New Clues in the Target Breach, KrebsOnSecurity Hit With Record DDoS, Akamai on the Record KrebsOnSecurity Attack, Mirai IoT Botnet Co-Authors Plead Guilty, Target Hackers Broke in Via HVAC Company, A “Kill Chain” Analysis of the 2013 Target Data Breach - U.S. Senate, Brian Krebs - AAE Speakers Bureau, Brian Krebs is CISO MAG Cybersecurity Person of the Year, Brian Krebs - National Press Foundation, Sophos - Thugs who sent Brian Krebs heroin and a SWAT team sentenced

Vous connaissez le gag du cambrioleur qui entre par la porte parce que vous avez laissé la clé sous le paillasson ? Bah là c’est pareil, sauf que c’est pas une blague et que ça concerne des millions de coffres-forts supposés être ultra-sécurisés. C’est une histoire de dingue qui mélange hackers ultra déterminés, une entreprise chinoise, un sénateur américain et même le FBI. Accrochez-vous !

Tout commence avec deux chercheurs en sécurité, Omo et Rowley, qui décident de fouiller les entrailles des serrures électroniques Securam ProLogic. Ces trucs équipent les coffres de marques prestigieuses comme Liberty Safe, Fort Knox, FireKing et plein d’autres. Ce sont des coffres utilisés par CVS pour stocker des narcotiques ou par des chaînes de restaurants pour planquer leur cash. Pas exactement le genre de truc qu’on veut voir ouvert par n’importe qui.

Les chercheurs ont présenté leurs découvertes à la conférence Defcon le 8 août dernier, et croyez-moi, ça a fait l’effet d’une bombe car ils ont trouvé non pas une, mais deux méthodes pour ouvrir ces coffres en quelques secondes. La première exploite l’interface Bluetooth du coffre pour injecter des commandes directement dans le firmware. Oui, y’a des ingénieurs qui ont mis du BT sur des coffres forts… C’est pas bien débile ça quand même ? Et la seconde utilise une backdoor cachée qui permet de bypasser complètement le code utilisateur sans déclencher la moindre alarme.

Et cette histoire de backdoor, c’est pas nouveau puisque le sénateur Ron Wyden avait déjà tiré la sonnette d’alarme en mars 2024, avertissant que Securam, l’entreprise chinoise, était légalement obligée de coopérer avec les demandes de surveillance du gouvernement chinois. En gros, Pékin pourrait théoriquement avoir accès aux codes de tous les coffres Securam vendus dans le monde. Sympa pour stocker vos secrets industriels et vos lingots d’or.

D’ailleurs, l’histoire rappelle étrangement le scandale Liberty Safe d’août 2023, quand l’entreprise avait fourni au FBI le code d’accès du coffre d’un client sur simple présentation d’un mandat. Les utilisateurs avaient hurlé à la trahison, déclenchant un mouvement de boycott massif. Liberty Safe avait alors dû faire marche arrière en promettant de supprimer les codes sur demande des clients.

Mais revenons à nos moutons. Le système de reset de Securam fonctionne avec un code de récupération (par défaut “999999”, super sécurisé), qui génère un code affiché à l’écran. Un serrurier autorisé appelle ensuite Securam, leur lit ce code, et en retour obtient le sésame pour réinitialiser la serrure. Sauf que Omo et Rowley ont réussi à reverse-engineer l’algorithme secret. Du coup, ils peuvent générer le code de reset sans appeler personne.

On dirait vous quand vous activiez des licences Windows et Office par téléphone sans appeler Microsoft ^^.

Et la réponse de Securam a été pathétique puisque Jeremy Brookes, le directeur des ventes, a confirmé qu’ils ne comptaient pas patcher les serrures déjà installées. Donc si vous voulez être en sécurité, vous allez devoir en acheter une nouvelle. Il accuse même les chercheurs de vouloir “discréditer” l’entreprise. Omo leur a alors répondu qu’ils essayent juste d’alerter le public sur les vulnérabilités d’une des serrures les plus populaires du marché.

Ce qui est fou dans cette affaire, c’est que le département de la Défense américain a confirmé que les produits Securam ne sont pas approuvés pour un usage gouvernemental, justement à cause de ces backdoors. Mais pour le commun des mortels, bah circulez, y’a rien à voir. Vos documents sensibles, vos armes, votre cash, tout ça reste vulnérable.

Securam promettait dans leur communiqué de presse des “produits de nouvelle génération” pour fin 2025 et assure que “la sécurité des clients est notre priorité”….

Mais lol, permettez-moi d’en douter quand on refuse de patcher une vulnérabilité critique qui permet d’ouvrir un coffre en quelques secondes.

Encore une fois, les backdoors, qu’elles soient dans les coffres-forts ou dans les logiciels de chiffrement, sont systématiquement une idée catastrophique car on ne peut pas créer une porte dérobée juste pour les gentils. Une fois qu’elle existe, n’importe qui avec les bonnes connaissances peut l’utiliser.

Voilà, donc pour ceux qui possèdent un coffre avec une serrure Securam ProLogic, je n’ai qu’un conseil : considérez que celui-ci n’est plus sûr. Soit vous changez la serrure (et pas par un autre modèle Securam), soit vous stockez vos objets de valeur ailleurs. Et optez pour une solution purement mécanique car au moins, elle n’aura pas de backdoor Bluetooth.

Source

Vous vous souvenez du film Volte/Face avec Nicolas Cage et John Travolta ? Mais siii, c’est ce film où ils échangent leurs visages ? Bah les chercheurs allemands viennent de faire pareil avec Windows Hello, sauf qu’eux n’ont eu besoin que de deux lignes de code. Pas de chirurgie, pas d’effets spéciaux, juste un petit tour de passe-passe et hop, le PC croit que vous êtes votre collègue.

Le truc vient d’être montré en direct au Black Hat de Las Vegas par Tillmann Osswald et le Dr Baptiste David, deux chercheurs d’ERNW Research. Sur scène, David s’est connecté avec son visage, puis Osswald a tapé quelques commandes, et quelques secondes plus tard, il déverrouillait la machine de David avec son propre visage capturé sur un autre ordinateur. La sécurité biométrique de Microsoft vient de se faire avoir comme une débutante.

Ce qui rend cette attaque particulièrement sournoise, c’est qu’elle cible spécifiquement Windows Hello for Business, le système que Microsoft pousse à fond pour remplacer les mots de passe dans les entreprises. Vous savez, ce truc censé être ultra-sécurisé qui permet aux PC corporate de se connecter à Entra ID ou Active Directory avec juste votre belle gueule. Sauf que là, n’importe quel admin local malveillant ou compromis peut littéralement injecter sa tronche dans votre base de données biométrique.

Selon les informations techniques détaillées, l’attaque exploite une faiblesse dans CryptProtectData, le système censé protéger la base de données du Windows Biometric Service. Les chercheurs ont découvert qu’avec des droits admin locaux, on peut décrypter cette base et y injecter n’importe quelle empreinte biométrique.

Le plus fou dans cette histoire, c’est que Microsoft a bien une solution : Enhanced Sign-in Security (ESS). Ce système fonctionne au niveau hyperviseur avec une isolation VTL1 (Virtual Trust Level 1) qui bloque complètement l’attaque. Mais le problème c’est qu’il faut du matériel très spécifique pour que ça marche : un CPU 64 bits avec virtualisation hardware, une puce TPM 2.0, Secure Boot activé, et des capteurs biométriques certifiés.

D’ailleurs, petit détail rigolo, même des ThinkPad achetés pourtant il y a un an et demi ne supportent pas ESS parce qu’ils ont des puces AMD au lieu d’Intel. Comme l’explique Osswald, “ESS est très efficace pour bloquer cette attaque, mais tout le monde ne peut pas l’utiliser.”

Pour vérifier si vous êtes protégé, Microsoft recommande donc d’aller dans les paramètres Windows : Comptes → Options de connexion. Si vous voyez une option “Se connecter avec une caméra externe ou un lecteur d’empreintes digitales”, et qu’elle est sur OFF, ESS est activé. Quand ce toggle est OFF, vous êtes protégé mais vous ne pouvez plus utiliser de périphériques externes. Par contre, quand il est ON, vous pouvez utiliser vos gadgets mais vous êtes vulnérable.

Cette recherche fait partie du programme Windows Dissect, financé par l’Office fédéral allemand pour la sécurité informatique (BSI), un projet de deux ans qui se termine au printemps prochain. Et apparemment, ce n’est que le début car les chercheurs promettent d’autres révélations sur Windows dans les mois qui viennent. Ce qui inquiète vraiment la communauté, c’est que le fix n’est pas simple. Les experts estiment qu’il faudrait soit réécrire une partie significative du code, soit stocker les données biométriques dans le TPM, ce qui n’est peut-être même pas faisable techniquement…. Breeef, en attendant, la recommandation officielle pour les entreprises sans ESS est radicale : Désactivez complètement la biométrie et revenez au bon vieux code PIN.

Microsoft pousse agressivement tout le monde vers la biométrie depuis de nombreux mois, pour justement se débarrasser des mots de passe, mais quand je vois que leur solution de contournement recommandée est… de revenir aux codes PIN, j’avoue qu’on commence un peu à marcher sur la tête.

Et le support complet des périphériques externes avec ESS n’est pas prévu avant fin 2025 toujours selon Microsoft donc d’ici là, si vous utilisez Windows Hello for Business sans le hardware compatible ESS, vous jouez littéralement à la roulette russe avec l’identité de vos employés.

Ça montre donc que la biométrie n’est pas la solution miracle mais juste une autre forme d’authentification avec ses propres failles. Maintenant, la différence, c’est que quand quelqu’un vole votre mot de passe, vous pouvez le changer. Mais quand quelqu’un compromet votre système biométrique… bah vous changez de visage comme Cage et Travolta ?

Source

Cet article fait partie de ma série de l’été spécial hackers. Bonne lecture !

C’est l’histoire d’une hackeuse qui a littéralement fait trembler Intel, Microsoft et toute l’industrie de la sécurité et qui a prouvé qu’on ne pouvait JAMAIS faire confiance à un ordinateur.

Je ne me souviens absolument pas du jour où j’ai découvert Blue Pill mais c’est en août 2006, lors de la présentation de Joanna Rutkowska à Black Hat, que le monde a découvert cet outil. Les forums de sécurité étaient en ébullition totale car une hackeuse polonaise de 25 ans venait de démontrer comment créer un rootkit 100% indétectable en utilisant de la virtualisation hardware. Les experts étaient alors partagés entre l’admiration et la terreur absolue.

Comment une chercheuse inconnue du grand public avait-elle pu mettre à genoux toute l’industrie et devenir quelques années plus tard, l’architecte de l’OS le plus sécurisé au monde ? Je vais tout vous raconter…

Joanna Rutkowska naît en 1981 à Varsovie, dans une Pologne encore sous régime communiste. Quand elle débarque sur Terre, Solidarność vient juste d’être interdit et le général Jaruzelski impose la loi martiale. C’est dans ce contexte politique super tendu qu’elle grandit, dans une ville où l’accès à la technologie occidentale reste un luxe rare.

En 1992, à 11 ans, Joanna découvre son premier ordinateur. Un PC/AT 286 avec un processeur à 16 MHz, 2 MB de RAM et un disque dur de 40 MB. Pour une gamine de cet âge dans la Pologne post-communiste, c’est comme trouver un trésor. Alors pendant que ses copines jouent à la poupée Barbie, Joanna passe ses journées devant l’écran monochrome, fascinée par ce monde binaire.

Elle commence par apprendre GW-BASIC, puis découvre Borland Turbo Basic. Les lignes de code défilent, les programmes prennent vie. C’est magique ! Elle passe des heures à créer des petits jeux, des utilitaires et tout ce qui lui passe par la tête. Mais très vite, le BASIC ne lui suffit plus. Elle veut comprendre comment fonctionne VRAIMENT la machine.

L’adolescence de Joanna est marquée par une curiosité dévorante pour les entrailles des systèmes. Elle se plonge dans la programmation assembleur x86, le langage le plus proche du hardware. C’est hardcore, c’est complexe, mais c’est exactement ce qu’elle cherche. Elle veut tout contrôler, tout comprendre, tout maîtriser jusqu’au dernier registre du processeur.

Alors elle ne se contente pas d’apprendre. Elle expérimente, crée ses premiers virus. Pas pour nuire hein, mais pour comprendre. Comment un programme peut-il se répliquer ? Comment peut-il se cacher ? Comment peut-il survivre ? Ces questions l’obsèdent. Elle passe ses nuits à désassembler des programmes, à tracer leur exécution instruction par instruction.

Et au milieu des années 90, quelque chose change. Les maths et l’intelligence artificielle commencent à la fasciner. Elle découvre les réseaux de neurones, les algorithmes génétiques, et tout ce qui touche à l’IA naissante. Elle dévore les whitepapers de recherche, implémente des prototypes. Et cette même passion qu’elle avait mise dans l’assembleur, elle la met maintenant dans l’IA.

Parallèlement, elle découvre Linux et le monde de l’open source et c’est une révélation totale ! Un système d’exploitation dont on peut lire le code source, c’est fou ! Elle peut enfin voir comment fonctionne vraiment un OS moderne. Elle compile son premier kernel, le modifie, le recompile. Elle apprend la programmation système, les drivers, les mécanismes de sécurité du kernel.

Puis à la fin des années 90, Joanna fait un choix crucial. Elle retourne à sa première passion : la sécurité informatique. Mais cette fois avec une approche différente. Elle ne veut plus créer des virus pour le fun, non, elle veut comprendre comment sécuriser les systèmes, comment les protéger, comment détecter les attaques les plus sophistiquées.

Alors elle s’inscrit à l’Université de Technologie de Varsovie (Warsaw University of Technology), l’une des meilleures facs d’informatique de Pologne et là, elle approfondit ses connaissances théoriques tout en continuant ses recherches personnelles sur les exploits Linux x86 et Win32 puis finit par se spécialiser dans la sécurité système, un domaine encore peu exploré à l’époque.

Son mémoire de master porte sur les techniques de dissimulation des malwares. Elle y développe des concepts qui préfigurent déjà ses futures recherches. Comment un programme malveillant peut-il se rendre totalement invisible ? Comment peut-il tromper les outils de détection les plus sophistiqués ? Ses profs sont bluffés par la profondeur de son analyse.

Diplômée, Joanna commence à bosser comme consultante en sécurité, mais très vite, elle réalise que le consulting ne la satisfait pas. Elle veut faire de la recherche pure et dure, explorer les limites de ce qui est possible, repousser les frontières de la sécurité informatique. Pas juste auditer des systèmes pour des clients corporate.

C’est à cette époque qu’elle commence à s’intéresser à la virtualisation. Intel et AMD viennent de sortir leurs nouvelles extensions de virtualisation hardware : VT-x et AMD-V. Pour la plupart des gens, c’est juste une amélioration technique pour faire tourner des VMs plus efficacement mais pour Joanna, c’est bien plus que ça. C’est une nouvelle surface d’attaque.

Elle passe des mois à étudier ces nouvelles technologies. Elle lit les manuels Intel de 3000 pages (oui, 3000 !), analyse chaque instruction, comprend chaque mécanisme. Les opcodes VMXON, VMXOFF, VMRESUME deviennent ses meilleurs amis et petit à petit, une idée germe dans son esprit génial.

Et si on pouvait utiliser la virtualisation non pas pour protéger, mais pour attaquer ? Et si on pouvait créer un hyperviseur malveillant qui prendrait le contrôle total d’un système sans que personne ne s’en aperçoive ? Un rootkit qui s’exécuterait à un niveau encore plus bas que le kernel, dans le ring -1 comme on dit.

L’idée est révolutionnaire car jusqu’alors, les rootkits devaient modifier le kernel, laissaient des traces, et étaient détectables d’une manière ou d’une autre. Mais avec la virtualisation hardware, on pourrait créer un rootkit qui contrôle le système d’exploitation lui-même sans jamais le toucher. Le rootkit parfait en somme…

En 2006, Joanna est prête. Elle a développé une preuve de concept qu’elle appelle “Blue Pill”, en référence à la pilule bleue de Matrix. Le nom est parfait car comme dans le film, le système d’exploitation continue de vivre dans une réalité virtuelle sans se douter qu’il est contrôlé par une entité supérieure. “Your operating system swallows the Blue Pill and it awakes inside the Matrix”, comme elle le dira.

À cette époque, Joanna bosse pour COSEINC Research, une boîte de sécurité basée à Singapour et ce sont eux qui financent ses recherches sur Blue Pill. Mais attention, Blue Pill n’est pas destiné à être vendu ou distribué. C’est exclusivement pour la recherche, simplement pour “prouver le concept” (PoC).

Le 3 août 2006, Las Vegas. C’est l’heure de la Black Hat, LA conférence de sécurité la plus prestigieuse au monde. Joanna monte sur scène, elle a 25 ans, elle est inconnue du grand public américain, et elle s’apprête à bouleverser le monde de la cybersécurité.

“The idea behind Blue Pill is simple”, commence-t-elle avec son accent polonais caractéristique, “Your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra-thin Blue Pill hypervisor.”

La salle est bondée. Les experts sont venus voir cette jeune chercheuse polonaise qui prétend avoir créé un rootkit indétectable. Certains sont sceptiques. D’autres curieux. Personne ne s’attend à ce qui va suivre.

Joanna lance sa démo. En quelques secondes, elle installe Blue Pill sur un système Windows Vista en cours d’exécution. Pas de redémarrage. Pas de modification visible. Le système continue de fonctionner normalement, sauf qu’il est maintenant entièrement sous le contrôle de Blue Pill.

Elle montre alors comment Blue Pill peut intercepter tous les appels système, modifier les résultats, cacher des processus, des fichiers, des connexions réseau. Tout ça sans toucher à un seul octet du kernel Windows. Les outils de détection de rootkits ne voient rien, les antivirus sont aveugles et le système lui-même n’a aucune idée qu’il s’exécute dans la machine virtuelle.

Le plus fou c’est que Blue Pill n’exploite aucun bug dans AMD-V ou Intel VT-x. Il utilise uniquement les fonctionnalités documentées. Ce n’est pas un exploit, c’est une utilisation créative de la technologie. “Blue Pill does *not* rely on any bug in Pacifica neither in OS”, précise-t-elle.

La démonstration se termine. Un silence de cathédrale règne dans la salle. Puis les applaudissements explosent. Les experts présents réalisent qu’ils viennent d’assister à quelque chose d’historique. Joanna Rutkowska vient de prouver que la virtualisation hardware peut être “weaponisée”.

L’impact est immédiat et dévastateur et les médias s’emparent de l’histoire. eWeek Magazine la nomme parmi les “Five Hackers who put a mark on 2006”. Les forums de sécurité s’enflamment et les débats font rage. Est-ce vraiment indétectable ? Comment se protéger ? Faut-il interdire la virtualisation hardware ?

Microsoft est en panique totale. Leur nouveau Vista, qui devait être le système le plus sécurisé jamais créé, vient d’être compromis par une hackeuse de 25 ans et surtout, Intel n’est pas mieux car leur technologie VT-x, censée améliorer la sécurité, devient soudain une menace. Même AMD essaie de minimiser, publiant un communiqué disant que Blue Pill n’est pas vraiment “indétectable”.

Mais Joanna ne s’arrête pas là et dans les mois qui suivent, elle publie plus de détails techniques sur son blog “The Invisible Things”. Elle explique comment Blue Pill fonctionne, les défis techniques qu’elle a dû surmonter. Bien sûr, elle ne publie pas le code source complet (COSEINC garde ça pour leurs trainings), mais elle donne assez d’infos pour que d’autres chercheurs comprennent.

Et en 2007, la controverse atteint son paroxysme. Trois chercheurs en sécurité de renom, Thomas Ptacek de Matasano Security, Nate Lawson de Root Labs et Peter Ferrie de Symantec, défient publiquement Joanna. Ils prétendent avoir développé des techniques pour détecter Blue Pill et ils lui proposent un duel à Black Hat 2007.

Leur présentation s’intitule “Don’t Tell Joanna: The Virtualised Rootkit Is Dead”. Ils veulent prouver que Blue Pill n’est pas si indétectable que ça alors ils proposent un challenge : leur détecteur contre le rootkit de Joanna. Que le meilleur gagne !

Joanna accepte le défi, mais à une condition : Elle demande 384 000 dollars pour participer. Pas par cupidité, mais pour border le projet car ce qu’elle a maintenant, c’est un prototype et pour en faire quelque chose de vraiment “hard to detect”, il faudrait deux personnes à plein temps pendant six mois à 200 dollars de l’heure. Elle et Alexander Tereshkin ont déjà investi quatre mois-personnes et il en faudrait douze de plus pour avoir un vrai rootkit de production.

Certains disent qu’elle a peur de perdre, d’autres comprennent sa position et que le montant demandé représente le coût réel du développement d’un rootkit de production, et pas juste une preuve de concept académique.

Finalement, le duel n’aura pas lieu et les deux parties s’accordent sur le fait qu’en l’état actuel, Blue Pill n’est pas prêt pour un tel challenge. Mais les chercheurs présentent quand même leur talk. Joanna et Alexander Tereshkin contre-attaquent avec leur propre présentation, démontrant que les méthodes de détection proposées sont imprécises et facilement contournables.

En avril 2007, au milieu de cette tempête médiatique, Joanna prend alors une décision qui va changer sa vie. Elle fonde Invisible Things Lab (ITL) à Varsovie. L’idée est simple : créer un laboratoire de recherche indépendant, focalisé sur la sécurité système au plus bas niveau. Pas de produits commerciaux, pas de bullshit marketing. Juste de la recherche pure et dure.

ITL attire rapidement les meilleurs talents. Alexander Tereshkin, un génie russe de la sécurité hardware. Rafał Wojtczuk, un expert polonais des systèmes d’exploitation qui deviendra son bras droit pendant des années. Ensemble, ils forment une dream team de la sécurité offensive. Et leur première cible majeure c’est Intel Trusted Execution Technology (TXT).

C’est une technologie qui est censée garantir qu’un système démarre dans un état sûr, non compromis. C’est le Saint Graal de la sécurité à savoir un boot de confiance, vérifié par le hardware. Intel en fait la promotion comme LA solution contre les rootkits.

Alors en janvier 2009, Joanna et Rafał frappent fort et publient une attaque dévastatrice contre Intel TXT. Le point faible c’est le System Management Mode (SMM), un mode d’exécution spécial du processeur qui a plus de privilèges que tout le reste, y compris l’hyperviseur. C’est le ring -2, encore plus profond que le ring -1 de Blue Pill !

Leur découverte est brillante dans sa simplicité car TXT vérifie l’intégrité du système au démarrage, mais il ne vérifie pas le code SMM. Si un attaquant parvient à infecter le SMM avant le boot, il peut alors survivre au processus de démarrage sécurisé et compromettre le système “de confiance”. Pour prouver leur dires, ils créent un rootkit SMM qui s’installe via une vulnérabilité de cache poisoning et une fois en place, il peut compromettre n’importe quel système, même après un boot TXT “sécurisé”. Ils démontrent ainsi l’attaque en ajoutant une backdoor au hyperviseur Xen.

Game over pour Intel TXT.

Intel est furieux. Non seulement leur technologie phare vient d’être cassée, mais Joanna révèle que des employés Intel avaient alerté le management sur cette vulnérabilité dès 2005. Trois ans d’inaction. Trois ans pendant lesquels les clients ont cru être protégés alors qu’ils ne l’étaient pas. C’est un scandale.

Face au silence d’Intel, Joanna et Rafał décident de leur forcer la main. En mars 2009, ils annoncent qu’ils vont publier le code complet de leur exploit SMM. C’est un coup de poker risqué car publier un exploit aussi puissant pourrait être dangereux, mais c’est le seul moyen de forcer Intel à agir.

Heureusement, la stratégie fonctionne et Intel se met enfin au boulot pour pondre des correctifs. Mais le problème est complexe car il ne s’agit pas juste de patcher un bug. Il faut repenser toute l’architecture de confiance, développer un “SMM Transfer Monitor” (STM), convaincre les fabricants de BIOS de l’implémenter. Ça va prendre des années.

Pendant ce temps, Joanna continue d’explorer d’autres angles d’attaque. Elle s’intéresse particulièrement aux attaques physiques. C’est dans ce contexte qu’elle invente un concept qui va entrer dans l’histoire : l’attaque “Evil Maid”.

L’idée lui vient lors d’un voyage. Elle réalise que même avec le chiffrement intégral du disque, un laptop laissé dans une chambre d’hôtel reste vulnérable. Une femme de chambre malveillante (d’où le nom “Evil Maid”) pourrait booter l’ordinateur sur une clé USB, installer un keylogger dans le bootloader, et capturer le mot de passe de déchiffrement lors du prochain démarrage.

En 2009, elle publie alors une preuve de concept contre TrueCrypt, le logiciel de chiffrement le plus populaire de l’époque. L’attaque est élégante : une clé USB bootable qui modifie TrueCrypt pour enregistrer le mot de passe. L’utilisateur revient, tape son mot de passe, et hop, il est enregistré sur le disque. L’attaquant n’a plus qu’à revenir pour le récupérer.

Le terme “Evil Maid attack” entre immédiatement dans le vocabulaire de la sécurité car il capture parfaitement la vulnérabilité fondamentale des appareils laissés sans surveillance. Même avec les meilleures protections logicielles, un accès physique change tout. C’est devenu un classique, au même titre que “man-in-the-middle” ou “buffer overflow”. Mais Joanna ne se contente pas de casser des choses… Elle veut aussi construire et c’est là que naît son projet le plus ambitieux : Qubes OS.

L’idée de Qubes germe depuis longtemps dans son esprit, car après des années à découvrir faille sur faille, elle réalise une vérité fondamentale : aucun système n’est sûr. Il y aura toujours des bugs, toujours des vulnérabilités. La question n’est donc pas “si” mais “quand” un système sera compromis.

Alors plutôt que d’essayer de créer un système parfait (mission impossible), pourquoi ne pas créer un système qui assume qu’il sera compromis ? Un système où la compromission d’une partie n’affectera pas le reste ? C’est le concept de “security by compartmentalization”, la sécurité par compartimentation.

En 2010, elle s’associe avec Rafał Wojtczuk et Marek Marczykowski-Górecki pour concrétiser cette vision. Qubes OS est basé sur Xen, un hyperviseur bare-metal mais au lieu d’utiliser Xen pour faire tourner plusieurs OS complets, Qubes l’utilise pour créer des dizaines de machines virtuelles légères, chacune dédiée à une tâche spécifique. Vous voulez surfer sur des sites douteux ? Une VM dédiée isolée. Faire du banking en ligne ? Une autre VM. Travailler sur des documents sensibles ? Encore une autre VM. Chaque VM est isolée des autres, comma ça, si l’une est compromise par un malware, les autres restent safe. C’est loin d’être con !

Mais Qubes va encore plus loin. Il utilise des VMs spécialisées pour les tâches critiques. NetVM gère uniquement le réseau. USB VM gère les périphériques USB (super dangereux). AudioVM gère le son. Ainsi, même si un driver est compromis, il ne peut pas accéder au reste du système. L’isolation est totale.

Le développement de Qubes est un défi monumental car il faut repenser toute l’expérience utilisateur. Comment faire pour que l’utilisateur lambda puisse utiliser des dizaines de VMs sans devenir fou ? Comment gérer le copier-coller entre VMs de manière sécurisée ? Comment partager des fichiers sans compromettre l’isolation ?

Joanna et son équipe passent ainsi deux ans à résoudre ces problèmes. Ils créent des mécanismes élégants pour que tout soit transparent. Les fenêtres des différentes VMs s’affichent sur le même bureau, avec des bordures colorées pour indiquer leur niveau de sécurité (rouge pour non fiable, jaune pour perso, vert pour travail, etc.) et le copier-coller fonctionne, mais de manière contrôlée via des canaux sécurisés.

Puis le 3 septembre 2012, Qubes OS 1.0 est officiellement lancé. La réaction de la communauté sécurité est mitigée. Certains adorent le concept tandis que d’autres trouvent ça trop complexe, trop lourd, trop paranoïaque. “C’est overkill”, disent certains. “C’est le futur”, répondent d’autres. Mais Joanna a un supporter de poids…

En 2013, Edward Snowden fuit les États-Unis avec des téraoctets de documents classifiés de la NSA. Pour communiquer avec les journalistes de manière sécurisée, il a besoin d’un système ultra-sécurisé. Son choix ? Qubes OS.

Le 29 septembre 2016, Snowden tweete : “If you’re serious about security, @QubesOS is the best OS available today. It’s what I use, and free. Nobody does VM isolation better.” Pour Joanna, c’est une validation extraordinaire car si l’homme le plus recherché du monde fait confiance à Qubes pour sa sécurité, c’est que le système fonctionne.

Le soutien de Snowden propulse Qubes dans la lumière et, d’un coup, tout le monde veut comprendre ce système. Les journalistes qui travaillent sur des sujets sensibles l’adoptent (Laura Poitras, Glenn Greenwald), les activistes l’utilisent, les chercheurs en sécurité aussi.

Mais Joanna reste humble. “A reasonably secure operating system”, c’est comme ça qu’elle décrit Qubes. Pas “ultra-secure”, pas “unbreakable”. Juste “reasonably secure”. Cette humilité, cette reconnaissance des limites, c’est ce qui fait la force de son approche car elle sait qu’aucun système n’est parfait.

Au fil des ans, Qubes continue d’évoluer. Version 2.0 en 2014, 3.0 en 2015, 4.0 en 2018. Chaque version apporte des améliorations, des raffinements et l’équipe grandit. La communauté aussi. Qubes devient une référence dans le monde de la sécurité, utilisé par ceux qui ont vraiment besoin de protection.

Mais Joanna a une philosophie qui la distingue des autres, car elle refuse catégoriquement de déposer des brevets. “I proudly hold 0 (zero) patents”, affirme-t-elle sur ses réseaux. Pour elle, les brevets sont antithétiques à la sécurité et la sécurité doit être ouverte, vérifiable, accessible à tous et surtout pas enfermée dans des coffres légaux.

Cette philosophie s’étend à sa vision de la liberté individuelle. “I strongly believe that freedom of individuals is the most important value”, dit-elle car pour elle, la sécurité informatique n’est pas une fin en soi. C’est un moyen de préserver la liberté, de permettre aux individus de faire des choix, de protéger leur vie privée contre les États et les corporations.

En octobre 2018, après neuf ans à la tête de Qubes et d’ITL, Joanna surprend tout le monde. Elle annonce qu’elle prend un congé sabbatique. Elle veut explorer de nouveaux horizons, réfléchir à la suite. Qubes est entre de bonnes mains avec Marek Marczykowski-Górecki qui prend la relève.

Sa décision est mûrement réfléchie. “These are very important problems, in my opinion, and I’d like to work now on making the cloud more trustworthy, specifically by limiting the amount of trust we have to place in it”, explique-t-elle. Après avoir sécurisé les endpoints, elle veut maintenant s’attaquer au cloud.

Nouvelle surprise : Joanna rejoint Golem, un projet de blockchain visant à créer un “ordinateur décentralisé”. Elle devient Chief Strategy Officer et Chief Security Officer. Son passage de la sécurité des endpoints à la blockchain surprend beaucoup de monde. “Qu’est-ce qu’elle va faire dans la crypto ?”, se demandent certains.

Mais pour Joanna, c’est une évolution logique car après avoir passé des années à sécuriser des systèmes individuels, elle veut maintenant s’attaquer à la sécurité des systèmes distribués. Comment sécuriser un ordinateur composé de milliers de machines appartenant à des inconnus ? Comment garantir la confidentialité dans un système décentralisé ?

En juillet 2019, la Golem Foundation commence alors ses opérations et Joanna devient “Long-term navigator and Wildland chief architect”. Son projet le plus ambitieux chez Golem c’est Wildland, un système de fichiers décentralisé qui veut libérer les données des silos des GAFAM. L’idée de Wildland c’est de permettre aux utilisateurs de stocker leurs données où ils veulent (Amazon S3, Dropbox, leur propre serveur, IPFS…) tout en ayant une interface unifiée. Plus besoin de se souvenir où est stocké quoi. Plus de vendor lock-in. Vos données vous appartiennent vraiment.

Et surtout, Wildland va plus loin que le simple stockage. Il introduit des concepts innovants comme la “multi-catégorisation” (un fichier peut appartenir à plusieurs catégories simultanément) et le “cascading addressing” (possibilité de créer des hiérarchies complexes sans point central de confiance). C’est de la décentralisation pragmatique.

“What we believe we do in a non-standard way is we are more pragmatic”, explique Joanna. “We don’t tell the user: ditch any kind of data centers you use and only use a P2P network. We say: use anything you want.” Cette approche pragmatique, c’est du pur Joanna.

Le 24 juin 2021, Wildland 0.1 est lancé lors d’un meetup à Varsovie. Joanna présente le projet : “Wildland containers are similar to Docker containers, except that dockers are for code, and Wildland containers can store any type of information.” L’accueil est positif mais mesuré. Le projet est ambitieux, peut-être trop.

Pour Joanna, Wildland représente la suite logique de son travail sur Qubes. Si Qubes compartimente l’exécution pour la sécurité, Wildland compartimente les données pour la liberté. Les deux ensemble offrent une vision d’un futur où les utilisateurs reprennent le contrôle de leur vie numérique.

Aujourd’hui, Joanna continue son travail sur les systèmes décentralisés. Elle reste conseillère pour Qubes OS, participe aux décisions stratégiques et sur son profil GitHub, ces 2 mots résument sa philosophie : “Distrusts computers.” Cette méfiance fondamentale envers la technologie, paradoxale pour quelqu’un qui y a consacré sa vie, est en fait sa plus grande force.

C’est parce qu’elle ne fait pas confiance aux ordinateurs qu’elle peut les sécuriser. C’est parce qu’elle comprend leurs failles qu’elle peut les protéger. C’est parce qu’elle sait qu’ils nous trahiront qu’elle construit des systèmes qui limitent les dégâts.

Elle a montré que la virtualisation pouvait être une arme avec Blue Pill. Elle a prouvé qu’aucun système n’est inviolable avec ses attaques contre Intel TXT. Elle a inventé des concepts comme l’Evil Maid attack qui font maintenant partie du vocabulaire de base. Mais surtout, elle a créé Qubes OS, un système qui protège les plus vulnérables. Journalistes, activistes, lanceurs d’alerte… Tous ceux qui ont vraiment besoin de sécurité utilisent Qubes. C’est son œuvre majeure, sa contribution la plus importante à la liberté numérique.

Elle incarne aussi une certaine éthique du hacking. Pas le hacking pour la gloire ou l’argent (elle aurait pu se faire des millions avec des brevets), mais le hacking comme outil de liberté. Le hacking comme moyen de reprendre le contrôle. Le hacking comme acte de résistance contre les systèmes opaques et les monopoles technologiques.

Aujourd’hui, Joanna continue d’écrire, de chercher et de construire. Ses articles sur “Intel x86 Considered Harmful” et “State Considered Harmful” proposent des visions radicales de ce que pourrait être l’informatique. Un monde sans état persistant, sans les architectures x86 legacy, sans les compromis du passé.

Des rêves impossibles ? Peut-être pas…

Sources : Wikipedia - Joanna Rutkowska, Wikipedia - Blue Pill, The Invisible Things Blog, Black Hat 2006 - Blue Pill Presentation, Qubes OS Official Website, Edward Snowden Twitter, Wildland Project, Invisible Things Lab

Bon, là on va parler d’un truc qui va faire trembler pas mal de développeurs. VulnHuntr, c’est le nouveau joujou de Protect AI qui utilise l’intelligence artificielle pour dénicher des vulnérabilités 0-day dans du code Python. Et quand je dis dénicher, c’est pas pour rigoler car en quelques heures seulement, cet outil a trouvé plus d’une douzaine de failles critiques dans des projets open source ayant plus de 10 000 étoiles sur GitHub !

Le principe c’est qu’au lieu de balancer tout le code source dans un LLM et espérer qu’il trouve quelque chose, VulnHuntr découpe le code en petits morceaux digestes. Puis il analyse méthodiquement la chaîne complète depuis l’entrée utilisateur jusqu’à la sortie serveur, en demandant uniquement les portions de code pertinentes.

L’outil peut ainsi détecter sept types de vulnérabilités majeures : exécution de code à distance (RCE), inclusion de fichiers locaux (LFI), falsification de requêtes côté serveur (SSRF), cross-site scripting (XSS), références directes non sécurisées (IDOR), injection SQL et écrasement arbitraire de fichiers.

Pas mal pour un outil gratuit et open source, non ?

Et puis il y a la liste des victimes… euh pardon, des projets où VulnHuntr a trouvé des failles. Je vous présente gpt_academic (67k étoiles), ComfyUI (66k étoiles), Langflow (46k étoiles), FastChat (37k étoiles), et j’en passe. Des projets ultra populaires dans l’écosystème IA qui se sont fait épingler avec des vulnérabilités critiques. Par exemple, Ragflow s’est retrouvé avec une belle RCE qui a été corrigée depuis.

Pour l’utiliser, c’est assez simple puisque ça s’installer avec pipx ou Docker (d’ailleurs ils recommandent Python 3.10 spécifiquement à cause de bugs dans Jedi). Ensuite, vous exportez votre clé API Anthropic ou OpenAI, et vous lancez l’analyse sur votre repo. Attention quand même, les développeurs préviennent que ça peut vite coûter cher en tokens si vous n’avez pas mis de limites de dépenses !

Je trouve son workflow plutôt bien pensé, car le LLM résume d’abord le README pour comprendre le contexte du projet et fait ensuite une première analyse afin d’identifier les vulnérabilités potentielles. Pour chaque faille détectée, VulnHuntr relance alors une analyse spécifique avec un prompt adapté au type de vulnérabilité. Puis il continue à demander du contexte (fonctions, classes, variables d’autres fichiers) jusqu’à avoir reconstruit toute la chaîne d’appel. À la fin, vous avez un rapport détaillé avec le raisonnement, un exploit proof-of-concept, et un score de confiance.

D’après les retours, un score de confiance inférieur à 7 signifie qu’il n’y a probablement pas de vulnérabilité. Un score de 7, c’est à investiguer. Et 8 ou plus, c’est très probablement une vraie faille. Les développeurs recommandent d’ailleurs d’utiliser Claude plutôt que GPT, car apparemment les résultats sont meilleurs, ce qui ne m’étonne pas.

Malheureusement, pour le moment, ça ne fonctionne que sur du code Python et même s’ils ont ajouté le support d’Ollama pour les modèles open source, les résultats ne sont pas terribles avec ces derniers car ils galèrent à structurer correctement leur output. A voir avec le dernier modèle OSS d’OpenAI cela dit…

Alors d’un côté, je trouve ça génial d’avoir un outil aussi puissant pour sécuriser nos propres projets mais de l’autre, ça montre à quel point nos codes sont vulnérables et combien il est facile pour quelqu’un de mal intentionné de trouver des failles. Voilà, donc si vous développez en Python, je vous conseille vraiment de tester VulnHuntr sur vos projets car mieux vaut découvrir les failles vous-même plutôt que de les voir exploitées dans la nature !

Un scénario classique en entreprise c’est un script Python de synchronisation qui doit tourner sous Windows et qui se barre en erreur à chaque redémarrage. Le coupable c’est ce fichu service Windows qui s’obstine à chercher sa configuration dans C:\Windows\System32 plutôt que dans le répertoire de l’application. Du coup, ça prend 3 heures de débogage pour un problème vieux comme Windows NT et ça c’est moche !

Car le problème avec les services Windows, c’est qu’ils sont coincés dans les années 90. La commande sc create ne fonctionne qu’avec des applications spécialement conçues pour être des services. Et NSSM est puissant mais avec une interface en ligne de commande cryptique et des éditions du registre à la main. Et le pire dans tout ça, c’est ce fameux répertoire de travail bloqué sur System32 qui fait planter la moitié des applications qui dépendent de chemins relatifs.

La bonne nouvelle c’est qu’il existe Servy qui débarque comme une bouffée d’air frais dans cet écosystème poussiéreux. Développé entièrement en C# par Aelassas, ce petit outil open source fait exactement ce qu’on attend de lui à savoir transformer n’importe quel executable en service Windows, avec une vraie interface graphique moderne et surtout, la possibilité de définir ce foutu répertoire de travail.

Pour l’utiliser, il vous suffit de télécharger la dernière release sur GitHub, de le décompresser, et de lancez Servy.exe. L’interface est claire… nom du service, description, chemin de l’exe, working directory (enfin !), paramètres de démarrage, et c’est parti. En 30 secondes, votre application Node.js, votre script Python ou votre serveur web tournera alors comme un vrai service Windows.

Et les fonctionnalités de Servy vont bien au-delà du simple lancement puisqu’il intègre des health checks configurables avec intervalle personnalisé (30 secondes par défaut) et un nombre d’échecs tolérés avant action. Le système de recovery gère comme un chef le redémarrage du service, du processus, ou même de la machine complète selon vos besoins. Et pour éviter les boucles infinies, vous pouvez bien sûr limiter le nombre de tentatives de redémarrage.

La gestion des logs est également un autre point fort de Servy puiqu’il peut rediriger automatiquement stdout et stderr vers des fichiers avec rotation automatique basée sur la taille. Comme ça, plus besoin de scripts batch complexes ou de solutions tierces pour capturer les sorties de vos applications console. Tout est géré proprement, avec des logs organisés et consultables.

Selon le guide Windows Services Manager, accéder aux services Windows reste toujours aussi archaïque : Win+R, services.msc, + Entrée. Heureusement, avec Servy, tout se fait depuis son interface. Vous pouvez démarrer, arrêter, mettre en pause, redémarrer vos services, modifier leur priorité (Real-time, High, Normal, Low), et même définir le type de démarrage (Automatic, Manual, Disabled).

Un détail qui fait la différence avec d’autres outils du même genre, c’est la prévention des processus zombies. Hé oui, Servy se la joue comme dans Walking Dead et gère proprement le cycle de vie des processus enfants, s’assurant qu’aucun processus orphelin ne traîne après l’arrêt d’un service. C’est le genre de conneries qu’on découvre généralement après plusieurs semaines de production, quand le serveur commence à ramer sans raison apparente.

Et ça tourne aussi bien de Windows 7 SP1 jusqu’à Windows 11, en passant par toutes les versions Server. Et surtout, le code source complet est disponible sur GitHub sous licence MIT.

Bref, c’est un super outil gratuit, open source, avec une interface bien pensée, et toutes les fonctionnalités dont on rêvait sans le côté usine à gaz !!

Pour les entreprises, c’est une solution idéale pour déployer des applications métier sans les réécrire, avoir à se former sur NSSM ou de maintenir des scripts PowerShell complexes. Cet outil permet de réduire les coûts de maintenance et les erreurs humaines. Bref, c’est un logiciel qui devrait être dans la boîte à outils de tout les admins Windows qui se respectent.

Ça vous dirait de pouvoir taper cursor-agent "trouve et corrige tous les bugs" dans votre terminal et voir GPT-5 analyser l’ensemble de votre code, proposer des corrections, et même les appliquer après votre validation ?

Plus besoin de copier-coller entre ChatGPT et votre éditeur, plus besoin de jongler entre interfaces. Et bien c’est exactement ce que Cursor CLI propose.

Avec la sortie de GPT-5 et l’explosion des assistants de code IA, Cursor frappe fort en proposant une alternative terminal-first qui s’intègre partout : JetBrains, Android Studio, Xcode, ou même directement dans votre shell préféré. Et ce qui est cool c’est qu’on peut utiliser GPT-5 gratuitement pendant la beta.

Alors perso, moi je suis un fervent utilisateur de Claude Code qui fonctionne excellement bien, à tel point que je trouve les IDE Cursor et Windsurf un peu nul maintenant. Donc voir Cursor sortir son clone de Claude Code, branché sur GPT-5, évidemment, ça m’intéresse.

L’installation se fait avec cette ligne magique :

curl https://cursor.com/install -fsS | bash

Une fois installé, vous suivez les instructions pour exporter cursor-agent dans votre environnement shell et ensuite vous lancez cursor-agent, et vous voilà avec un agent IA surpuissant directement dans votre terminal. Selon la documentation officielle, le CLI réutilise toute votre configuration Cursor existante : vos règles personnalisées, votre fichier AGENTS.md, et même vos intégrations MCP.

Ce qui distingue Cursor CLI des alternatives comme Claude Code ou Gemini CLI, c’est son système d’approbation granulaire. Par exemple, si vous demandez à l’agent de créer une API Express avec des tests Jest, il vous montrera d’abord les modifications proposées. Vous pouvez ensuite accepter, refuser, ou modifier chaque changement avant qu’il ne touche vos fichiers. Cette approche réduit considérablement les erreurs par rapport aux solutions qui appliquent tout automatiquement.

La vraie puissance du truc se révèle surtout dans l’automatisation, car vous pouvez créer des scripts qui utilisent Cursor CLI pour :

• Générer automatiquement de la documentation à partir de votre code
• Lancer des revues de sécurité sur chaque commit
• Créer des agents personnalisés pour vos workflows spécifiques
• Scaffolder des projets entiers avec une seule commande

Le support des modèles est lui aussi impressionnant. A part GPT-5, vous avez accès à Claude 4 Sonnet, Opus (et aussi Gemini, Grok, o3…etc mais j’ai pas vu ça dans ma beta). Un simple /model ls liste tous les modèles disponibles, et /model gpt-5 vous permet de basculer dessus instantanément. Cette flexibilité permet d’utiliser le modèle le plus adapté à chaque tâche.

Perso, j’ai beaucoup testé GPT-5 hier via Windsurf pour voir ce qu’il avait dans le ventre (sur du code uniquement) et hormis le fait que c’était lent de fou, ça ne m’a pas non plus très impressionné. J’avais un bug à régler et le truc a tourné toute la matinée pour au final me faire un gros caca. Et j’ai fini par résoudre le bug en fin de journée, cette fois avec Claude Code et en quelques dizaines de minutes. Donc j’avoue que pour le moment, je suis hyper déçu de GPT-5 mais bon, je lui redonnerai sa chance plus tard.

Pour les équipes, Cursor CLI c’est top pour votre CI/CD. Vous pourriez par exemple concevoir des pipelines qui utilisent GPT-5 pour :

• Générer automatiquement des tests pour le code non couvert
• Optimiser les performances avant chaque déploiement
• Créer des changelogs détaillés basés sur les commits
• Adapter automatiquement le code aux breaking changes des dépendances

Le système de règles personnalisées change aussi la donne. Vous pouvez définir des contraintes spécifiques dans votre fichier AGENTS.md (TypeScript strict, tests obligatoires, commentaires en français, etc.) et Cursor CLI respectera ces règles dans toutes ses générations.

L’aspect privacy est également bien pensé aussi car contrairement à des outils comme Copilot qui envoie votre contexte en permanence, Cursor CLI ne transmet que ce que vous lui demandez explicitement. Vos secrets restent locaux et votre code propriétaire reste protégé.

Par contre, c’est encore en beta donc il reste des bugs notamment sous Windows (WSL), et certains utilisateurs ont indiqué avoir des timeouts sur les gros projets. Mais bon, ça comme avec Claude Code, l’équipe met à jour quasiment non stop.

Pour tester rapidement, lancez simplement cursor-agent pour un chat interactif, ou utilisez les flags -m pour choisir le modèle et --no-interactive pour l’automation complète sans confirmation manuelle.

Et prochainement, il devrait y avoir du contexte persistant entre sessions, de la collaboration multi-agents, et même une intégration native avec les éditeurs via LSP.

Voilà, donc si vous cherchez une alternative à Claude Code ou GitHub Copilot qui respecte votre workflow dans le terminal, Cursor CLI mérite le détour. C’est gratuit pendant la beta et ça devrait bien vous aider !

J’ai vu sur Github un développeur qui a réussi à résoudre le problème le plus universel du télétravail. Ce problème c’est cette fâcheuse tendance qu’on a tous à finir comme Quasimodo, complétement avachis devant notre écran après deux heures de coding, de blogging ou de bitching sur Mastodon.

SlouchDetector, c’est donc l’œuvre d’Alexander Kranga qui a eu cette idée brillante à savoir utiliser MediaPipe pour apprendre à la machine votre posture idéale et vous balancer une alerte quand vous commencez à vous ratatiner. Le tout tourne directement dans votre navigateur, sans qu’aucune donnée ne parte sur Internet. Votre webcam, votre navigateur, et votre vie privée respectée.

Ce qui rend ce projet vraiment bien, c’est qu’il résout un vrai problème. Car selon Planet Nomad, une mauvaise posture au bureau peut réduire la productivité de 18% et augmenter les troubles musculo-squelettiques (TMS) de 65%. Et le pire, c’est qu’on ne se rend même pas compte quand on commence à s’affaler sur notre clavier.

Pour cela, SlouchDetector utilise la détection faciale de MediaPipe pour établir votre position de référence quand vous êtes bien assis et ensuite, l’algorithme surveille en temps réel les déviations par rapport à cette baseline. Pas besoin des 33 points de détection corporelle que propose MediaPipe Pose, juste votre joli visage suffit pour détecter si vous commencez à pencher vers l’écran.

Je souis là

Pour faire tourner ce truc chez vous, c’est du Next.js 15 avec React 19, TypeScript pour la robustesse, et Tailwind CSS 4 pour l’interface. Le développeur a clairement misé sur les dernières technos pour offrir une expérience fluide. Et niveau installation, c’est du classique :

npm ci
npm run dev
# Hop, c'est parti sur http://localhost:3000

Ce qui me plaît, vous vous en doutez, c’est l’approche full respect de la vie privée. Votre webcam capture, MediaPipe analyse, JavaScript alerte, et personne d’autre que vous n’est au courant que vous ressemblez à un bretzel à 16h.

MediaPipe peut détecter des postures complexes en temps réel même sur des machines modestes et c’est cette efficacité qui permet à SlouchDetector de tourner sans problème dans n’importe quel navigateur moderne, sans avoir besoin d’une RTX 4090 pour vous dire de vous redresser.

L’intérêt va au-delà du simple gadget geek. Quand on sait qu’un bureau assis-debout peut faire chuter la pression sur les disques vertébraux de 40%, imaginez l’impact d’un simple rappel régulier pour corriger sa posture. C’est un outil qui pourrait vous éviter bien des visites chez le kiné.

Je souis plou là

Bien sûr, MediaPipe ne détecte qu’une personne à la fois, donc si vous avez l’habitude de travailler avec votre chat sur les genoux, il risque de perturber la détection. Donc mangez-le, avec des frites et une petite sauce au bleu, c’est délicieux ! Les conditions d’éclairage peuvent aussi affecter la précision, mais dans l’ensemble, ça reste très utilisable au quotidien.

Le code est ici ! Et merci à Lorenper pour la découverte !

Vous aussi vous en avez marre de voir vos images disparaître d’Imgur après 6 mois d’inactivité ? Ou de devoir passer par Discord qui compresse tout ce qui bouge ?

Ça tombe bien car j’ai découvert Slink il y a quelques jours et je pense que ça va vous plaire si vous voulez retrouver le contrôle sur vos partages d’images.

Slink, c’est le projet d’Andrii Kryvoviaz, un développeur qui a décidé de combiner ses deux passions : La danse et l’amour de la forêt euuuh, non… Avoir son propre service de partage d’images ET pouvoir raccourcir les URLs en même temps. Parce que oui, en plus d’héberger vos images, Slink génère automatiquement des liens courts pour les partager facilement. Et comme le souligne XDA Developers, tout tient dans un seul container Docker, ce qui rend le déploiement hyper simple.

Le truc vraiment bien pensé, c’est que Slink ne se contente pas de stocker bêtement vos fichiers. Il génère automatiquement des previews, gère l’expiration automatique si vous le souhaitez (pratique pour les partages temporaires), et propose même un mode galerie pour organiser vos images. Le backend en Symfony assure la robustesse, tandis que le frontend en SvelteKit offre une interface moderne et réactive.

Pour l’installation, c’est du Docker classique. Créez votre docker-compose.yml :

services:
slink:
image: ghcr.io/andrii-kryvoviaz/slink:latest
container_name: slink
environment:
- DATABASE_URL=postgresql://user:password@db:5432/slink
- APP_SECRET=your-secret-key
- STORAGE_DRIVER=local
volumes:
- ./uploads:/app/uploads
- ./data:/app/data
ports:
- "3000:3000"

Et une fois lancé, vous aurez accès à une interface web complète avec drag & drop, upload multiple, et même une API REST pour automatiser vos uploads depuis vos scripts ou applications. Le système de permissions est granulaire ce qui vous permet de créer des utilisateurs, définir des quotas, et même activer l’upload anonyme si vous voulez faire votre propre service public.

Ce qui m’a particulièrement séduit dans ce projet, c’est surtout la gestion intelligente du stockage. Selon la doc GitHub, Slink supporte non seulement le stockage local, mais aussi S3 (compatible avec MinIO, Backblaze B2, etc.), et même le partage réseau via SMB. Vous pouvez également définir des limites de taille par fichier, par utilisateur, et même configurer une rétention automatique pour ne pas exploser votre espace disque.

La partie raccourcisseur d’URL est aussi vraiment bien intégrée. Chaque image uploadée reçoit automatiquement un identifiant court (style “slink.io/a8f2”), et vous pouvez aussi créer des liens personnalisés avec votre propre nom de domaine. Et contrairement à des services comme bit.ly, vous gardez le contrôle total sur vos analytics avec le nombre de vues, l’origine des visiteurs, et bien sûr tout est stocké localement (génial pour le RGPD, comme dirait le Capitaine Haddock).

Pas de tracking tiers, pas de publicités, pas de vente de données. Avec Slink, vos images restent vos images, point. Et si vous voulez partager quelque chose de sensible, Slink propose même un chiffrement côté client avec des liens à usage unique qui s’autodétruisent après consultation.

Pour les développeurs, l’API est un vrai bonheur avec de l’authentification via tokens JWT, endpoints RESTful bien documentés, et même des webhooks pour intégrer Slink dans vos workflows. Vous pouvez par exemple configurer un hook pour redimensionner automatiquement les images, les envoyer vers un CDN, ou les sauvegarder sur un service externe.

Et les performances sont au rendez-vous grâce à Rust pour la partie critique (génération des identifiants courts et routing), avec un cache Redis optionnel pour accélérer les requêtes fréquentes. Ainsi, sur un VPS basique, Slink peut facilement gérer des milliers de requêtes par seconde. Un détail sympa, le mode sombre adaptatif suit les préférences système, et il y a une PWA complète pour installer Slink comme une app native sur mobile. De plus, l’interface est responsive et fonctionne parfaitement sur tablette ou smartphone.

Après si vous cherchez des alternatives, il y a Chevereto (payant mais très complet), Lychee (orienté galerie photo), ou PictShare (plus minimaliste et que je testerai une prochaine fois…). Slink trouve donc un excellent équilibre entre fonctionnalités et simplicité, et il y a des mises à jour régulières, ce que j’apprécie beaucoup vue que ma passion dans la vie c’est lire des changelogs.

Voilà, donc pour ceux qui veulent tester avant de se lancer, le projet est entièrement open source sous licence MIT et dispo ici !