Pendant des années, le navigateur était le joli visage de l’application et le cloud était le lieu où se déroulaient les tâches difficiles. L'utilisateur écrit, clique, télécharge un fichier ; le frontend envoie tout au serveur ; le serveur appelle un modèle ; la réponse revient.

Ce dispositif reste très utile, mais il n’est pas gratuit. Chaque appel soulève des questions de latence, de coût, de dépendance au réseau et de confidentialité. Si l’utilisateur écrit une phrase et souhaite une suggestion, une demi-seconde compte. Si vous classez des milliers de petits intrants, les centimes deviennent de l'argent réel. Si le texte est sensible, l’envoyer depuis l’appareil n’est pas un choix neutre.

C'est pourquoi le WebGPU et l'IA sur appareil sont à la mode. Non pas parce que nous exécuterons tous les modèles dans le navigateur demain. Parce que certaines fonctionnalités intelligentes peuvent se rapprocher de l’utilisateur.

Tout ne doit pas nécessairement devenir local

La version enfantine de l’argument est la suivante : « cloud contre appareil ». La version utile est hybride.

Certaines tâches s'affichent parfaitement sur l'appareil : courts résumés, détection de langue, réécritures légères, classifications simples, filtres d'image, petits modèles de vision, expériences créatives avec retour immédiat.

D'autres tâches restent meilleures dans le cloud : raisonnement complexe, modèles frontières, données côté serveur, audit centralisé, qualité uniforme, workflow où il faut contrôler soigneusement chaque étape.

L'architecture saine décide au moment de l'exécution :

Le navigateur n'a pas besoin de gagner contre le cloud. Cela doit éviter au cloud d'effectuer un travail qui n'a pas besoin d'être effectué là-bas.

Pourquoi WebGPU est important

WebGPU est une API moderne permettant d'utiliser le GPU depuis le navigateur. Ce n'est pas seulement pour de plus beaux graphismes 3D. C’est également important car il expose des primitives adaptées au calcul : charges de travail parallèles, shaders, pipelines plus proches de ce que font bien les GPU.

Pour l’IA, la visualisation scientifique, les éditeurs 3D, les filtres vidéo et les outils de création, cette différence se fait sentir. WebGL a fait beaucoup pour le web, mais WebGPU est né avec un modèle mieux adapté au présent.

Cependant, la première chose à écrire n’est pas un shader. C'est une détection de fonctionnalité sobre :

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

Cette fonctionnalité dit une chose importante : WebGPU n'est pas un droit accordé sur chaque appareil. C'est une capacité à vérifier. Certains navigateurs ne le prennent pas entièrement en charge, certains GPU ont des limitations, certains environnements d'entreprise désactivent des fonctionnalités, certains utilisateurs utilisent un matériel modeste.

IA intégrée : lorsque le navigateur apporte le modèle

Chrome propose des API intégrées pour des tâches telles que les invites locales, le résumé, la rédaction, la réécriture, la traduction, la détection de langue et la relecture. L'idée est très intéressante : le navigateur gère le modèle, la disponibilité et les mises à jour ; l'application utilise une API plus proche de la plateforme.

Si ça marche bien, ça change beaucoup :

• moins d'appels au serveur pour des tâches simples ;
• les données pouvant rester sur l'appareil ;
• latence inférieure ;
• expériences hors ligne ou semi-hors ligne ;
• UX plus naturelle pour la rédaction et la traduction.

Mais cela doit être traité comme une amélioration progressive. Certaines API sont stables, d'autres en version d'essai ou en avant-première, d'autres encore dépendent de la version, de la langue et de l'appareil.

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

Le code spécifique changera, mais le modèle demeure : vous vérifiez la disponibilité, expliquez les téléchargements, proposez des solutions de secours et mesurez la qualité.

Le repli n’est pas un triste plan B

Le repli sur le cloud n’est pas une défaite. Cela fait partie du produit.

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

Cette architecture vous permet de vous améliorer progressivement. Ceux qui bénéficient d’un support local bénéficient d’une meilleure latence et d’une meilleure confidentialité. Ceux qui ne l’ont pas utilisent toujours cette fonctionnalité. Vous pouvez mesurer le pourcentage de demandes locales, les délais, les erreurs, la mémoire, la qualité perçue et le coût.

