Le nouveau framework Speech d'Apple : SpeechAnalyzer face à SFSpeechRecognizer

iOS 26 introduit un nouveau framework de reconnaissance vocale aux côtés du SFSpeechRecognizer existant. La nouvelle surface d’API, c’est SpeechAnalyzer accompagné de modules (SpeechTranscriber, SpeechDetector) qui se composent autour de lui¹. Apple le présente lui-même comme la voie moderne : un nouveau modèle exécuté sur l’appareil, la prise en charge de l’audio de longue durée, une gestion automatique des langues, une faible latence pour les usages temps réel et une architecture modulaire capable d’accueillir d’autres types d’analyse au fil du temps. SFSpeechRecognizer continue d’être livré et de fonctionner ; les raisons de rester tiennent à la prise en charge des systèmes plus anciens et à une lacune plus étroite : le vocabulaire personnalisé sur le modèle longue durée SpeechTranscriber du nouveau framework, puisque le chemin courte durée DictationTranscriber, lui, accepte bien les contextual strings.

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

En bref

• SpeechAnalyzer (iOS 26+) est le framework moderne de reconnaissance vocale sur l’appareil signé Apple. Il coordonne des modules d’analyse configurés à l’initialisation ; iOS 26 en livre trois : SpeechTranscriber (longue durée), DictationTranscriber (énoncés courts, l’équivalent de SFSpeechRecognizer) et SpeechDetector (détection d’activité vocale, à associer obligatoirement à un transcripteur)².
• Le nouveau framework est bâti autour de l’audio de longue durée : cours, réunions, conversations à plusieurs voix. Il s’exécute entièrement sur l’appareil, gère seul les ressources de modèle par langue et embarque 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 — et le vocabulaire personnalisé n’est plus son apanage. Le AnalysisContext.contextualStrings du nouveau framework (défini via SpeechAnalyzer.setContext(_:)) enregistre jusqu’à 100 expressions propres à un domaine pour le chemin DictationTranscriber⁶. La lacune restante concerne le modèle longue durée SpeechTranscriber, qui n’accepte pas les contextual strings.
• La migration se fait fonctionnalité par fonctionnalité, pas en tout ou rien. Les apps qui ont besoin de transcription longue durée, d’une latence moindre ou d’une meilleure qualité sur audio distant passent à SpeechAnalyzer. Celles qui ont investi dans le vocabulaire personnalisé peuvent migrer la dictée courte durée via DictationTranscriber et les contextual strings ; seule la transcription longue durée avec vocabulaire personnalisé plaide encore pour l’API historique.
• L’article sur le framework Vision du même cluster traite l’autre primitive de perception sur l’appareil chez Apple ; SpeechAnalyzer étend à l’audio ce même schéma local, sans cloud.

L’architecture : analyseur + modules

SpeechAnalyzer ne transcrit pas à lui seul. C’est un coordinateur qui gère une session d’analyse audio et distribue le tampon audio à un ou plusieurs modules². Les modules se configurent à l’initialisation via l’initialiseur init(modules:), et l’analyse démarre en alimentant une AsyncSequence de valeurs AnalyzerInput — chacune enveloppant un tampon 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 conçu pour l’audio de longue durée (cours, réunions, conversations à plusieurs voix). Il renvoie des résultats en flux continu avec un horodatage par jeton, des scores de confiance et une AsyncSequence results que l’app consomme par for try await. Chaque résultat porte un indicateur isFinal qui sépare les hypothèses partielles volatiles du texte finalisé.

DictationTranscriber. L’équivalent direct de l’ancien cas d’usage SFSpeechRecognizer : la transcription d’énoncés courts avec le même modèle local que celui de SFSpeechRecognizer. Les apps qui migrent depuis SFSpeechRecognizer pour des requêtes courtes se tournent vers DictationTranscriber ; celles qui adoptent le framework pour de longs enregistrements se tournent vers SpeechTranscriber. La distinction compte, car SpeechTranscriber et DictationTranscriber reposent sur une couverture linguistique et des chemins de modèle différents.

SpeechDetector. La détection d’activité vocale. Il signale les événements de début et de fin de parole dans le flux audio. Le détecteur ne peut pas fonctionner seul : il doit être associé à l’un des modules de transcription dans la même instance de SpeechAnalyzer. Les apps s’en servent pour limiter le calcul de transcription (inutile de transcrire le silence) ou pour piloter des repères d’interface (les indicateurs « parlez maintenant »).

L’architecture modulaire constitue l’amélioration structurelle par rapport à SFSpeechRecognizer. L’ancienne API concentre configuration, gestion des tampons et livraison des résultats dans un couple recognizer/request, et reposait sur l’activation des langues par l’utilisateur dans les réglages ; la nouvelle sépare le coordinateur de session de ses modules d’analyse, si bien que chaque app compose ce dont elle a besoin.

