Une transcription peut-elle être en partie locale et en partie dans le cloud ?

La plupart des explications sur le local ou le cloud — y compris celles de ce site — décrivent quelque chose qui arrive à un enregistrement : la passe locale est tentée, et soit elle réussit, soit la requête retombe sur le serveur d'Apple. Ce cadrage est exact pour une courte note vocale, transcrite en une seule passe. Il cesse discrètement d'être toute l'histoire dès qu'un enregistrement est assez long pour être découpé avant même d'atteindre le moteur de reconnaissance.

Un enregistrement long n'est pas une seule requête

La reconnaissance vocale sur iOS n'est pas conçue pour prendre une heure d'audio et rendre une heure de texte en un seul aller-retour. Ce qui s'appuie sur le framework vocal d'Apple traite l'audio long par tronçons, en soumettant chacun comme sa propre requête de reconnaissance. Une note de trois minutes peut tenir en un seul tronçon. Un cours, un entretien, ou tout ce qui dure, ce sont plusieurs tronçons, traités l'un après l'autre.

Ce détail compte ici précisément parce que la règle qui départage local et serveur ne s'applique pas une fois, à l'enregistrement entier — elle s'applique séparément, à chaque tronçon. Chacun a sa propre tentative de reconnaissance locale, et chacun est libre de finir sur un chemin différent de son voisin.

Ce qui envoie un tronçon vers le serveur pendant qu'un autre reste local

La règle de nouvelle tentative est la même que celle qui régit un enregistrement court : la reconnaissance locale est tentée en premier, et seulement si cette tentative ne rend rien d'exploitable, ou lève une erreur, le même audio est retenté avec la reconnaissance locale désactivée — c'est le chemin qui l'envoie vers le service vocal d'Apple. Appliquez cela tronçon par tronçon et le résultat découle naturellement de ce qu'il y a réellement dans chaque bout d'audio. Un tronçon plein de parole claire et continue réussit généralement en local et la bascule ne se déclenche jamais. Un tronçon qui est surtout du silence, du bruit lointain, une salve de friture, ou de la parole dans une langue pour laquelle le modèle local n'a pas été conçu, c'est exactement le genre d'audio qui revient vide — et vide est la seule condition qui déclenche la nouvelle tentative.

Rien de tout cela n'exige quoi que ce soit d'inhabituel dans l'enregistrement. Cela arrive dans une réunion ordinaire qui a un moment calme le temps que les gens s'installent, un cours avec une longue pause pour les questions, ou une note vocale qui commence par quelques bruits avant que quiconque ne parle. Les passages faciles pour un modèle local passent sans encombre en local. Ceux qui ne le sont pas sont justement ceux qui finissent par demander de l'aide au serveur — et un seul enregistrement contient couramment les deux.

La transcription finale peut donc vraiment être mixte

Mettez ces deux faits bout à bout et la réponse à la question du titre n'est pas une esquive — c'est ce que fait réellement le mécanisme. Un enregistrement de quarante minutes peut avoir ses dix premières minutes traitées entièrement en local, un passage de deux minutes de bruit ambiant au milieu qui retombe sur le serveur, puis le reste qui repasse en local, le tout dans une seule transcription que vous lisez comme un texte continu. Rien n'oblige un enregistrement à aller entièrement dans un sens ou dans l'autre. Les deux chemins n'ont jamais été exclusifs au niveau du fichier entier — seulement au niveau de chaque tronçon.

Pourquoi la transcription ne montre pas où est la couture

C'est là que ça devient vraiment difficile à démêler après coup. Une transcription terminée se lit comme un seul texte continu parce que l'application fait exactement ce qu'on attendrait d'elle : recoudre les tronçons dans l'ordre et afficher les mots, pas la mécanique qui les a produits. Il n'y a ni marqueur, ni changement de couleur, ni note dans un export TXT ou JSON qui distingue une phrase venue d'une passe locale de celle venue d'une nouvelle tentative sur le serveur. Les deux arrivent par le même appel et s'affichent de la même façon, si bien qu'au moment où vous lisez le résultat, la partie de l'enregistrement restée entièrement sur votre téléphone et celle qui a touché les serveurs d'Apple sont indiscernables.

Cela veut aussi dire qu'un contrôle ponctuel ne règle pas le sort du fichier entier. Tester un passage d'un enregistrement long en Mode Avion — ou remarquer que la majeure partie de la transcription est revenue vite, un indice approximatif d'une passe locale — vous renseigne sur le passage testé, pas sur un tronçon de deux minutes de bruit vingt minutes plus loin qui n'a jamais été vérifié.

