Que se passe-t-il si votre connexion coupe pendant la transcription sur iPhone ?

Cette question vient en général d’une situation bien précise : une transcription tournait, un ascenseur est arrivé, un tunnel a commencé, le téléphone est passé du Wi-Fi aux données mobiles en sortant de chez soi, et le résultat ensuite a été soit rien, soit un texte incohérent. Cela vaut la peine de séparer ce qui s’est réellement passé de ce que cela a donné l’impression de faire, car les deux chemins d’échec sur iPhone ne sont pas la même chose et n’ont pas les mêmes conséquences.

Les deux tentatives ne dépendent pas de la même façon de votre connexion

iOS tente toujours d’abord la reconnaissance sur l’appareil. Cette passe s’exécute entièrement à partir d’un modèle de langue déjà présent sur le téléphone — elle n’a aucune étape réseau susceptible d’être interrompue, donc une coupure de Wi-Fi ou un signal mort pendant cette partie ne change rien au résultat. Si cette première passe, à elle seule, a produit votre transcription, une coupure de connexion à n’importe quel moment de son déroulement n’a jamais été un facteur.

La partie qui dépend réellement d’une connexion, c’est la nouvelle tentative : si la passe sur l’appareil revient vide ou échoue, l’étape suivante habituelle est une seconde tentative avec la reconnaissance sur l’appareil désactivée, qui envoie l’audio au service vocal d’Apple et attend que le texte revienne. C’est le seul moment de tout le processus où perdre sa connexion peut réellement changer quelque chose au résultat.

Ce qu’une coupure de connexion fait à cette requête

Le repli serveur n’est pas un flux qui remplit les mots au fur et à mesure et qui pourrait plausiblement vous laisser la première moitié d’une phrase. Il est envoyé comme une seule requête et reçoit une seule réponse : de l’audio en entrée, du texte en sortie, ou rien du tout. Il n’existe pas d’état intermédiaire où le téléphone aurait reçu les trois quarts d’une transcription. Si la connexion coupe pendant que cette requête est en cours, elle échoue simplement à se terminer, et ce qu’il reste est identique à n’importe quelle autre tentative ratée : une transcription vide ou absente, pas une version tronquée ou incohérente.

Cela veut aussi dire qu’il n’y a rien à nettoyer de votre côté. Une requête échouée ne laisse ni fichier corrompu, ni processus bloqué, ni transcription à moitié écrite dans l’application. Elle laisse exactement ce que laisserait un échec n’ayant jamais impliqué le réseau : rien n’a changé, une tentative a été consommée, il suffit de réessayer quand les conditions seront différentes.

Une coupure de connexion veut-elle dire que de l’audio est quand même parti

C’est la partie honnête, un peu insatisfaisante, de la réponse. Une requête qui échoue en cours de route n’est pas la même chose qu’une requête qui n’a jamais démarré : une certaine quantité d’audio a pu réellement quitter le téléphone avant la coupure, même si aucune transcription n’en est jamais revenue. Il n’existe aucun moyen fiable, pour une application posée au-dessus du framework vocal du système, de vous dire jusqu’où une requête vouée à l’échec est allée avant de mourir. Ce que l’on peut affirmer avec certitude est plus étroit, mais reste utile : une requête échouée ne produit aucun résultat, donc rien n’a été gagné avec ce qui a pu partir en partie, et l’enregistrement source sur votre téléphone n’est touché dans aucun des deux cas. Si ce qu’il vous faut vraiment pour un fichier donné, c’est la garantie que rien n’est sorti, la façon fiable de l’obtenir n’est pas de compter sur une coupure providentielle — c’est de transcrire en mode avion, où la requête de repli n’a aucune issue possible et où seule la passe sur l’appareil peut s’exécuter.

En quoi cela diffère d’une transcription vide pour d’autres raisons

