La conversation qui survit aux coupures

Un téléphone perd sa liaison avec le serveur bien plus souvent qu'on ne le croit : un tunnel, le passage du wifi au réseau mobile, un signal faible. L'application se reconnecte seule, en quelques secondes. Mais jusqu'au 19 mai, elle revenait de chaque coupure sans le fil des dernières minutes, parce que ce fil vivait dans la liaison elle-même. Depuis, la conversation en cours appartient à la personne, pas au câble : une reconnexion dans la demi-heure la retrouve intacte, historique et locuteur compris. Et une erreur passagère du côté du serveur ne l'efface plus non plus.

Dix secondes de tunnel

Léa est dans le train, elle prépare son week-end. « Note que Samuel arrive vendredi soir, il dort à la maison. » L'application confirme, la fiche est créée. « Et rappelle-moi de sortir le lit d'appoint jeudi. » Nouvelle confirmation, puis une question en retour : « pour une nuit ou pour deux ? ». Le train entre dans un tunnel. En haut de l'écran, le petit point qui signale la liaison passe du vert au rouge. Dix secondes. Le train ressort, le point redevient vert. Léa répond : « deux ».

Avant le 19 mai, la suite était embarrassante. « Deux quoi ? » Ou pire : une réponse qui repartait de la mémoire longue, retrouvait la fiche de Samuel, et brodait autour, sans plus savoir qu'une question venait d'être posée. Les souvenirs étaient tous là. Le prénom de Samuel, la date, le lit d'appoint, rien n'avait été perdu. Ce qui manquait, c'était la minute d'avant.

Ce défaut a une particularité : il ne se voit que sur un téléphone en mouvement. Dans un train, dans un ascenseur, en sortant de chez soi, la liaison casse tout le temps, et c'est justement là qu'on a envie de parler plutôt que de taper.

Ce qu'une coupure veut dire pour un téléphone

Le téléphone et le serveur se parlent par un canal qui reste ouvert pendant toute la session. C'est ce qui permet à la voix de circuler dans les deux sens sans rétablir une connexion à chaque phrase. Mais un canal ouvert a une fragilité : il dépend du réseau qui le porte, et un téléphone change de réseau sans arrêt.

On franchit la porte de chez soi : le wifi lâche, le réseau mobile prend le relais, et le canal, lui, ne survit pas au changement. On traverse une zone de signal faible : le canal est déclaré mort par un équipement quelque part entre le téléphone et le serveur, sans que personne n'ait rien décidé. On reste silencieux quelques minutes : certains réseaux ferment une ligne qui ne dit rien. Aucun de ces événements n'est une panne. C'est la vie normale d'un appareil qu'on porte dans sa poche.

L'application sait s'en remettre, et elle le fait toute seule. Quand le canal tombe, elle tente de le rouvrir après une seconde. Si ça échoue, elle réessaie après deux secondes, puis quatre, puis huit, sans dépasser un plafond de quinze secondes entre deux tentatives. Pendant ce temps, le petit point en haut de l'écran passe au rouge, à l'orange le temps d'une tentative, puis revient au vert. C'est tout ce qu'on voit, et c'est voulu : une reconnexion n'a pas à être un événement.

Quand le canal est rouvert, le serveur commence par dire bonjour : un premier message qui contient un identifiant de conversation. Toute l'affaire tient dans cet identifiant. S'il est nouveau, la conversation repart de zéro. S'il est le même qu'avant le tunnel, le fil est retrouvé.

Avant : un fil attaché au câble

Côté serveur, ce qui reçoit tes phrases, fait travailler le modèle, exécute ses outils et te renvoie la réponse est une sorte de chef d'orchestre. C'est lui qui tient la conversation en cours : les derniers échanges, dans une fenêtre glissante qui couvre largement quelques dizaines de tours ; la personne déclarée comme tenant le téléphone, quand ce n'est pas toi qui parles ; et la liste des fiches créées depuis le début de la conversation, celles qu'un toucher sous la réponse rouvre.

Jusqu'au 19 mai, un chef d'orchestre était construit pour chaque canal. Un canal, un chef d'orchestre, une conversation. Tant que le canal vivait, tout allait bien. Mais chaque tunnel fabriquait un canal neuf, donc un chef d'orchestre neuf, donc une conversation vide. Le serveur voyait arriver un identifiant inconnu et faisait ce qu'il fait pour un inconnu : il repartait de rien, avec la seule mémoire longue.

