L'IA dans une application mobile
L'IA est utile quand elle sert l'usage, inutile quand elle sert le discours. Sur mobile, elle doit en plus composer avec une connexion qui tombe, une batterie limitée, un écran de six pouces et un coût facturé à chaque requête. Ces quatre contraintes changent complètement les bonnes réponses par rapport à un produit web.
Cette page passe en revue les usages qui tiennent leurs promesses, les choix d'architecture propres au mobile et les réflexes à éviter, puis la méthode complète pour intégrer une IA dans votre application.
La frontière est simple : si l'on retire l'IA et qu'il reste un produit utile, vous êtes sur cette page. Sinon, vous êtes sur l'autre.
Ce qui fonctionne
Quatre familles d'usages que nous voyons produire un gain mesurable sur mobile. Le point commun : elles retirent du travail à l'utilisateur au lieu de lui en donner.
Photographier une facture, une plaque, un compteur, un code-barres abîmé, et récupérer les données structurées sans les saisir. Sur le terrain, c'est le gain le plus immédiatement compris par l'utilisateur.
Gain : la saisie disparaîtL'utilisateur trouve ce qu'il cherche dans un catalogue ou une base documentaire, même quand il exprime mal sa demande. Sur mobile, où taper coûte cher, c'est souvent le levier de conversion le plus rentable.
Gain : moins de frappe, plus de trouvaillesPré-remplissage à partir du contexte, détection d'incohérences, suggestions de formulation pour un compte rendu d'intervention. Le gain le plus discret, et celui que les équipes réclament une fois qu'elles y ont goûté.
Gain : des rapports réellement remplisSynthèse d'un historique client, d'un fil de messages ou d'un dossier avant une visite. Utile précisément parce que l'écran est petit et le temps court.
Gain : lire moins, savoir autantLes contraintes du mobile
Ce sont elles qui font qu'une réponse valable sur le web ne l'est pas forcément sur un téléphone.
Un modèle appelé en ligne ne répond pas dans un parking, un sous-sol ou une zone blanche. Sur une application de terrain, c'est la contrainte la plus structurante : la fonction doit soit se mettre en attente proprement, soit basculer sur un modèle embarqué.
Toujours prévoir le chemin dégradéMultipliée par vos utilisateurs et leur fréquence d'usage, une fonction anodine peut représenter des milliers d'euros par mois. Le calcul se fait avant le lancement, sur un volume réaliste plutôt que sur celui de la démo.
Modéliser le coût par utilisateur actifUn modèle embarqué consomme le processeur du téléphone ; un modèle en ligne consomme du temps d'attente. Au-delà d'une seconde, l'utilisateur croit que l'application a planté et il ferme.
Une seconde perçue, au maximumEnvoyer une photo de document ou un historique client à un modèle en ligne, c'est un transfert de données personnelles. Il faut savoir où il va, ce qui en est conservé, et l'écrire dans votre politique de confidentialité.
Traiter le RGPD au cadrageAPI ou modèle embarqué
C'est le choix technique central, et il se prend au cadrage : il oriente l'architecture, le coût récurrent et le traitement des données personnelles.
Plus puissant, mis à jour sans republier l'application, capable de traiter des demandes complexes. C'est le choix par défaut dès que la connexion est raisonnablement disponible.
Limite · Exige du réseau, coûte à chaque requête, et fait sortir les données de l'appareil.
Fonctionne hors ligne, sans coût par requête, sans transfert de données. Les modèles embarqués récents suffisent pour la reconnaissance d'image, la classification et l'extraction simple.
Limite · Capacités plus limitées, poids de l'application augmenté, mise à jour liée aux Stores.
L'application utilise le modèle en ligne quand elle le peut et bascule sur l'embarqué sinon. L'utilisateur ne voit pas la différence, sauf sur la finesse du résultat.
Limite · Deux chaînes à maintenir et à tester, donc un coût de développement plus élevé.
Ce qu'on vous déconseille
Trois réflexes courants qui coûtent cher et n'apportent rien. Nous préférons le dire avant le devis.
Le champ de discussion posé dans un coin de l'application. Coûteux à maintenir, rarement utilisé passé l'effet de nouveauté, il laisse surtout à l'utilisateur le soin de deviner quoi demander.
Si l'extraction se trompe et que l'utilisateur ne peut pas corriger à la main, vous avez remplacé une saisie fastidieuse par une impasse. La correction manuelle fait partie intégrante de la fonction.
Mettre l'IA en avant dans la fiche Store attire des téléchargements curieux et des désinstallations rapides. Ce qui retient, c'est le bénéfice : « photographiez, on remplit le formulaire ».
Pour aller plus loin
Le guide complet, pour préparer un projet : ce qui a changé depuis l'arrivée des modèles génératifs, les usages éprouvés en production et la méthode que nous suivons pour intégrer une intelligence artificielle dans une application mobile.
L'intelligence artificielle désigne la capacité d'un programme à accomplir des tâches qui demandaient jusqu'ici un humain : comprendre un texte, reconnaître une image, transcrire une voix, anticiper un comportement. Elle est dans nos téléphones depuis longtemps : Netflix recommande, Shazam reconnaît un morceau, le clavier prédit le mot suivant. Pendant des années, l'intégrer à une application supposait de collecter des données, d'entraîner un modèle sur mesure puis de le maintenir. Un chantier long et coûteux, réservé aux équipes spécialisées.
Les grands modèles de langage (LLM) ont changé la donne. Ils sont devenus multimodaux : un même modèle lit un texte, analyse une photo, écoute un enregistrement et répond dans la langue de l'utilisateur. Surtout, ils s'appellent par une simple API. Pour la majorité des besoins, il n'y a plus rien à entraîner : on choisit un modèle, on le relie à l'application et on encadre ses réponses avec les données du métier.
Sur des Stores qui comptent des millions d'applications, l'IA est devenue un levier de différenciation évident. Les utilisateurs se sont habitués aux expériences personnalisées et aux interfaces qui comprennent le langage courant : une application qui oblige encore à traverser douze menus pour trouver une information paraît datée face à celle qui répond directement à la question.
L'effet joue aussi dans l'autre sens. Un chatbot ajouté à une application qui ne résout rien laisse le problème entier, et ajoute une facture d'API. L'IA amplifie une proposition de valeur existante : il lui faut un vrai problème à résoudre.
Notre position, après 12 ans de projets mobiles : une fonctionnalité IA se juge comme n'importe quelle fonctionnalité. Quel problème résout-elle, pour qui et à quelle fréquence ? Que se passe-t-il quand elle se trompe ? Si ces questions restent sans réponse claire au cadrage, la fonctionnalité attend la version suivante.
Au-delà des quatre familles présentées en haut de page, voici les usages que nous voyons fonctionner dans des applications en production, face à de vrais utilisateurs et à de vraies contraintes de coût.
C'est l'usage le plus déployé. Un assistant relié à la documentation, au catalogue ou à l'historique du client répond aux questions courantes à toute heure, dans plusieurs langues. Bien conçu, il absorbe une large part des demandes de premier niveau et transmet les cas complexes à un humain avec tout le contexte. Mal conçu, il invente des réponses. D'où l'importance de le restreindre à vos propres contenus, avec la technique dite RAG (génération augmentée par la recherche), plutôt que de le laisser improviser.
Rien à voir avec le champ de discussion générique déconseillé plus haut : ici, l'assistant répond sur un périmètre précis, à partir de sources qu'il peut citer. Notre guide du chatbot IA de support client détaille cette architecture.
Moteur historique de Netflix, Spotify ou Amazon, la recommandation reste l'un des usages les plus rentables : proposer le bon contenu, le bon produit ou le bon parcours au bon moment. Sur une application de commerce ou de contenu, elle se mesure directement en rétention et en panier moyen. Elle ne demande d'ailleurs pas forcément un LLM : des modèles de recommandation classiques, plus légers et moins chers, font souvent mieux.
Extraire les champs d'un document, reconnaître un produit en rayon, estimer l'état d'un bien à partir de photos, vérifier une pièce d'identité : la vision est partout dans les applications métier. Le mobile y a un avantage naturel, puisque l'appareil photo est déjà dans la poche de l'utilisateur. L'extraction depuis une photo, décrite plus haut, en est la forme la plus simple et la plus vite rentabilisée.
La transcription automatique est désormais assez fiable pour la production : comptes rendus dictés par des techniciens sur le terrain, notes vocales transformées en tâches, traduction quasi instantanée. Pour une application utilisée debout, en déplacement ou avec des gants, la voix est souvent une meilleure interface que le clavier.
La méthode est celle de tout projet bien mené, avec quelques questions propres à l'IA. Elle prolonge les cinq étapes clés de la conception d'une application mobile : l'IA se décide au cadrage, avant le développement.
Définissez précisément ce que l'IA doit accomplir et comment vous mesurerez sa réussite : taux de résolution d'un assistant, précision d'une extraction, temps gagné sur une saisie. Cette étape conditionne tout le reste. Un objectif flou, du type « améliorer l'expérience avec de l'IA », produit presque toujours une fonctionnalité gadget.
Ce qui a le plus changé ces derniers temps : de vrais modèles tournent désormais directement sur le téléphone, sans serveur. Sur iOS, Apple ouvre aux développeurs son modèle de langage embarqué avec le framework Foundation Models depuis iOS 26, sur les appareils compatibles Apple Intelligence : inférence gratuite, hors ligne, sans que les données quittent l'appareil. Sur Android, Gemini Nano est accessible par les API d'IA générative de ML Kit (résumé, reformulation, description d'images), là aussi sur les appareils compatibles. Core ML et LiteRT (l'ancien TensorFlow Lite) permettent d'embarquer vos propres modèles.
Les modèles les plus puissants, ceux d'OpenAI, d'Anthropic, de Google ou de Mistral, restent appelés par API : indispensables pour les tâches complexes, le raisonnement long ou les grandes bases de connaissances. Le comparatif des trois options, avec leurs limites, figure plus haut sur cette page ; en pratique, les architectures solides sont souvent hybrides.
Une fonctionnalité IA consomme et produit des données, souvent personnelles. Il faut décider au cadrage ce qui est envoyé au modèle, où il est hébergé, combien de temps les échanges sont conservés et comment l'utilisateur en est informé.
Le règlement européen sur l'IA (AI Act), entré en vigueur le 1er août 2024, s'applique par étapes. Pour une application, l'échéance qui compte le plus est celle des obligations de transparence, en vigueur depuis le 2 août 2026 : dire qu'une IA intervient et signaler les contenus qu'elle produit. Notre article sur l'IA Act et les obligations d'une application détaille le calendrier. Ces exigences rejoignent celles que nous appliquons déjà à la sécurité des applications mobiles : chiffrement, minimisation des données, hébergement maîtrisé.
Ces coûts ont fortement baissé. D'après le rapport AI Index 2025 de l'université Stanford, le coût d'interrogation d'un modèle du niveau de GPT-3.5 a été divisé par plus de 280 entre novembre 2022 et octobre 2024. Pour beaucoup d'applications, la facture se compte désormais en dizaines d'euros par mois.
Un coût par requête, même faible, reste pourtant variable : il grandit avec votre succès. Il se modélise donc au cadrage (utilisateurs actifs, requêtes par session, longueur des réponses), avant la mise en ligne. Notre article sur le coût d'intégration d'une IA dans une application détaille le calcul.
Un modèle d'IA se trompe, et l'application doit être conçue pour que l'erreur soit rattrapable : réponses sourcées, validation humaine sur les actions sensibles, correction possible en un geste. Ce travail d'intégration, de test et d'itération relève du développement mobile classique. C'est lui qui transforme une démonstration en produit.
L'intelligence artificielle est passée du statut d'argument marketing à celui de brique standard du développement mobile : les outils sont mûrs, les coûts ont fondu et les plateformes l'intègrent nativement. Ce qui fait la différence, c'est la qualité du cadrage : un cas d'usage précis, une architecture adaptée (embarquée, cloud ou hybride), des données traitées proprement et des coûts modélisés dès le départ.
Nous développons des applications mobiles sur mesure depuis 2014 et nous intégrons l'IA quand elle sert le projet. Pour situer le budget du socle applicatif, notre estimateur de prix donne un ordre de grandeur en quelques minutes.
Questions fréquentes
Pour le reste du projet mobile (technologies, Stores, coûts, délais), tout est sur le pilier agence mobile.
Posez-vous une question simple : y a-t-il, dans votre application, un moment où l'utilisateur saisit, cherche ou relit quelque chose de façon répétitive ? Si oui, il y a probablement un gain mesurable. Sinon, l'IA ajoutera de la complexité, du coût récurrent et un risque d'erreur, sans contrepartie.
Tout dépend d'abord du socle : l'IA s'ajoute à une application qu'il faut de toute façon concevoir, développer et maintenir, et nos fourchettes de prix détaillent ce socle. Une fonction d'extraction ou de recherche intelligente bien délimitée représente ensuite, en général, 4 à 12 k€ de développement supplémentaire. S'y ajoute un coût d'usage mensuel, souvent plus déterminant : nous le modélisons avec vous sur votre volume réel avant tout engagement. Un modèle entraîné sur mesure avec vos données demande un investissement nettement supérieur, rarement justifié pour une première version.
Regardez la fréquence, la sensibilité et la difficulté de la tâche. Une tâche fréquente, simple ou qui touche des données sensibles gagne à tourner sur le téléphone : hors ligne, sans coût par requête, sans transfert de données. Une tâche complexe, qui demande du raisonnement ou une grande base de connaissances, passe par un modèle appelé en ligne, avec un coût variable et une dépendance au réseau. Beaucoup de projets combinent les deux, l'un servant de repli à l'autre.
Cela dépend de ce qui part et de ce que vous en dites. Une photo de compteur n'est pas un dossier médical. Selon la sensibilité, on anonymise avant l'envoi, on choisit un modèle hébergé en Europe, ou on reste sur un modèle embarqué. Cette décision se prend au cadrage, avant la première ligne de code.
Il se trompera, c'est une certitude. L'interface doit le prévoir : montrer ce qui a été compris, permettre la correction en un geste, et ne jamais valider seule une action engageante. Sur mobile, où l'attention est courte, cette correction doit tenir en un écran.
Oui, et c'est souvent la bonne façon de faire : vous savez déjà où vos utilisateurs perdent du temps. Nous commençons par un audit de l'existant pour vérifier que l'architecture le permet sans tout remettre à plat.
Votre cas d'usage
Trente minutes pour vérifier si l'IA apporte vraiment quelque chose à cet endroit, estimer le coût d'usage sur votre volume et repérer les contraintes de données. Parfois, la conclusion est qu'il ne faut pas d'IA : nous vous le dirons.