L'IA dans une application mobile
Sur mobile, l'IA doit 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 traite de l'IA ajoutée à une application mobile. Si l'IA est le cœur de votre produit plutôt qu'une fonction parmi d'autres, c'est un sujet différent — et une autre page.
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 marche vraiment
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 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 — pas sur 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, pas davantageEnvoyer 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é après la nouveauté, et il déplace la charge sur l'utilisateur au lieu de la lui retirer : il doit maintenant 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 n'est pas une option : c'est 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 ».
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.
Une fonction d'extraction ou de recherche intelligente bien délimitée représente en général 8 à 20 k€ de développement supplémentaire, plus le coût d'usage mensuel. Ce dernier est le vrai sujet : il faut le modéliser sur votre volume réel avant de s'engager.
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é. C'est une décision de cadrage, pas un détail d'implémentation.
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 — on vous le dira.