Google annule les applications mobiles AI Studio alors que Gemini prend le relais dans la création d’applications

Gemini absorbe un produit que Google avait annoncé il y a seulement deux mois, malgré des projets d’applications AI Studio distinctes sur Android et iOS. Le rapport de 9to5Google indique que ces applications mobiles sont annulées. Google prévoit désormais d’intégrer la création d’applications directement dans Gemini, avec à terme des logiciels pour mobile et ordinateur.

Il ne s’agit pas d’une simple expérience Google de plus qui est abandonnée. Cette décision revient sur la présentation faite par l’entreprise lors de l’I/O 2026, qui présentait AI Studio mobile comme un espace dédié à la création depuis un téléphone. Google semble plutôt considérer que la génération d’applications doit être intégrée à l’assistant que les utilisateurs emploient déjà.

Cette décision oppose une interface de développement autonome à une interface conversationnelle intégrée. AI Studio reste accessible sur le web, mais Gemini compte plus de 900 millions d’utilisateurs mensuels. Intégrer la création à ce produit plus vaste pourrait faire de la création d’applications non plus une destination, mais une composante ordinaire d’une conversation.

Ce qui a changé selon le rapport de 9to5Google

Google a annulé le conteneur mobile autonome, et non son effort plus large visant à rendre la création de logiciels accessible depuis les appareils du quotidien.

Lors de Google I/O, le 19 mai, l’entreprise a invité les utilisateurs à se préinscrire pour des applications AI Studio dédiées sur Android et iOS. L’expérience prévue promettait le mode Build complet sur téléphone. Le mode Build est l’environnement d’AI Studio fondé sur des prompts, conçu pour générer et prévisualiser des applications.

Google décrivait un flux de travail commençant par la capture d’une idée loin d’un bureau. Les utilisateurs pouvaient ensuite itérer sur le code, prévisualiser les versions, remixer des projets de la galerie et partager des déploiements en direct. Ils pouvaient reprendre le même travail plus tard sur ordinateur.

Le plan d’application mobile initial de l’entreprise présentait la portabilité comme son principal avantage. Un téléphone devait devenir une surface de développement compacte, au lieu de simplement afficher une application générée ailleurs.

La fiche iOS évoquait même une sortie en juillet, tandis que les utilisateurs Android pouvaient se préinscrire via Google Play. Aucune des deux versions n’a finalement atteint le public comme prévu initialement.

Selon le rapport sur l’annulation des applications du 31 juillet, Google a changé de stratégie. L’entreprise s’éloigne des clients mobiles AI Studio dédiés et concentre son attention sur la création d’applications au sein de Gemini.

La communication publique de Google laisse entendre que les utilisateurs créeront à terme des applications mobiles et de bureau via de simples conversations avec Gemini. Une idée pourrait émerger lorsqu’une personne discute d’un voyage, organise son travail ou cherche à résoudre un problème concret. Gemini pourrait alors transformer ce besoin en logiciel interactif.

La formulation est importante, car elle décrit un modèle d’interaction différent. AI Studio demande à l’utilisateur d’entrer dans un environnement de développement avec une idée d’application. Gemini pourrait repérer une opportunité de créer un logiciel alors que l’utilisateur est déjà en train d’expliquer un objectif.

Cette distinction change le point d’entrée. L’utilisateur n’a plus besoin de décider qu’une application est la réponse avant de commencer. Gemini pourrait proposer ou générer une interface après avoir compris la tâche sous-jacente.

Google n’a pas publié de calendrier de lancement détaillé pour cette fonctionnalité. L’entreprise n’a pas non plus précisé quelles plateformes, quels types de comptes ou quels pays y auraient accès en premier. L’annulation est concrète, tandis que le remplacement reste une orientation produit future.

AI Studio lui-même ne disparaît pas. Son produit web prend toujours en charge la génération d’applications, l’expérimentation avec les modèles, le déploiement et le développement Android natif. Les produits annulés sont les clients mobiles autonomes prévus.

