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…

Amazon ne prend pas de vacances et offre toujours des jeux vidéo à ses abonnés Prime. De quoi les occuper, un peu, cet été.

Pour montrer les capacités de GPT-5, OpenAI a eu une idée : faire jouer son modèle d'IA à Pokémon Rouge. Il s'agit en fait surtout d'un affrontement avec Gemini et Claude, d'autres IA qui jouent également au jeu. Qui battra la Ligue Pokémon le plus rapidement ?

Deux scientifiques ont rassemblé un catalogue détaillé des fonds marins, mettant au jour 332 réseaux de canyons sous l'océan de glace de l'Antarctique. Ces canyons ont un énorme impact sur le climat mondial et la biodiversité océanique.

La marque haut de gamme de BYD baptisée Yangwang s'apprête à dévoiler une version extrême de sa supercar U9. Avec une puissance en théorie supérieure à 3 000 ch, la Chinoise met une claque à la Xiaomi SU7 Ultra.

Le futur patron de Jaguar Land Rover n’a pas l’intention de changer une virgule à la stratégie de la marque, malgré les critiques virulentes de Donald Trump.  

[Deal du jour] Xiaomi propose de nombreux produits pour la maison, dont plusieurs ventilateurs connectés. Le Smart Standing Fan 2 Lite est un modèle de qualité, bien plus abordable en promotion.

Pour la première fois, des atomes en train de bouger au sein d'une molécule ont pu être directement observés. Une mesure au niveau quantique, qui montre des mouvements extrêmement synchronisés et incessants.

Après des mois d'attente, les fans ont enfin pu découvrir les toutes premières images de la saison 2 de One Piece, sur Netflix. L'occasion de rencontrer de nouveaux personnages, bien connus des fans du manga original.

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

La der8enchtable est bien plus qu’une simple table de bench. Elle est pensée pour les overclockers et intègre un PCB actif

Cet article Thermal Grizzly lance la der8enchtable, est-ce la table de bench ultime ? a été publié en premier par GinjFo.

La GeForce RTX 5090 ROG Astral OC “BTF” (pour Back to the Future) d'Asus est disponible au prix de 3 033 €

Cet article ASUS lance sa RTX 5090 ROG Astral OC édition “Retour vers le Futur” a été publié en premier par GinjFo.

On est certainement en train d'assister au retour en grâce de la saga Battlefield. Les premiers chiffres de la bêta de Battlefield 6 sont vertigineux, que ce soit en termes de joueuses et joueurs connectés en même temps ou de statistiques de streaming.

Si vous n'avez pas encore osé faire vos premiers pas dans le remake incroyable de Silent Hill 2, plusieurs fans ont récemment recréé la ville du brouillard dans Roblox. Une version complète et fidèle à parcourir pour le plaisir, et à plusieurs.

Cet été 2025, les automobilistes français doivent faire face à un nouveau piège sur la route des vacances : les faux SMS et mail Ulys. Depuis la mise en place du péage en flux libre, les cybercriminels profitent du flou qui entoure ce nouveau procédé pour arnaquer les voyageurs.

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