Ce que cela change dans votre façon d'y penser

• « Cet enregistrement est-il parti dans le cloud ? » cesse d'être une question à réponse binaire dès que l'enregistrement dépasse quelques minutes. La version honnête est « quelles parties », et la réponse honnête est le plus souvent un peu des deux.
• Un enregistrement de parole claire et continue, d'une seule personne du début à la fin, est le cas le moins susceptible d'avoir un tronçon qui retombe sur le serveur — il y a peu de choses dedans qui reviendraient vides d'une passe locale.
• Un enregistrement avec de vrais creux — silence, bruit de fond, passage à une deuxième langue en cours de route — est le cas le plus susceptible d'avoir au moins un tronçon confié au serveur, précisément parce que ce sont les passages avec lesquels un modèle local peine.
• Si un enregistrement précis compte assez pour avoir besoin d'une certitude sur toute sa durée, pas seulement sur un échantillon, la seule méthode qui couvre réellement le fichier entier est de le transcrire en entier en Mode Avion, du début à la fin, en une seule passe.

Ce que le Mode Avion garantit vraiment ici

Couper le réseau avant de transcrire ne fait pas réussir tous les tronçons — un tronçon qui aurait eu besoin du serveur pour rendre quelque chose d'exploitable échoue toujours, comme il échouerait hors ligne dans un enregistrement court. Ce que cela garantit est plus étroit et vaut quand même la peine d'être eu : sans aucune route réseau disponible, aucun tronçon, nulle part dans le fichier, n'a où envoyer son audio. Vous échangez les mots que seule la passe serveur aurait récupérés contre la certitude que rien, d'aucune partie de l'enregistrement, n'est sorti. Pour un enregistrement où chaque mot compte plus que cette garantie, c'est un vrai coût. Pour un enregistrement où la garantie est le but recherché, c'est la seule méthode qui la tient réellement de bout en bout, pas seulement sur un échantillon.

Comment Voice Studio s'inscrit là-dedans

Voice Studio utilise le framework vocal d'Apple exactement comme décrit ici : reconnaissance locale tentée en premier, avec une nouvelle tentative contre le serveur d'Apple uniquement pour ce qui revient vide ou lève une erreur, et les enregistrements longs traités comme plusieurs requêtes plutôt qu'une seule. Cela veut dire qu'une longue transcription dans l'application peut être un vrai mélange — une partie produite entièrement sur le téléphone, une partie seulement après une nouvelle tentative qui a atteint le service vocal d'Apple — sans rien dans l'interface de l'application ni dans son export TXT ou JSON qui marque quelle phrase vient de quelle passe, parce que l'application elle-même ne garde pas trace de cette distinction non plus. Voice Studio n'a ni compte, ni serveur propre, ni SDK d'analytique, donc le service vocal d'Apple est le seul endroit où de l'audio peut jamais aller ; si un enregistrement précis a besoin d'une garantie qui couvre le fichier entier plutôt qu'un contrôle ponctuel, le transcrire en Mode Avion est le seul moyen de l'obtenir, pour les raisons ci-dessus.

Questions fréquentes

Un enregistrement long est-il envoyé au cloud d'un coup, ou par morceaux ?

Par morceaux. L'audio long est traité par tronçons, et chaque tronçon est soumis à la reconnaissance de son côté — c'est aussi pour cela que chacun tranche entre local et serveur indépendamment des autres.

Si l'essentiel de mon enregistrement a été transcrit rapidement, cela signifie-t-il que rien n'a atteint le serveur ?

Pas forcément. Un enregistrement peut être en grande majorité de la parole claire transcrite en local en quelques secondes, et contenir malgré tout un court passage de bruit ou de silence revenu vide, qui a déclenché une nouvelle tentative pour ce seul tronçon.

Puis-je savoir après coup quelles phrases d'une transcription viennent de quel chemin ?

Non. Le texte final est identique dans les deux cas, et rien dans l'interface de l'application ni dans un export TXT ou JSON ne marque quel tronçon a été produit en local plutôt que par la nouvelle tentative sur le serveur.

Transcrire en Mode Avion garantit-il que rien d'un enregistrement long n'a été envoyé nulle part ?

Oui, pour le fichier entier, parce qu'aucune route réseau n'est disponible pour aucun tronçon. La contrepartie, c'est que les tronçons qui auraient eu besoin du serveur reviennent simplement vides au lieu de revenir avec du texte.