Ce qu’apporte le nouveau modèle

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

Qualité sur l’audio de longue durée. Le modèle est entraîné pour une transcription soutenue sur des minutes ou des heures, pas seulement sur des requêtes brèves. Cours, podcasts, réunions à plusieurs voix et séances de dictée se transcrivent avec une précision qu’Apple positionne face aux modèles de la classe Whisper. Un test indépendant de MacStories a mesuré une vitesse environ 2,2× supérieure à celle de la version Large V3 Turbo de MacWhisper sur des tâches de transcription équivalentes³.

Gestion de l’audio distant. Micros placés à l’autre bout de la pièce, prise de son de table de conférence avec plusieurs intervenants, audio capté avec du bruit ambiant. Le modèle est entraîné pour ces conditions ; l’ancien modèle de SFSpeechRecognizer s’en sort moins élégamment.

Fonctionnement temps réel à faible latence. Les résultats en flux continu de SpeechTranscriber arrivent plus vite que les rappels SFSpeechRecognitionRequest.shouldReportPartialResults de l’ancien framework. Les apps qui affichent une transcription en direct (sous-titres, interfaces pilotées à la voix, dictée) obtiennent des mises à jour plus fluides.

Gestion automatique des langues. La formulation d’Apple (ma paraphrase, pas leur terme) renvoie à la gestion des modèles et des ressources, pas à un changement de langue en cours de flux. Le système télécharge et installe les bonnes ressources de modèle pour une langue via AssetInventory, ce qui dispense les apps de gérer à la main la disponibilité des modèles langue par langue. Une instance de transcripteur travaille toujours sur une seule langue à la fois — comme dans l’ancien framework — mais la plomberie des ressources, qui rendait le multilingue pénible, incombe désormais au système.

Aucun coût sur la taille de l’app. Le modèle est livré avec le système, pas avec l’app. Les apps qui adoptent SpeechAnalyzer n’embarquent aucun poids de modèle supplémentaire. Le contraste avec la livraison d’un modèle de la classe Whisper dans le bundle est net : une pile de transcription locale compétitive coûte zéro octet de bundle.

Ce que l’ancien framework offre encore

SFSpeechRecognizer continue d’être livré et de fonctionner dans iOS 26. Trois raisons de le conserver :

Le vocabulaire personnalisé sur l’audio de longue durée. SFSpeechRecognitionRequest.contextualStrings permet à l’app 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 correctement. La fonctionnalité améliore nettement la précision des apps spécialisées (dictée médicale avec des noms de molécules, apps juridiques avec des références de jurisprudence, apps d’ingénierie avec des références de pièces). Le nouveau framework en propose sa propre version sur le chemin de la dictée : AnalysisContext.contextualStrings accepte jusqu’à 100 expressions regroupées par étiquette, se définit sur l’analyseur via SpeechAnalyzer.setContext(_:), et les expressions ainsi enregistrées peuvent être reconnues même lorsqu’elles sont absentes du vocabulaire système⁶. DictationTranscriber accepte en outre une configuration de modèle de langue personnalisée grâce à son indice de contenu ContentHint.customizedLanguage(modelConfiguration:)⁷. Ce qui n’a pas encore d’équivalent, ce sont les contextual strings sur le modèle longue durée SpeechTranscriber : une app qui a besoin de vocabulaire personnalisé en transcription longue durée régresserait en migrant ce chemin.

La prise en charge des systèmes plus anciens. SFSpeechRecognizer est disponible depuis iOS 10 ; SpeechAnalyzer exige iOS 26 au minimum. Les apps qui visent iOS 18 et antérieur ont besoin du framework historique.

Une intégration existante qui fonctionne. Les apps dotées d’intégrations SFSpeechRecognizer stables, auditées et performantes n’ont aucune raison pressante de migrer. Les progrès du nouveau framework comptent surtout pour de nouveaux usages (transcription longue durée, audio distant, conversations à plusieurs voix) ; celles qui traitent de brèves requêtes vocales via l’API historique n’y gagneront peut-être pas assez pour justifier la migration.

Quand migrer

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

L’app traite de l’audio de longue durée. Un enregistreur de réunions, une app de transcription de cours, un outil qui convertit un podcast en texte. L’entraînement du nouveau modèle sur l’audio soutenu tombe juste ; l’ancien modèle se dégrade au fil des longues sessions. À migrer en premier.

L’app a besoin d’audio distant ou bruité. Transcription en salle de réunion, enregistrement d’entretiens avec un unique micro éloigné, prises de son dans des environnements bruyants. Le nouveau modèle gère ces conditions nettement mieux.