Cette limite est importante. Certaines réactions ont décrit cette décision comme l’arrêt d’AI Studio par Google, mais les éléments disponibles ne permettent pas de tirer cette conclusion. Google modifie l’endroit où vivra son expérience de création destinée au grand public.

Le récit de 9to5Google comporte donc à la fois un recul et une expansion. Une paire d’applications mobiles promises disparaît. L’ambition sous-jacente inclut désormais les applications de bureau et l’audience bien plus vaste de Gemini.

Ce revirement soulève la question centrale : un assistant généraliste peut-il offrir un contrôle suffisant pour créer des applications sérieuses, ou l’intégration effacera-t-elle la clarté qui rendait AI Studio utile ?

Google échange un outil de création dédié contre la portée de Gemini

Les applications annulées suppriment une destination évidente, mais donnent à Google l’occasion de placer la génération d’applications devant des centaines de millions d’utilisateurs existants.

Google a indiqué en mai que Gemini servait plus de 900 millions d’utilisateurs mensuels dans 230 pays et plus de 70 langues. Un an plus tôt, l’entreprise rapportait 400 millions d’utilisateurs. Ces chiffres proviennent de Google et n’ont pas fait l’objet d’un audit indépendant.

Même avec cette réserve, l’écart d’échelle est considérable. AI Studio cible les développeurs, les créateurs techniques et les personnes qui expérimentent activement les modèles Gemini. L’application Gemini touche un public plus large, qui ne visitera peut-être jamais un outil pour développeurs.

La mise à jour de l’application Gemini de Google montre également pourquoi cette consolidation correspond à sa stratégie actuelle. L’entreprise transforme Gemini en une couche d’action généraliste plutôt que de le cantonner à un chatbot de questions-réponses.

Lors de l’I/O, Google a présenté Gemini Spark, un agent conçu pour effectuer des tâches en arrière-plan sous la direction de l’utilisateur. L’entreprise a aussi étendu la génération de fichiers, les services connectés et l’assistance proactive. La création d’applications s’inscrit dans cette orientation, car elle transforme une conversation en artefact exécutable.

Prenons le cas d’un chef de projet préparant le lancement d’un produit. La conversation pourrait révéler le besoin d’un tableau de bord de suivi, d’un outil de suivi des risques ou d’un trieur de retours. Gemini pourrait générer cette interface sans obliger l’utilisateur à ouvrir un produit de développement distinct.

Un enseignant pourrait demander un quiz de classe qui s’adapte après chaque réponse. Un responsable commercial pourrait demander un formulaire mobile de collecte relié à une feuille partagée. Un voyageur pourrait transformer une discussion sur son itinéraire en liste de contrôle hors ligne.

Ces exemples restent hypothétiques tant que Google n’a pas déployé l’intégration. Ils illustrent néanmoins pourquoi le contexte conversationnel est important. Gemini connaît peut-être déjà l’objectif de l’utilisateur, ses contraintes, ses fichiers et le résultat souhaité avant de générer une application.

Une application AI Studio dédiée démarrerait avec moins de contexte. Elle pourrait accéder à l’historique d’un projet, mais l’utilisateur devrait toujours traduire un problème concret en demande de développement. Gemini peut potentiellement supprimer cette étape de traduction.

C’est aussi là que les intégrations Workspace de Google deviennent stratégiquement utiles. AI Studio peut déjà créer des applications qui fonctionnent avec Sheets, Drive et des documents. Ces connexions permettent aux logiciels générés d’agir sur les informations que les gens utilisent au travail.

Les points forts destinés aux développeurs de l’entreprise plaçaient AI Studio dans une chaîne plus large. Les utilisateurs pouvaient créer un prototype dans AI Studio, exporter les projets vers Antigravity et poursuivre jusqu’au déploiement.

