De l'intérêt d'être INdépendant

L’équipe Rust a signalé jeudi une attaque visant un crate très populaire, arrayref. Elle a permis, pendant un peu plus d’une heure, de distribuer des composants vérolés vraisemblablement destinés à la récupération de mots de passe sur les machines des utilisateurs finaux. L’incident, rapidement contenu, s’inscrit dans une longue liste d’attaques visant la chaîne d’approvisionnement.

L’équipe en charge de la maintenance du langage Rust et de ses composants a alerté jeudi 20 août d’une attaque visant arrayref, un crate (l’unité de compilation de base, qui se présente soit sous forme de binaires, soit comme une bibliothèque) très courant.

Pour ce faire, les auteurs ont réussi à publier sur crates.io, le registre de paquets Rust, un composant baptisé proc-macro1. Il contenait un build script (code qui s’exécute à la compilation) ayant pour objet de déclencher le téléchargement d’une charge malveillante de type infostealer (vol de données).

Une charge calculée pour extraire des données

Pour favoriser la diffusion de leur attaque (dont le nom est une forme de typosquatting d’un autre crate légitime, proc-macro2), les attaquants ont réussi à modifier le crate arrayref pour que leur charge soit appelée lors de l’utilisation de ce dernier. Ils ont également piégé de la même façon d’autres composants courants (internment, append-only-vec).

D’après l’équipe Rust, la fenêtre de diffusion s’est heureusement révélée limitée, suite à une alerte rapidement formulée par les chercheurs de Nextron Systems. Elle estime ainsi que les composants vérolés sont restés en ligne entre 90 et 107 minutes : un laps de temps trop court pour permettre une propagation à grande échelle, mais tout de même suffisamment long pour que des développeurs aient pu être touchés.

« Nous vous recommandons de vérifier vos dépendances locales pour vous assurer que ces crates n’ont pas été téléchargées », déclare ainsi l’équipe Rust, qui invite à vérifier le contenu du dossier ~/.cargo/registry/cache pour y débusquer les éventuelles versions vérolées.

Deux chercheurs de l’entreprise de cybersécurité Wiz (passée aux mains de Google en mars 2026) ont détaillé le contenu exact de la charge malveillante. Lancée donc dès la compilation, elle a vocation à reconstruire une URL de destination pour l’envoi de données volées, désactiver la validation d’un certificat TLS et ainsi autoriser le contrôle et commande à distance (C2).

Elle télécharge ensuite un composant spécifique à l’OS et à l’architecture de la machine et lance ce dernier, qui commence ensuite à extraire des informations, en s’intéressant notamment aux identifiants stockés au niveau du navigateur. Il s’installe par ailleurs de façon persistante, soit via le registre Windows, soit au moyen de LaunchAgent (macOS) ou systemd (Linux).

Le compte d’un mainteneur compromis

Les attaquants n’ont probablement pas choisi leur cible au hasard. Le crate arrayref compte en effet la bagatelle de 245 millions de téléchargements, et il est utilisé comme dépendance dans 400 autres crates populaires, utilisés notamment sur les chaînes de blocs Ethereum et Solana, associées à des cryptomonnaies bien connues.

La subtilité ici réside dans le fait que le crate arrayref ne comportait en tant que tel aucun code malveillant, notent les chercheurs de Step Security : c’est simplement son fichier de dépendances qui était modifié.

La version corrompue, arrayref@0.3.10, semble avoir été publiée depuis le compte d’un mainteneur Rust historique, et non des moindres puisqu’il s’agirait de l’auteur du crate initial, initialement publié il y a 15 ans. « Nous ne pensons pas que l’auteur d’arrayref agisse de manière malveillante, mais son ordinateur ou ses identifiants sont probablement compromis, et nous essayons de le contacter », indique l’équipe Rust.

Dans la foulée de la publication, les attaquants ont yanké (retiré) les versions 0.3.5 à 0.3.9 du crate arrayref pour que les développeurs soient enclins à lancer cargo update, la commande de mise à jour censée précisément les protéger lorsque leur environnement exploite une version obsolète (et donc potentiellement vulnérable) d’un composant.

L’attaque a donné lieu à la publication, vendredi, d’une CVE (2026 - 77651) qualifiée de critique avec un score de 9,8.