Il y avait pire. La fermeture du canal était prise pour la fin de la conversation : à cet instant, elle était résumée, archivée dans la mémoire longue et retirée de la mémoire vive. Le tunnel de Léa ne faisait pas qu'effacer la question sur le lit d'appoint, il clôturait la conversation, comme si elle avait dit au revoir.

D'où les symptômes. Un « oui » lancé après une coupure recevait « oui à quoi ? ». Une demande formulée en deux temps, la première moitié avant le tunnel et la seconde après, n'avait plus de première moitié. Et un téléphone prêté redevenait, sans prévenir, le téléphone de son propriétaire, avec le risque de ranger sous le mauvais nom ce que la personne de passage venait de dire.

Depuis : le fil appartient à la personne

La correction du 19 mai est un déplacement. Il n'y a plus qu'un chef d'orchestre pour tout le serveur, et c'est lui qui garde toutes les conversations en cours, une par personne, indépendamment des canaux qui vont et viennent. Ce qui dépendait du canal, l'écran vers lequel envoyer une fiche à afficher, la façon de programmer un rappel pour ce téléphone précis, lui est remis au moment de chaque tour, au lieu d'être scellé dans sa construction.

À côté, le serveur tient une petite table : pour chaque personne, la conversation en cours et l'heure de sa dernière activité. « Personne » a un sens précis. Si tu as un compte, c'est le compte. Si tu utilises l'application sans compte, c'est l'appareil, reconnu par l'identifiant qu'il porte. Dans les deux cas, la clé ne change pas quand le canal change.

Quand un canal s'ouvre, le serveur regarde cette table. Si la personne avait une conversation active il y a moins de trente minutes, il lui rend le même identifiant, et le chef d'orchestre retrouve tout : l'historique, le locuteur déclaré, les fiches de la session. Sinon, il en crée un nouveau. Dans les journaux du serveur, ça donne une ligne par ouverture : « reprise de la conversation, âge 9 s », ou « nouvelle conversation ». Le tunnel de Léa est devenu une ligne de la première sorte.

Et « deux » redevient une réponse. Le modèle a la question sous les yeux, il sait à quoi elle répond, il ajuste le rappel. Rien de spectaculaire : c'est exactement ce qui se serait passé sans tunnel.

Pourquoi trente minutes

Le chiffre n'est pas tombé du ciel. C'est le même que celui de la règle du prêt de téléphone, apprise le matin même : après une demi-heure de silence, l'application considère que l'appareil est revenu à son propriétaire. Une conversation obéit à la même logique. Trente minutes sans un mot, ce n'est plus une coupure, c'est une pause, et une pause de cette longueur est le signal naturel qu'on est passé à autre chose.

Un détail compte dans le calcul. L'heure de dernière activité est rafraîchie au moment où ta phrase arrive, avant que le modèle ne se mette au travail, pas après. Une réponse longue, une recherche sur le web, une chaîne d'outils qui prend son temps, ne peut donc pas te pousser hors de la fenêtre pendant que tu attends.

Ce qui dépasse trente minutes n'est pas perdu pour autant. La conversation est archivée, et c'est un autre mécanisme qui prend le relais : les échanges passés, lus tels quels et datés, sont remis au modèle au début de la conversation suivante. C'est ce qui répond à « de quoi on parlait la dernière fois ? », et c'est le sujet d'un autre article, du même jour. Deux mécanismes, deux échelles de temps : la survie à la coupure couvre la minute, le rappel des conversations passées couvre les jours.

Partir n'est pas être coupé

Il faut distinguer deux choses que le serveur ne distinguait pas. Être coupé, c'est subir : le tunnel, le wifi qui lâche, la ligne fermée par le réseau. Partir, c'est décider : tu quittes l'application pour en ouvrir une autre, ou tu reviens à l'écran d'accueil.

Quand tu pars vraiment, l'application prévient le serveur que la conversation est terminée. Elle est archivée, et la prochaine ouverture repart sur une conversation neuve, avec les résumés des précédentes sous la main. C'est un choix : une conversation qu'on a quittée est une conversation finie, et la reprendre mot pour mot une heure plus tard serait plus déroutant qu'utile.

Mais « partir vraiment » est plus étroit qu'il n'y paraît. Ouvrir le clavier, tirer le volet des notifications, voir surgir une fenêtre du système : rien de tout cela n'est un départ, et l'application a dû apprendre à ne plus les prendre pour tels. Seule la mise à l'arrière-plan complète compte. Le reste, tunnels compris, n'est pas ta décision, et le fil tient.

