Un softphone est un logiciel qui passe et reçoit des appels à la place d’un combiné, en s’appuyant sur le protocole SIP. L’embarquer dans votre propre application mobile ajoute quatre chantiers au cahier des charges : les autorisations système, le réveil en arrière-plan, la journalisation des appels et leur enregistrement. Chacun se tranche avant le devis.
Passer un appel depuis l’application : deux chemins, deux devis
Deux architectures répondent à la même demande, et leurs conséquences n’ont rien de comparable. La première délègue : un lien de composition ouvre le clavier natif du téléphone, l’appel part sur le réseau de l’opérateur, votre application reprend la main une fois raccroché. La seconde embarque la voix : l’application porte un client SIP, la conversation transite par les données mobiles, et le logiciel garde le contrôle du numéro présenté, de la mise en attente et du transfert.
Le choix se paie ailleurs que sur la facture de développement. Un lien de composition coûte quelques heures et ne réclame aucune autorisation micro, mais votre appli ne saura jamais si l’échange a duré douze secondes ou onze minutes. En face, la journalisation, l’enregistrement et la présentation du numéro d’entreprise n’existent qu’avec un softphone embarqué, au prix d’une pile audio à maintenir sur deux systèmes.
Cinq points tranchent la question dans un cahier des charges :
- Le numéro présenté à votre correspondant : ligne de l’entreprise ou mobile du salarié
- Le réseau emprunté par la voix : données mobiles, Wi-Fi ou réseau de l’opérateur
- Le comportement attendu quand la couverture tombe pendant la conversation
- Le sort de l’appel en cours lorsqu’un appel classique arrive au même moment
- La sortie audio par défaut : écouteur, haut-parleur ou casque Bluetooth
- La reprise de la conversation quand l’utilisateur change de réseau en cours d’appel
Ces deux chemins ne se chiffrent pas de la même façon, et l’écart se creuse bien avant la première ligne de code. Un devis qui mentionne « appel intégré » sans dire lequel des deux scénarios il couvre vous engage sur un malentendu coûteux.
La parade tient en trois gestes peu coûteux : écrire le scénario retenu dans le cahier des charges, faire estimer le budget correspondant, puis comparer les prestataires capables de le tenir près de chez vous. Un modèle de cahier des charges déroulé ligne à ligne, puis un avis technique demandé à des spécialistes du développement mobile, valent mieux qu’un arbitrage repoussé après le développement, qui se paie en refonte. La suite déroule les fonctions une à une.
Recevoir un appel quand l’application est fermée
Un utilisateur qui ferme votre application ne s’attend pas à rater ses appels. Le problème tient en une phrase : votre code ne tourne plus, et seul le système d’exploitation sait le réveiller.
iOS : le push VoIP doit déclencher l’appel dans la seconde
Apple réserve un canal de notification aux appels, PushKit, et l’assortit d’une contrainte stricte depuis iOS 13 : à la réception du push, l’application signale l’appel entrant à CallKit immédiatement, à l’intérieur même du gestionnaire. Négliger ce signalement expose à la coupure pure et simple des pushs VoIP par le système. Les règles de revue d’Apple suivent la même logique, leur point 2.5.4 réservant les services d’arrière-plan à leurs usages prévus, les appels VoIP figurant en tête de la liste autorisée.
Android : réveiller le téléphone malgré l’économie d’énergie
Le réveil passe par une notification de priorité haute. La documentation de Firebase Cloud Messaging distingue deux niveaux : les messages de priorité normale sont regroupés et remis quand l’appareil sort de veille, ceux de priorité haute sont remis sans attendre, y compris lorsque le mode Doze est actif. La sonnerie d’un appel entrant VoIP relève du second cas.
Vient ensuite le service au premier plan qui portera l’audio. Depuis Android 14, chaque service au premier plan déclare son type dans le manifeste et demande l’autorisation correspondante, faute de quoi l’application s’arrête net. Android 15 interdit en plus de démarrer un service d’appel depuis le récepteur de démarrage de l’appareil. La bibliothèque Core-Telecom et l’autorisation MANAGE_OWN_CALLS déclarent enfin vos appels au gestionnaire de téléphonie, qui arbitre le routage audio avec les communications en cours.
À inscrire au cahier des charges :
- Le délai maximal toléré entre l’émission du push et la sonnerie
- Le comportement observé sous les modes d’économie propres à chaque constructeur
- L’écran attendu lorsque le téléphone est verrouillé
- La bascule vers la messagerie vocale au bout d’un nombre de sonneries fixé
- La trace serveur des notifications restées sans accusé de réception
Demander les autorisations sans perdre l’utilisateur
Chaque fonction d’appel déclenche une boîte de dialogue système, et chaque refus laisse une fonctionnalité morte. Le micro conditionne la conversation, les notifications conditionnent la sonnerie, les contacts conditionnent la reconnaissance de l’appelant. Depuis Android 13, l’envoi de notifications repose lui aussi sur une autorisation demandée à l’exécution : sans accord explicite, le système écarte silencieusement vos notifications, sonnerie comprise.
Les deux boutiques encadrent la formulation de ces demandes. Apple exige au point 5.1.1 de ses règles de revue des textes d’explication décrivant clairement et complètement l’usage fait des données. Google Play limite les autorisations sensibles à ce qui sert la fonction principale annoncée sur la fiche, et demande de retenir la portée la plus étroite possible.
Le journal d’appels, l’autorisation la plus verrouillée
La règle de Google Play sur les groupes d’autorisations SMS et journal d’appels ferme presque entièrement l’accès à l’historique natif : l’application doit être enregistrée comme gestionnaire par défaut du téléphone ou des SMS, sauf cas d’exception, et retirer ces autorisations de son manifeste dans le cas contraire. La conséquence se résume vite : votre softphone tient son propre journal, celui de ses propres appels.
Quatre lignes à écrire noir sur blanc :
- Le texte exact affiché dans chaque demande d’autorisation
- Le moment du déclenchement, au premier usage plutôt qu’au lancement
- L’écran de repli présenté quand l’utilisateur refuse
- La liste des autorisations réellement déclarées dans le manifeste
Relier l’appel à la fiche client et au journal
Un appel qui ne laisse aucune trace dans vos outils vaut à peine mieux qu’un appel passé depuis un mobile personnel. La valeur d’un softphone d’entreprise tient dans ce qu’il écrit après le raccroché. Le couplage entre standard et logiciels de gestion forme un sujet à part entière, traité dans notre article sur le branchement de la téléphonie au CRM et à l’ERP ; côté application maison, la question se déplace vers le contexte transporté.
Le contexte que le bouton d’appel doit transporter
Le click-to-call en donne la mesure. Un bouton posé sur une fiche client déclenche la composition, mais l’événement d’appel doit repartir avec l’identifiant du dossier ouvert au moment du clic. Sans lui, votre journal contiendra une liste de numéros et de durées, pas un historique exploitable dossier par dossier. Le technicien qui rappelle depuis une intervention attend exactement ce rattachement.
Cinq exigences suffisent à rendre le journal utile :
- L’identifiant du dossier transporté avec l’événement d’appel
- Le sens, la durée et l’issue consignés dès le raccroché
- Le motif choisi dans une liste fermée plutôt qu’en texte libre
- La synchronisation différée des appels passés hors couverture
- Le format international appliqué à tous les numéros de la base
Enregistrer une conversation dans les règles
L’enregistrement fait basculer votre projet dans le champ du droit des données personnelles. Le sujet s’arbitre au cadrage, pas au recettage.
Ce que la CNIL autorise, et pour combien de temps
La CNIL pose une limite nette : pas d’enregistrement permanent ni systématique des postes, en dehors des exceptions prévues par un texte. Les finalités admises restent la formation, l’évaluation et le pilotage de la qualité de service.
L’information des personnes conditionne le reste. Salariés et appelants doivent connaître l’existence du dispositif, sa finalité, la durée de conservation et leurs droits, l’appelant devant pouvoir s’y opposer avant la fin de la conversation. La CNIL fixe la conservation des enregistrements à six mois au maximum, et à un an celle des documents d’analyse qui en découlent ; l’accès reste réservé aux personnes habilitées, avec traçabilité des consultations, et une ligne non enregistrée doit rester disponible pour les appels personnels. Le cadre juridique complet figure dans notre guide sur ce que la loi autorise en matière d’enregistrement d’appel.
Reste la base légale, à choisir parmi celles de l’article 6 du RGPD avant l’écriture du code. Quand l’appel sert à conclure un contrat, la CNIL admet l’exécution du contrat comme fondement ; hors de ce cas, l’intérêt légitime suppose une mise en balance documentée avec les droits des personnes.
Où le flux se capte réellement
La technique suit le droit, pas l’inverse. Un enregistrement propre se capte là où la voix transite, donc côté plateforme si votre architecture embarque un client SIP, et devient à peu près impossible dès lors que l’appel a été délégué au clavier natif. L’arbitrage de la première section revient ici, avec ses conséquences.
Cinq points à verrouiller :
- Le lieu de captation du flux : terminal ou plateforme
- Le message d’information diffusé à l’ouverture de l’appel
- La commande de coupure de l’enregistrement à la demande
- La purge automatique des fichiers à six mois
- La liste nominative des comptes autorisés à réécouter
Protéger la voix et les comptes SIP
Une ligne logicielle volée sert immédiatement à passer des appels facturés. L’ANSSI, dans sa note technique de 2014 consacrée à la sécurisation d’une architecture de téléphonie sur IP, place l’isolation de l’infrastructure téléphonique et l’emploi de mécanismes cryptographiques au premier rang des mesures attendues.
Chiffrer la signalisation et le média séparément
Les flux d’un softphone mobile se protègent sur deux canaux distincts. TLS couvre la signalisation, donc les messages qui ouvrent, transfèrent et ferment les appels ; SRTP couvre les paquets de voix. Les deux se négocient avec l’opérateur au raccordement, pas après la mise en production.
Le stockage des identifiants mérite la même attention. Un compte SIP inscrit en dur dans le binaire de votre softphone se retrouve extrait en quelques minutes par qui sait ouvrir un paquet applicatif. La pratique saine consiste à provisionner un compte par utilisateur via une interface authentifiée, révocable depuis votre administration sans republier l’application.
Quatre garanties à exiger du prestataire :
- Le mode de stockage des identifiants de compte sur le terminal
- La procédure de rotation des mots de passe de ligne
- Le plafond de dépense paramétré par ligne chez l’opérateur
- La marche à suivre convenue en cas de compte compromis
Passer la revue des boutiques et déclarer les données
La publication forme une étape de projet, pas une formalité de fin de chantier. Apple impose de renseigner les informations de confidentialité avant toute mise en ligne comme avant chaque mise à jour, et Google Play exige le formulaire de sécurité des données accompagné d’une politique de confidentialité, une déclaration inexacte pouvant bloquer les mises à jour ou entraîner le retrait de l’application.
Une application qui cible Android 14 ou une version supérieure déclare en plus ses types de service au premier plan dans la console Google Play. Le relecteur doit ensuite constater la fonction par lui-même, et un softphone intégré ne se démontre pas sans ligne active : un compte de test et un numéro joignable évitent le refus le plus banal.
À prévoir dans le rétroplanning :
- La fiche de confidentialité remplie avant la première soumission
- La justification écrite de chaque autorisation sensible demandée
- Le compte de démonstration livré avec un numéro joignable
- Le délai de revue intégré au calendrier de mise en service
Le module générique contre l’intégration pensée pour votre métier
Trois versions successives d’Android ont modifié les règles décrites plus haut : les notifications en 13, les types de service au premier plan en 14, le démarrage des services d’appel en 15. Un module de téléphonie logicielle collé à la va-vite traverse mal ce rythme, parce que sa maintenance n’appartient à personne le jour où une boutique change ses conditions.
Une intégration pensée pour votre métier part du geste réel, puis remonte vers la fonction d’appel et vers le socle qui la porte. Le vocabulaire de base reste utile pour arbitrer : notre guide de la téléphonie sur internet pose les notions de SIP et de voix sur IP, et notre comparatif pour choisir une solution de téléphonie adaptée à une PME traite l’infrastructure opérateur sur laquelle votre application viendra se brancher. Les critères de notre guide pour choisir un smartphone professionnel cadrent la flotte de test.
Prochaine étape : reprendre les check-lists ci-dessus, cocher ce que votre cahier des charges couvre déjà, puis transmettre les lignes restées vides au prestataire avant de demander un chiffrage. Comptez une demi-journée de travail, contre plusieurs semaines de reprise si la question de l’appel arrive après la première version.