Le nouveau framework Speech d'Apple : SpeechAnalyzer vs SFSpeechRecognizer

iOS 26 introduit un nouveau framework de reconnaissance vocale aux côtés du SFSpeechRecognizer existant. La nouvelle surface API est SpeechAnalyzer plus des modules (SpeechTranscriber, SpeechDetector) qui se composent autour d’elle¹. Le positionnement d’Apple est que SpeechAnalyzer constitue la voie moderne : un nouveau modèle on-device, la prise en charge de l’audio long format, la gestion automatique des langues, une faible latence pour les cas d’usage temps réel, et une architecture modulaire qui permet d’ajouter davantage de types d’analyse au fil du temps. SFSpeechRecognizer continue d’être livré et de fonctionner ; il reste l’outil approprié pour les applications qui dépendent de sa fonctionnalité de vocabulaire personnalisé, que le nouveau framework n’offre pas encore.

Cet article confronte le nouveau framework à l’ancien. Le cadrage est « quand migrer » plutôt que « comment utiliser la nouvelle API », parce que chaque équipe disposant d’une intégration SFSpeechRecognizer fonctionnelle fait face à la même décision de tri : le modèle moderne et l’architecture du nouveau framework justifient-ils le coût de migration, ou les investissements existants en vocabulaire personnalisé justifient-ils de rester ?

TL;DR

• SpeechAnalyzer (iOS 26+) est le framework moderne de reconnaissance vocale on-device d’Apple. Il coordonne des modules d’analyse configurés à l’initialisation ; iOS 26 en livre trois : SpeechTranscriber (long format), DictationTranscriber (énoncés courts, l’équivalent de SFSpeechRecognizer), et SpeechDetector (détection d’activité vocale, qui doit être associée à un transcripteur)².
• Le nouveau framework est conçu autour de l’audio long format : conférences, réunions, conversations multi-locuteurs. Il s’exécute entièrement on-device, gère automatiquement les langues, et est livré avec un nouveau modèle propriétaire d’Apple qui serait 2× plus rapide que Whisper Large V3 Turbo sur des tâches de transcription équivalentes³.
• SFSpeechRecognizer continue d’être livré et de fonctionner. Le framework hérité conserve la fonctionnalité Vocabulaire personnalisé (enregistrement de mots-clés connus pour une meilleure précision sur les termes spécifiques au domaine), que le nouveau framework n’offre pas encore.
• La migration se fait par fonctionnalité, pas en tout-ou-rien. Les applications qui ont besoin de transcription long format, de latence plus faible ou d’une meilleure qualité audio à distance migrent vers SpeechAnalyzer. Les applications avec des investissements en Vocabulaire personnalisé conservent SFSpeechRecognizer pour ces fonctionnalités et ajoutent SpeechAnalyzer pour les nouvelles.
• L’article du cluster sur le framework Vision couvre l’autre primitive de perception on-device d’Apple ; SpeechAnalyzer étend le même schéma on-device, sans cloud, à l’audio.

L’architecture : Analyzer + Modules

SpeechAnalyzer n’est pas un transcripteur en soi. C’est un coordinateur qui gère une session d’analyse audio et dispatche le buffer audio vers un ou plusieurs modules². Les modules sont configurés à l’initialisation via l’initialiseur init(modules:), et l’analyse démarre en alimentant une AsyncSequence de buffers audio via start(inputSequence:) :

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

for try await result in transcriber.results {
    if result.isFinal {
        print(result.text)
    }
}

Trois modules sont livrés dans iOS 26 :

SpeechTranscriber. Le module de transcription vocale conçu pour l’audio long format (conférences, réunions, conversations multi-locuteurs). Renvoie des résultats en streaming avec le timing par token, des scores de confiance, et une AsyncSequence results que l’application consomme via for try await. Chaque résultat possède un drapeau isFinal qui sépare les hypothèses partielles volatiles du texte finalisé.

DictationTranscriber. L’équivalent direct pour le cas d’usage de l’ancien SFSpeechRecognizer : transcription d’énoncés courts avec le même modèle on-device qu’utilise SFSpeechRecognizer. Les applications qui migrent depuis SFSpeechRecognizer pour des requêtes courtes se tournent vers DictationTranscriber ; les applications qui adoptent le framework pour de l’enregistrement long format se tournent vers SpeechTranscriber. La distinction importe parce que SpeechTranscriber et DictationTranscriber utilisent une couverture linguistique différente et des chemins de modèle différents.

