Appels téléphoniques par agent IA : MCP ou composeur Android avec FoneClaw

Un agent IA peut-il passer des appels ?

Oui, mais l’expression appels téléphoniques par agent IA recouvre trois réalités différentes. Première possibilité : un agent utilise un service cloud de téléphonie, avec son propre numéro de service, pour lancer ou recevoir des appels. Deuxième possibilité : un agent Android ouvre le composeur du téléphone avec le bon numéro, puis l’utilisateur reste dans le workflow visible du téléphone. Troisième possibilité : un assistant vocal ou conversationnel aide à préparer l’appel, tandis que l’utilisateur conduit l’échange.

Cette distinction permet de choisir le bon outil. Dire qu’un agent peut appeler ne précise pas encore quelle identité téléphonique est utilisée, quel réseau transporte l’appel, qui parle pendant la conversation, ni quel appareil affiche la confirmation. Un service d’appel MCP peut donner une identité téléphonique cloud à l’agent. FoneClaw, de notre côté, traite le cas Android : aider l’utilisateur à appeler depuis son propre téléphone, avec des outils gouvernés, des permissions en contexte et une action visible dans le composeur.

Dans cet article, nous comparons surtout deux chemins : les appels via MCP avec une identité cloud, et le workflow FoneClaw qui ouvre le composeur Android pour appeler un contact avec un agent.

Comment fonctionnent les appels via MCP

MCP, pour Model Context Protocol, est un standard ouvert qui permet à une application IA de se connecter à des systèmes externes, des données, des outils et des workflows. La présentation officielle de MCP le décrit comme une couche de connexion entre une application IA et des capacités extérieures. MCP sert donc à exposer des outils ; la téléphonie elle-même vient du service connecté.

Un service d’appel peut utiliser MCP pour rendre la téléphonie accessible à un agent. La documentation produit de Dial présente par exemple un service qui donne à un agent IA un numéro de téléphone de service pour les appels et messages. Dial expose ses capacités via MCP, REST, CLI ou SDK, avec des fonctions autour des appels vocaux sortants, de la réception d’événements entrants, de SMS et de WhatsApp selon le périmètre du service.

Le détail important est l’identité. Dans ce modèle, l’agent appelle depuis un numéro fourni par le service cloud, distinct de la carte SIM Android de l’utilisateur. Cela peut être très utile pour un agent de support, une automatisation métier, un suivi commercial ou un assistant capable de recevoir des appels entrants. Le téléphone personnel de l’utilisateur peut rester hors du chemin d’exécution de l’appel.

Le workflow ressemble donc à ceci : l’agent reçoit une demande, choisit l’outil exposé par le service d’appel, fournit le numéro cible ou le scénario, puis le service cloud place l’appel depuis son infrastructure. Les journaux, coûts, règles de conformité, disponibilité des pays et capacités vocales dépendent alors du service choisi. MCP rend l’outil appelable par l’agent ; le service comme Dial fournit la téléphonie.

Ce qui change avec Android ACTION_DIAL

Android propose un autre modèle, beaucoup plus proche de l’utilisateur et de son appareil. La référence officielle Android ACTION_DIAL indique que cette action affiche l’interface du composeur avec le numéro fourni. L’utilisateur peut alors initier explicitement l’appel depuis le composeur. L’identité d’appel, l’opérateur et l’historique appartiennent alors au téléphone Android.

ACTION_DIAL est important pour les agents parce qu’il garde l’appel dans une interface familière. Le numéro est préparé, le composeur s’ouvre, et l’utilisateur voit ce qui va être appelé. Android recommande généralement ACTION_DIAL pour la plupart des applications plutôt qu’un appel direct avec ACTION_CALL, car le composeur donne une étape visible à l’utilisateur.

Ouvrir le composeur prépare l’appel ; la connexion téléphonique vient ensuite. Il y a donc au moins deux états à distinguer : le numéro affiché dans le composeur, puis l’appel effectivement lancé. Un agent IA pour composeur Android doit montrer ou vérifier le bon numéro, laisser l’utilisateur comprendre la cible, puis agir dans le cadre prévu. Le contact, le numéro et le bouton d’appel sont des éléments centraux du workflow.

Ce modèle convient quand l’utilisateur veut appeler depuis son propre téléphone : le numéro sortant, le journal d’appels, les règles de l’opérateur et l’interface Android appartiennent alors au smartphone. Pour une explication plus large des actions Android gouvernées, notre guide Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire détaille comment un agent passe de l’intention à une action visible et vérifiable.

Comment FoneClaw appelle un contact sur Android

Chez FoneClaw, nous traitons l’appel Android comme une action gouvernée. Un modèle configuré dans FoneClaw comprend la demande, par exemple “appelle Marie” ou “rappelle le dernier appel manqué”. FoneClaw vérifie ensuite quelle capacité Android est nécessaire : lecture de contacts, lecture du journal d’appels ou composition d’un numéro direct. Le modèle planifie, puis FoneClaw contrôle l’action sur le téléphone.

Le chemin par contact nommé commence par la résolution d’identité. Si l’utilisateur dit “appelle Julie”, FoneClaw cherche le contact correspondant. La lecture filtrée des contacts demande la permission Android adaptée et une approbation, car les contacts sont des données personnelles. Si un seul contact correspond clairement, FoneClaw peut préparer ce numéro. Si plusieurs contacts correspondent, le workflow demande à l’utilisateur de choisir la bonne personne.

