Les deux voies de l'IA : concurrence des points d'entrée cloud ou applications natives côté utilisateur ?

Récemment, j'ai vu qu'Alibaba a lancé l'application Tongyi Qianwen, s'engageant officiellement dans la bataille des applications côté C. Sam Altman a également exprimé à plusieurs reprises son obsession pour les « super applications », en incorporant sans cesse diverses fonctionnalités sociales dans ChatGPT.

Dans le récit des grandes entreprises, il semble que la future application AI soit condamnée à être une version des applications super Internet actuelles - devenant le seul point d'entrée, intégrant de nombreuses fonctionnalités.

Mais l'avenir des applications d'IA se limitera-t-il vraiment à ce chemin ? Existe-t-il d'autres possibilités ?

Si nous détournons notre attention des applications de chat AI générales pour regarder des outils de programmation comme Cursor et Windsurf, en intégrant divers outils MCP, nous pourrions avoir un aperçu et ressentir le pouls radicalement différent des applications nativement AI (AI Native App).

Le fossé disparu et le sentiment d'insécurité généralisé

L'écosystème actuel des applications d'IA, si l'on utilise un organisme vivant comme métaphore, peut être décomposé en trois rôles :

* Cerveau (fournisseur de modèle LLM) : Fournit le raisonnement, la prise de décision et les connaissances de base.
* Corps (fournisseur de client) : Fournit une interface utilisateur (UI/GUI), un environnement contextuel (Contexte) et de la mémoire.
* Mains et pieds (fournisseur de services d'outils) : Fournir des capacités spécifiques, telles que la recherche, le calendrier, la réservation, le paiement, etc. outils MCP.

Dans un état idéal, le client (le corps) relie le cerveau et les bras et les jambes, aidant l'utilisateur à résoudre des problèmes.

À l'ère d'Internet, les barrières des applications proviennent de deux choses : l'interface (UI) et l'interface de programmation (API). Les utilisateurs ne peuvent effectuer des services spécifiques que par une interface spécifique. Mais lorsque les besoins peuvent être exprimés en langage naturel, le Prompt devient la nouvelle interface, et les barrières de l'API commencent à se desserrer. Les "frontières" entre les applications commencent à devenir instables.

Cela a conduit chaque rôle dans l'écosystème à manquer cruellement de sécurité :

* Les fournisseurs de LLM craignent de devenir des "tuyaux" : s'ils se contentent de faire des API, cela ne sera pas perceptible pour les utilisateurs. Aujourd'hui, un utilisateur utilise Claude 4.5, demain il passe à GPT 5.1 ou GLM-4.6, et les fournisseurs de modèles peuvent être remplacés à tout moment par une puissance de calcul moins chère. Pour éviter d'être "tuyautés", ils doivent entrer sur le marché des clients (corps) et garder les utilisateurs dans leur propre application.
* Les clients craignent d'être "étranglés" : c'est ce qu'on appelle l'anxiété liée à la "sous-traitance". Si le cerveau central est entre les mains d'autrui, il peut à tout moment être coupé ou voir son prix augmenter. Ainsi, ceux qui développent des applications commencent également à créer leurs propres modèles, essayant de posséder le cerveau.
* Les outils ont peur de la "dissimulation": par exemple, si une plateforme locale de recommandation devient un outil MCP, les utilisateurs dialogueront directement avec l'IA pour faire des recherches, cette plateforme deviendra alors un fournisseur de services API de base, et la valeur de son interface ainsi que ses revenus publicitaires s'effondreront directement. Ainsi, ils ne sont pas contents et essaient d'imposer des fonctionnalités d'IA dans leur application pour tenter de fidéliser les utilisateurs.

Le résultat de cette "anxiété généralisée" est le chaos actuel : tout le monde fait du full stack, essayant de maîtriser complètement le cerveau, le corps et les membres.

Chemin un : Léviathan dans le cloud (entrée super)

Pour résoudre cette anxiété, la solution proposée par les grandes entreprises correspond parfaitement à leur pensée habituelle : reproduire l'histoire des super applications Internet.

Selon les fabricants de modèles, l'assemblage du cerveau et des membres ne devrait pas avoir lieu sur le client, car cela donnerait le contrôle à l'utilisateur. Ils souhaitent que le client revienne à un mode de "client léger" (Thin Client) - ne conservant que la capacité de recevoir des instructions vocales ou textuelles.

Dans cette architecture :

Le cerveau dans le cloud : La prise de décision et le raisonnement sont complètement contrôlés par le fournisseur.
Mains et pieds dans le cloud : intégrer les backends des grandes entreprises via Function Calling ou Plugin.
Mémoire dans le cloud : toutes les données, préférences et historiques des utilisateurs sont téléchargés.

Cela permet de reproduire parfaitement la logique des super applications et est même plus effrayant que les super applications Internet. Car à l'ère d'Internet, bien que les super applications monopolisent le trafic, les données entre les services sont encore relativement isolées. Dans les "super applications AI", les fournisseurs non seulement contrôlent l'entrée, mais maîtrisent également toute la logique décisionnelle intermédiaire à travers les modèles.

C'est un "Léviathan du cloud" parfait, extrêmement efficace, mais les utilisateurs dans ce système n'ont aucune vie privée ni droit de choix, ils ne sont que des objets d'alimentation pour l'algorithme.

Chemin deux : Applications AI natives - Intégration côté utilisateur

Mais il y a aussi une autre possibilité, cette tendance est déjà très claire dans le domaine de la programmation.

Regardez maintenant l'éditeur AI (IDE) : le sujet est du côté de l'utilisateur, la base de code est locale, toute la logique métier et le contexte sont locaux.

Le cerveau est interchangeable : vous pouvez configurer différents modèles dans l'IDE, même si l'IDE ne prend pas en charge la configuration, ajouter une couche de proxy d'interface pour la conversion peut également fonctionner.
Les mains et les pieds sont standardisés : l'émergence de protocoles comme le MCP a transformé des outils tels que les bases de données, Git et les terminaux en blocs Lego standard.

Dans cette architecture, l'application n'est pas un mur pour enfermer les utilisateurs par de grandes entreprises, mais un "exosquelette" porté par les utilisateurs.

Dans ce mode, l'intégration se produit côté client. L'application organise les données locales de l'utilisateur (Contexte), appelle selon les besoins le "cerveau" dans le cloud ou local pour réfléchir, puis dirige les "mains" et "pieds" standardisés pour exécuter.

Les données et la logique essentielles restent du côté de l'utilisateur. Au moins, vos données ne sont pas toutes entre les mains d'un seul fournisseur ; au moins, lorsque un modèle devient obsolète, vous pouvez en changer pour un cerveau plus intelligent.

Bien sûr, ce chemin n'est pas sans embûches, le plus grand défi réside dans l'absence d'infrastructures : sans une application de grande envergure effectuant l'authentification d'identité (Auth) dans le cloud, il est extrêmement difficile de relier les identités, les paiements et de construire des modèles commerciaux durables à partir de divers outils et services côté client, et pour le moment, il n'y a pas de voie claire.

Mais je crois que l'ID décentralisé (DID) et les réseaux de paiement dans le domaine de la crypto peuvent jouer un rôle important ici, en fournissant la base de confiance et de règlement pour cette coopération décentralisée en IA. Nous en discuterons plus en détail dans notre prochain article.

Le jeu du futur

L'évolution technologique actuelle se trouve à un carrefour : d'une part, les grandes entreprises tentent de "regrouper" toutes leurs capacités derrière leurs propres API, construisant ainsi un écosystème fermé ; d'autre part, les développeurs utilisent des technologies telles que MCP et Local LLM pour tenter de construire un écosystème ouvert "découplé".

L'avenir dépend du jeu entre les utilisateurs, les fabricants et les développeurs d'aujourd'hui. Les choix de chacun votent en réalité pour ces deux futurs.