Une transcription vide ou absente causée par une coupure de connexion ressemble, de l’extérieur, exactement à une transcription vide causée par un audio trop faible, la mauvaise langue sélectionnée, ou un modèle local manquant — dans tous les cas, vous vous retrouvez face à un résultat vide sans aucun message d’erreur pour expliquer pourquoi. La façon de les distinguer est de se fier à ses propres conditions plutôt qu’à la transcription : si vous savez que la connexion était instable à ce moment-là, c’est l’explication la plus probable, et la solution est différente aussi. Une langue mal choisie demande de corriger le réglage. Un audio faible demande un micro plus proche la prochaine fois. Une coupure de connexion ne demande de changer rien du tout — juste une connexion stable et une nouvelle tentative sur exactement le même fichier.

Que faire concrètement

• Attendez d’avoir une connexion en laquelle vous avez confiance, puis retranscrivez le même enregistrement. Rien n’a changé dans le fichier audio, donc il n’y a aucune raison qu’une seconde tentative se comporte différemment une fois le réseau stable.
• Si vous passez souvent du Wi-Fi aux données mobiles — en sortant d’un bâtiment, pendant un trajet, en conduisant dans une zone à la couverture inégale —, cela vaut la peine de le reconnaître comme la cause probable avant de supposer qu’il y a un problème avec l’enregistrement.
• Si une langue a bien son modèle sur l’appareil installé sur votre téléphone, une coupure de connexion pendant la première tentative n’a aucune importance, puisque cette tentative n’a jamais eu besoin du réseau. Une coupure ne compte que lorsque la passe sur l’appareil a déjà échoué et que la nouvelle tentative est celle en cours.
• Pour tout ce dont vous ne pouvez pas vous permettre de perdre les mots exacts, transcrivez une fois que vous êtes quelque part avec une connexion en laquelle vous avez confiance, plutôt qu’en traversant l’unique zone morte de votre trajet habituel.

Comment Voice Studio gère cela

Voice Studio suit le même processus en deux étapes : d’abord la reconnaissance sur l’appareil, et une nouvelle tentative contre le serveur d’Apple seulement si cette première passe revient vide ou échoue. Si votre connexion coupe pendant que cette nouvelle tentative est en cours, la tentative de transcription échoue et la transcription revient vide plutôt que partielle ou corrompue — l’enregistrement lui-même reste totalement intact, puisque transcrire est une étape séparée que vous pouvez relancer à tout moment. Il n’y a rien à annuler ni aucun état à réparer ; relancer la transcription une fois la connexion plus stable est tout le remède nécessaire.

Questions fréquentes

Une coupure de connexion peut-elle abîmer ou raccourcir mon enregistrement ?

Non. Le fichier audio est déjà terminé et enregistré avant même que vous ne touchiez « transcrire ». Une requête réseau échouée pendant la transcription n’a aucun moyen de revenir en arrière modifier un enregistrement qui existe déjà.

Est-ce que j’obtiens une transcription partielle si la connexion coupe en cours de route ?

Non. Le repli serveur reçoit une réponse complète ou aucune réponse du tout — il n’existe pas d’état de transcription partielle. Une coupure de connexion produit un résultat vide ou absent, comme n’importe quelle autre tentative échouée.

Comment savoir si une transcription vide vient d’une coupure de connexion ou d’autre chose ?

La transcription elle-même ne le dira pas. Votre propre souvenir des conditions est le meilleur indice : une connexion instable à ce moment-là pointe vers un échec réseau, tandis qu’une langue mal sélectionnée ou un audio très faible pointent ailleurs.

Existe-t-il un moyen de garantir que rien n’est sorti de mon téléphone même si la connexion était capricieuse ?

Oui : transcrivez en mode avion. Sans aucun réseau disponible, la requête de repli n’a nulle part où aller, donc seule la passe sur l’appareil peut s’exécuter — soit vous obtenez une transcription produite entièrement sur le téléphone, soit vous n’obtenez rien, sans aucun cas intermédiaire ambigu.