Vue lecture

« Au début, on nous prenait pour des fous » : entretien avec William Méauzoone, co-fondateur du cloud français Leviia

Alors que le contexte géopolitique place la souveraineté numérique au cœur des débats et que la doctrine française en matière d'achats numériques priorise désormais clairement les acteurs français et européens, Numerama est allé à la rencontre des dirigeants qui composent l'écosystème tech souverain français pour retracer leurs aventures et analyser les défis actuels.

  •  

Lunettes Meta : l’intégration de la reconnaissance faciale est discrètement en cours

Harcèlement de rue connecté
Lunettes Meta : l’intégration de la reconnaissance faciale est discrètement en cours

L’intégration de la fonction Name Tag est déjà en cours dans l’application Meta AI. Celle-ci doit permettre la reconnaissance faciale via les lunettes connectées de l’entreprise. La communication de l’entreprise vis-à-vis de la fonctionnalité intrusive reste ambivalente.

Meta a discrètement intégré du code dans son application Meta AI pour activer la reconnaissance faciale dans ses lunettes connectées, dont les modèles créés en collaboration avec Ray-Ban et Oakley.

En février, on apprenait que l’entreprise de Mark Zuckerberg réfléchissait à une fonctionnalité de ce genre baptisée « Name Tag ». Un mémo datant de janvier 2025 analysait de façon assez cynique que le lancement pourrait bénéficier « d’une période de contexte politique dynamique » dans laquelle les personnes critiques envers ce genre de fonctionnalités « auront concentré leurs ressources sur d’autres préoccupations ».

Du code déjà bien intégré dans l’app Meta AI

Mais Wired a pu découvrir que, depuis janvier dernier, plusieurs mises à jour de l’application Meta AI ont permis à l’entreprise d’y ajouter du code implémentant « Name Tag » petit à petit. Nos confrères affirment que des « composants essentiels du système » ont été intégrés dans l’application distribuée à des millions de personnes qui est nécessaire à l’utilisation des lunettes connectées de Meta.

Dès qu’elle sera activée, la fonction « Name Tag » pourra comparer tous les visages passant devant les lunettes à une base de données d’ « empreintes faciales » qui sera stockée sur le téléphone de l’utilisateur. La reconnaissance d’un visage entrainera des notifications à l’utilisateur tandis qu’un nouveau visage sera automatiquement indexé dans cette base dans un dossier « en attente ».

Le code du système « Name Tag » qu’a pu analyser Wired peut aussi récupérer des empreintes faciales depuis les serveurs de Meta et les stocker sur les appareils des utilisateurs afin d’alimenter cette base d’empreintes faciales.

Une empreinte biométrique représentée par une série de 2 048 nombres

Selon l’analyse du code, Meta a découpé la fonctionnalité « Name Tag » en trois : un modèle détecte les visages, une autre partie du code les recadre et enfin une troisième permet de les convertir en données biométriques. Les premières esquisses de l’interface graphique baptiseraient la fonction du nom « Connections » et proposeraient aux utilisateurs des lunettes Meta de « se souvenir des personnes qu’ils ont rencontrées ».

L’Electronic Frontier Foundation (EFF) confirme l’analyse de nos confrères. L’ONG ajoute que la fonctionnalité mise en place par Meta « enregistre les empreintes faciales sous la forme d’une série de 2 048 nombres représentant de manière unique la disposition des traits du visage d’une personne ». « Lorsque cette fonctionnalité est activée, elle convertit chaque nouveau visage capté par les lunettes de surveillance en une série de nombres, puis la compare à toutes les empreintes faciales existantes dans la base de données de l’utilisateur », explique-t-elle.

L’EFF déplore que « malgré les innombrables raisons de ne pas le faire, Meta semble avoir mis en place les moyens de transformer ses clients en une machine de surveillance décentralisée ». Elle ajoute que « c’est une raison de plus de bien réfléchir avant d’acheter ou d’utiliser les lunettes de surveillance de Meta ».

« En intégrant la technologie dans l’écosystème, on établit des normes et des standards », explique l’ancien responsable de l’encadrement des pratiques chez Meta Reality Labs, Joseph Jerome. « Je ne vois pas comment Meta pourrait déployer une technologie comme celle-ci de manière responsable », ajoute-t-il.

L’ambivalente communication de Meta

En avril dernier, plus de soixante-dix associations dédiées à la défense des libertés numériques ou à la lutte pour les droits des femmes et des minorités signaient une lettre ouverte contre l’intégration de la reconnaissance faciale dans les lunettes connectées de Meta à destination de Mark Zuckerberg. À l’époque, l’entreprise assurait :« Nos concurrents proposent ce type de produit de reconnaissance faciale, ce qui n’est pas notre cas. Si nous devions lancer une telle fonctionnalité, nous adopterions une approche très réfléchie avant de la déployer ».

Face aux révélations de nos confrères, Meta assure maintenant : « les faits sont simples : nous avons déjà indiqué que nous étudiions ce type de fonctionnalités, et ce que vous voyez n’est que la preuve de cette exploration ». L’entreprise ajoute : « rien n’a encore été mis à la disposition des utilisateurs et aucune décision définitive n’a été prise quant à la suite à donner, le cas échéant. Si nous décidons de déployer une telle fonctionnalité, nous adopterons une approche réfléchie et le ferons en toute transparence. Une chose est sûre : nous ne sommes pas en train de créer une base de données centrale de visages ».

Rappelons qu’en 2021, Meta avait annoncé l’abandon de la reconnaissance faciale. Elle expliquait à l’époque devoir « peser l’utilisation positive de la reconnaissance faciale par rapport aux préoccupations sociétales croissantes, d’autant plus que les régulateurs n’ont pas encore défini de règles claires ».

En France, la CNIL faisait encore part récemment de ses craintes sur l’utilisation des lunettes connectées et les risques majeurs qu’elles présentent pour la vie privée.

  •  

Lunettes Meta : l’intégration de la reconnaissance faciale est discrètement en cours

