Combien coûte une application d'assistant personnel avec IA ?

Décrire le service rendu avant de choisir le modèle

La première démonstration produit facilement son petit effet. Une demande apparaît, la réponse est fluide et l'on imagine déjà un assistant qui remet de l'ordre dans la semaine. Puis arrive un mardi ordinaire : deux agendas se contredisent, une réunion vient de bouger et personne n'a décidé si « décale le rendez-vous » signifie proposer un horaire ou prévenir réellement six personnes.

C'est là que le dialogue devient un produit. L'application doit reconnaître la bonne personne, choisir une source à jour, limiter ce qu'elle mémorise, demander une validation et expliquer une action restée à moitié exécutée. À notre avis, ces décisions discrètes comptent davantage que l'élégance de la fenêtre de conversation.

Elles expliquent aussi l'écart entre les budgets. Résumer un texte fourni par l'utilisateur reste une fonction étroite. Consulter un agenda, créer le rendez-vous et retenir une préférence engage des comptes, des droits et des conséquences. Les deux paraissent proches pendant cinq minutes de démonstration ; ils ne le sont plus après une semaine d'utilisation.

Ce guide traite ce deuxième cas. Pour comparer plus largement modèles, données, évaluation et consommation, consultez le coût de développement d'une application avec IA. Pour explorer les usages possibles, lisez les fonctions IA utiles dans une application mobile.

« Aider l'utilisateur à mieux s'organiser » est une belle ambition, mais elle laisse l'équipe sans prise. « Transformer une note vocale en trois créneaux et demander une validation avant d'ajouter le rendez-vous » devient un service que l'on peut observer. Réduire ainsi la promesse ne réduit pas la valeur ; cela évite simplement de prendre une intention séduisante pour une fonction terminée.

Un bon premier cas d'usage peut aussi répondre à partir d'un cours validé, préparer une réponse en tenant compte du statut réel d'une commande ou produire une liste de courses avec des préférences expressément enregistrées. Il doit être assez précis pour réunir des exemples de réussite et d'échec.

Reste la question qui met souvent la discussion sous tension : l'assistant propose-t-il ou agit-il ? Rédiger un message n'est pas l'envoyer. Nous préférons généralement laisser la dernière validation à la personne dans la première version, le temps d'observer les erreurs réelles. Ce n'est pas brider l'IA ; c'est choisir le moment où l'autonomie devient enfin méritée.

Trois niveaux de produit à ne pas confondre

Le niveau intermédiaire convient à beaucoup de MVP. Il permet une personnalisation réelle et des propositions fondées sur des données actuelles. Les opérations qui engagent l'utilisateur restent protégées par un écran de confirmation.

La conversation n'est que la façade

Un assistant fiable sépare cinq responsabilités. Le modèle comprend la demande. Le serveur vérifie l'identité et les droits. La mémoire fournit uniquement le contexte autorisé. Les connecteurs lisent ou modifient les services extérieurs. Enfin, les journaux et les mesures permettent de savoir ce qui s'est passé et combien l'opération a coûté.

Une consigne adressée au modèle ne remplace pas une règle applicative. Le modèle peut proposer d'appeler un agenda, mais un code contrôlé doit vérifier l'utilisateur, les paramètres, le droit d'accès et le besoin de confirmation. De même, les clés des fournisseurs ne doivent pas être placées dans l'application installée.

Cette couche serveur applique les quotas, réduit les données envoyées, gère les délais et permet de changer de fournisseur. Le même principe est détaillé dans notre guide sur le coût des intégrations API d'une application mobile.

Concevoir la mémoire comme un espace administrable

La mémoire apporte une continuité appréciable. L'assistant peut retenir la durée habituelle d'une réunion ou le format préféré d'un compte rendu. Mais conserver toute la conversation sans distinction accumule du bruit et des informations que l'utilisateur ne s'attendait pas à retrouver plus tard.

Il vaut mieux distinguer le contexte de la session, les préférences approuvées, les données métier consultées à leur source et l'état temporaire d'une tâche. Chaque catégorie possède une durée, une façon d'être corrigée et une règle de suppression. L'écran « Ce que l'assistant retient » donne une réalité concrète à ce contrôle.

Une réponse issue d'un document ou d'un dossier client devrait aussi indiquer sa provenance. L'utilisateur peut alors repérer une source périmée au lieu d'attribuer toute erreur au modèle.

Le parcours Google sur les agents personnalisés avec mémoire présente plusieurs niveaux de mémoire plutôt qu'un historique sans fin. L'article de Microsoft Guarding AI memory montre que cette persistance devient elle-même une surface à protéger.

Pour un MVP, mieux vaut mémoriser peu de choses, mais les rendre visibles et modifiables. Les préférences sensibles doivent être enregistrées avec une intention claire, pas déduites silencieusement de chaque échange.

Encadrer les outils avant de les connecter

Chaque intégration devrait répondre à quatre questions : quelles informations l'assistant peut-il lire, que peut-il suggérer, que peut-il exécuter et quelles opérations exigent une validation humaine ? Cette grille évite de réduire une « connexion au CRM » ou une « connexion à l'agenda » à une seule ligne du devis.

Il faut ensuite prévoir l'incident. Un service peut répondre lentement, retourner un état ancien ou accepter la demande au moment où l'application affiche une erreur. Les opérations d'écriture ont donc besoin d'un identifiant unique, d'une vérification du résultat et, si possible, d'une annulation ou d'un parcours de réparation.