Pour Wiz, le mode opératoire et une adresse IP détectée par l’une des victimes de l’attaque rappellent directement de précédentes attaques sur la chaîne d’approvisionnement (supply chain) telles que celles menées ces derniers mois contre Trivy, Axios et npm.

De l'intérêt d'être INdépendant

L’équipe Rust a signalé jeudi une attaque visant un crate très populaire, arrayref. Elle a permis, pendant un peu plus d’une heure, de distribuer des composants vérolés vraisemblablement destinés à la récupération de mots de passe sur les machines des utilisateurs finaux. L’incident, rapidement contenu, s’inscrit dans une longue liste d’attaques visant la chaîne d’approvisionnement.

L’équipe en charge de la maintenance du langage Rust et de ses composants a alerté jeudi 20 août d’une attaque visant arrayref, un crate (l’unité de compilation de base, qui se présente soit sous forme de binaires, soit comme une bibliothèque) très courant.

Pour ce faire, les auteurs ont réussi à publier sur crates.io, le registre de paquets Rust, un composant baptisé proc-macro1. Il contenait un build script (code qui s’exécute à la compilation) ayant pour objet de déclencher le téléchargement d’une charge malveillante de type infostealer (vol de données).

Une charge calculée pour extraire des données

Pour favoriser la diffusion de leur attaque (dont le nom est une forme de typosquatting d’un autre crate légitime, proc-macro2), les attaquants ont réussi à modifier le crate arrayref pour que leur charge soit appelée lors de l’utilisation de ce dernier. Ils ont également piégé de la même façon d’autres composants courants (internment, append-only-vec).

D’après l’équipe Rust, la fenêtre de diffusion s’est heureusement révélée limitée, suite à une alerte rapidement formulée par les chercheurs de Nextron Systems. Elle estime ainsi que les composants vérolés sont restés en ligne entre 90 et 107 minutes : un laps de temps trop court pour permettre une propagation à grande échelle, mais tout de même suffisamment long pour que des développeurs aient pu être touchés.

« Nous vous recommandons de vérifier vos dépendances locales pour vous assurer que ces crates n’ont pas été téléchargées », déclare ainsi l’équipe Rust, qui invite à vérifier le contenu du dossier ~/.cargo/registry/cache pour y débusquer les éventuelles versions vérolées.

Deux chercheurs de l’entreprise de cybersécurité Wiz (passée aux mains de Google en mars 2026) ont détaillé le contenu exact de la charge malveillante. Lancée donc dès la compilation, elle a vocation à reconstruire une URL de destination pour l’envoi de données volées, désactiver la validation d’un certificat TLS et ainsi autoriser le contrôle et commande à distance (C2).

Elle télécharge ensuite un composant spécifique à l’OS et à l’architecture de la machine et lance ce dernier, qui commence ensuite à extraire des informations, en s’intéressant notamment aux identifiants stockés au niveau du navigateur. Il s’installe par ailleurs de façon persistante, soit via le registre Windows, soit au moyen de LaunchAgent (macOS) ou systemd (Linux).

Le compte d’un mainteneur compromis

Les attaquants n’ont probablement pas choisi leur cible au hasard. Le crate arrayref compte en effet la bagatelle de 245 millions de téléchargements, et il est utilisé comme dépendance dans 400 autres crates populaires, utilisés notamment sur les chaînes de blocs Ethereum et Solana, associées à des cryptomonnaies bien connues.

La subtilité ici réside dans le fait que le crate arrayref ne comportait en tant que tel aucun code malveillant, notent les chercheurs de Step Security : c’est simplement son fichier de dépendances qui était modifié.

La version corrompue, arrayref@0.3.10, semble avoir été publiée depuis le compte d’un mainteneur Rust historique, et non des moindres puisqu’il s’agirait de l’auteur du crate initial, initialement publié il y a 15 ans. « Nous ne pensons pas que l’auteur d’arrayref agisse de manière malveillante, mais son ordinateur ou ses identifiants sont probablement compromis, et nous essayons de le contacter », indique l’équipe Rust.

Dans la foulée de la publication, les attaquants ont yanké (retiré) les versions 0.3.5 à 0.3.9 du crate arrayref pour que les développeurs soient enclins à lancer cargo update, la commande de mise à jour censée précisément les protéger lorsque leur environnement exploite une version obsolète (et donc potentiellement vulnérable) d’un composant.