Harcèlement de rue connecté
Lunettes Meta : l’intégration de la reconnaissance faciale est discrètement en cours

L’intégration de la fonction Name Tag est déjà en cours dans l’application Meta AI. Celle-ci doit permettre la reconnaissance faciale via les lunettes connectées de l’entreprise. La communication de l’entreprise vis-à-vis de la fonctionnalité intrusive reste ambivalente.

Meta a discrètement intégré du code dans son application Meta AI pour activer la reconnaissance faciale dans ses lunettes connectées, dont les modèles créés en collaboration avec Ray-Ban et Oakley.

En février, on apprenait que l’entreprise de Mark Zuckerberg réfléchissait à une fonctionnalité de ce genre baptisée « Name Tag ». Un mémo datant de janvier 2025 analysait de façon assez cynique que le lancement pourrait bénéficier « d’une période de contexte politique dynamique » dans laquelle les personnes critiques envers ce genre de fonctionnalités « auront concentré leurs ressources sur d’autres préoccupations ».

Du code déjà bien intégré dans l’app Meta AI

Mais Wired a pu découvrir que, depuis janvier dernier, plusieurs mises à jour de l’application Meta AI ont permis à l’entreprise d’y ajouter du code implémentant « Name Tag » petit à petit. Nos confrères affirment que des « composants essentiels du système » ont été intégrés dans l’application distribuée à des millions de personnes qui est nécessaire à l’utilisation des lunettes connectées de Meta.

Dès qu’elle sera activée, la fonction « Name Tag » pourra comparer tous les visages passant devant les lunettes à une base de données d’ « empreintes faciales » qui sera stockée sur le téléphone de l’utilisateur. La reconnaissance d’un visage entrainera des notifications à l’utilisateur tandis qu’un nouveau visage sera automatiquement indexé dans cette base dans un dossier « en attente ».

Le code du système « Name Tag » qu’a pu analyser Wired peut aussi récupérer des empreintes faciales depuis les serveurs de Meta et les stocker sur les appareils des utilisateurs afin d’alimenter cette base d’empreintes faciales.

Une empreinte biométrique représentée par une série de 2 048 nombres

Selon l’analyse du code, Meta a découpé la fonctionnalité « Name Tag » en trois : un modèle détecte les visages, une autre partie du code les recadre et enfin une troisième permet de les convertir en données biométriques. Les premières esquisses de l’interface graphique baptiseraient la fonction du nom « Connections » et proposeraient aux utilisateurs des lunettes Meta de « se souvenir des personnes qu’ils ont rencontrées ».

L’Electronic Frontier Foundation (EFF) confirme l’analyse de nos confrères. L’ONG ajoute que la fonctionnalité mise en place par Meta « enregistre les empreintes faciales sous la forme d’une série de 2 048 nombres représentant de manière unique la disposition des traits du visage d’une personne ». « Lorsque cette fonctionnalité est activée, elle convertit chaque nouveau visage capté par les lunettes de surveillance en une série de nombres, puis la compare à toutes les empreintes faciales existantes dans la base de données de l’utilisateur », explique-t-elle.

L’EFF déplore que « malgré les innombrables raisons de ne pas le faire, Meta semble avoir mis en place les moyens de transformer ses clients en une machine de surveillance décentralisée ». Elle ajoute que « c’est une raison de plus de bien réfléchir avant d’acheter ou d’utiliser les lunettes de surveillance de Meta ».

« En intégrant la technologie dans l’écosystème, on établit des normes et des standards », explique l’ancien responsable de l’encadrement des pratiques chez Meta Reality Labs, Joseph Jerome. « Je ne vois pas comment Meta pourrait déployer une technologie comme celle-ci de manière responsable », ajoute-t-il.

L’ambivalente communication de Meta

En avril dernier, plus de soixante-dix associations dédiées à la défense des libertés numériques ou à la lutte pour les droits des femmes et des minorités signaient une lettre ouverte contre l’intégration de la reconnaissance faciale dans les lunettes connectées de Meta à destination de Mark Zuckerberg. À l’époque, l’entreprise assurait :« Nos concurrents proposent ce type de produit de reconnaissance faciale, ce qui n’est pas notre cas. Si nous devions lancer une telle fonctionnalité, nous adopterions une approche très réfléchie avant de la déployer ».

Face aux révélations de nos confrères, Meta assure maintenant : « les faits sont simples : nous avons déjà indiqué que nous étudiions ce type de fonctionnalités, et ce que vous voyez n’est que la preuve de cette exploration ». L’entreprise ajoute : « rien n’a encore été mis à la disposition des utilisateurs et aucune décision définitive n’a été prise quant à la suite à donner, le cas échéant. Si nous décidons de déployer une telle fonctionnalité, nous adopterons une approche réfléchie et le ferons en toute transparence. Une chose est sûre : nous ne sommes pas en train de créer une base de données centrale de visages ».

Rappelons qu’en 2021, Meta avait annoncé l’abandon de la reconnaissance faciale. Elle expliquait à l’époque devoir « peser l’utilisation positive de la reconnaissance faciale par rapport aux préoccupations sociétales croissantes, d’autant plus que les régulateurs n’ont pas encore défini de règles claires ».

En France, la CNIL faisait encore part récemment de ses craintes sur l’utilisation des lunettes connectées et les risques majeurs qu’elles présentent pour la vie privée.

  •  

Amazon shopping génère en temps réel par IA des images de produits qui… n’existent pas

Amazon PrAIme
Amazon shopping génère en temps réel par IA des images de produits qui… n’existent pas

L’application shopping d’Amazon propose à ses utilisateurs, non pas des images de produits existants correspondant aux mots-clefs recherchés, mais des images générées par IA, évoluant et s’affinant à chaque mot ajouté.

Amazon vient d’annoncer 8 nouvelles « fonctionnalités intuitives » de recherche visuelle dans son application mobile de shopping. Trois d’entre elles, censées « permettre d’effectuer des recherches de produits plus rapides et plus précises », et rendre l’utilisation de son application de shopping « plus ludique », reposent sur l’IA générative.

