La question arrive souvent sous cette forme : « on veut une application avec de l'IA, il faut partir sur quoi ? » Elle en cache deux. La première porte sur le produit : votre application doit résumer, classer, répondre, reconnaître une image. La seconde porte sur la fabrication : vous voulez écrire l'application plus vite avec un assistant de code.
Les deux n'ont pas la même réponse. Pour la première, un seul critère décide : l'endroit où tourne le modèle. Pour la seconde, les outils ont rattrapé les langages mobiles, et le choix se fait ailleurs.
Le modèle tourne sur un serveur : le langage de l'application pèse peu
C'est le cas le plus courant. Votre application envoie une requête (un texte, une photo, un enregistrement), un serveur appelle le modèle, puis renvoie le résultat. Pour le téléphone, ce n'est qu'un appel réseau parmi d'autres, que Flutter, React Native, Swift et Kotlin savent tous faire.
Le serveur n'est pas là par habitude. Il garde la clé du fournisseur de modèle hors de l'application : une clé embarquée dans un binaire distribué sur les stores peut en être extraite, et quelqu'un d'autre consomme alors votre crédit. C'est aussi le serveur qui contrôle qui a le droit de poser quelle question, qui limite le volume, et qui garde une trace des échanges. Quand l'IA doit lire vos propres données (catalogue, dossiers clients, procédures), c'est encore lui qui va les chercher dans votre système d'information. Sur nos projets, ce serveur est écrit en Symfony, et c'est le sujet de notre page Symfony AI.
Une variante existe chez Google. Firebase AI Logic permet d'appeler les modèles Gemini directement depuis l'application, avec des SDK « in Swift for Apple platforms, Kotlin & Java for Android, JavaScript for web, Dart for Flutter, and Unity » (documentation Firebase, lue le 20 octobre 2026). Même là, la clé ne quitte pas un serveur : la documentation précise que le proxy de Firebase et App Check font que « your Gemini API key stays on the server and is not embedded in your apps' codebase ». Le serveur est celui de Google au lieu du vôtre, et vous êtes limité aux modèles que Firebase propose. Nous ne l'avons pas trouvé dans la liste des SDK pour React Native.
Dans ce premier cas, gardez donc les critères habituels pour choisir la technologie de l'application : budget, délai, présence sur les stores, compétences de l'équipe qui maintiendra. Ils sont détaillés dans notre comparatif application native, hybride ou PWA. Le coût d'usage du modèle, lui, ne dépend pas du langage de l'application : il se lit modèle par modèle sur notre page prix des modèles IA.
Le modèle tourne sur le téléphone : le natif reprend l'avantage
Le second cas est plus rare, mais il change la donne. Le modèle est exécuté sur l'appareil lui-même, sans appel réseau. On le choisit pour trois raisons : une donnée qui ne doit pas quitter le téléphone, un usage sans réseau (entrepôt, chantier, zone blanche), ou un traitement en continu de la caméra que la latence d'un serveur rendrait inutilisable.
Les outils pour le faire sont ceux d'Apple et de Google, et ils sont pensés d'abord pour leurs langages.
| Outil | Éditeur | Ce qu'il fait | Côté code |
|---|---|---|---|
| Core ML | Apple | Exécute un modèle dans l'application : prédire, entraîner ou ajuster, « all on a person's device » | API Swift et Objective-C |
| Foundation Models | Apple | Donne accès au modèle de langage d'Apple Intelligence sur l'appareil | « a native Swift API », selon Apple ; l'appareil doit être compatible Apple Intelligence |
| ML Kit | Fonctions prêtes à l'emploi (texte, image, caméra) traitées sur l'appareil, sur iOS et Android | SDK Android et iOS | |
| ML Kit GenAI | Résumé, correction, réécriture, description d'image avec Gemini Nano | Repose sur AICore, un service système d'Android ; liste d'appareils limitée (Pixel 9 à 11, certains Samsung, Honor, Xiaomi…) | |
| LiteRT | Exécute vos propres modèles, issus de PyTorch, TensorFlow ou JAX | Multiplateforme : Android, iOS, web, ordinateur ; « built on the battle-tested foundation of TensorFlow Lite » |
Sources : documentation Apple (Core ML, Foundation Models, page Apple Intelligence pour les développeurs) et documentation Google (ML Kit, ML Kit GenAI, LiteRT), lues le 20 octobre 2026.
Une application Flutter ou React Native peut s'en servir, mais par un pont. Flutter le prévoit dans sa documentation sur le code propre à chaque plateforme, écrit en « Kotlin, Java » pour Android et en « Swift, Objective-C » pour iOS. React Native fait de même avec ses modules natifs, écrits en Java ou Kotlin et en Objective-C. Des plugins existent pour les fonctions courantes. Dès que l'IA embarquée devient le cœur de l'application, une partie du code s'écrit donc de toute façon en Swift et en Kotlin, et l'intérêt d'une base de code unique diminue.
Le cas mixte se défend aussi : l'interface en Flutter, et un module natif fin pour la seule fonction qui tourne sur l'appareil. C'est un choix à faire au cadrage, en sachant quels téléphones vos utilisateurs ont en main. ML Kit GenAI ne tourne que sur la liste d'appareils de Google, et Foundation Models que sur les appareils compatibles Apple Intelligence. Une flotte de terminaux durcis achetés il y a quatre ans peut rendre ces deux options caduques.
Vous hésitez entre un modèle sur serveur et un modèle sur le téléphone ? Décrivez-nous l'usage, le type de données et les appareils de vos équipes : diagnostic offert de votre projet d'application mobile.
Coder l'application avec un assistant IA : ce qui change selon le langage
Seconde question, celle des équipes qui veulent écrire leur application avec Claude, Gemini ou ChatGPT dans leur éditeur. Ici, aucun des quatre choix n'est laissé de côté par les outils des éditeurs.
- Android, Kotlin : Google intègre Gemini à Android Studio, présenté comme « your AI-powered coding companion for Android development » (page Android Studio, mise à jour le 25 août 2026).
- iPhone, Swift : la page Xcode d'Apple annonce des « coding agents in Xcode, powered by the model of your choice » (page lue le 20 octobre 2026).
- Flutter, Dart : l'équipe Flutter publie un serveur MCP qui « connects the assistant to the Dart SDK », avec les diagnostics de l'analyseur, les tests et l'inspection de l'application en cours d'exécution (documentation Flutter, lue le 20 octobre 2026).
- React Native, TypeScript : c'est le langage le plus répandu des quatre. L'enquête développeurs 2025 de Stack Overflow le donne utilisé par 43,6 % de l'ensemble des répondants, contre 10,8 % pour Kotlin, 5,9 % pour Dart et 5,4 % pour Swift.
Faut-il en conclure qu'un assistant écrit mieux le TypeScript que le Dart ? Nous n'avons trouvé aucune mesure publiée qui compare les assistants de code sur Dart, Kotlin, Swift et TypeScript à la fois. Les bancs d'essai multilingues connus, comme SWE-bench Multilingual ou celui d'Aider, ne couvrent ni Dart, ni Kotlin, ni Swift. Toute affirmation chiffrée sur ce point serait donc une impression, pas une mesure.
Ce qui compte davantage, c'est ce que l'assistant produit au-delà de l'écran qui fonctionne : la gestion des droits, le stockage des données sur le téléphone, la dette qu'on découvre à la première modification. Nous avons décrit ce que l'on trouve en relisant ce type de code dans notre article sur l'audit d'une application générée par IA.
Notre position par défaut, et quand on en sort
Sur notre page application mobile, la règle est écrite : quand l'application part de zéro, notre choix par défaut est Flutter. L'IA ne la change pas dans la majorité des projets, puisque le modèle est appelé par le serveur. Nous en sortons dans deux cas : l'IA embarquée est au cœur de l'usage, et le natif s'impose ; ou votre équipe travaille déjà en TypeScript, et React Native lui permettra de reprendre le code.
Le reste se joue côté serveur : quel modèle, à quel coût, avec quelles données et quels contrôles. Pour cadrer ce volet sans partir du langage, notre guide pour intégrer l'IA dans une entreprise quand on la dirige pose les questions dans le bon ordre.
Si vous avez un projet d'application, commencez par nous dire ce que l'IA doit y faire, avant de parler technologie : diagnostic offert de votre projet d'application mobile.