Gemini pourrait devenir la première étape de cette même chaîne. Il capterait l’intention et générerait une première expérience. AI Studio ou Antigravity pourraient ensuite offrir un contrôle plus approfondi lorsqu’un projet devient plus exigeant.

Cette structure ressemble davantage à un entonnoir qu’à un remplacement. Gemini apporte la création d’applications à un vaste public. AI Studio prend en charge la création dans le navigateur, tandis qu’Antigravity permet un développement plus étendu et l’orchestration d’agents.

Le défi consiste à préserver une transition fluide. Une application générée devient plus difficile à maintenir à mesure qu’elle acquiert une authentification, des bases de données, des autorisations, une facturation et des services externes. Les utilisateurs ont besoin d’accéder au code, à la configuration, aux tests et aux enregistrements de déploiement.

Google n’a pas expliqué comment les projets Gemini passeront vers ces interfaces professionnelles. L’entreprise n’a pas indiqué si le contexte conversationnel, les fichiers générés, les secrets ou les paramètres de déploiement les accompagneraient.

L’entreprise prend déjà en charge l’exportation de projets AI Studio vers Antigravity avec le contexte associé. Une passerelle comparable depuis Gemini rendrait la stratégie intégrée plus crédible. Sans cela, les applications générées risquent de devenir des démonstrations temporaires.

Pour Google, l’argument de la portée demeure convaincant. Constituer une audience mobile distincte exigerait une installation, un onboarding et un engagement répété. Gemini dispose déjà de ces relations et est présent sur Android, iOS, le web et les ordinateurs.

Pour les utilisateurs, la consolidation réduit également la confusion entre les produits. Google propose Gemini, AI Studio, Android Studio, Firebase, Antigravity et plusieurs services de développement cloud. Une application mobile supplémentaire aurait ajouté une nouvelle frontière à comprendre.

La portée ne garantit toutefois pas l’adoption. Les utilisateurs ouvrent Gemini pour de nombreuses tâches sans lien avec le logiciel. Google doit rendre la génération d’applications facile à découvrir sans interrompre les conversations ordinaires ni produire des interfaces non désirées.

Le rapport de 9to5Google reflète un pari de distribution. Google sacrifie un produit ciblé afin que la création d’applications puisse apparaître dans son plus grand assistant. Le succès de cet arbitrage dépend de l’exécution, et non de la seule taille de l’audience.

Le véritable revirement concerne le point de départ des idées d’applications

Google avait initialement conçu AI Studio mobile autour d’une création intentionnelle, tandis que le plan pour Gemini part d’un besoin qui apparaît au cours d’une conversation.

L’ancien concept suivait une séquence de développement familière. Une personne avait une idée, ouvrait AI Studio, décrivait l’application, examinait le résultat et partageait un déploiement. Le téléphone changeait l’appareil, mais pas le flux de travail fondamental.

Le nouveau concept modifie le flux de travail lui-même. Les utilisateurs peuvent commencer par discuter d’un problème plutôt que de demander un logiciel. Gemini pourrait déterminer qu’une application interactive constitue une réponse utile.

C’est le principal revirement de l’article. Google passe de « ouvrir un outil de création » à « laisser l’assistant créer lorsque cela est approprié ». L’initiative passe ainsi de l’utilisateur au modèle.

Cette approche s’appuie sur des fonctionnalités déjà présentes dans les produits d’IA conversationnelle. Les assistants peuvent créer des documents, des feuilles de calcul, des graphiques, des visualisations interactives et de petits artefacts fondés sur du code. Les applications constituent une extension plus vaste de ce modèle de sortie.

Google a ajouté la génération de fichiers téléchargeables à Gemini en avril. Les utilisateurs peuvent demander des documents, des feuilles de calcul, des PDF et d’autres formats sans quitter une conversation. L’entreprise positionne désormais le logiciel comme un autre artefact qu’une conversation peut produire.