L’attaque a donné lieu à la publication, vendredi, d’une CVE (2026 - 77651) qualifiée de critique avec un score de 9,8.

Pour Wiz, le mode opératoire et une adresse IP détectée par l’une des victimes de l’attaque rappellent directement de précédentes attaques sur la chaîne d’approvisionnement (supply chain) telles que celles menées ces derniers mois contre Trivy, Axios et npm.

Too fast too furious

GitHub a été victime lundi d’une panne globale qui a entraîné une interruption de service de plus de 7 heures. Dans son post-mortem, la plateforme invoque une nouvelle fois un problème de capacité, dû à l’explosion du volume de requêtes découlant des pratiques liées à l’IA générative. Et promet, encore, qu’on ne l’y reprendra plus.

La panne du 17 août a finalement duré 7 heures et 47 minutes, d’après le décompte officiel. « Si vous avez essayé de livrer du code ce jour-là, on vous a laissé tomber », admet Vlad Fedorov, directeur technique de GitHub, dans un billet de blog en forme de post-mortem. L’incident, largement relayé sur les réseaux sociaux, a en effet touché la quasi-totalité des services de la plateforme, qu’il s’agisse de l’authentification, du site Web proprement dit, de l’accès aux dépôts, des pull requests ou des fonctions d’IA générative Copilot.

Le mea culpa se justifie d’autant plus que cet incident n’est pas isolé. Comme le rappelle Fedorov, GitHub a déjà été victime d’une panne de grande ampleur le 6 août dernier. Les premiers mois de l’année ont eux aussi été marqués par une série de dysfonctionnements ponctuels ou de ralentissements. Elle avait conduit l’entreprise, propriété de Microsoft, à présenter ses excuses aux développeurs en avril dernier.

Un pic de trafic le 17 août

Que s’est-il précisément passé lundi ? GitHub indique que la panne n’est due ni à une faille de sécurité, ni à une erreur manuelle. D’après Fedorov, elle découle purement et simplement d’un pic de trafic que les infrastructures en place n’ont pas été capables d’absorber correctement. « La pression sur la capacité qui en a résulté s’est propagée à l’ensemble de nos systèmes, provoquant des échecs d’authentification et perturbant plusieurs services GitHub », décrit l’intéressé.

C’est au niveau d’un composant critique, hébergé dans le datacenter Central US, que la congestion est intervenue, comme le révèle le rapport d’incident associé :

« À l’origine, ce problème était dû à un pod sidecar Istio ayant atteint ses limites de concurrence et ne parvenant pas à une mise à l’échelle automatique correcte en raison d’une politique mal configurée qui surveillait le service hôte mais pas les limites du sidecar. Cette défaillance s’est propagée en cascade, et finalement quatre nœuds HAProxy ont atteint leurs limites de flux, dégradant le chemin d’authentification de la passerelle et provoquant une latence et des échecs d’authentification généralisés. »

En réponse, les équipes techniques ont mis en place des routes parallèles, isolé l’infrastructure concernée, suspendu HAProxy sur les nœuds concernés et lancé la restauration des différents services tombés, mais le plan de continuité ne s’est pas déroulé tout à fait comme prévu. « Des erreurs dans ces services ont déclenché une boucle de nouvelles tentatives côté client, ce qui a augmenté le trafic pendant la récupération. Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité », explique le CTO.

Le service Copilot est quant à lui resté interrompu plusieurs heures supplémentaires, en raison d’un autre problème inédit :

« Une partie du trafic défaillant a été redirigée du centre des États-Unis vers le nord de la Virginie, où elle a été acheminée avec succès jusqu’à ce que la panne réseau dans le centre des États-Unis soit identifiée et résolue. Des réponses tardives à un point de terminaison interne ont déclenché un bug latent de nouvelle tentative dans VS Code, amplifiant le trafic d’environ 10 fois et provoquant un retard de rétablissement pour le service de tokens Copilot. »

Le volume de commits a doublé depuis avril

Comment GitHub a-t-il pu subir un pareil incident, alors que le service assurait en avril prendre toutes les mesures nécessaires pour dimensionner correctement son infrastructure ? Les efforts mis en œuvre semblent ne pas avoir suffi à absorber l’augmentation continue du nombre de requêtes, dont le volume aurait plus que doublé entre avril et août, passant de 1,4 milliard à 2,9 milliards de commits par mois.