« La toute nouvelle fonctionnalité de recherche basée sur l’IA d’Amazon permet de faire le lien entre l’imagination et la découverte de produits directement dans la barre de recherche de l’application Amazon Shopping », souligne Mihir Bhanot, directeur d’Amazon Search :

« Notre toute nouvelle fonctionnalité de recherche génère des images par IA en temps réel à mesure que les clients décrivent ce qu’ils ont en tête dans la barre de recherche, donnant ainsi vie à leur vision au fur et à mesure qu’ils la saisissent, la visualisent et effectuent leurs achats. »

Une des utilisations les plus « ridiculement stupides » de l’IA à ce jour

C’est peu dire que la presse spécialisée ne semble guère emballée. TechCrunch évoque « ce qui pourrait être l’une des utilisations les plus discutables de l’IA à ce jour », 9to5google «l’une des plus absurdes », qui « n’a pas de sens ». Amazon «invente des produits générés par l’IA que l’on ne pourra pas acheter », ironise The Verge.

« C’est quand même un peu dingue qu’un commerçant invente de faux produits pour orienter les utilisateurs vers certains résultats de recherche », résume TechCrunch :

« Pour commencer, cela peut prêter à confusion : les clients qui ne lisent pas attentivement pourraient croire qu’ils sont redirigés vers une page où ils trouveront exactement cette robe, puis être déçus de constater qu’elle n’est pas disponible. Et puis, on peut se demander pourquoi inventer des images de produits alors que votre site regorge de photos réelles de produits réels — ce qui est sans doute ce que les acheteurs en ligne souhaitent réellement voir. »

« En plus d’être extrêmement gaspilleuse en termes d’utilisation des ressources de l’IA, l’idée de générer de fausses images de produits lors d’une recherche semble tout simplement ridiculement stupide », plussoie 9to5google :

« Les gens se rendent sur Amazon pour acheter de vrais produits physiques ; il est donc totalement absurde qu’une IA se serve de leur recherche pour créer des choses qui n’existent pas. »

Amazon précise que ses clients peuvent en profiter dès aujourd’hui lorsqu’ils recherchent des articles dans les catégories « Mode » et « Maison », mais que d’autres catégories seront progressivement ajoutées.

Des suggestions d’images évoluant et s’affinant à chaque mot ajouté

Ce recours à l’IA générative est d’autant plus absurde que ces images GenAI ne sont pas générées après que les mots-clefs recherchés ont été entrés dans le formulaire, à la manière d’un prompt, mais au fur et à mesure, conduisant à générer bien plus d’images qu’il n’en faut, à la volée, comme le souligne le communiqué d’Amazon lui-même, et le .gif associé :

« Désormais, lorsque les clients recherchent des produits en utilisant des termes descriptifs – tels que la couleur, la texture ou le motif –, des images générées par l’IA apparaissent instantanément dans les suggestions situées sous la barre de recherche, évoluant et s’affinant à chaque mot ajouté. »

Dit autrement : non content de ne pas correspondre à des produits existants, la quasi-totalité des images générées par IA ne serviront à rien… sauf à ce qu’Amazon les stocke quelque part et trouve un moyen de les réutiliser et rentabiliser.

L’entreprise vante elle-même le fait que ces images soient « générées par IA en temps réel », ce qui est d’autant plus absurde (et coûteux) qu’Amazon aurait tout aussi bien pu se contenter d’utiliser des images préalablement stockées dans une base de données et associées à tels ou tels mots-clefs, plutôt que générées à la volée, à chaque fois, la plupart du temps pour rien.

On peut aussi s’interroger quant à la pertinence d’utiliser des images générées par IA plutôt que des images de produits existants. À part pour lancer une « nouvelle fonctionnalité » surfant sur le buzzword « généré par IA ».

Pour rappel, des salariés d’Amazon en étaient récemment arrivés à brûler des tokens pour se faire bien voir, une pratique qualifiée de « tokenmaxxing », au point que l’entreprise vient de fermer le classement encensant ceux qui en dépensaient le plus.

The Verge relève cela dit que Google avait lui aussi lancé l’an passé une fonctionnalité similaire, qui génère des images de tenues et de décorations fictives pour aider ses utilisateurs à trouver des produits ressemblants.

En commentaire, un lecteur qualifie l’idée de « géniale parce que si les gens détestent suffisamment ça, ils commenceront à faire leurs achats dans des magasins physiques, sauvant ainsi nos centres commerciaux locaux ».

  •  

Amazon shopping génère en temps réel par IA des images de produits qui… n’existent pas

Amazon PrAIme
Amazon shopping génère en temps réel par IA des images de produits qui… n’existent pas

L’application shopping d’Amazon propose à ses utilisateurs, non pas des images de produits existants correspondant aux mots-clefs recherchés, mais des images générées par IA, évoluant et s’affinant à chaque mot ajouté.

Amazon vient d’annoncer 8 nouvelles « fonctionnalités intuitives » de recherche visuelle dans son application mobile de shopping. Trois d’entre elles, censées « permettre d’effectuer des recherches de produits plus rapides et plus précises », et rendre l’utilisation de son application de shopping « plus ludique », reposent sur l’IA générative.

« La toute nouvelle fonctionnalité de recherche basée sur l’IA d’Amazon permet de faire le lien entre l’imagination et la découverte de produits directement dans la barre de recherche de l’application Amazon Shopping », souligne Mihir Bhanot, directeur d’Amazon Search :

« Notre toute nouvelle fonctionnalité de recherche génère des images par IA en temps réel à mesure que les clients décrivent ce qu’ils ont en tête dans la barre de recherche, donnant ainsi vie à leur vision au fur et à mesure qu’ils la saisissent, la visualisent et effectuent leurs achats. »

Une des utilisations les plus « ridiculement stupides » de l’IA à ce jour

