CallCoach, l’application que j’ai créée parce que je ne comprenais pas ce qu’on me disait

Il y a ce moment dans un appel de prospection : la personne a décroché, elle parle, tu hoches la tête. Mais à l’intérieur, c’est le silence. Tu n’as pas compris un mot.

Surtout si, à l’autre bout, il y a un Britannique avec un accent particulier ou un Indien qui parle très vite et avec beaucoup d’assurance. Ces deux situations étaient mon quotidien pendant mes premières semaines de courtier à Dubaï.

Je suis designer. Je sais concevoir des systèmes complexes. Je comprends le produit. Mais une conversation téléphonique avec un accent inconnu est une compétence à part, qui ne s’acquiert pas par la seule volonté.

J’aurais pu simplement m’entraîner et attendre. J’ai décidé de construire un outil.

Qu’est-ce que CallCoach ?

Une application iOS native en Swift, avec Apple Intelligence et Live Translation.

Pendant l’appel, elle reconnaît la parole de l’interlocuteur en temps réel et affiche le texte à l’écran. Elle analyse ce qu’il a dit et propose des indications : quoi répondre, comment poursuivre, quelle question poser.

Ce n’est pas de la transcription pour la transcription. C’est un assistant de scripts qui apparaît exactement quand il le faut, dans une conversation en direct, sans délai.

Pourquoi Swift et Apple Intelligence ?

J’aurais pu choisir n’importe quelle stack web. Mais le web n’offre ni la vitesse requise ni l’intégration native avec le microphone et les API système.

Apple Intelligence est un moteur de langage local, directement sur l’appareil. Aucune requête vers le cloud, aucune latence, aucune fuite des données de conversation. Tout reste sur le téléphone.

Live Translation traite l’anglais accentué avec la précision nécessaire. Exactement ce qu’il faut dans le Dubaï multinational.

Ce que cela a changé dans le travail

Quand on voit le texte de ce que dit l’interlocuteur, l’angoisse s’en va. On cesse de dépenser son énergie à se demander « qu’a-t-il dit ? » et on commence à réfléchir à « que répondre ? ».

Du mode survie au mode dialogue. Un changement fondamental.

Je continue à le développer. Prochaine étape : une base de scripts pour différents scénarios, premier appel, objection, précision du budget, prise de rendez-vous. Des suggestions qui ne seraient pas une simple transcription, mais une réponse contextuelle intelligente à une phrase précise.

Pourquoi j’en parle

CallCoach illustre ma façon de penser les produits.

Non pas « quelle technologie essayer ? », mais « quel problème résoudre ? ». Le problème était concret et personnel. La solution, native, rapide, sans dépendances superflues.

Un designer qui sait coder n’est pas un développeur. Mais c’est parfois précisément ce qui empêche une idée de mourir dans la file d’attente de sa réalisation.

Réalisation technique

Sur le plan technique, j’ai construit CallCoach comme un véritable outil de travail, pas comme un concept.

J’ai d’abord travaillé l’idée et l’architecture avec ChatGPT : défini le problème produit et le scénario utilisateur, puis préparé un long prompt initial pour Codex afin qu’il crée le projet Swift de base, installe les dépendances et construise une première ossature fonctionnelle.

Quand la fenêtre de tokens de Codex s’est épuisée, j’ai transféré le projet dans Claude Code. L’essentiel du développement, la partie consistante, s’est ensuite fait là, avec le modèle Opus 4.7.

Il s’est révélé très fort sur la durée en ingénierie : il réfléchit beaucoup, consomme beaucoup de tokens, mais tient bien l’architecture, écrit soigneusement du code cohérent et aide à rendre l’application fonctionnelle.

Ensuite, je passais régulièrement dans Xcode : je compilais, lançais les tests, repérais les plantages, renvoyais les erreurs à Claude Code et corrigeais avec lui les points problématiques. J’effectuais aussi certaines modifications directement dans Xcode, où j’avais également connecté Codex et Claude comme assistants sur place.

La logique de l’application

L’application est construite autour du traitement local de la parole sur l’appareil.

En mode normal, CallCoach peut écouter le flux du microphone et afficher une transcription en direct. Mais la décision technique clé a été de séparer les voix.

Le problème principal : lors d’un appel sur haut-parleurs, le microphone entend à la fois votre voix et celle de l’interlocuteur. La transcription mélange alors les deux côtés du dialogue et cesse d’être utile au coaching.