L’app affiche une interface de transcription en direct. Incrustations de sous-titres, interfaces de dictée, interfaces d’assistance pilotées à la voix. La latence réduite des résultats en flux continu de SpeechTranscriber rend l’interface plus réactive.

Les cas qui ne justifient pas forcément une migration :

• La transcription longue durée qui dépend d’un vocabulaire personnalisé (un enregistreur de réunions qui doit capter des noms de molécules ou des références de jurisprudence). Le modèle longue durée SpeechTranscriber n’accepte pas les contextual strings : cette combinaison reste donc sur SFSpeechRecognizer tant qu’Apple n’a pas comblé la lacune. Les requêtes vocales courtes avec vocabulaire personnalisé migrent proprement — DictationTranscriber et AnalysisContext.contextualStrings les couvrent⁶.
• Les apps qui doivent prendre en charge iOS 18 et antérieur. SpeechAnalyzer est réservé à iOS 26 ; de toute façon, la base de code aura besoin du framework historique pour les cibles plus anciennes.

Le motif côte à côte

Pour les apps qui visent à la fois des versions plus anciennes du système et la qualité du nouveau framework à partir d’iOS 26, le motif côte à côte est la bonne approche :

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    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 (des requêtes courtes avec le même modèle de dictée). Les apps qui visent l’audio de longue durée remplacent DictationTranscriber par SpeechTranscriber dans la branche iOS 26.

Les deux frameworks cohabitent ; le test à l’exécution retient le bon selon la disponibilité. Aucun ne bloque l’autre ; le pipeline de transcription de l’app s’adapte.

Confidentialité et surface d’autorisation de la reconnaissance vocale

Les deux frameworks divergent au niveau des autorisations. SFSpeechRecognizer conserve son autorisation dédiée à la reconnaissance vocale : NSSpeechRecognitionUsageDescription dans l’Info.plist, plus l’invite SFSpeechRecognizer.requestAuthorization(_:)⁵. SpeechAnalyzer n’emprunte pas cette surface — une app qui transcrit de l’audio en direct avec lui a besoin de l’autorisation micro (NSMicrophoneUsageDescription), et de rien de plus pour transcrire de l’audio qu’elle possède déjà. Côté confidentialité, les deux restent locaux : SpeechAnalyzer fonctionne exclusivement sur l’appareil par conception ; SFSpeechRecognizer s’exécute localement lorsque l’indicateur requiresOnDeviceRecognition est mis à true sur la SFSpeechRecognitionRequest elle-même — c’est obligatoire, pas la valeur par défaut — sinon il peut emprunter un chemin serveur.

Ce que cela implique pour le motif côte à côte : une app qui fait tourner les deux frameworks porte les deux surfaces d’autorisation — l’invite micro pour la branche SpeechAnalyzer et l’autorisation de reconnaissance vocale pour la branche historique — et l’étiquette de confidentialité de l’App Store doit refléter les deux.

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

Le lien avec les workflows d’agents

Le modèle local et la sortie structurée de SpeechAnalyzer s’accordent proprement avec deux motifs du cluster :

Foundation Models pour le raisonnement dans l’app. Un pipeline qui transcrit l’audio avec SpeechTranscriber, puis résume la transcription avec le LLM local (traité dans Foundation Models, le LLM sur l’appareil), s’exécute entièrement sur l’appareil. Total des appels réseau : zéro. Total des données exposées à des tiers : zéro.

App Intents pour les actions pilotées à la voix. Un AppIntent qui prend une transcription en entrée peut être invoqué par les Vocal Shortcuts (traités dans L’accessibilité comme plateforme) ou par la surface d’action d’Apple Intelligence. La méthode perform de l’intent lance SpeechAnalyzer pour transcrire l’entrée, puis passe la main à la logique de l’app. Tout le parcours reste privé et local.

Le motif : le nouveau framework Speech complète le triangle de la perception locale (Vision pour les images, Foundation Models pour le raisonnement langagier, Speech pour l’audio) qui rend les fonctionnalités d’IA entièrement locales praticables dans les apps iOS.

Ce que ce motif implique pour les apps iOS 26+

Trois enseignements.

1. Prenez SpeechAnalyzer par défaut pour tout nouveau code. Le modèle moderne, l’architecture modulaire et les gains sur le long, le distant et le direct en font le bon point de départ. Le framework historique devient le recours quand la prise en charge de systèmes plus anciens ou le vocabulaire personnalisé en transcription longue durée s’imposent.

2. Les apps tributaires du vocabulaire se scindent selon la durée de l’audio. La dictée courte durée avec vocabulaire personnalisé migre : DictationTranscriber et AnalysisContext.contextualStrings portent les termes métier⁶. La transcription longue durée avec vocabulaire personnalisé reste sur SFSpeechRecognizer jusqu’à ce que le modèle SpeechTranscriber accepte les contextual strings. Les deux frameworks cohabitent ; les mélanger fonctionnalité par fonctionnalité est le bon motif.