Une fin qui n'est plus la fermeture d'une porte

Si la fermeture du canal ne signifie plus la fin de la conversation, il faut un autre moment pour l'archiver, sinon deux problèmes apparaissent. Les conversations abandonnées, celles dont la personne a simplement posé son téléphone, ne rejoindraient jamais la mémoire longue. Et la mémoire vive du serveur se remplirait de conversations que personne ne viendra chercher.

Le serveur passe donc en revue, toutes les cinq minutes, sa table des conversations en cours. Celles dont la personne est silencieuse depuis plus de trente minutes sont archivées, comme elles l'auraient été à la fermeture du canal autrefois, puis retirées de la mémoire vive. Une conversation abandonnée finit donc quand même dans la base, avec un résumé, et rien ne s'accumule. L'archivage n'arrive plus à la seconde où le canal tombe, mais à la fin de la fenêtre : pour la personne qui reprend, c'est le but ; pour celle qui ne reprend pas, ça ne change rien.

L'autre coupure, celle qui ne vient pas du réseau

Le même après-midi a réparé une seconde famille de coupures, invisibles celles-là, parce qu'elles se produisent entre le serveur et les services dont il dépend. Le réseau de Léa est parfait, le point est bleu, et pourtant l'application répond comme si elle avait perdu le fil.

Le premier cas est celui du modèle lui-même. Il arrivait que le service distant renvoie une réponse vide sur le premier appel d'un tour, une surcharge maquillée en succès. Le serveur prenait ça pour une panne, et tu entendais la phrase de secours, celle qui annonce un souci technique. Ce premier appel est désormais retenté une fois, après une courte pause, avant de renoncer. Une fois seulement, et seulement le premier appel du tour. Au milieu d'une chaîne d'outils, rejouer un appel reviendrait à exécuter deux fois ce qui a déjà été fait : deux fiches, deux rappels. Une réponse ratée est réparable. Une fiche en double ne l'est pas sans qu'on s'en aperçoive.

Le second cas est celui de la mémoire remise au modèle. Elle est assemblée à partir de plusieurs sources interrogées en même temps, et une seule source en retard suffisait à vider l'ensemble. Le modèle recevait alors une mémoire blanche et répondait, de bonne foi, qu'il ne se souvenait pas. La règle est devenue « tout ce qui répond est gardé », et le détail de ce changement est raconté dans l'article voisin. Ce qui compte ici, c'est la parenté : une source qui tousse et un tunnel produisent la même phrase dans la bouche de l'application, et méritaient d'être traités le même jour.

Enfin, à chaque tour, le serveur note dans ses journaux ce qu'il a réellement remis au modèle : conversations récentes, souvenirs de chaque étage, règles, et la taille du tout. Avant, « il a oublié » était un rapport impossible à instruire. Maintenant, on peut dire si le fil était là et mal lu, ou absent.

Ce qui ne survit pas encore

Ce jour-là a fixé un cadre, pas résolu chaque cas, et il vaut mieux dire lesquels restent ouverts.

Une phrase prononcée pendant les dix secondes elles-mêmes ne part pas. Si le point est rouge au moment où tu relâches l'orbe, l'application ne peut pas envoyer ta phrase, et tu la redis quand il est redevenu vert. Le fil est intact, mais ce tour-là est à refaire. Mettre ces phrases en attente pour les envoyer au retour du réseau est un chantier à part.

Un redémarrage du serveur emporte les conversations pas encore archivées, puisqu'elles vivent en mémoire vive entre deux archivages. Écrire chaque tour dans la base au fur et à mesure, pour qu'un redémarrage ne coûte au pire qu'une phrase, est la suite logique, et elle attend que celle-ci ait fait ses preuves.

Au-delà de trente minutes, c'est une nouvelle conversation, et c'est voulu. Et la réponse elle-même a besoin du réseau : comprendre ta voix, réfléchir, te répondre à voix haute, tout cela se passe sur le serveur. Ce qui survit à la coupure, c'est le fil. Pas la possibilité de parler dans le tunnel.

Pour Léa, la journée se résume simplement. Elle peut tenir une conversation dans un train, et le train a le droit d'entrer dans un tunnel. Quand il en sort, la question posée avant est toujours posée, la personne qui parlait parle toujours, et « deux » veut dire deux nuits. C'est peu de chose à énoncer. C'était la différence entre une application qu'on utilise assis et une application qu'on utilise en marchant.