Une application diffère d’un fichier parce qu’elle possède un état et un comportement. Elle peut accepter des saisies utilisateur, appeler des services externes, stocker des informations ou évoluer avec le temps. Cela rend la génération plus utile, mais crée aussi davantage de possibilités d’échec.

Google AI Studio prend déjà en charge des applications full-stack fondées sur des prompts, qui combinent une interface, une logique serveur et des services de données connectés. Son guide actuel du mode Build décrit la génération d’applications autour des capacités de Gemini, du déploiement et de la gestion des secrets côté serveur.

L’outil web fournit des contrôles de développement visibles. Les utilisateurs peuvent inspecter le code, ajuster les prompts, tester le comportement, connecter des services et gérer les déploiements. Ces contrôles établissent une frontière mentale entre la conversation et l’ingénierie logicielle.

L’interface conversationnelle de Gemini est volontairement moins technique. Cela la rend accessible, mais peut aussi masquer des décisions importantes. Une application générée a toujours besoin d’autorisations, de règles de données, de gestion des erreurs et de limites de sécurité.

Google doit décider quelle part de cette complexité apparaît dans la conversation. Trop de configuration donnera à Gemini l’impression d’être un environnement de développement intégré. Trop peu empêchera les utilisateurs de juger ce que fait l’application générée.

La génération pour mobile et ordinateur ajoute une couche supplémentaire. Google a démontré la création native Android dans AI Studio à l’aide de Kotlin et de Jetpack Compose, le framework d’interface moderne d’Android. Les utilisateurs peuvent prévisualiser le code dans un émulateur accessible depuis un navigateur et envoyer des builds vers une piste de test interne.

Le développement pour ordinateur est moins clairement défini. Google n’a pas identifié les systèmes d’exploitation, frameworks applicatifs, formats de packaging ou méthodes de distribution qu’il prévoit de prendre en charge via Gemini.

Les « applications de bureau » pourraient désigner des logiciels installables pour Windows et macOS. Elles pourraient aussi décrire des applications web optimisées pour les grands écrans. Il s’agit de promesses sensiblement différentes : Google doit donc définir ce terme.

La voie iOS est tout aussi incertaine. La prise en charge annoncée du développement natif dans AI Studio était centrée sur Android. Google n’a pas annoncé de workflow équivalent basé sur Swift pour générer des applications iPhone natives.

L’annulation d’un client iOS ne crée pas automatiquement une prise en charge du développement iOS. Ce client aurait permis d’utiliser AI Studio sur un iPhone. Il n’aurait pas nécessairement généré de logiciels iOS natifs.

Cette distinction peut facilement disparaître dans les titres. Google affirme que Gemini créera à terme des applications mobiles, mais le format de sortie reste non précisé. Une application web adaptée au mobile n’est pas la même chose qu’une application native prête pour les stores.

La version la plus ambitieuse du plan de Google utiliserait la conversation pour identifier un besoin, produire une interface fonctionnelle et laisser les utilisateurs choisir une cible de sortie. Elle exposerait ensuite le code et les outils de test avant le déploiement.

Une version plus limitée créerait des cartes interactives éphémères qui ne fonctionnent qu’à l’intérieur de Gemini. Ces expériences pourraient tout de même aider les utilisateurs, mais elles ne correspondraient pas aux attentes courantes concernant des logiciels mobiles ou de bureau indépendants.

La frontière du produit déterminera qui ressentira la pression. Les outils de création basés sur les prompts se distinguent en proposant un espace de travail dédié, des projets réutilisables, l’hébergement et le déploiement. Gemini peut les concurrencer si ses résultats conversationnels restent modifiables et portables.

Les environnements de développement traditionnels font face à une pression différente. Google ne remplace pas l’ingénierie professionnelle par un seul prompt. L’entreprise déplace le prototypage précoce vers un espace où de nombreux utilisateurs décrivent déjà leurs besoins.

Les développeurs pourraient recevoir davantage de projets partiellement générés de la part de collègues n’ayant jamais ouvert un outil de programmation. Cela peut accélérer la découverte, mais aussi créer du travail de maintenance. Le code généré doit toujours être examiné avant de traiter des informations sensibles ou de servir de vrais clients.