Pour résoudre cela, j’ai créé deux modes de fonctionnement.

Mode 1 — System Audio

C’est le mode principal et recommandé.

Avec ScreenCaptureKit, l’application capture la sortie audio du système, donc uniquement ce qui est envoyé aux haut-parleurs. Elle peut ainsi transcrire précisément la voix de l’interlocuteur sans capter la mienne au microphone.

On utilise également le paramètre excludesCurrentProcessAudio = true, pour exclure les sons de l’application elle-même.

Au premier lancement, macOS demande l’autorisation d’enregistrer l’écran : sans elle, la capture audio du système est impossible.

Mode 2 — Microphone + Push-to-Mute

C’est le scénario de secours.

Il utilise la capture classique du microphone, mais pendant que je parle, je peux maintenir un bouton pour suspendre l’envoi des buffers audio au transcripteur.

La logique est très simple : je parle, je maintiens le bouton ; j’ai fini, je le relâche, et l’application écoute de nouveau l’interlocuteur.

Ce qui a été écrit dans le code

L’architecture de l’application repose sur plusieurs gestionnaires distincts, chacun responsable d’une partie du pipeline.

AudioCaptureManager

Gère la capture audio via AVAudioEngine.

• utilise installTap sur inputNode
• startRecording() renvoie AsyncStream<AVAudioPCMBuffer>
• le flux de buffers est transmis sans problème de passage entre acteurs (actor crossing)
• le niveau du signal est calculé en parallèle par mesure RMS et en dB
• les mises à jour de l’interface sont envoyées à @MainActor via Task

SystemAudioCaptureManager

C’est une classe distincte que j’ai ajoutée pour capturer l’audio système via SCStream.

C’est elle qui a rendu possible une transcription limitée à la voix de l’interlocuteur sortant des haut-parleurs, au lieu de tout le bruit ambiant.

TranscriptionManager

Cette couche reçoit le flux de buffers audio et le transmet à SpeechAnalyzer du framework Speech.

Il parcourt ensuite AsyncThrowingStream<SpeechTranscriptionResult>, distingue les transcriptions partielles et finales et gère explicitement les passages vers @MainActor.

Il ne s’agit donc plus seulement de « reconnaître du son », mais d’intégrer soigneusement la transcription en continu dans une interface vivante.

CoachingEngine

C’est une couche logique distincte qui transforme une simple transcription en outil de conversation utile.

• processNewTranscript(_:) utilise un debounce de 1,5 seconde
• le précédent Task est annulé si un nouveau fragment de parole arrive
• LanguageModelSession est créée une fois par session, puis réutilisée
• l’historique du contexte est conservé
• le parseur analyse les réponses au format [TYPE] : texte avec un repli sur .phrase
• l’étape de la conversation est identifiée par mots-clés
• les quelque 300 derniers mots sont envoyés au modèle, plutôt que toute la transcription

J’ai aussi ajouté du contexte propre au marché de Dubaï : Emaar, DAMAC, Binghatti, ROI, réservation, rendez-vous, Zoom et autres signaux caractéristiques de ces conversations.

ContentView

C’est ici que tout est relié à l’interface utilisateur.

• .task demande l’autorisation du microphone au lancement
• .onChange(segments.count) déclenche coach.processNewTranscript
• toggleSession() transmet le flux et le format à startTranscription
• les erreurs des gestionnaires sont affichées via des gestionnaires distincts .onChange

C’est cette couche qui donne vie à l’ensemble de l’application : changement de source audio, démarrage et arrêt de session, logique de mise en sourdine, gestion des erreurs et actualisation des suggestions en temps réel.

Comment j’ai entraîné les suggestions

J’ai aussi nourri le système de contexte pratique.

Pour les appels de prospection, j’ai utilisé de véritables scripts de vente : accueil, maintien du dialogue, qualification initiale du client, clarification du budget, traitement des doutes et conclusion sur un rendez-vous ou un Zoom détaillé.

Ce n’étaient pas des modèles abstraits trouvés sur Internet, mais la logique que l’on nous enseignait à l’agence SPI Dubai.

Les suggestions sont ainsi devenues plus concrètes. Pas simplement « réponds quelque chose de poli », mais une suite de conversation dans la bonne structure et au bon stade.

Deuxième scénario : les entretiens de product designer