GitHub affirme avoir été limité par la capacité électrique de ses propres infrastructures. « Depuis, nous avons ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage haute vitesse et une capacité réseau considérable. Nous avons installé autant de matériel que la puissance disponible le permettait dans nos centres de données existants, tout en accélérant notre migration vers Azure », écrit Vlad Fedorov.

A priori conscient de ses propres carences, GitHub avait annoncé en octobre 2025 son intention de migrer progressivement ses services vers Azure, l’infrastructure cloud globale de Microsoft. Le mouvement semble s’être considérablement accéléré depuis avril : « Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme GitHub et la moitié des opérations Git, contre 12 % en mai », affirme le CTO.

Problème : en matière de ressources disponibles sur Azure, GitHub entre en concurrence avec le reste des services Microsoft, et surtout avec l’offre commerciale cloud de l’éditeur. À tel point que GitHub envisagerait désormais une stratégie multi-cloud, qui conduirait à aller louer de l’infrastructure chez le grand rival, Amazon Web Services (AWS).

En attendant, GitHub temporise, et affirme avoir mis en place plusieurs optimisations pour réduire les risques de défaillance. Entre autres actions de suivi, la plateforme s’engage ainsi à corriger ses politiques de mise à l’échelle automatique, à renforcer les limites de nouvelle tentative (pour éviter l’effet boule de neige qui sature l’infra en cas de défaillance), à corriger les problèmes de VS Code et à surveiller plus efficacement tous les mécanismes d’équilibre de charge et de bascule. Ses difficultés favoriseront peut-être l’essor d’Origin, la nouvelle forge logicielle (calquée sur GitHub) tout juste lancée par Cursor après son rachat par SpaceX.

Too fast too furious

GitHub a été victime lundi d’une panne globale qui a entraîné une interruption de service de plus de 7 heures. Dans son post-mortem, la plateforme invoque une nouvelle fois un problème de capacité, dû à l’explosion du volume de requêtes découlant des pratiques liées à l’IA générative. Et promet, encore, qu’on ne l’y reprendra plus.

La panne du 17 août a finalement duré 7 heures et 47 minutes, d’après le décompte officiel. « Si vous avez essayé de livrer du code ce jour-là, on vous a laissé tomber », admet Vlad Fedorov, directeur technique de GitHub, dans un billet de blog en forme de post-mortem. L’incident, largement relayé sur les réseaux sociaux, a en effet touché la quasi-totalité des services de la plateforme, qu’il s’agisse de l’authentification, du site Web proprement dit, de l’accès aux dépôts, des pull requests ou des fonctions d’IA générative Copilot.

Le mea culpa se justifie d’autant plus que cet incident n’est pas isolé. Comme le rappelle Fedorov, GitHub a déjà été victime d’une panne de grande ampleur le 6 août dernier. Les premiers mois de l’année ont eux aussi été marqués par une série de dysfonctionnements ponctuels ou de ralentissements. Elle avait conduit l’entreprise, propriété de Microsoft, à présenter ses excuses aux développeurs en avril dernier.

Un pic de trafic le 17 août

Que s’est-il précisément passé lundi ? GitHub indique que la panne n’est due ni à une faille de sécurité, ni à une erreur manuelle. D’après Fedorov, elle découle purement et simplement d’un pic de trafic que les infrastructures en place n’ont pas été capables d’absorber correctement. « La pression sur la capacité qui en a résulté s’est propagée à l’ensemble de nos systèmes, provoquant des échecs d’authentification et perturbant plusieurs services GitHub », décrit l’intéressé.

C’est au niveau d’un composant critique, hébergé dans le datacenter Central US, que la congestion est intervenue, comme le révèle le rapport d’incident associé :

« À l’origine, ce problème était dû à un pod sidecar Istio ayant atteint ses limites de concurrence et ne parvenant pas à une mise à l’échelle automatique correcte en raison d’une politique mal configurée qui surveillait le service hôte mais pas les limites du sidecar. Cette défaillance s’est propagée en cascade, et finalement quatre nœuds HAProxy ont atteint leurs limites de flux, dégradant le chemin d’authentification de la passerelle et provoquant une latence et des échecs d’authentification généralisés. »