Les équipes peuvent se préparer en considérant les prototypes conversationnels comme des artefacts d’exigences, et non comme des produits finis. Elles devraient conserver les prompts, le comportement attendu, les cas de test et les sources. Un ensemble consultable de documents d’ingénierie peut faciliter cette transmission.

Le pari de Google est que la création d’applications commence avant qu’une personne ne réalise qu’elle développe un logiciel. Gemini occupe déjà ce moment plus précoce. AI Studio ne l’occupe pas.

La création d’applications dans Gemini a toujours un problème de contrôle

La stratégie intégrée réduit les frictions, mais Google n’a pas montré comment Gemini gérera les tests, la sécurité, la portabilité et la maintenance à long terme.

La première incertitude concerne la définition du produit. Google a décrit une orientation future plutôt qu’une fonctionnalité finalisée. Il n’existe ni date de lancement publique, ni liste des plateformes prises en charge, ni démonstration détaillée de la génération mobile et desktop dans Gemini.

Cette lacune compte, car les applications autonomes étaient suffisamment concrètes pour une préinscription. Google a annoncé des fonctionnalités, montré une interface et décrit un workflow multi-appareils. Le remplaçant offre actuellement moins de détails opérationnels.

La deuxième incertitude concerne le contrôle de l’utilisateur. Les conversations sont efficaces pour recueillir une intention, mais remplacent mal une gestion de projet structurée. Les applications nécessitent un historique des versions, des fichiers, des dépendances, des variables d’environnement, des paramètres de déploiement et des tests reproductibles.

L’utilisateur doit également comprendre quand Gemini propose une application. Générer automatiquement une interface pour chaque question complexe créerait de l’encombrement. Attendre une demande explicite affaiblirait la promesse d’applications émergeant naturellement de la conversation.

Google doit établir une étape de consentement claire. Gemini peut suggérer une application, expliquer à quelles données elle accédera et demander à l’utilisateur d’approuver sa génération. Cela préserverait la découverte conversationnelle tout en laissant le contrôle à l’utilisateur.

Les autorisations exigent un traitement similaire. Un tableau de bord connecté à une feuille de calcul nécessite un accès différent de celui d’une calculatrice locale. Une application qui envoie des e-mails ou stocke des informations clients présente plus de risques qu’un graphique interactif.

La documentation Firebase de Google avertit déjà les développeurs de ne pas laisser les clés API Gemini dans le code client. Elle recommande aussi des règles de sécurité et des contrôles d’application pour les services connectés. Ces protections ne peuvent pas disparaître simplement parce que Gemini a généré le projet.

Les applications générées peuvent contenir des paramètres par défaut non sécurisés, une logique peu fiable ou des dépendances présentant des vulnérabilités connues. Une interface soignée ne prouve pas qu’une application est sûre. Les utilisateurs peuvent surestimer sa qualité parce que Gemini a produit un aperçu convaincant.

L’article de 9to5Google sur Google ne doit donc pas être interprété comme la preuve que Gemini peut remplacer des équipes logicielles. Google a annoncé une stratégie de distribution et d’interface. L’entreprise n’a pas démontré un développement de bout en bout fiable sur les plateformes mobiles et desktop.

La portabilité présente un autre risque. Les utilisateurs doivent savoir s’ils peuvent exporter le code généré, le déployer ailleurs et poursuivre le développement sans Gemini. Un projet enfermé dans une conversation a une valeur limitée pour le travail à long terme.

AI Studio offre actuellement des workflows orientés code et des connexions à d’autres outils de développement Google. Cela crée un chemin entre le prototype et un projet maintenu. Gemini a besoin d’une sortie tout aussi visible vers AI Studio, Antigravity, Android Studio ou un autre environnement standard.