C’est peu dire que la presse spécialisée ne semble guère emballée. TechCrunch évoque « ce qui pourrait être l’une des utilisations les plus discutables de l’IA à ce jour », 9to5google «l’une des plus absurdes », qui « n’a pas de sens ». Amazon «invente des produits générés par l’IA que l’on ne pourra pas acheter », ironise The Verge.

« C’est quand même un peu dingue qu’un commerçant invente de faux produits pour orienter les utilisateurs vers certains résultats de recherche », résume TechCrunch :

« Pour commencer, cela peut prêter à confusion : les clients qui ne lisent pas attentivement pourraient croire qu’ils sont redirigés vers une page où ils trouveront exactement cette robe, puis être déçus de constater qu’elle n’est pas disponible. Et puis, on peut se demander pourquoi inventer des images de produits alors que votre site regorge de photos réelles de produits réels — ce qui est sans doute ce que les acheteurs en ligne souhaitent réellement voir. »

« En plus d’être extrêmement gaspilleuse en termes d’utilisation des ressources de l’IA, l’idée de générer de fausses images de produits lors d’une recherche semble tout simplement ridiculement stupide », plussoie 9to5google :

« Les gens se rendent sur Amazon pour acheter de vrais produits physiques ; il est donc totalement absurde qu’une IA se serve de leur recherche pour créer des choses qui n’existent pas. »

Amazon précise que ses clients peuvent en profiter dès aujourd’hui lorsqu’ils recherchent des articles dans les catégories « Mode » et « Maison », mais que d’autres catégories seront progressivement ajoutées.

Des suggestions d’images évoluant et s’affinant à chaque mot ajouté

Ce recours à l’IA générative est d’autant plus absurde que ces images GenAI ne sont pas générées après que les mots-clefs recherchés ont été entrés dans le formulaire, à la manière d’un prompt, mais au fur et à mesure, conduisant à générer bien plus d’images qu’il n’en faut, à la volée, comme le souligne le communiqué d’Amazon lui-même, et le .gif associé :

« Désormais, lorsque les clients recherchent des produits en utilisant des termes descriptifs – tels que la couleur, la texture ou le motif –, des images générées par l’IA apparaissent instantanément dans les suggestions situées sous la barre de recherche, évoluant et s’affinant à chaque mot ajouté. »

Dit autrement : non content de ne pas correspondre à des produits existants, la quasi-totalité des images générées par IA ne serviront à rien… sauf à ce qu’Amazon les stocke quelque part et trouve un moyen de les réutiliser et rentabiliser.

L’entreprise vante elle-même le fait que ces images soient « générées par IA en temps réel », ce qui est d’autant plus absurde (et coûteux) qu’Amazon aurait tout aussi bien pu se contenter d’utiliser des images préalablement stockées dans une base de données et associées à tels ou tels mots-clefs, plutôt que générées à la volée, à chaque fois, la plupart du temps pour rien.

On peut aussi s’interroger quant à la pertinence d’utiliser des images générées par IA plutôt que des images de produits existants. À part pour lancer une « nouvelle fonctionnalité » surfant sur le buzzword « généré par IA ».

Pour rappel, des salariés d’Amazon en étaient récemment arrivés à brûler des tokens pour se faire bien voir, une pratique qualifiée de « tokenmaxxing », au point que l’entreprise vient de fermer le classement encensant ceux qui en dépensaient le plus.

The Verge relève cela dit que Google avait lui aussi lancé l’an passé une fonctionnalité similaire, qui génère des images de tenues et de décorations fictives pour aider ses utilisateurs à trouver des produits ressemblants.

En commentaire, un lecteur qualifie l’idée de « géniale parce que si les gens détestent suffisamment ça, ils commenceront à faire leurs achats dans des magasins physiques, sauvant ainsi nos centres commerciaux locaux ».

  •  

Gemini piégé par de simples notifications : une attaque par injection de prompt a détourné l’assistant de Google

Dans un article publié le 3 juin 2026, des chercheurs de SafeBreach ont prouvé comment de simples notifications pouvaient suffire à manipuler Google Gemini. En exploitant le résumé vocal des messages, ils sont notamment parvenus à injecter des instructions invisibles, capables de tromper l’utilisateur à son insu.

  •  

Le portail d’actualités MSN de Microsoft rémunère une quarantaine de médias générés par IA

Embed with Bolloré
Le portail d’actualités MSN de Microsoft rémunère une quarantaine de médias générés par IA

Promettant d’afficher « le meilleur des informations en ligne », jusque dans son widget Actualités présent sur tous les PC Windows, MSN a une curieuse ligne éditoriale. Le portail de Microsoft recommande en effet des vidéos complotistes, survalorise CNews, et rémunère de nombreux médias qui ont remplacé (ou dopé) leurs journalistes et rédacteurs par des IA, en violation de ses propres lignes directrices.

En 2020, Microsoft avait licencié les équipes éditoriales américaine et britannique de ses portails d’actualité MSN, soit près de 80 journalistes, et confié le travail de curation à des intelligences artificielles, rapportait alors Le Figaro.

Sur sa page « Qui sommes-nous? », MSN explique aujourd’hui travailler avec plus de 1 300 éditeurs de presse représentant plus de 4 500 marques dans les principaux pays du globe (mais sans préciser combien par pays, ni donc en France), afin de « regrouper les meilleures actualités, vidéos, photos et autres contenus et les diffuser gratuitement à toute personne dans le monde entier » :

« Nous pensons qu’une presse gratuite et bien financée est un élément essentiel de notre tissu social et nous sommes fiers de nous associer aux meilleures marques de contenus au monde, offrant un modèle commercial qui donne aux gens l’accès à une information fiable et fournit une source de revenus durable pour nos partenaires. »

MSN y précise aussi que « chaque jour, nos algorithmes évaluent des centaines de milliers de contenus envoyés par nos partenaires ». Une curation combinée à « une modération humaine pour garantir que le contenu que nous vous proposons corresponde à nos valeurs et que les informations à ne pas manquer figurent toujours en bonne position ».