En réponse, les équipes techniques ont mis en place des routes parallèles, isolé l’infrastructure concernée, suspendu HAProxy sur les nœuds concernés et lancé la restauration des différents services tombés, mais le plan de continuité ne s’est pas déroulé tout à fait comme prévu. « Des erreurs dans ces services ont déclenché une boucle de nouvelles tentatives côté client, ce qui a augmenté le trafic pendant la récupération. Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité », explique le CTO.

Le service Copilot est quant à lui resté interrompu plusieurs heures supplémentaires, en raison d’un autre problème inédit :

« Une partie du trafic défaillant a été redirigée du centre des États-Unis vers le nord de la Virginie, où elle a été acheminée avec succès jusqu’à ce que la panne réseau dans le centre des États-Unis soit identifiée et résolue. Des réponses tardives à un point de terminaison interne ont déclenché un bug latent de nouvelle tentative dans VS Code, amplifiant le trafic d’environ 10 fois et provoquant un retard de rétablissement pour le service de tokens Copilot. »

Le volume de commits a doublé depuis avril

Comment GitHub a-t-il pu subir un pareil incident, alors que le service assurait en avril prendre toutes les mesures nécessaires pour dimensionner correctement son infrastructure ? Les efforts mis en œuvre semblent ne pas avoir suffi à absorber l’augmentation continue du nombre de requêtes, dont le volume aurait plus que doublé entre avril et août, passant de 1,4 milliard à 2,9 milliards de commits par mois.

GitHub affirme avoir été limité par la capacité électrique de ses propres infrastructures. « Depuis, nous avons ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage haute vitesse et une capacité réseau considérable. Nous avons installé autant de matériel que la puissance disponible le permettait dans nos centres de données existants, tout en accélérant notre migration vers Azure », écrit Vlad Fedorov.

A priori conscient de ses propres carences, GitHub avait annoncé en octobre 2025 son intention de migrer progressivement ses services vers Azure, l’infrastructure cloud globale de Microsoft. Le mouvement semble s’être considérablement accéléré depuis avril : « Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme GitHub et la moitié des opérations Git, contre 12 % en mai », affirme le CTO.

Problème : en matière de ressources disponibles sur Azure, GitHub entre en concurrence avec le reste des services Microsoft, et surtout avec l’offre commerciale cloud de l’éditeur. À tel point que GitHub envisagerait désormais une stratégie multi-cloud, qui conduirait à aller louer de l’infrastructure chez le grand rival, Amazon Web Services (AWS).

En attendant, GitHub temporise, et affirme avoir mis en place plusieurs optimisations pour réduire les risques de défaillance. Entre autres actions de suivi, la plateforme s’engage ainsi à corriger ses politiques de mise à l’échelle automatique, à renforcer les limites de nouvelle tentative (pour éviter l’effet boule de neige qui sature l’infra en cas de défaillance), à corriger les problèmes de VS Code et à surveiller plus efficacement tous les mécanismes d’équilibre de charge et de bascule. Ses difficultés favoriseront peut-être l’essor d’Origin, la nouvelle forge logicielle (calquée sur GitHub) tout juste lancée par Cursor après son rachat par SpaceX.

Aie confiance, crois en moi, que je puisse veiller sur toi

OpenAI lance un plugin qui permet à l’application ChatGPT sur macOS d’interagir directement avec les messages (iMessage, SMS) de l’utilisateur. Une intégration censée faciliter la vie de l’utilisateur, mais qui ne va pas sans poser de sérieuses questions quant à la confidentialité des données associées.

« Vos conversations de tous les jours viennent de gagner en simplicité grâce au nouveau plugin Apple Messages », annonce fièrement OpenAI. L’entreprise vient en effet d’annoncer la mise en ligne d’un nouveau composant optionnel, dédié aux versions macOS de ses clients logiciels, qui permet aux utilisateurs de ChatGPT de bénéficier d’une intégration renforcée avec l’application Messages du système, celle qui permet de gérer les messages texte (iMessage, SMS, RCS) envoyés par le truchement de l’iPhone de l’utilisateur.

Un accès complet aux messages (et au disque)