Les tests deviennent également plus complexes d’une plateforme à l’autre. Une application de bureau peut se comporter différemment sur Windows et macOS. Une application mobile doit tenir compte des tailles d’écran, des autorisations, de l’activité en arrière-plan, de l’utilisation de la batterie et des règles des stores.

Google contrôle Android et Google Play, ce qui lui donne une voie directe pour les tests et la distribution. L’entreprise ne contrôle ni l’environnement de développement d’Apple ni le processus de validation de l’App Store. Les affirmations multiplateformes exigeront des preuves allant au-delà de la génération d’une interface responsive.

La démonstration de l’I/O de l’entreprise a fixé une référence utile pour Android. AI Studio pouvait générer du code Kotlin, l’exécuter dans un émulateur de navigateur, se connecter via Android Debug Bridge et publier sur une piste de test interne. Gemini devrait offrir les mêmes contrôles avant que les utilisateurs considèrent ses résultats comme des logiciels déployables.

Il existe aussi un problème de découvrabilité pour les utilisateurs avancés. AI Studio sépare les modèles, prompts, outils et code dans un environnement conçu pour l’expérimentation. L’interface plus simple de Gemini pourrait masquer les choix de modèles ou supprimer des options de configuration dont ces utilisateurs ont besoin.

La consolidation ne fonctionne que si Google préserve des niveaux de contrôle distincts. Un utilisateur occasionnel peut accepter une mini-application générée automatiquement. Un développeur doit pouvoir examiner l’implémentation et modifier son fonctionnement.

Les réactions des utilisateurs reflètent déjà ces deux aspects. Certaines personnes jugent l’application autonome inutile parce qu’AI Studio fonctionne dans un navigateur mobile. D’autres craignent que l’intégration de la création dans Gemini réduise l’accès aux contrôles plus avancés d’AI Studio.

Aucun de ces points de vue ne peut être tranché avant le lancement du remplaçant. L’annulation réduit aujourd’hui l’encombrement des applications. Elle retire aussi une expérience promise avant que Google ait montré que Gemini en propose une équivalente.

L’historique produit de Google suscite un scepticisme compréhensible. L’entreprise regroupe souvent des services qui se chevauchent, mais les utilisateurs peuvent perdre des workflows lors de ces transitions. Une préinscription annulée rend les promesses futures plus difficiles à évaluer sans logiciel fonctionnel.

L’interprétation prudente est restreinte. Google estime que la création conversationnelle d’applications a davantage de valeur stratégique qu’un client mobile AI Studio autonome. La question de savoir si cette décision profite aux créateurs dépend de l’exportation, des tests, de la prise en charge des plateformes et de la fiabilité.

Ce que Google, les développeurs et les concurrents doivent démontrer ensuite

Trois signaux montreront si Google a trouvé une meilleure voie vers la création d’applications ou s’il a simplement annulé un produit avant que son remplaçant ne soit prêt.

Le premier signal est un aperçu fonctionnel de génération d’applications dans Gemini. Google doit montrer une conversation complète qui devient une application modifiable. La démonstration devrait inclure le comportement généré, les autorisations, les tests et un chemin d’exportation.

Une simple carte interactive affaiblirait l’affirmation plus large. Un projet qui passe dans AI Studio ou Antigravity en conservant son contexte étayerait la stratégie de consolidation de Google.

Le deuxième signal est une définition précise des plateformes. Google doit expliquer ce qu’il entend par applications mobiles et desktop. Les développeurs doivent savoir si Gemini génère du code natif, des packages multiplateformes, des applications web progressives ou des expériences limitées à Gemini.

La prise en charge native d’Android s’appuierait sur des capacités déjà annoncées par Google. Une sortie native iOS, Windows ou macOS nécessiterait de nouvelles chaînes d’outils et de nouveaux workflows de distribution. Chaque cible entraîne des exigences techniques et réglementaires différentes.

