Chrome Prompt API : L'IA locale au prix de l'interopérabilité

Le Pitch

La Prompt API permet aux développeurs web d'accéder directement à un modèle de langage intégré au navigateur (type Gemini Nano) pour l'exécution d'inférences on-device. L'objectif affiché est de supprimer la latence et les coûts prohibitifs des appels API vers des modèles LLM propriétaires côté serveur (source: GitHub).

Sous le capot

Le projet est actuellement au stade de "Draft Community Group Report" au W3C depuis le 10 avril 2026 et n'est absolument pas un standard formel (W3C Report). L'implémentation technique pose un problème majeur de neutralité : les prompts optimisés pour Gemini Nano 2.5 risquent de produire des hallucinations ou de l'output incohérent s'ils sont exécutés sur les modèles locaux d'autres navigateurs (Dossier UsedBy).

L'opposition est frontale. Mozilla a officiellement marqué sa position comme "négative" sur cette API (mozilla/standards-positions #1213). En réponse au forcing de Google, Firefox 148 a introduit en février 2026 un "AI Kill Switch" centralisé permettant aux utilisateurs de désactiver totalement ces fonctionnalités au niveau du hardware (Firefox 148 Release Notes).

L'aspect juridique est un nid de poules. Pour utiliser l'API dans Chrome, les développeurs doivent accepter explicitement la "Generative AI Prohibited Uses Policy" de Google. Cette politique impose des restrictions sur le contenu politique ou sexuel qui dépassent le cadre légal standard, créant un flou sur la responsabilité juridique en cas de sortie non conforme générée localement (Chrome Dev Docs 2026).

On ne sait pas encore comment les différents vendeurs comptent s'accorder sur une "personnalité" de modèle de base pour garantir une expérience consistante. De plus, les benchmarks comparatifs entre l'implémentation native de Google et des alternatives comme Phi-4 on-device restent fragmentés et peu fiables (Dossier UsedBy).

L'avis de Ruben

C'est un outil pour vos side-projects ou vos outils internes sous Chrome, mais rien d'autre. Dépendre d'une API qui vous force à signer les CGU de Google pour une exécution locale est une aberration en termes d'architecture. Le risque de Vendor Lock-in est maximal : vous allez coder des wrappers complexes pour gérer les spécificités de Gemini Nano pendant que les utilisateurs Firefox auront simplement désactivé la feature. En l'absence d'une roadmap d'interopérabilité claire, restez sur de l'inférence server-side ou du WebAssembly (WASM) si vous tenez vraiment au local.

Codez propre,
Ruben.