Le blog de Toniob

L’IA générative pourrit vraiment tout

Anthony Bourguignon — Tue, 10 Feb 2026 13:22:00 +0000

Pendant mes études d’informatique, on parle du début des années 2000, j’avais eu des cours et des travaux pratiques sur les réseaux de neurones. On ne parlait pas encore d’IA à l’époque, de mon souvenir. Et j’avais vraiment aimé cette partie, très intéressante, à la pointe. J’ai gardé pendant longtemps cet à priori très positif de l’intelligence artificielle.

Aujourd’hui, mon avis est bien à l’opposé. Je ne vais pas m’étendre sur les soucis de l’IA aujourd’hui, écologiques (les ressources consommées), sociaux (les licenciements) et idéologiques (l’adoration par l’extrême droite pour inventer des mensonges qui les arrangent).

Mais des fois, on se rend compte que l’IA générative pose problème d’une manière plus fourbe.

Vous connaissez peut-être le logiciel libre cURL. Il s’agit d’un outil en ligne de commande qui permet de parcourir le web. Mais le sous-projet est également la bibliothèque libcurl, qui permet à d’autres logiciels de faire des requêtes HTTP sans avoir à réinventer la roue, et en s’appuyant sur une base de code qui est connue et maintenue. La libcurl est très très utilisée dans le monde du logiciel libre, mais du fait de sa licence, également dans des logiciels propriétaires, commerciaux ou non. C’est une bibliothèque qu’on retrouve partout. Si vous utilisez un logiciel qui fait des requêtes en HTTP, il y a une bonne probabilité que ça soit la libcurl derrière. Il est donc très important que la bibliothèque soit maintenue et exempte de failles. En effet, un souci de sécurité dans libcurl, et ce serait potentiellement tous les projets qui l’utilisent qui seraient vulnérables.

Pour faire en sorte que le code soit le plus vérifié possible, le projet cURL avait recours à un programme de bug bounty. Les personnes découvrant des failles dans le logiciel pouvaient donc les proposer et recevoir de l’argent en contrepartie. Ça peut sembler étrange, mais ça fonctionne assez bien. Du moins, ça fonctionnait assez bien. Mais depuis quelques mois, le projet croulait sous les rapports qui sont générés par IA. Comprendre par là que des personnes qui n’y connaissent rien, qui ne voient que le profit qu’elles pourraient obtenir, font analyser le code par une IA avec un prompt demandant de trouver les failles. Et comme d’hab, elle se plante carrément, hallucine des fonctions qui n’existent pas, ou trouve des erreurs qui n’en sont pas. L’équipe de cURL s’est retrouvée devant beaucoup de demandes de revue, dont la plupart étaient fausses. Mais qui nécessitent quand même du temps pour s’apercevoir que c’est de l’IA slop. Et tout ce temps, c’est du temps qui n’est pas investi dans le projet.

Suite à ces trop nombreuses demandes au rapport signal/bruit bien trop faible, le projet curl a décidé d’arrêter le programme de bug bounty. Ça ne peut avoir que 2 conséquences. La première étant que les vraies personnes expertes vont être moins tentées de chercher des failles dans cURL, puisqu’il n’y aura plus de compensation financière à la clé. Donc les failles seront là, mais pas remontées au projet. La deuxième conséquence c’est que les personnes qui trouvent des failles désormais, ce qui peut prendre du temps, vont quand même souhaiter rentrer dans leurs frais. Et elles vont être tentées d’aller les revendre à des personnes qui aimeraient exploiter des failles de sécurité et les garder pour elles. Dans les 2 cas, on se retrouve avec un logiciel qui est moins sûr. Pour un projet aussi utilisé que cURL, c’est un énorme problème et une épée de Damoclès au dessus de nos têtes.

Tout ça à cause de l’IA Générative et de personnes malveillantes, volontairement ou non. Vivement que cette bulle explose.

HTTP/3 avec Nginx sous Debian Trixie

Anthony Bourguignon — Thu, 05 Feb 2026 11:18:00 +0000

La version 13 de Debian, nommée Trixie, dispose d’une version assez récente de Nginx pour pouvoir activer HTTP/3 et Quic. La syntaxe a un peu changé, y compris pour HTTP/2. Il fallait l’indiquer avant en paramètre de la directive listen :

listen 0.0.0.0:443 ssl http2;

Il s’agit maintenant d’une directive à part :

http2 on;
listen 0.0.0.0:443 ssl;

Il est possible d’activer HTTP/3 sur un vhost avec la même syntaxe, mais une directive et des paramètres différents (il faut également que le port 443 soit ouvert en UDP sur votre firewall) :

http3 on;
listen 0.0.0.0:443 quic;

Jusque là, pas de souci. Les problèmes arrivent toutefois à partir du moment où vous avez un backend en HTTP/1.1 (typiquement du websocket). Et là, il est possible que vous constatiez que tout est ok en HTTP/2 mais que si le client passe en HTTP/3, le backend va refuser de répondre.

server {
  listen 0.0.0.0:443 quic;
  …
  location / {
    include proxy_params;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_pass http://127.0.0.1:9000;
  }
}

Le problème vient du fichier proxy_params qui est packagé par Debian :

proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Il envoie au proxy la valeur de la variable $http_host. Malheureusement, en HTTP/3, le client n’envoie pas de header Host, l’information étant envoyée pendant la connexion. La variable est donc vide. Et comme en HTTP/1.1, l’en-tête Host est obligatoire, ça ne passe pas. Pour résoudre cela, il est possible de changer la variable $http_host en $host. Cette variable prend une valeur en fonction de ce qui est disponible dans la requête. Elle ne peut pas être vide.

J’ai créé le bug 1126960 chez Debian pour changer la variable du fichier proxy_params par défaut.

Sans déconner ?

Anthony Bourguignon — Fri, 30 Jan 2026 18:51:00 +0000

Réouvrir un blog personnel ? En 2026 ?

Bah oui, il faut croire que je l’ai fait.

Le blog de Toniob

L’IA générative pourrit vraiment tout

HTTP/3 avec Nginx sous Debian Trixie

Sans déconner ?

HTTP/3 avec Nginx sous Debian Trixie