SpeechDetector. Détection d’activité vocale. Signale les événements de début et de fin de parole dans le flux audio. Le détecteur ne peut pas s’exécuter seul ; il doit être associé à l’un des modules transcripteurs dans la même instance SpeechAnalyzer. Les applications l’utilisent pour conditionner le calcul de transcription (ne pas transcrire le silence) ou pour piloter les affordances d’interface (indicateurs « parlez maintenant »).

L’architecture modulaire constitue l’amélioration structurelle par rapport à SFSpeechRecognizer. L’ancienne API combine la gestion de session audio, la détection de langue et la transcription en un seul objet ; la nouvelle API sépare les responsabilités, de sorte que les applications composent les modules dont elles ont besoin.

Ce qu’apporte le nouveau modèle

Le modèle de transcription derrière SpeechTranscriber est un nouveau modèle on-device qu’Apple a développé spécifiquement pour ce framework⁴. Les améliorations qu’Apple met en avant à la WWDC 2025 :

Qualité de l’audio long format. Le modèle est entraîné pour la transcription soutenue sur des minutes ou des heures, pas seulement pour des requêtes courtes. Conférences, podcasts, réunions multi-locuteurs et sessions de dictée sont transcrits avec une précision qu’Apple positionne face aux modèles de classe Whisper. Le test indépendant de MacStories a mesuré un gain d’environ 2,2× par rapport à la version Large V3 Turbo de MacWhisper sur des tâches de transcription équivalentes³.

Gestion de l’audio à distance. Microphones placés à l’autre bout d’une pièce, audio de table de conférence avec plusieurs locuteurs, audio avec bruit environnemental. Le modèle est entraîné pour ces conditions ; le modèle plus ancien de SFSpeechRecognizer les gère avec moins d’élégance.

Fonctionnement temps réel à faible latence. Les résultats en streaming de SpeechTranscriber arrivent plus rapidement que les rappels SFSpeechRecognitionTask.shouldReportPartialResults de l’ancien framework. Les applications qui affichent de la transcription en direct (sous-titrage, interfaces vocales, dictée) bénéficient de mises à jour plus fluides.

Gestion automatique des langues. SpeechTranscriber(locale:) accepte une locale de départ, mais le modèle peut s’adapter aux changements de langue en cours de flux. L’ancien framework exige du développeur qu’il instancie des reconnaisseurs par langue et qu’il bascule entre eux.

Aucun coût en taille d’application. Le modèle est livré avec l’OS, pas avec l’application. Les applications qui adoptent SpeechAnalyzer n’embarquent pas de poids de modèle supplémentaires. Le contraste avec l’embarquement d’un modèle de classe Whisper dans le bundle de l’application est significatif : une pile de transcription on-device compétitive coûte zéro octet de bundle.

Ce que l’ancien framework offre toujours

SFSpeechRecognizer continue d’être livré et de fonctionner dans iOS 26. Trois raisons pour lesquelles une application pourrait continuer à l’utiliser :

Vocabulaire personnalisé. SFSpeechRecognitionRequest.contextualStrings permet à l’application d’enregistrer une liste de mots-clés connus (noms propres, termes techniques, noms de produits) que le modèle aura plus de chances de reconnaître avec précision. La fonctionnalité améliore considérablement la précision pour les applications spécifiques à un domaine (dictée médicale avec noms de médicaments, applications juridiques avec citations de jurisprudence, applications d’ingénierie avec références de pièces). SpeechAnalyzer n’offre pas encore le Vocabulaire personnalisé ; pour les applications qui dépendent de cette fonctionnalité, migrer constituerait une régression de précision.

Prise en charge des OS plus anciens. SFSpeechRecognizer est disponible à partir d’iOS 10 ; SpeechAnalyzer exige iOS 26+. Les applications qui ciblent iOS 18 et antérieurs ont besoin du framework hérité.

Une intégration existante qui fonctionne. Les applications dotées d’intégrations SFSpeechRecognizer stables, auditées et performantes n’ont aucune raison urgente de migrer. Les améliorations du nouveau framework comptent surtout pour les nouveaux cas d’usage (transcription long format, audio à distance, conversations multi-locuteurs) ; les applications qui traitent des requêtes vocales courtes via la API héritée pourraient ne pas y gagner suffisamment pour justifier la migration.

Quand migrer

Trois déclencheurs de migration valent d’être nommés :

L’application traite de l’audio long format. Un enregistreur de réunions, une application de transcription de conférences, un outil de podcast vers texte. L’entraînement du nouveau modèle sur de l’audio soutenu est l’ajustement adéquat ; l’ancien modèle se dégrade sur de longues sessions. Migrez en premier.