Les risques recensés par OWASP pour les applications génératives deviennent ici très pratiques. Un document récupéré sur le web ne doit pas pouvoir étendre les pouvoirs de l'assistant. La sortie d'un modèle doit être validée avant d'atteindre un autre système. Un compte ne doit pas pouvoir déclencher une consommation illimitée.

Paiements, publications publiques, droits d'accès et changements de compte méritent une confirmation explicite. L'utilisateur doit voir l'opération exacte, pas seulement un message rassurant.

La voix et l'initiative changent l'expérience

Un bouton de microphone ne suffit pas à créer un assistant vocal. L'enregistrement, la transcription, l'interruption, la lecture, les corrections et les différents états d'autorisation doivent être conçus. Le bruit, les accents, les silences et les mauvaises connexions révèlent vite les limites d'une démonstration trop propre.

La voix augmente aussi le délai et la consommation, car plusieurs traitements s'enchaînent. Si elle est indispensable au concept, testez-la tôt avec de vraies situations et une alternative visuelle.

L'initiative est un autre chantier. Une notification choisie par l'utilisateur est prévisible. Un assistant qui décide de relancer a besoin d'horaires calmes, de limites de fréquence, d'une raison explicite et d'un apprentissage après un refus. Commencer par des événements objectifs, comme un rendez-vous proche ou un paiement échoué, reste plus prudent.

Budget de développement

Appfyl utilise des repères pour un produit mobile complet. Ces fourchettes décrivent notre manière de planifier, pas une moyenne universelle du marché.

Une seule tâche, un modèle existant, une source limitée et aucune action sensible peuvent rester dans le premier niveau. La mémoire persistante, plusieurs rôles, la voix, les abonnements, l'administration et plusieurs services extérieurs conduisent plutôt au deuxième. De nombreuses actions, des données sensibles, un modèle sur mesure ou une exécution sur l'appareil augmentent encore les besoins de test et de sécurité.

Le guide français de Forgit sur le coût d'un agent IA souligne lui aussi l'écart entre une chaîne déterministe et une architecture plus autonome. Une proposition sérieuse doit expliquer ce choix au lieu d'additionner des « agents » sans démontrer leur utilité.

Ne pas confondre réalisation et consommation

La dépense mensuelle dépend des utilisateurs actifs, des tâches par utilisateur, des appels nécessaires à chaque tâche et du coût moyen d'un appel. S'ajoutent la voix, les recherches, les fichiers, le stockage, l'hébergement, les journaux, la surveillance et les services tiers.

coût mensuel = utilisateurs actifs x tâches x appels par tâche x coût moyen d'un appel

Préparez un scénario bas, un scénario attendu et un scénario haut. Incluez les demandes ambiguës et les échecs, car un parcours qui finit au support peut avoir consommé plusieurs appels auparavant.

Les limites doivent exister dès la première version : longueur maximale du contexte et de la réponse, nombre d'étapes, quota par compte et alerte en cas de hausse. Les tâches simples peuvent utiliser un modèle moins coûteux. Les résultats approuvés et répétitifs peuvent être mis en cache.

Construire un MVP que l'on peut évaluer

Avant le développement, rassemblez vingt à cinquante demandes réelles. Pour chacune, notez les données autorisées, le résultat attendu, le résultat interdit et le moment où une personne doit confirmer. Ce jeu d'essai donne une définition concrète de la qualité.

Connectez ensuite une seule source et une seule action importante. Un assistant pédagogique peut répondre depuis des leçons publiées et ouvrir le bon passage. Un assistant de rendez-vous peut trouver des créneaux et préparer l'inscription. Les autres outils attendront une preuve d'usage.

Mesurez les propositions acceptées, les corrections, les actions terminées, les annulations et les transferts vers un humain. Le nombre de messages n'est pas un indicateur de réussite si l'utilisateur doit tout vérifier.

Le guide d'Anthropic Building effective agents conseille de commencer par le mécanisme le plus simple qui fonctionne et de distinguer les parcours prévisibles des agents ouverts. C'est également une bonne discipline de produit.

Vie privée et confiance

Messages, voix, localisation, contacts, fichiers et historique de compte peuvent tous devenir des données de l'assistant. Pour chaque catégorie, le produit doit expliquer l'usage, le fournisseur éventuel, la durée et le moyen de suppression. Autoriser le microphone n'autorise pas automatiquement la conservation des enregistrements.

La préparation de la politique de confidentialité et la check-list de sécurité mobile doivent accompagner l'architecture. Réduire les données au départ coûte moins cher que reprendre les flux à la veille de la publication.

La confiance repose aussi sur des états clairs. Une proposition, une opération en cours et une opération confirmée ne doivent pas se ressembler. Lorsque l'assistant ne peut pas vérifier le résultat, l'application doit proposer une recherche classique, un formulaire ou un contact humain.

L'approche Appfyl

Appfyl part du service rendu, des données autorisées et de la conséquence d'une erreur. Le chiffrage sépare l'expérience mobile, le serveur, la mémoire, les sources, les outils, les validations, les essais, les mesures et les services récurrents. Il précise également ce que le MVP ne pourra pas faire.

Décrivez une tâche, sa source et l'action attendue dans l'outil d'estimation Appfyl. Cette limite permet de discuter d'un premier produit concret plutôt que d'un assistant universel impossible à vérifier.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes