Le virage d’Opera vers WebAI ne tient pas tant à une fonctionnalité isolée qu’à un changement de lieu d’exécution de l’inférence. En proposant une interface d’IA intégrée au navigateur, Opera permet aux pages web et aux extensions d’appeler des modèles exécutés localement sur l’appareil de l’utilisateur — y compris des modèles préinstallés ou activés sur demande, proposés par des fournisseurs pris en charge. Pour de nombreux développeurs, cela supprime une étape opérationnelle de longue date : il n’est plus forcément nécessaire d’héberger des serveurs d’inférence, de gérer leur montée en charge ou de payer des frais d’API calculés au token pour des fonctionnalités dont l’inférence est peu coûteuse et sensible à la latence.
En pratique, WebAI est indépendant des modèles, mais son utilité dépend de l’adéquation entre les modèles et le matériel. Dans un premier temps, Opera permet aux utilisateurs d’activer la famille Gemma de Google et, sur les Mac équipés d’une puce Apple, le modèle de fondation embarqué d’Apple. Ces modèles ont été retenus parce que les architectures modernes à « poids ouverts » sont désormais suffisamment efficaces pour fonctionner sur des ordinateurs portables courants et des ordinateurs de bureau haut de gamme. Les développeurs peuvent ainsi créer des fonctionnalités de classification de contenu, de résumé et de génération légère sans mettre en place des grappes de GPU ni payer chaque requête — à condition de prévoir des performances variables selon les appareils.
Les effets concrets sur les produits sont bien réels. L’exécution locale ramène le délai aller-retour de l’inférence de plusieurs centaines de millisecondes, voire de quelques secondes, à quelques dizaines de millisecondes sur un appareil suffisamment puissant. Les fonctionnalités interactives en temps réel, comme l’organisation des onglets ou les suggestions contextuelles, gagnent ainsi en réactivité. Les données sensibles restent également sur l’appareil, ce qui réduit les contraintes réglementaires et de conformité liées au traitement de documents privés ou à la présélection de CV. En contrepartie, les responsabilités changent : les développeurs doivent détecter les capacités disponibles, prévoir des solutions de repli adaptées et tester l’expérience liée au téléchargement facultatif des modèles et aux autorisations.
Les compromis liés à l’adoption dépendront des limites matérielles, de la taille des modèles et de la confiance des utilisateurs. Les appareils disposant de peu de mémoire vive, d’un processeur limité ou dépourvus d’accélérateurs neuronaux exécuteront mal les petits modèles, voire ne pourront pas utiliser l’IA locale, ce qui imposera des architectures hybrides. La sécurité et les mécanismes de mise à jour comptent aussi : les navigateurs doivent isoler l’exécution des modèles, garantir des canaux de mise à jour transparents pour leurs poids et empêcher que l’inférence locale ne devienne une nouvelle surface d’attaque. Pour les équipes produit, la question n’est pas seulement celle de la faisabilité technique, mais aussi de l’adéquation au marché : quelles fonctionnalités nécessitent réellement une exécution locale, et lesquelles peuvent basculer vers le cloud ?