L’application a besoin d’audio distant ou bruyant. Transcription de salle de conférence, enregistrement d’entretien avec un micro unique distant, audio capté dans des environnements avec bruit ambiant. Le nouveau modèle gère ces conditions sensiblement mieux.

L’application affiche une interface de transcription en direct. Superpositions de sous-titres, interfaces de dictée, interfaces d’assistance pilotées par la voix. La latence plus faible des résultats en streaming de SpeechTranscriber rend l’interface plus réactive.

Les cas qui ne justifient pas nécessairement une migration :

• Requêtes vocales courtes avec vocabulaire personnalisé (dictée d’ordonnances, terminologie juridique). Conservez SFSpeechRecognizer pour la fonctionnalité de vocabulaire ; tournez-vous vers SpeechAnalyzer si Apple ajoute la prise en charge du vocabulaire dans une version future.
• Applications qui doivent prendre en charge iOS 18 et antérieurs. SpeechAnalyzer est exclusif à iOS 26 ; la base de code a besoin du framework hérité pour les cibles plus anciennes de toute façon.

Le schéma côte à côte

Pour les applications qui ciblent à la fois des versions d’OS plus anciennes et qui souhaitent la qualité du nouveau framework sur iOS 26+, le schéma côte à côte est la bonne approche :

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

DictationTranscriber est le bon choix pour la branche iOS 26+ parce que la cible de migration est le cas d’usage de SFSpeechRecognizer (requêtes courtes avec le même modèle de dictée). Les applications qui ciblent l’audio long format remplacent DictationTranscriber par SpeechTranscriber dans la branche iOS 26.

Les deux frameworks coexistent ; la vérification au runtime sélectionne le bon en fonction de la disponibilité. Aucun ne bloque l’autre ; le pipeline de transcription de l’application s’adapte.

Vie privée et surface d’autorisation Speech

Les deux frameworks partagent la même autorisation du framework Speech (NSSpeechRecognitionUsageDescription dans Info.plist) et le même flux d’autorisation côté utilisateur⁵. L’histoire de la confidentialité est la même : la transcription vocale a lieu on-device pour les deux frameworks. SpeechAnalyzer est on-device uniquement par conception ; SFSpeechRecognizer est on-device par défaut lorsque le drapeau requiresOnDeviceRecognition de la requête est défini sur true sur le SFSpeechRecognitionRequest lui-même, sinon il peut basculer vers un chemin côté serveur.

Implication : les applications qui utilisent SpeechAnalyzer doivent toujours gérer correctement l’autorisation Speech. L’invite utilisateur, l’entrée des Réglages, et l’étiquette de confidentialité de l’App Store utilisent tous le même mécanisme d’autorisation.

Pour les applications qui transmettent de l’audio microphone à l’analyseur, la configuration standard AVAudioSession s’applique. L’article du cluster sur le Privacy Manifest couvre les entrées de manifeste pour les applications qui utilisent Speech ; les deux frameworks relèvent des mêmes déclarations de confidentialité.

La connexion avec les workflows agentiques

Le modèle on-device de SpeechAnalyzer et sa sortie structurée s’apparient proprement avec deux schémas du cluster :

Foundation Models pour le raisonnement in-app. Un pipeline qui transcrit l’audio avec SpeechTranscriber, puis résume la transcription avec le LLM on-device (couvert dans Foundation Models LLM on-device), s’exécute entièrement on-device. Total des appels réseau : zéro. Total de l’exposition de données à des tiers : zéro.

App Intents pour les actions pilotées par la voix. Un AppIntent qui prend une transcription en entrée peut être invoqué via les Raccourcis vocaux (couverts dans L’accessibilité comme plateforme) ou via la surface d’action d’Apple Intelligence. La méthode perform de l’intention exécute SpeechAnalyzer pour transcrire l’entrée, puis dispatche vers la logique de l’application. L’ensemble du flux est privé et local.

Le schéma : le nouveau framework Speech complète le triangle de perception on-device (Vision pour les images, Foundation Models pour le raisonnement linguistique, Speech pour l’audio) qui rend les fonctionnalités d’IA entièrement locales praticables pour les applications iOS.

Ce que ce schéma signifie pour les applications iOS 26+

Trois enseignements.

1. Adoptez SpeechAnalyzer par défaut pour le nouveau code. Le modèle moderne, l’architecture modulaire, et les performances améliorées sur le long format / l’audio distant / le direct en font le bon point de départ. Le framework hérité est le repli lorsque la prise en charge d’OS plus anciens ou le Vocabulaire personnalisé sont requis.