En parallèle, j’ai développé un second usage de cette approche : passer des entretiens de product designer.

Là, j’ai entraîné le système sur mes projets, mes cas et mon portfolio pour m’aider non en prospection, mais dans un autre type d’échange, où il faut répondre vite, avec assurance et de façon structurée aux questions sur sa propre expérience.

CallCoach est donc devenu bien plus qu’une application speech-to-text : un assistant conversationnel polyvalent, adaptable à un scénario de communication précis.

Le processus réel de développement

Et, pour être tout à fait honnête, c’est aussi pour moi un exemple important de ce qu’est aujourd’hui le développement réel d’un produit.

L’idée naît d’une difficulté personnelle.

L’architecture se construit rapidement avec l’aide des modèles de langage.

Le code difficile s’écrit en collaboration avec les agents.

La finition se fait à la main dans Xcode, à travers compilations, plantages, débogage et itérations successives.

Pas de « magie du réseau neuronal », mais un processus d’ingénierie normal, simplement accéléré par de nouveaux outils.

Journal des modifications / la construction de CallCoach

1. Formulation de l’idée

• J’ai identifié un problème précis : lors des appels de prospection avec des accents britanniques et indiens, une partie des paroles échappe tout simplement à la compréhension à l’oreille, faute de temps.
• J’ai défini la mission du produit : pas seulement transcrire la conversation, mais aider à la poursuivre.
• Avec ChatGPT, j’ai travaillé le concept, le parcours utilisateur et la structure de la future application.
• J’ai généré un long prompt de départ pour Codex afin de monter rapidement l’ossature du projet Swift.

2. Première construction du projet

• Codex a créé le projet Swift de base.
• Les principales dépendances ont été installées.
• L’architecture de base a été préparée.
• Un premier prototype exécutable a été construit.

3. Réalisation technique principale

• Après épuisement de la fenêtre de tokens de Codex, le projet a été transféré dans Claude Code.
• Le développement principal s’est poursuivi avec Opus 4.7.
• Claude Code a permis de construire le cœur de l’application : capture audio, transcription, logique de coaching et liaison avec l’interface.

4. Résolution du principal problème produit : séparer les voix

• Le problème clé a été identifié : le microphone entend à la fois l’utilisateur et l’interlocuteur.
• Deux modes ont été réalisés :
  • System Audio — capture de la seule sortie audio système via ScreenCaptureKit
  • Microphone + Push-to-Mute — mode de secours avec arrêt manuel de l’envoi des buffers au transcripteur
• Ajout de excludesCurrentProcessAudio = true, pour exclure les sons de l’application elle-même.

5. Composants réalisés

• SystemAudioCaptureManager.swift — nouvelle classe de capture audio système via SCStream
• AudioCaptureManager.swift — capture audio via AVAudioEngine, ajout de isMuted
• TranscriptionManager — transcription en continu via SpeechAnalyzer
• CoachingEngine — debounce, réutilisation de la session du modèle, analyse des phrases, logique des étapes de l’appel
• ContentView.swift — gestion de session, choix de la source audio, erreurs, boutons et interface
• Info.plist — autorisations de capture système
• project.pbxproj — intégration de ScreenCaptureKit.framework

6. Débogage et tests

• La compilation et l’exécution passaient par Xcode.
• À chaque plantage, l’erreur était renvoyée dans Claude Code.
• Les corrections se faisaient par itérations : Xcode → plantage/erreur → Claude Code → correction → nouvelle compilation.
• Certaines retouches rapides étaient faites directement dans Xcode avec Codex et Claude connectés.

7. Entraînement pour des scénarios réels

• Pour la prospection, de véritables scripts de vente ont été ajoutés au système :
  • salutation
  • bavardage ordinaire
  • qualification du client
  • identification de l’intérêt
  • conclusion sur un rendez-vous ou un Zoom
• Les scripts s’appuyaient sur la pratique réelle et la formation de SPI Dubai.
• Un deuxième cas d’usage a été créé en parallèle : l’aide aux entretiens pour un poste de product designer.
• Le modèle a été entraîné pour cela sur mes projets, mes cas et mon portfolio.

8. Le résultat final

• transcription locale sans envoi de données dans le cloud
• suggestions en temps réel pendant la conversation
• logique distincte pour la vente et les entretiens
• stack native sans rustines web
• produit fonctionnel construit avec ChatGPT + Codex + Claude Code + Xcode