155 réponses égarées : la fuite Cloudflare rappelle que l'IA du cloud n'est pas un coffre-fort

155 réponses. C'est le nombre de réponses d'un modèle d'intelligence artificielle hébergé par Cloudflare qui contenaient des morceaux de conversations appartenant à d'autres clients. L'entreprise américaine, qui fait transiter une part considérable du trafic web mondial, l'a reconnu elle-même dans un rapport technique publié le 26 octobre 2026.

La fuite a commencé le 27 août et a duré jusqu'au 9 septembre. Pendant ces treize jours, un client qui envoyait une très longue requête au modèle GLM-5.3, proposé sur la plateforme Workers AI, pouvait recevoir en retour des fragments de requêtes envoyées peu avant par quelqu'un d'autre.

Ce n'est pas un piratage. C'est pire, d'une certaine manière : c'est une panne silencieuse, au cœur de la machine.

Ce qui s'est passé, en clair

Pour répondre vite, un modèle de langage garde en mémoire une sorte de brouillon de calcul, appelé cache KV. Chez Cloudflare, ce travail est découpé en deux étapes confiées à des serveurs différents : l'un lit et prépare la requête, l'autre rédige la réponse.

Selon le rapport de Cloudflare, deux erreurs se sont additionnées. D'abord, une mauvaise configuration : le modèle acceptait des requêtes allant jusqu'à 1 048 576 tokens, mais la mémoire prévue pour les préparer n'en contenait que 681 280. Ensuite, un défaut dans SGLang, le moteur d'inférence libre utilisé : les requêtes trop longues étaient marquées comme rejetées, mais pas réellement arrêtées.

Résultat : le serveur chargé d'écrire la réponse allait piocher dans des pages de mémoire périmées. Des pages qui contenaient encore les données de l'utilisateur précédent.

Les 155 réponses touchées concernaient toutes des requêtes de plus de 681 280 tokens, précise l'entreprise. Elle dit n'avoir trouvé aucun signe d'exploitation délibérée : les volumes et le calendrier correspondent à un usage normal des très longs contextes.

Un chercheur en sécurité a signalé le problème le 8 septembre via un programme de primes aux bogues. Le modèle a été coupé le lendemain, corrigé, puis remis en ligne le jour même.

L'aveu le plus utile

Le rapport contient une phrase que tous les développeurs devraient afficher au-dessus de leur bureau. Cloudflare reconnaît que ses tests ne vérifiaient que les codes de réponse et les performances sur les longs contextes. Autrement dit, personne ne contrôlait que la réponse renvoyée à un client contenait bien ses données à lui.

Les ingénieurs supposaient que chaque nouvelle requête écrasait proprement la mémoire de la précédente. Elle ne le faisait pas toujours.

Les correctifs annoncés sont précis : mémoire portée à environ 2,04 millions de tokens pour que toute requête valide y tienne, correction du moteur pour éliminer les requêtes rejetées avant tout transfert, libération différée des pages de mémoire, contrôles systématiques entre taille du contexte et taille de la mémoire. Cloudflare recommande aussi à tous ceux qui utilisent SGLang de passer à la version 0.5.22 ou plus récente. Un défaut proche avait d'ailleurs été signalé aux développeurs du moteur dès le 6 juillet.

Pourquoi ça concerne Tunis

À première vue, l'affaire est lointaine. Un modèle chinois, servi par une entreprise californienne, utilisé par une poignée de clients. Mais elle touche exactement le modèle économique de la jeune scène IA tunisienne.

Une startup tunisienne qui construit un assistant juridique, un outil RH ou un chatbot bancaire ne fait presque jamais tourner son propre modèle. Elle loue de la puissance de calcul à un fournisseur étranger, via une API, et lui envoie les données de ses clients. Contrats, fiches de paie, échanges avec des patients, dossiers de crédit.

C'est rationnel. Un serveur équipé de cartes graphiques haut de gamme coûte une fortune, se paie en devises et s'amortit mal à l'échelle d'un marché de 12 millions d'habitants. L'API, elle, se règle à la consommation.

Mais ce confort a un prix caché : la confidentialité repose sur des couches techniques que personne, côté client, ne voit ni ne contrôle. Le développeur tunisien qui envoie un long dossier à une API ne sait pas comment le fournisseur découpe le calcul, ni quelle version du moteur tourne derrière.

La loi tunisienne sur la protection des données personnelles impose pourtant à celui qui traite des données d'en assurer la sécurité, y compris lorsqu'il les confie à un sous-traitant. Si une fuite survient chez le fournisseur, c'est d'abord la startup qui devra rendre des comptes à ses propres clients.

Ce que les équipes peuvent faire dès maintenant

Il ne s'agit pas de renoncer aux API d'IA. Il s'agit de les utiliser avec les yeux ouverts.

Première règle : n'envoyer que le nécessaire. Masquer les noms, les numéros de carte d'identité, les RIB avant l'appel au modèle. Une donnée qui n'est pas envoyée ne peut pas fuir.

Deuxième règle : se méfier des très longs contextes. L'incident Cloudflare montre que c'est précisément aux limites, quand on remplit la mémoire jusqu'au bord, que les systèmes cassent. Découper un long document en morceaux est souvent plus sûr, et moins cher.

Troisième règle : lire les engagements du fournisseur. Conservation des requêtes, isolation entre clients, procédure de notification en cas d'incident. Un fournisseur qui publie un rapport aussi détaillé que celui-ci donne au moins une indication de sérieux.

Quatrième règle : pour ceux qui hébergent eux-mêmes un modèle avec un moteur libre, mettre à jour. Les correctifs existent, encore faut-il les appliquer.

La nuance qui compte

Ce n'est pas un scandale. Les chiffres sont faibles, la réaction a été rapide et la transparence remarquable : Cloudflare détaille ses propres erreurs avec une précision que beaucoup d'entreprises n'oseraient pas. Les chercheurs qui signalent ce genre de faille, et les entreprises qui les écoutent, font avancer tout l'écosystème.

Mais c'est un rappel. L'IA générative a été vendue comme une boîte magique, alors qu'elle repose sur une plomberie complexe, en évolution permanente, où un simple écart entre deux réglages peut faire passer la conversation d'un client dans la réponse d'un autre.

Pour les développeurs tunisiens, qui construisent souvent vite, avec peu de moyens et beaucoup d'enthousiasme, la leçon est simple : la confiance ne se délègue pas, elle se vérifie.

Dans le cloud, le makroud est peut-être partagé. Le secret, lui, ne doit jamais l'être.