Perplexity Hybrid Compute et sa barrière de confidentialité, expliqués

Le 1er septembre 2026, Perplexity a lancé une fonction appelée Hybrid Compute sur Mac. L'idée en bref : une même tâche est répartie entre deux endroits. Les étapes lourdes (recherche web, planification, raisonnement à long horizon) s'exécutent sur des modèles de pointe dans le cloud. Les étapes qui touchent vos données sensibles sont confiées à un petit modèle qui tourne sur votre propre machine, et ces données ne quittent jamais l'appareil.

En apparence, c'est une nouvelle produit pour les utilisateurs de Mac. Mais ce qui mérite l'attention d'un chef d'entreprise, ce n'est pas le produit : c'est le schéma d'architecture qui le sous-tend, à savoir classer les données avant leur envoi, et non après leur arrivée. Et ce schéma, vous pouvez l'appliquer dans vos propres systèmes, indépendamment de Perplexity et indépendamment des Mac.

Ce qui a réellement été annoncé

Avant toute analyse, il vaut la peine de séparer ce qui a été annoncé de ce qui relève de l'interprétation :

• Date : 1er septembre 2026.
• Fonctionnement : chaque tâche commence dans le cloud, puis confie les étapes sensibles à un modèle local en cours de route, sans perdre le contexte.
• La barrière de confidentialité : un classifieur installé sur l'appareil lit chaque tâche avant son envoi, remplace les noms, les adresses et les numéros de compte par des substituts, puis les restitue au retour de la réponse.
• Configuration requise : un Mac équipé d'une puce Apple, macOS 15 ou ultérieur, et au minimum 24 Go de mémoire unifiée, avec 32 Go recommandés.
• Abonnement : disponible pour les abonnés Pro et Max ainsi que pour les clients entreprise.
• Coût : le travail traité par le modèle local ne consomme aucun crédit cloud.
• Modèles locaux : plusieurs options au lancement, dont Gemma 4 E4B de Google, Qwen3.6 35B-A3B d'Alibaba et un modèle entraîné par Perplexity elle-même.

Ce qui n'a pas été annoncé, et qu'il ne faut pas supposer, c'est un quelconque engagement contractuel de conformité à la loi saoudienne sur la protection des données personnelles (PDPL), ou un audit indépendant certifiant les performances de la barrière. Ce qui a été annoncé, c'est un mécanisme technique et des chiffres de performance que l'entreprise a publiés sur elle-même.

Pourquoi c'est différent de l'« IA locale » dont vous avez déjà entendu parler

Le cadrage habituel était binaire : soit tout envoyer dans le cloud et obtenir un modèle puissant, soit faire tourner un petit modèle en local et accepter une qualité moindre en échange de la confidentialité. En pratique, dans la plupart des organisations, la confidentialité a perdu ce débat, parce que les équipes ont besoin de réponses de qualité pour faire leur travail.

Ce que fait cette architecture, c'est refuser ce choix binaire. Une même tâche s'exécute aux deux endroits : le raisonnement a lieu dans le cloud, et l'étape qui touche les données a lieu sur l'appareil. Plus important encore, la décision n'est ni manuelle ni laissée à la vigilance d'un employé : elle est prise par un classifieur automatique qui lit le texte avant qu'il ne parte.

Et voici le détail qui mérite qu'on s'y arrête : Perplexity a publié les chiffres de performance de ce classifieur avec une franchise inhabituelle, faiblesses comprises. L'entreprise a indiqué que le rappel baisse nettement dès que le texte dépasse environ dix mille caractères, et qu'elle a corrigé ce point par une technique de décodage plutôt qu'en réentraînant le modèle. Elle a aussi publié le classifieur en open source.

La leçon pour votre entreprise, même si vous n'utilisez jamais Perplexity

La plupart des organisations saoudiennes qui utilisent l'IA aujourd'hui le font sans aucune barrière. Un employé copie le message d'un client, une clause de contrat ou un relevé de compte, et le colle dans un outil public pour demander un résumé ou un projet de réponse. Les données ont quitté l'organisation à ce moment-là, sans aucune trace et sans qu'aucune décision n'ait été prise.

Quand la direction s'en aperçoit, la réaction est généralement l'une de deux options, et les deux sont perdantes. Interdire purement et simplement les outils, et les employés contournent l'interdiction sur leurs appareils personnels. Ou fermer les yeux jusqu'à ce qu'un incident survienne. La troisième voie est celle qu'illustre cette annonce : cesser de se demander si vous utilisez l'IA, et commencer à se demander ce qui a le droit de quitter vos systèmes, qui en décide et où cette décision est consignée.