MSN, qui sert de page d’accueil sur Edge (le navigateur « par défaut » de Microsoft), et affiche sur tous les ordinateurs dotés du système d’exploitation Windows un widget Actualités les « dernières manchettes de sources de confiance », explique vouloir afficher « le meilleur des informations en ligne ».

Voire. La page de présentation de MSN (archive) se conclut par un recensement des membres de sa « direction des contenus ». Or, Taroon Mandhana ne travaille plus pour Microsoft depuis 2022, Jamil Valliani depuis 2023, Sally Salas et Ming Ye depuis 2024.

Des vidéos conspis à la sauce Bollo niaise

MSN est également truffé de vidéos conspirationnistes, tout en ne partageant majoritairement, pour ce qui est de l’actualité politique, que les vidéos de CNews, l’ex-chaîne d’information devenue média d’opinion du groupe Bolloré.


Il reste 91% de l'article à découvrir.
Vous devez être abonné•e pour lire la suite de cet article.
Déjà abonné•e ? Générez une clé RSS dans votre profil.

  •  

Un data center ne puisant pas plus d’eau qu’un restaurant : l’audacieuse promesse de Microsoft face à la soif de l’IA

À la conférence Build 2026, Satya Nadella a frappé fort en affirmant que ses futurs data centers IA ne consommeraient pas plus d'eau à l'année qu'un simple restaurant de quartier. Une promesse de circuit fermé qui cherche à rassurer face à la « soif » de l'IA générative.

  •  

« Ne pas dépendre des autres » : l’Europe dévoile son nouveau plan d’urgence pour les puces IA

puces chips act 2

Face à l'explosion de l'IA et aux coups de pression géopolitiques mondiaux, l'Europe accélère sa mue industrielle. La Commission a dévoilé le Chips Act 2.0 : une mise à jour stratégique taillée pour libérer la production de puces souveraines, connecter les usines et briser les dépendances technologiques.

  •  

Un data center consomme autant d’eau qu’un restaurant ? L’audacieuse promesse de Microsoft pour calmer la soif de l’IA

À la conférence Build 2026, Satya Nadella a frappé fort en affirmant que ses futurs data centers IA ne consommeraient pas plus d'eau à l'année qu'un simple restaurant de quartier. Une promesse de circuit fermé qui cherche à rassurer face à la « soif » de l'IA générative.

  •  

Vent de panique chez Dashlane ? Voici ce qu’il s’est réellement passé chez le gestionnaire de mots de passe français

Le 31 mai 2026, des milliers d'utilisateurs de Dashlane ont reçu des mails de vérification qu'ils n'avaient jamais demandés. Certains se sont retrouvés bloqués hors de leur compte. L'entreprise française a depuis confirmé avoir subi une attaque par force brute, et reconnu que les coffres-forts chiffrés d'une vingtaine d'utilisateurs ont été copiés.

  •  

Riches, mais pas que : pourquoi les fans de F1 sont-ils des cibles parfaites pour les hackers ?

La popularité de la Formule 1 ne profite pas qu'aux écuries et aux diffuseurs. Dans l'ombre, une autre industrie tourne à plein régime : la cybercriminalité. Rencontre avec Bogdan Botezatu, directeur de la recherche sur les menaces chez Bitdefender, qui a cartographié les risques cyber auxquels s'exposent les fans du sport automobile.

  •  

SelfRecover — protocole AGPL de récupération de compte sans email

Je suis agriculteur en Creuse et je code sur mon temps libre. J'ai commencé à m'intéresser à la question de la récupération de compte en développant ARC PVE Hub, un site destiné à fédérer une communauté de joueurs. Je n'ai jamais compris pourquoi il fallait transmettre son email pour régénérer un mot de passe — ça déplace la sécurité du compte vers un fournisseur SMTP tiers, qui n'est pas contrôlé par l'utilisateur.

J'ai donc imaginé un protocole de récupération sans email, sans SMS et sans tiers. Le travail s'est étoffé en partenariat avec un assistant IA (Claude), comme outil de réflexion et de mise en forme — j'y reviens en fin de dépêche dans une note de transparence.

L'incident de sécurité ANTS du 15 avril 2026 a publiquement illustré le problème. J'en ai eu connaissance après avoir développé SelfRecover, ce qui m'a confirmé la pertinence d'un protocole sans dépendance à l'email. SelfRecover est publié sous AGPL-3.0-or-later sur GitHub.