Le troisième signal est la manière dont les créateurs concurrents réagiront. Les services axés sur la création d’applications à partir de prompts peuvent mettre en avant une modification prévisible, le déploiement, les intégrations et la propriété du code. Ils peuvent aussi rendre la prise en charge multiplateforme plus facile à comprendre que la collection grandissante de produits Google.

Si les concurrents améliorent leur passage des prototypes en langage naturel à du code maintenu, l’avantage de distribution de Google pourrait ne pas décider du marché. Les utilisateurs acceptent souvent une application supplémentaire lorsqu’elle offre un contrôle plus clair.

Google doit également clarifier le rôle continu d’AI Studio. Maintenir l’outil web actif ne suffit pas. L’entreprise devrait expliquer quel travail commence dans Gemini, lequel passe dans AI Studio et lequel relève d’Antigravity ou d’Android Studio.

Cette cartographie aiderait à la fois les créateurs occasionnels et les équipes professionnelles. Sans elle, la famille de produits peut donner l’impression de proposer plusieurs réponses qui se chevauchent à la même question.

Pour les développeurs, la réponse à court terme doit être pragmatique. Ne réorganisez pas un workflow autour d’une fonctionnalité Gemini non lancée. Continuez d’utiliser les outils web actuels d’AI Studio lorsqu’ils répondent aux besoins du projet.

Parallèlement, surveillez les projets qui démarrent hors de l’ingénierie. Des collègues pourraient bientôt arriver avec des prototypes générés au cours de conversations Gemini ordinaires. Les équipes devraient décider comment ces artefacts passent en revue, en tests, en évaluation de sécurité et en attribution de propriété.

Les acheteurs d’entreprise devraient se concentrer sur la gouvernance plutôt que sur la vitesse de démonstration. Ils ont besoin d’enregistrements indiquant quelles données une application générée a consultées, quel code a été déployé et qui a approuvé chaque autorisation.

Les travailleurs du savoir devraient observer à quelle fréquence Gemini propose des applications sans qu’on le lui demande. Des suggestions utiles pourraient transformer des tâches récurrentes en petits outils personnalisés. De mauvaises suggestions pourraient rendre les conversations plus difficiles à parcourir.

Le débat central reste celui d’un outil de création dédié face à un assistant intégré. AI Studio offre l’intention, la structure et des contrôles visibles. Gemini offre le contexte, la distribution et une barrière à l’entrée plus faible.

Google a choisi l’assistant intégré comme principal canal destiné aux consommateurs. L’entreprise n’a pas encore établi que cette voie peut préserver le contrôle nécessaire lorsqu’un prototype devient important.

Cette annulation fait des applications un choix de produit particulièrement révélateur. Google n’a pas abandonné la création sur mobile parce que les téléphones étaient inadaptés. L’entreprise a estimé qu’une destination distincte avait moins de valeur que l’intégration de la création à Gemini.

Les prochains mois devraient montrer si ce jugement se vérifie. Un aperçu détaillé de Gemini le renforcerait. Des démonstrations vagues, des exportations limitées ou un silence persistant sur la prise en charge des plateformes l’affaibliraient.

Le rapport de 9to5Google sur Google marque la fin d’un produit annoncé, mais pas celle des ambitions de Google en matière de développement mobile. Il impose à Gemini une responsabilité plus grande : relier la conversation, le code et le déploiement sans dissimuler les choix essentiels.

Que devraient faire les utilisateurs maintenant ? Continuer à développer avec les outils existants et évaluer la future création d’applications dans Gemini à l’aune du code exporté, plutôt que de ses aperçus soignés. Ils doivent se demander si les projets restent modifiables, testables et portables une fois la conversation terminée. Les développeurs devraient également exiger des limites d’autorisation claires avant de connecter des logiciels générés à des données réelles. Si Google fournit ces éléments, l’annulation des applications autonomes apparaîtra comme une consolidation ciblée. Dans le cas contraire, cette décision ressemblera à un repli prématuré enveloppé dans une promesse plus vaste.