Sans métriques, l’IA intégrée aux appareils devient un choix esthétique. Avec les métriques, cela devient un levier produit.

L'UX du modèle compte

Si le navigateur a besoin de télécharger un modèle, l'utilisateur le perçoit. Ne le cachez pas derrière une vague roulette. Mieux vaut être clair : "Nous préparons le modèle pour utiliser cette fonction plus rapidement et même hors ligne."

Une bonne expérience :

• affiche l'état de préparation ;
• ne bloque pas la page entière ;
• vous permet de continuer avec le repli sur le cloud ;
• évitez les surprises liées à la batterie et à la mémoire ;
• mémorisez le modèle autant que possible ;
• expliquez le bénéfice en une phrase concrète.

Le pire, c'est une fonctionnalité "intelligente" qui semble cassée car elle télécharge quelque chose en silence.

Confidentialité : meilleure, pas automatiquement sécurisée

Le traitement des données sur l'appareil peut être un grand avantage. Il n'est pas nécessaire qu'un brouillon d'e-mail, un document interne ou une note personnelle quitte votre navigateur pour recevoir une suggestion.

Cependant, local ne signifie pas automatiquement sécurité. Cependant, vous devez penser à :

• XSS ;
• journaux accidentels ;
• données enregistrées en stockage ;
• injection rapide à partir de contenu non fiable ;
• autorisations accordées au modèle ;
• sorties utilisées dans les actions automatiques.

Si un modèle local peut lire une page Web puis remplir un formulaire, cette page peut tenter de la manipuler. S'il peut appeler l'outil, une confirmation est nécessaire. S’il produit une sortie structurée, il doit être validé. Le fait qu’il s’exécute sur l’appareil réduit certains risques liés à la vie privée, mais n’élimine pas le modèle de sécurité.

Où ça devient vraiment intéressant

Le texte n'est que le début. WebGPU rend crédibles les expériences Web qui, jusqu'à récemment, ressemblaient à une application native :

• éditeurs 3D complexes ;
• Éclaboussures gaussiennes dans le navigateur ;
• filtres vidéo en temps réel ;
• CAO légère ;
• visualisations scientifiques;
• outils créatifs avec aperçu instantané ;
• inférence de vision à proximité de l'interface utilisateur ;
• des jeux par navigateur plus ambitieux.

Ici, le frontend, les graphiques et l'apprentissage automatique commencent à se mélanger. C'est un domaine un peu délicat, mais aussi fertile : le navigateur redevient une plate-forme d'application sérieuse, et pas seulement l'endroit où l'on met des formulaires et des tableaux de bord.

Liste de contrôle avant la production

Avant de proposer une fonctionnalité sur l'appareil aux utilisateurs, je vérifierais :

1. Ciblez les navigateurs et les appareils.
2. Repli du cloud ou dégradation élégante.
3. Temps de téléchargement et cache du modèle.
4. Mémoire et batterie sur matériel moyen.
5. Qualité par rapport à la version cloud.
6. Politique de confidentialité et messages des utilisateurs.
7. Test avec des entrées hostiles.
8. Métriques distinctes pour l’exécution locale et cloud.
9. Prévoyez de mettre à jour ou de désactiver le modèle.

C'est une liste concrète parce que le problème est concret. Une fonctionnalité d’IA lente, fragile ou opaque ne s’améliore pas simplement parce qu’elle s’exécute dans le navigateur.

Le bon compromis

Je ne crois pas que l'avenir réside dans "tout sur l'appareil". Et je ne pense pas non plus que le cloud restera le seul endroit raisonnable pour faire des déductions. L'avenir le plus probable est un mélange : local lorsque cela améliore la latence, la confidentialité ou le coût ; cloud lorsque la qualité, les données mises à jour et le contrôle centralisé sont nécessaires.

WebGPU, WebNN et les API d'IA intégrées ne rendent pas le navigateur omnipotent. Ils le rendent plus adulte. Et pour ceux qui créent des produits Web, c’est une énorme nouvelle.

Sources utiles

• API WebGPU - MDN
• Spécification WebGPU - W3C
• IA intégrée – Chrome pour les développeurs
• API d'IA intégrées – Chrome pour les développeurs
• API WebNN