Cette dépêche présente le protocole, ses choix de conception, ses limites assumées, et la comparaison avec les approches existantes (Keycloak Recovery Codes en particulier, qui m'a été suggéré en relecture). Audit communautaire bienvenu.

Sommaire

Le contexte

Depuis l'essor du web, la réponse standard à « l'utilisateur a oublié son mot de passe » est « on lui envoie un lien de réinitialisation par email ». C'est devenu si universel qu'on oublie ce que ça implique :

  • La sécurité du compte est déléguée au fournisseur de la boîte mail (Gmail, Outlook, ProtonMail). Si la boîte mail tombe, le compte aussi.
  • Le canal email est régulièrement exploité par phishing : campagnes imitant des mails de réinitialisation légitimes pour capturer les mots de passe.
  • Les bases de données qui stockent les emails des utilisateurs deviennent une cible massive : leur fuite expose à la fois l'identité et les vecteurs de récupération.

L'incident de sécurité ANTS illustre une autre facette du problème de gestion des données d'authentification dans les services en ligne. Détecté le 15 avril 2026 et rendu public le 20 avril, il a touché 11,7 millions de comptes selon les communiqués officiels. La cause technique identifiée est une faille d'énumération de type IDOR (Insecure Direct Object Reference) : il était possible d'accéder aux données d'un autre compte en modifiant un identifiant dans une URL. La fuite ne concerne ni les mots de passe, ni les pièces justificatives, mais les données personnelles associées aux demandes de titres.

Devant ces limites structurelles autour de l'authentification web, SelfRecover propose une inversion : conserver le secret de récupération chez l'utilisateur, et utiliser le navigateur pour faire les calculs cryptographiques nécessaires à la vérification. Le serveur ne détient plus que des dérivés, jamais les secrets bruts.

Le protocole en deux phrases

Côté navigateur, on calcule HMAC-SHA256(secret, domaine) : une fonction cryptographique standard qui combine le secret de l'utilisateur avec le nom de domaine du site, et produit une empreinte impossible à inverser. Côté serveur, on ne stocke que cette empreinte, en plus protégée par un hash adaptatif et memory-hard : Argon2id, qui est le standard moderne recommandé contre les attaques par brute force.

Deux propriétés découlent de cette construction :

  • Le secret brut ne quitte jamais le poste de l'utilisateur.
  • Un secret capturé sur un site A (par exemple via phishing) est mathématiquement inutilisable sur un site B : la dérivation HMAC produit des empreintes différentes pour des domaines différents. C'est de l'anti-phishing par construction, pas par convention.

Note conceptuelle : l'inspiration vient des machines à rotors historiques type Enigma. Le principe partagé est qu'une même configuration secrète, présente des deux côtés (émetteur et récepteur), permet de produire et vérifier un message dérivé. La cryptographie moderne (HMAC-SHA256 ici) repose sur des fondations mathématiques différentes, mais ce principe de dérivation contrôlée par un secret commun est resté.

Deux modes d'adoption

SelfRecover propose deux modes selon le contexte de déploiement.

Mode Full — Sans email

L'application abandonne entièrement le flow de réinitialisation par email. L'utilisateur génère une passphrase diceware à l'inscription (liste EFF de 7 776 mots, 4 à 7 mots par défaut), qu'il mémorise ou stocke dans son gestionnaire de mots de passe. Cette passphrase, combinée au nom de domaine du site via HMAC-SHA256, permet de réinitialiser le mot de passe sans aucune dépendance externe.

Pour qui : nouveaux projets qui veulent s'affranchir de SMTP dès la conception, ou services qui adoptent un modèle de menace post-fuite (l'email n'est plus considéré comme un canal de confiance).

Mode Lite — Avec email + mot mémorisé

L'application conserve le flow de réinitialisation par email habituel, mais y ajoute une étape supplémentaire : l'utilisateur saisit un mot mémorisé (choisi à l'inscription) qui est dérivé HMAC-SHA256 côté navigateur. Le mot brut n'est jamais transmis au serveur. La validation combine donc deux facteurs :

  1. La possession de la boîte mail (lien reset reçu)
  2. La connaissance du mot mémorisé (dérivé HMAC côté client)

Pour qui : applications existantes qui ne peuvent abandonner SMTP du jour au lendemain, mais veulent durcir progressivement leur flow de récupération. Conséquence : un email intercepté seul ne suffit plus à compromettre un compte — il faut aussi connaître le mot mémorisé.

Synthèse

Mode Canal email Crypto utilisateur Cible
Full Aucun Passphrase diceware EFF + HMAC Nouveaux projets
Lite Conservé Mot mémorisé + HMAC Applications existantes

SelfRecover vs Keycloak Recovery Codes

Lors de la relecture de cette dépêche, devnewton a soulevé une question importante : quelle est la différence avec les Recovery Codes de Keycloak ?

Keycloak est l'IAM (Identity and Access Management) open-source de référence, maintenu par Red Hat sous licence Apache 2.0, déployé dans de nombreuses organisations depuis plus d'une décennie. Son mécanisme de Recovery Codes est un fallback d'authentification à deux facteurs : si l'utilisateur perd son téléphone TOTP, il peut saisir un code de secours préalablement généré côté serveur.

Note importante de positionnement : les Recovery Codes Keycloak adressent le cas « j'ai perdu mon 2FA mais je connais toujours mon mot de passe principal ». Le password reset principal de Keycloak utilise, lui, le canal email standard (configuration SMTP dans l'onglet Email de l'admin console).

SelfRecover s'attaque à un cas différent : « j'ai oublié mon mot de passe principal et je ne veux pas dépendre de l'email pour le récupérer ». Concrètement :

Aspect Keycloak Recovery Codes SelfRecover
Cible Fallback 2FA Password recovery sans email
Architecture Serveur IAM standalone (Java + BDD + admin) Bibliothèque à intégrer dans le code de l'application
Source du secret Serveur génère, utilisateur sauvegarde Utilisateur génère/mémorise (diceware ou mot mémorisé)
Stockage utilisateur Codes à sauvegarder physiquement Passphrase mémorisable (mode Full) ou mot mémorisé (mode Lite)
Email reset principal Reste nécessaire (SMTP configuré dans l'admin) Aucun (mode Full) ou en complément (mode Lite)
Anti-phishing crypto Pas spécifique au mécanisme Dérivation HMAC par domaine : un secret capturé sur un site est mathématiquement inutilisable ailleurs
Licence Apache 2.0 AGPL-3.0-or-later
Maturité 10+ ans, audité, déployé largement Récent, audit communautaire bienvenu

Pour la majorité des projets qui acceptent l'email comme canal de récupération, Keycloak (et son écosystème) reste le bon choix. SelfRecover s'adresse aux applications qui veulent réduire ou supprimer leur dépendance à SMTP, et qui n'ont pas besoin de la richesse d'un IAM complet (multi-realm, OIDC/SAML, fédération d'identité, etc.).

Que se passe-t-il si l'utilisateur perd son secret ?

C'est la question critique d'un protocole de récupération. SelfRecover y répond par escalade progressive sur trois niveaux, complétée par un système de litiges et un chat administrateur pour les cas extrêmes.

Niveau 1 — Passphrase oubliée

L'utilisateur saisit son username + sa passphrase diceware (match exact). Sur succès, un nouveau mot de passe est généré et affiché une seule fois. Anti-brute force : 3 tentatives par 15 minutes, 3 blocages successifs → éjection vers L2.

Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus

L'utilisateur saisit son identifiant public (numéro client, identifiant métier — fourni par le site) et son mot de récupération dérivé HMAC-SHA256 côté navigateur. 3 tentatives maximum avec compteur visible. Sur 3 échecs → redirection vers L3. Un litige est automatiquement créé (LIT-XXXX), tracé en base, admin notifié. Les litiges auto-résolus sont purgés après 24 heures.

Niveau 3 — Accès complètement perdu

Entrée par un lien discret « accès perdu » sur la page de connexion. L'utilisateur saisit son identifiant public en premier (anti-timing : délai forcé de 2 à 3 secondes), puis remplit un formulaire de scoring multi-facteur :

Catégorie Champs Points
Identifiant public 4 20
Mot de récupération (dérivé HMAC) 5 25
Username 3 30
Passphrase (fragments) 3 25

Bonus passifs : IP connue (+5), fingerprint connu (+5).

  • Score ≥ 60/100 → compte récupéré, nouveau mot de passe généré
  • Score < 60/100 après 3 tentatives → le compte passe en mode restreint : l'utilisateur n'a plus accès qu'au chat administrateur, le compte n'est ni utilisable ni écrasable tant que l'admin n'a pas validé
  • Cooldown : 1 heure entre tentatives

Chat administrateur humain en mode restreint — état actuel

Dans l'implémentation actuelle (déployée en production sur ARC PVE Hub), le chat L3 est un canal direct entre l'utilisateur en mode restreint et un administrateur humain du site. Pas d'intermédiaire automatisé, pas de bot.

Le canal de chat est bidirectionnel et fonctionne en polling (pas WebSocket temps réel, pour rester simple). L'admin vérifie l'identité par l'échange et décide manuellement :

Accorder la récupération : mot de passe régénéré, compteurs réinitialisés, litige clôturé, mode restreint levé.

Refuser la récupération : ban temporaire de 24 heures, pas de nouveau litige possible pendant cette fenêtre, compteur de refus incrémenté (1/3, 2/3, 3/3). À chaque clic, l'interface admin rappelle explicitement les conséquences via une modale de confirmation (ban 24h aux refus 1 et 2, suppression définitive au 3e refus).

Au 3e refus, le compte est définitivement supprimé : décision exclusivement humaine, prise en pleine connaissance de cause par l'admin via la modale d'avertissement explicite. La suppression libère l'identifiant public pour une nouvelle inscription.

Principe de design MySelf : aucune destruction de données utilisateur n'est déclenchée sans validation humaine consciente. L'interface admin explicite systématiquement les conséquences avant chaque action irréversible. Une IA peut se tromper ou être manipulée ; lui déléguer la décision de supprimer un compte créerait une surface d'attaque.

Ce mécanisme empêche un attaquant de spammer les litiges indéfiniment : chaque refus lui coûte 24 h, et trois échecs effacent toute trace. Un propriétaire légitime bloqué par erreur peut retenter après chaque fenêtre de ban, ou se réinscrire depuis zéro si totalement verrouillé.

Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local

En complément du chat admin humain (qui resterait toujours disponible), une couche de pré-traitement par un agent conversationnel local (Ollama auto-hébergé) est en cours de design. Le chatbot poserait les questions initiales de vérification d'identité et estimerait si la demande est légitime. Sur estimation positive, le mot de passe serait régénéré directement ; sur doute, l'admin humain reprendrait la main.

Cette option serait configurable par site qui déploie (activable ou non), et le chatbot ne se substituerait jamais à l'admin pour les décisions destructives (suppression de compte) — ces décisions resteraient exclusivement humaines, conformément au principe MySelf énoncé plus haut.

L'enjeu principal en cours de réflexion : calibrer le seuil de confiance du chatbot pour ne pas créer un nouveau vecteur d'attaque par social engineering (un attaquant pourrait essayer de manipuler le LLM par prompts).

Démo standalone vs implémentation de référence

La démo publique (bi-self.my-self.fr/selfrecover/) ne couvre que les niveaux L1 et L2, car L3 nécessite une interface admin, un système de disputes et un dashboard — trop pour une démo à page unique.

L'implémentation de référence en production se trouve sur ARC PVE Hub, un site communautaire de joueurs ARC RAIDERS qui sert de terrain de test à l'écosystème MySelf. L1 + L2 + L3 + mode restreint + chat admin + dispute system y sont fonctionnels.

Pourquoi assumer cette friction

Dans la vie réelle, si l'on perd sa carte bancaire, son code, sa pièce d'identité, son adresse et sa date de naissance, on ne récupère pas son compte bancaire par email. On passe en agence avec preuve d'identité.

SelfRecover applique la même logique en ligne : la sécurité réelle nécessite parfois un passage par l'humain ou un processus d'identification rigoureux. Cette friction est assumée comme un trade-off conscient, pas comme une limitation à compenser.

Pour quel public

Adapté :
- Applications avec un administrateur actif et disponible pour traiter les litiges (forum communautaire, association, e-commerce indépendant, boutique en ligne militante)
- Sites où la sécurité prime sur la fluidité de récupération (services manipulant des données sensibles)
- Communautés à taille humaine (du forum de 50 membres au service de quelques milliers d'utilisateurs)

Non adapté :
- Plateformes à très grande échelle sans admin individuel (réseaux sociaux massifs, services publics avec millions d'utilisateurs) — le volume de litiges dépasse les capacités d'un humain réactif
- Services où une friction de récupération est inacceptable (gaming compétitif, services temps-réel)
- Projets sans maintenance active (l'admin doit pouvoir répondre aux litiges dans des délais raisonnables)

Pour ces cas, un IAM mature comme Keycloak avec ses mécanismes éprouvés reste plus adapté.

Modèle de menace assumé

Pour la transparence, voici les classes d'adversaires explicitement hors périmètre du protocole :

  • Compromission du poste utilisateur (logiciels malveillants, RAT, keyloggers) — un attaquant qui contrôle le poste peut capturer la passphrase à la saisie, indépendamment du protocole.
  • Compromission du navigateur (extensions malveillantes, exploits 0-day) — même cause, même effet : si le moteur JS qui calcule HMAC est compromis, la sortie l'est aussi.
  • Coercition physique — SelfRecover n'offre pas de plausible deniability (pas de second compte caché ou décoy).
  • Cryptanalyse théorique de SHA-256 / HMAC / Argon2id — un cassage mathématique de ces primitives mettrait à mal la quasi-totalité des systèmes cryptographiques modernes, pas seulement SelfRecover.

Ces limitations sont le périmètre normal d'un protocole côté navigateur. Pour les usages à plus haute exigence (cérémonies cryptographiques sensibles, génération initiale de clé maître), MySelf-Live est annoncé dans la roadmap V0.2 : une distribution Linux Live USB minimale, RAM-only, signée GPG, qui isolerait les opérations sensibles du système hôte. Pour les usages courants à fort enjeu, Tails ou Qubes OS offrent déjà ce niveau d'isolation et sont recommandés.

Démos en ligne

Aucune inscription préalable n'est requise. Les données sont éphémères côté serveur.

Code et image Docker

docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1

La démo de référence tourne sur PHP 8.0+ et SQLite (~600 lignes auditables, zéro dépendance externe). Tag GPG-signé v0.1.1, release datée du 5 mai 2026.

Licence et philosophie

AGPL-3.0-or-later. Toute version déployée publiquement doit publier ses modifications sous la même licence. Pas de capture SaaS possible.

SelfRecover est une brique du méta-projet MySelf, un écosystème de modules auto-hébergés qui couvre l'identité, la modération communautaire, le droit, et l'agriculture.

Un module complémentaire répond de manière directe à la problématique illustrée par l'incident ANTS : SelfDataGuard chiffre les données utilisateur côté client de telle sorte qu'une fuite de base de données ne livre que des blobs inexploitables. Le code est public, AGPL, en v0.1.0-beta — une dépêche dédiée pourra suivre quand le module aura plus de maturité (audit communautaire, retours d'intégration).

Note de transparence

Conception en partenariat avec un assistant IA

Ce protocole a été conçu et codé en partenariat avec un assistant IA (Claude), comme outil de réflexion, de revue critique, et d'écriture de code.

Pour être totalement transparent : je ne suis pas développeur de formation. Mon expérience technique vient du dev web amateur (ARC PVE Hub, un site destiné à fédérer une communauté de joueurs ; un outil de gestion de stock pour mon entreprise ; quelques sites perso). Pour SelfRecover, l'écriture des primitives cryptographiques et la mise en œuvre du protocole ont été largement assistées par l'IA, sur la base de mes choix architecturaux et de ma vision.

Ce qui vient de moi (humain) :
- La vision (souveraineté numérique, refus du SMTP comme canal de récupération)
- Les choix philosophiques (AGPL-3.0-or-later, fallback humain assumé, aucune destruction de données sans validation humaine consciente)
- Le contexte initial (besoin né en développant ARC PVE Hub)
- Chaque décision de trade-off d'architecture
- La responsabilité juridique et morale du code publié sous mon nom et signé GPG

Ce qui vient de l'IA :
- L'écriture des primitives cryptographiques (HMAC, dérivations, vérifications)
- L'agencement du code, la structure des fichiers
- La formalisation des paragraphes du whitepaper et de cette dépêche
- La génération de tests unitaires
- La vérification de cohérence interne

Plan d'audit

  • Auto-audit interne : en cours et continu (chaque modification est relue critiquement)
  • Audit communautaire : ouvert dès maintenant, je réponds aux remarques techniques avec sérieux (cette dépêche en est l'illustration directe)
  • Audit tiers certifié : envisagé à moyen terme via un cabinet agréé CESTI ANSSI (Synacktiv, Quarkslab, Wavestone, ou équivalent), sous réserve de financement

Statut du projet

SelfRecover en est à la version 0.1.1, taguée GPG et signée. C'est un état PoC fonctionnel + déployé en production sur un site réel (ARC PVE Hub), mais pas encore mature pour une adoption massive dans des contextes à fort enjeu. La roadmap V0.2 (MySelf-Live, finalisation du chatbot L3, audit tiers) précisera ce périmètre.

Engagement communauté LinuxFr et culture du libre

Mon compte LinuxFr est récent, mais mon ancrage dans la culture du libre ne l'est pas : utilisateur exclusif de distributions Linux depuis quinze ans (principalement Debian), j'ai aidé plusieurs proches à migrer des PC anciens vers Debian pour leur donner une seconde vie au lieu de la déchèterie. J'arrive sur LinuxFr depuis le monde agricole/permaculture et le jeu vidéo (ARC PVE Hub), pas du milieu dev historique.

Je suis salarié couvreur dans une PME et installé en agriculture à temps partiel — mon temps libre pour le développement et la participation communautaire est compté. Je m'engage à répondre aux retours techniques sur cette dépêche et à suivre les disputes sur l'état du projet. Pour le reste (commentaires réguliers, dépêches futures sur d'autres modules MySelf — en particulier SelfDataGuard quand il sera plus mature), ce sera au gré du temps disponible, sans promesse.

Toute critique technique constructive est bienvenue. Pour les critiques sur la légitimité du projet ou la nature humain/IA de la collaboration, j'invite à juger sur les choix concrets, le code public, et la qualité des réponses à vos questions.

Pour aller plus loin

SelfRecover est un module de l'écosystème MySelf, expérimentation citoyenne sur la souveraineté numérique sous licence AGPL-3.0-or-later.

Les retours techniques, audits communautaires, propositions d'intégration et questions de fond sont les bienvenus — en commentaire de cette dépêche ou en issue sur le repo GitHub.

Si une administration ou une organisation souhaite tester le protocole en environnement isolé, l'image Docker et le Dockerfile sont à disposition. Aucune démarche commerciale n'est associée à cette publication.

Merci aux modérateurs et contributeurs de LinuxFr — Pierre Jarillon, devnewton, Florent Zara, bobble bubble — dont les retours pendant la phase de rédaction ont substantiellement amélioré cette dépêche.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
❌