Dans une vidéo relayée sur X, OpenAI illustre l’utilité supposée de ce plugin : par exemple, demander à ChatGPT de retrouver les questions laissées en suspens dans les messages reçus la veille, puis rédiger, ou faire rédiger, directement la réponse depuis l’interface d’échange avec le LLM. Les fonctionnalités décrites illustrent la capacité du modèle à lire les messages envoyés ou reçus par l’utilisateur, pour en extraire des informations, générer une synthèse, ou préparer des réponses.

Sur son site, OpenAI précise le fonctionnement de ce nouveau plugin, et notamment la façon dont l’utilisateur garde le contrôle sur les messages envoyés, du moins s’il ne donne pas carte blanche à l’outil :

« Par défaut, ChatGPT n’envoie les messages qu’après votre approbation du message et de ses destinataires. Choisissez « Autoriser une seule fois » pour approuver uniquement cet envoi. Si vous sélectionnez « Toujours autoriser l’envoi vers cette conversation », ChatGPT pourra envoyer des messages ultérieurs à cette conversation sans nouvelle approbation. »

OpenAI annonce une disponibilité globale de ce plugin, ce que nous avons pu vérifier depuis une machine française, sur un compte ChatGPT gratuit. En passant par l’application et en sélectionnant le mode Codex, une recherche dans les plugins affiche bien l’intégration Messages. Son installation exige trois niveaux de permission : l’autorisation d’envoyer des messages, l’accès aux contacts, et l’accès total au disque (Full Disk Access), puisque le client doit pouvoir lire les messages archivés.

Dans sa doc, OpenAI ne dit rien en revanche des problèmes de confidentialité, ou de respect de la vie privée, soulevés par une telle intégration. L’entreprise a tout de même répondu à Bloomberg que son plugin ne créait pas d’index en propre des messages stockés sur la machine mais, dans les faits, on ne sait pas à ce stade quels sont les traitements exacts réalisés sur les Messages lors d’une requête, et dans quelle mesure le contenu de ces derniers transite par les serveurs d’OpenAI.

L’accès aux messages n’est pas anodin, puisqu’ils sont susceptibles de contenir des informations personnelles sensibles, qui impliquent l’utilisateur au premier chef, mais aussi l’ensemble des personnes avec lesquelles il correspond ou a correspondu.

Comptant sur l’impartialité d’un modèle par essence probabiliste, nous avons demandé à ChatGPT de résumer de façon concise les risques soulevés par une telle intégration. La capture d’écran ci-dessous illustre la réponse formulée par le modèle :

Un plugin concurrent de l’intégration ChatGPT dans Apple Intelligence

Reste à savoir ce qu’en pense Apple ? La firme de Cupertino ne s’est pas, pour l’instant, exprimée au sujet de cette nouveauté, qui vient pourtant marcher sur les platebandes d’une intégration plus officielle cette fois, celle qui permet d’utiliser ChatGPT avec Apple Intelligence et Siri sur l’iPhone, avec un volet confidentialité encadré par Apple.

Ce lancement intervient quelques jours seulement après l’introduction d’une autre fonctionnalité dédiée à macOS, « Computer History », qui permet à ChatGPT (dont l’application macOS a déjà été épinglée pour avoir stocké des informations en clair) de s’appuyer sur toutes les actions de l’utilisateur pour lui rappeler ce qu’il a fait sur son ordinateur. Fonctionnant littéralement comme un keylogger, celle-ci « génère un flux d’événements d’interaction à partir des applications et des sites web autorisés » en s’appuyant notamment sur « les clics, la saisie au clavier, les raccourcis clavier, les changements d’application et le contexte que macOS met à disposition via son système d’accessibilité ».

Apple accuse pour mémoire OpenAI de malversations et de vol de secrets industriels, ce qui donne lieu depuis le mois de juillet à un bras de fer judiciaire entre les deux entreprises.

Aie confiance, crois en moi, que je puisse veiller sur toi

OpenAI lance un plugin qui permet à l’application ChatGPT sur macOS d’interagir directement avec les messages (iMessage, SMS) de l’utilisateur. Une intégration censée faciliter la vie de l’utilisateur, mais qui ne va pas sans poser de sérieuses questions quant à la confidentialité des données associées.

« Vos conversations de tous les jours viennent de gagner en simplicité grâce au nouveau plugin Apple Messages », annonce fièrement OpenAI. L’entreprise vient en effet d’annoncer la mise en ligne d’un nouveau composant optionnel, dédié aux versions macOS de ses clients logiciels, qui permet aux utilisateurs de ChatGPT de bénéficier d’une intégration renforcée avec l’application Messages du système, celle qui permet de gérer les messages texte (iMessage, SMS, RCS) envoyés par le truchement de l’iPhone de l’utilisateur.

Un accès complet aux messages (et au disque)

Dans une vidéo relayée sur X, OpenAI illustre l’utilité supposée de ce plugin : par exemple, demander à ChatGPT de retrouver les questions laissées en suspens dans les messages reçus la veille, puis rédiger, ou faire rédiger, directement la réponse depuis l’interface d’échange avec le LLM. Les fonctionnalités décrites illustrent la capacité du modèle à lire les messages envoyés ou reçus par l’utilisateur, pour en extraire des informations, générer une synthèse, ou préparer des réponses.

Sur son site, OpenAI précise le fonctionnement de ce nouveau plugin, et notamment la façon dont l’utilisateur garde le contrôle sur les messages envoyés, du moins s’il ne donne pas carte blanche à l’outil :

« Par défaut, ChatGPT n’envoie les messages qu’après votre approbation du message et de ses destinataires. Choisissez « Autoriser une seule fois » pour approuver uniquement cet envoi. Si vous sélectionnez « Toujours autoriser l’envoi vers cette conversation », ChatGPT pourra envoyer des messages ultérieurs à cette conversation sans nouvelle approbation. »

OpenAI annonce une disponibilité globale de ce plugin, ce que nous avons pu vérifier depuis une machine française, sur un compte ChatGPT gratuit. En passant par l’application et en sélectionnant le mode Codex, une recherche dans les plugins affiche bien l’intégration Messages. Son installation exige trois niveaux de permission : l’autorisation d’envoyer des messages, l’accès aux contacts, et l’accès total au disque (Full Disk Access), puisque le client doit pouvoir lire les messages archivés.

Dans sa doc, OpenAI ne dit rien en revanche des problèmes de confidentialité, ou de respect de la vie privée, soulevés par une telle intégration. L’entreprise a tout de même répondu à Bloomberg que son plugin ne créait pas d’index en propre des messages stockés sur la machine mais, dans les faits, on ne sait pas à ce stade quels sont les traitements exacts réalisés sur les Messages lors d’une requête, et dans quelle mesure le contenu de ces derniers transite par les serveurs d’OpenAI.

L’accès aux messages n’est pas anodin, puisqu’ils sont susceptibles de contenir des informations personnelles sensibles, qui impliquent l’utilisateur au premier chef, mais aussi l’ensemble des personnes avec lesquelles il correspond ou a correspondu.

Comptant sur l’impartialité d’un modèle par essence probabiliste, nous avons demandé à ChatGPT de résumer de façon concise les risques soulevés par une telle intégration. La capture d’écran ci-dessous illustre la réponse formulée par le modèle :

Un plugin concurrent de l’intégration ChatGPT dans Apple Intelligence

Reste à savoir ce qu’en pense Apple ? La firme de Cupertino ne s’est pas, pour l’instant, exprimée au sujet de cette nouveauté, qui vient pourtant marcher sur les platebandes d’une intégration plus officielle cette fois, celle qui permet d’utiliser ChatGPT avec Apple Intelligence et Siri sur l’iPhone, avec un volet confidentialité encadré par Apple.

Ce lancement intervient quelques jours seulement après l’introduction d’une autre fonctionnalité dédiée à macOS, « Computer History », qui permet à ChatGPT (dont l’application macOS a déjà été épinglée pour avoir stocké des informations en clair) de s’appuyer sur toutes les actions de l’utilisateur pour lui rappeler ce qu’il a fait sur son ordinateur. Fonctionnant littéralement comme un keylogger, celle-ci « génère un flux d’événements d’interaction à partir des applications et des sites web autorisés » en s’appuyant notamment sur « les clics, la saisie au clavier, les raccourcis clavier, les changements d’application et le contexte que macOS met à disposition via son système d’accessibilité ».

Apple accuse pour mémoire OpenAI de malversations et de vol de secrets industriels, ce qui donne lieu depuis le mois de juillet à un bras de fer judiciaire entre les deux entreprises.