2. Conservez SFSpeechRecognizer pour les applications dépendantes du vocabulaire. Tant qu’Apple n’ajoute pas le Vocabulaire personnalisé au nouveau framework, les applications qui dépendent de contextualStrings pour la précision sur des termes spécifiques au domaine conservent l’ancienne API. Les deux frameworks coexistent ; les mélanger par fonctionnalité est le bon schéma.

3. L’histoire de la confidentialité on-device s’étend de Vision à Speech. Les applications qui se sont construites autour de la vision par ordinateur on-device de Vision disposent désormais de l’équivalent pour l’audio. Combinés à Foundation Models pour le raisonnement, le pipeline complet de la perception au langage peut s’exécuter localement sans exposition de données à des tiers.

L’intégralité du cluster Apple Ecosystem : App Intents typés ; serveurs MCP ; la question du routage ; Foundation Models ; la distinction LLM runtime vs outillage ; trois surfaces ; le schéma single source of truth ; Deux serveurs MCP ; hooks pour le développement Apple ; Live Activities ; le contrat runtime watchOS ; les internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les schémas Liquid Glass ; la livraison multi-plateformes ; la matrice des plateformes ; le framework Vision ; Symbol Effects ; l’inférence Core ML ; API Writing Tools ; Swift Testing ; Privacy Manifest ; L’accessibilité comme plateforme ; la typographie SF Pro ; les schémas spatiaux visionOS ; ce sur quoi je refuse d’écrire. Le hub se trouve à Apple Ecosystem Series. Pour un contexte plus large iOS-avec-agents-IA, consultez le guide iOS Agent Development.

FAQ

SFSpeechRecognizer est-il déprécié ?

Apple n’a pas formellement déprécié SFSpeechRecognizer. Il continue d’être livré dans iOS 26 et reste pris en charge. Le cadrage à la WWDC 2025 est que SpeechAnalyzer constitue la voie moderne et recommandée pour le nouveau code ; le framework hérité est l’outil approprié pour des cas spécifiques (Vocabulaire personnalisé, prise en charge d’OS plus anciens).

Puis-je utiliser SpeechAnalyzer avec des fichiers audio préenregistrés ?

Oui. SpeechAnalyzer.start(inputSequence:) accepte une AsyncSequence de buffers audio. Les applications enveloppent n’importe quelle source audio (microphone via AVAudioEngine, URL de fichier préenregistré, instances AVAsset) dans un adaptateur AsyncSequence et l’alimentent à l’analyseur. Le flux de transcription produit la même consommation for try await result in transcriber.results quelle que soit la source d’entrée.

Qu’advient-il du Vocabulaire personnalisé si je migre ?

Le Vocabulaire personnalisé n’est actuellement pas pris en charge par SpeechAnalyzer / SpeechTranscriber. Les applications qui en dépendent pour la précision sur des termes spécifiques à un domaine ne devraient pas migrer ce chemin tant qu’Apple n’a pas ajouté la fonctionnalité. Une approche hybride (utiliser SpeechAnalyzer pour la transcription générale et SFSpeechRecognizer avec contextualStrings pour la transcription sensible au vocabulaire) fonctionne dans iOS 26.

Puis-je exécuter SpeechAnalyzer côté serveur ?

Non. SpeechAnalyzer est un framework on-device uniquement. Il n’a pas de chemin côté serveur. Pour la transcription côté serveur, les bons outils sont les API cloud (API OpenAI Whisper, Google Cloud Speech-to-Text, AWS Transcribe) ou des modèles auto-hébergés. La valeur du framework Apple, c’est précisément l’histoire de la confidentialité on-device et le coût zéro par appel.

Comment fonctionne la détection de langue ?

SpeechTranscriber(locale:) accepte une locale initiale. Le modèle peut s’adapter automatiquement aux changements de langue en cours de flux. Pour les applications où la langue est connue à l’avance (la fonction de dictée d’une application localisée), spécifiez-la explicitement. Pour les contextes multilingues (un transcripteur de réunion où les locuteurs peuvent changer), la gestion automatique est le comportement approprié.

Comment cela s’inscrit-il avec les autres articles du cluster sur le ML on-device ?

SpeechAnalyzer est le troisième pilier de la pile de perception on-device : Vision (couvert dans Vision Framework) gère les images, Speech gère l’audio, et Core ML (couvert dans Core ML On-Device Inference) est le moteur sous-jacent aux deux. Foundation Models (couvert dans Foundation Models LLM on-device) gère le raisonnement linguistique. Ensemble, ils forment un pipeline d’IA on-device complet qui ne nécessite pas d’appels réseau.

Références