3. Le récit de la confidentialité locale s’étend de Vision à Speech. Les apps bâties autour de la vision par ordinateur locale de Vision disposent maintenant de l’équivalent pour l’audio. Combiné à Foundation Models pour le raisonnement, tout l’enchaînement de la perception au langage peut s’exécuter localement, sans exposition de données à des tiers.

Le cluster Apple Ecosystem au complet : les App Intents typés ; les serveurs MCP ; la question du routage ; Foundation Models ; la distinction entre LLM d’exécution et LLM d’outillage ; les trois surfaces ; le motif de la source unique de vérité ; deux serveurs MCP ; les hooks pour le développement Apple ; les Live Activities ; le contrat d’exécution watchOS ; les rouages de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les motifs Liquid Glass ; la livraison multiplateforme ; la matrice des plateformes ; le framework Vision ; les Symbol Effects ; l’inférence Core ML ; l’API Writing Tools ; Swift Testing ; le Privacy Manifest ; l’accessibilité comme plateforme ; la typographie SF Pro ; les motifs spatiaux visionOS ; ce sur quoi je refuse d’écrire. Le point d’entrée se trouve dans la série Apple Ecosystem. Pour un contexte plus large sur iOS et les agents d’IA, voyez le guide du développement d’agents iOS.

Questions

SFSpeechRecognizer est-il obsolète ?

Apple n’a pas formellement déprécié SFSpeechRecognizer. Il continue d’être livré dans iOS 26 et reste pris en charge. Le cadrage de la WWDC 2025 fait de SpeechAnalyzer la voie moderne et recommandée pour tout nouveau code ; le framework historique reste l’outil adapté à des cas précis (vocabulaire personnalisé en transcription longue durée, prise en charge de systèmes plus anciens).

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

Oui. SpeechAnalyzer.start(inputSequence:) accepte une AsyncSequence de valeurs AnalyzerInput, chacune enveloppant un tampon audio. Les apps enveloppent n’importe quelle source audio (le micro via AVAudioEngine, des URL de fichiers préenregistrés, des instances AVAsset) dans un adaptateur AsyncSequence et l’alimentent à l’analyseur. Le flux de transcription se consomme de la même façon, par for try await result in transcriber.results, quelle que soit la source d’entrée.

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

Cela dépend du transcripteur sur lequel la migration atterrit. Le chemin de la dictée le prend en charge : enregistrez jusqu’à 100 expressions via AnalysisContext.contextualStrings, définissez le contexte via SpeechAnalyzer.setContext(_:), et DictationTranscriber les consomme⁶. Le modèle longue durée SpeechTranscriber n’accepte pas les contextual strings : une transcription longue durée sensible au vocabulaire devrait donc rester sur SFSpeechRecognizer avec contextualStrings tant qu’Apple n’a pas comblé cette lacune. Une approche hybride (le nouveau framework pour la transcription générale, l’API historique pour le chemin longue durée sensible au vocabulaire) fonctionne dans iOS 26.

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

Non. SpeechAnalyzer est un framework strictement local. Il n’offre aucun chemin côté serveur. Pour une transcription côté serveur, les bons outils sont les API cloud (OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) ou des modèles auto-hébergés. La valeur du framework d’Apple tient précisément à la confidentialité sur l’appareil et à l’absence de coût par appel.

Comment fonctionne la détection de la langue ?

SpeechTranscriber(locale:) prend une langue par instance de transcripteur, et il n’existe pas de bascule linguistique en cours de flux. Ce qu’iOS 26 automatise, c’est le versant des ressources : AssetInventory télécharge et gère les ressources de modèle par langue, si bien que prendre en charge plusieurs langues ne suppose plus de gérer à la main la disponibilité des modèles. Lorsque la langue est connue d’avance (la dictée d’une app localisée), précisez-la explicitement. Dans les contextes multilingues (un transcripteur de réunions où les intervenants peuvent changer de langue), détectez la langue ou laissez l’utilisateur la choisir, puis instanciez le transcripteur pour cette langue.

Comment cela s’articule-t-il avec les autres articles du cluster sur le ML local ?

SpeechAnalyzer constitue le troisième pilier de la pile de perception locale : Vision (traité dans Le framework Vision) gère les images, Speech gère l’audio, et Core ML (traité dans L’inférence Core ML sur l’appareil) est le moteur sous les deux. Foundation Models (traité dans Foundation Models, le LLM sur l’appareil) prend en charge le raisonnement langagier. Ensemble, ils forment un pipeline d’IA entièrement local qui n’exige aucun appel réseau.

Références