Le chemin par numéro direct est plus simple : l’utilisateur fournit un numéro ou une demande non ambiguë. FoneClaw peut alors préparer l’action de composition. Pour un rappel depuis un appel manqué, FoneClaw consulte les appels récents après permission de journal d’appels et approbation. Dans tous les cas, l’objectif est de résoudre une cible claire avant d’ouvrir le composeur.

L’action de composition elle-même est à effet externe : elle prépare un appel vers une personne ou un numéro. Elle demande donc une approbation. Dans le workflow actuel, FoneClaw ouvre un numéro unique ou un contact résolu de manière unique, puis passe par l’interface visible du téléphone. Après l’ouverture du composeur, FoneClaw lit l’écran visible et agit sur le bouton d’appel visible. Cette séquence garde le numéro, l’écran et l’effet dans le champ de contrôle de l’utilisateur.

Le rôle de FoneClaw s’arrête au workflow Android de composition pris en charge : comprendre l’intention, résoudre la cible, appliquer les permissions et approbations, ouvrir le composeur visible et avancer l’action de composition. Une fois l’appel connecté, l’utilisateur conduit la conversation vocale sur son téléphone. Pour les questions liées à un assistant particulier, notre page Grok peut-il contrôler un téléphone Android ? Réponse claire avec FoneClaw explique aussi pourquoi le modèle et le contrôle du téléphone restent deux couches distinctes.

Appels MCP ou contrôle du composeur Android

Un service d’appel MCP et FoneClaw répondent à deux besoins différents. Le premier donne à un agent une identité téléphonique cloud. Le second aide l’utilisateur à utiliser son propre téléphone Android. Les deux chemins peuvent être utiles lorsque l’identité d’appel, le lieu d’exécution et le rôle de l’utilisateur sont clairs.

Premier scénario : une équipe veut qu’un agent appelle des prospects depuis un numéro de service et traite aussi des événements entrants. Un service comme Dial, exposé via MCP ou API, correspond mieux à ce besoin. L’appel appartient alors à l’identité cloud de l’agent, pas au smartphone personnel d’un utilisateur.

Deuxième scénario : l’utilisateur dit “appelle mon dentiste” sur son téléphone Android. Il veut utiliser son propre composeur, son contact local et son opérateur. FoneClaw est le chemin pertinent : résoudre le contact, demander les accès nécessaires, ouvrir le composeur et garder le geste d’appel visible. Le bon choix dépend donc de l’identité qui doit appeler : le service agentique ou le téléphone de l’utilisateur.

Permissions, approbations et risque de mauvais contact

Les appels exigent une attention particulière parce qu’une erreur se voit immédiatement : mauvais contact, mauvais numéro, mauvais contexte ou appel lancé trop tôt. FoneClaw traite donc la résolution de cible comme une étape essentielle. Si un nom correspond à plusieurs contacts, le workflow demande à l’utilisateur de choisir. Appeler “Paul” exige de distinguer Paul Martin, Paul du travail et Paul famille avant toute action.

Les permissions restent séparées de l’approbation. La permission de contacts autorise la lecture nécessaire pour résoudre une personne. La permission de journal d’appels permet de retrouver un appel récent. L’approbation de l’action, elle, répond à une autre question : voulez-vous appeler ce numéro maintenant ? Cette séparation est particulièrement importante dans les appels, car la cible et le moment comptent autant que la permission technique.

Pour les appels d’urgence, utilisez directement les moyens d’appel prévus localement et suivez les procédures de votre pays. Un workflow agentique de confort sert aux appels ordinaires et vérifiables, pas aux situations où chaque seconde, la localisation et les règles de télécommunication peuvent être déterminantes.

Pour les usages mains libres, par exemple en voiture, le niveau de sécurité dépend aussi du contexte. Notre guide Commandes vocales en voiture : guide Android plus sûr traite les précautions propres à la conduite. Pour la gouvernance générale des actions sensibles, Identité des agents IA : permissions, approbation par outil et piste d’audit explique pourquoi chaque action doit rester attribuable et contrôlable.

Choisir le bon workflow d’appel par agent IA

Choisissez le workflow selon l’identité qui doit appeler. Si vous voulez qu’un agent professionnel possède son propre numéro, reçoive des événements entrants et utilise des outils cloud, un service d’appel connecté via MCP ou API est le bon point de départ. Si vous voulez appeler depuis votre téléphone Android, avec vos contacts et votre composeur, utilisez un workflow local gouverné comme celui de FoneClaw.

Dans FoneClaw, vous pouvez utiliser le modèle gratuit par défaut ou configurer un modèle compatible à l’intérieur de l’agent. Le modèle comprend la demande ; FoneClaw gère les outils Android, les permissions et l’action visible. D’après les informations FoneClaw actuellement disponibles, FoneClaw ajoute les contrôles par outil, les remplacements d’approbation, la récupération de permissions et une meilleure gestion des échecs, ce qui aide à garder les appels dans un parcours lisible.

Pour tester avec méthode, commencez par un contact connu et non ambigu. Demandez à FoneClaw de préparer l’appel, vérifiez le numéro affiché, observez le composeur, puis confirmez seulement si la cible est correcte. La page Fonctionnalités FoneClaw présente plus de 100 outils intégrés, dont les capacités utiles pour les workflows Android de communication et d’action visible. Le principe reste simple : l’agent aide à atteindre le bon écran, l’utilisateur garde le contrôle de l’appel.