Comment intégrer cette barrière dans vos propres systèmes

En pratique, ce que nous mettons en place dans les systèmes de nos clients repose sur quatre couches, qui fonctionnent toutes quel que soit le fournisseur :

• Classer les champs avant de construire la fonction. Avant de connecter un modèle à votre système, classez les champs de votre base de données : ce qui est public, ce qui est commercialement sensible, ce qui relève des données personnelles. Ce classement est une décision de direction, pas une décision technique, et tout ce qui suit en dépend.
• Une couche d'anonymisation à la frontière du système. Placez un point unique par lequel passe chaque requête sortante vers un fournisseur externe, où les identifiants personnels sont remplacés par des jetons de substitution puis restitués au retour de la réponse. L'essentiel, c'est qu'il s'agisse d'un point unique, et non d'une logique répétée sur chaque écran.
• Un traitement local pour ce qui ne peut pas sortir. Toutes les tâches n'ont pas besoin d'un modèle de pointe. Classer un message, extraire un montant d'une facture, classer les demandes de maintenance par priorité : un petit modèle sur votre propre serveur s'en charge avec une qualité suffisante et pour un coût quasi nul.
• Un journal qui persiste. Quelle requête est sortie, quels champs ont été masqués, qui l'a demandée et quand. Sans journal, vous ne pouvez répondre ni à la question d'un auditeur ni à celle d'un client.

Remarquez qu'aucune des quatre couches ne nomme un fournisseur en particulier. C'est délibéré : les modèles changent toutes les quelques semaines, comme nous l'avons vu toute l'année, et la barrière que vous construisez aujourd'hui doit rester valable quand le modèle qui se trouve derrière change.

Ce que cela signifie au regard de la loi sur la protection des données personnelles

La loi saoudienne sur la protection des données personnelles (PDPL), supervisée par l'Autorité saoudienne des données et de l'intelligence artificielle (SDAIA), repose sur des principes qui incluent la définition de la finalité du traitement et la limitation des données collectées au strict nécessaire. L'organisation reste responsable des données personnelles qu'elle traite, même lorsqu'elle confie ce traitement à un tiers.

Une architecture comme celle décrite sert directement ces deux principes : les données personnelles ne sont pas du tout envoyées au tiers lorsque la tâche ne l'exige pas, et ce qui est envoyé se limite au minimum nécessaire pour accomplir le travail. Mais la technologie seule ne vaut pas conformité : il vous faut toujours une base légale pour le traitement, une politique de confidentialité et des procédures pour traiter les demandes des personnes concernées. Une barrière technique facilite la conformité ; elle ne s'y substitue pas, et la seule référence avant tout engagement reste la loi et ses règlements d'application.

Trois étapes pour commencer cette semaine

Rien de tout cela n'exige un grand projet pour démarrer :

• Posez une question à votre équipe : quand avez-vous collé pour la dernière fois le contenu d'un système de travail dans un outil d'IA public ? Les réponses vous donneront la taille réelle du problème en moins d'une heure.
• Rédigez une page qui définit trois catégories : ce qui ne doit jamais sortir, ce qui peut sortir après anonymisation, et ce qui peut sortir tel quel. Une page réellement appliquée vaut mieux qu'une politique de vingt pages que personne ne lit.
• Choisissez une tâche récurrente qui touche des données personnelles, par exemple le résumé des conversations avec les clients, et appliquez-lui les quatre couches à titre de prototype. Ce que vous apprenez sur une tâche se transpose aux autres.

L'essentiel

L'annonce de Perplexity concerne les utilisateurs de Mac, mais l'idée qui la sous-tend concerne toute organisation qui fait tourner de l'IA sur des données réelles : la bonne décision ne se joue pas entre le cloud et l'appareil, elle consiste à savoir s'il existe une barrière qui décide de ce qui sort avant que cela ne sorte. Les entreprises qui construisent cette barrière dès maintenant peuvent adopter n'importe quel nouveau modèle en toute sécurité en quelques jours. Celles qui la repoussent découvriront qu'elles en ont besoin au pire moment possible : après l'incident, pas avant.

Sources

• Perplexity : annonce officielle de Hybrid Compute sur Mac, source du mécanisme, de la configuration requise et de la description de la barrière de confidentialité.
• Article de 9to5Mac daté du 1er septembre 2026 : date de lancement, exigences matérielles et confirmation que le traitement local ne consomme aucun crédit cloud.
• Détails sur l'architecture du classifieur et ses chiffres de performance, dont la baisse du rappel sur les textes longs et les modèles locaux pris en charge.
• Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) : la loi sur la protection des données personnelles et ses règlements d'application.