Une soirée n'a pas de seconde prise.

C'est le cas le plus fréquent, et c'est celui qui fait perdre une vidéo de dix minutes après huit minutes d'attente. Un envoi coupé ne recommence pas de zéro : il reprend là où il s'est arrêté. Ce qui le rend possible est un choix d'architecture, pas une option : c'est le STOCKAGE lui-même qui fait foi sur les morceaux déjà reçus, donc il n'y a aucun compteur à croire sur parole, et la reprise fonctionne même si la requête retombe sur un autre serveur que celle d'avant.

À la fin d'une soirée, tout le monde vide son appareil au même moment. Les fichiers ne traversent jamais notre application : ils partent du téléphone directement vers le stockage, et l'application ne fait qu'ouvrir puis clore l'envoi. Elle ne voit passer aucun octet. C'est ce qui fait qu'une salle entière qui envoie ses vidéos occupe le stockage, dimensionné pour ça, et non nos serveurs web, qui ne le seraient pas.

Un iPhone filme dans un format que Chrome et Android ne lisent pas. Chaque vidéo déposée est donc reprise en arrière-plan pour être rendue lisible partout, avec l'original conservé intact. Ce travail est une FILE d'attente, pas un pari : trois tentatives, avec une attente qui grandit entre chacune, et une sentinelle qui vérifie au démarrage qu'aucune vidéo n'a été oubliée en route, y compris après un redémarrage de notre infrastructure.

Une application, c'est une version de système à exiger, un magasin qui redemande un mot de passe, et une centaine de mégaoctets à télécharger sur le réseau déjà saturé de la salle. Autant d'endroits où la soirée s'arrête pour un invité. Chez Medley il n'y a rien à installer et aucun compte à créer : le QR code ouvre une page web, un prénom suffit. Plusieurs services font le choix inverse, ce que détaille notre comparatif avec WedShoots.

Mesuré sur notre album d'exemple public, dans les conditions d'une soirée et non d'un bureau de développeur : téléphone simulé en 393 pixels de large, réseau bridé en « 4G lente » et processeur ralenti quatre fois, ce qui est le réglage d'essai standard pour un mobile d'entrée de gamme. Le seuil que Google considère comme bon est de deux secondes et demie. La page est calculée sur nos serveurs et les photos partent dans la réponse elle-même : le code source, qu'affiche n'importe quel navigateur, contient déjà les images.

Le décalage de mise en page, c'est ce qui fait qu'on appuie sur le mauvais bouton parce que la page a sauté au moment du geste. Sur cet album, il est de zéro. Ce n'est pas un hasard : chaque vignette connaît ses dimensions avant même que le premier octet d'image n'arrive, donc sa place est réservée et rien ne se réorganise ensuite.

Une photo de l'album existe en trois tailles, et le navigateur prend celle qui correspond à la place réellement occupée à l'écran : environ 17 kilooctets pour une vignette de galerie, au lieu des 122 kilooctets de la grande version. Sur un album dense affiché sur un téléphone, l'écart se compte en mégaoctets qui ne transitent jamais, donc en secondes rendues à l'invité et en forfait mobile qu'on ne dépense pas pour lui.

Une vidéo déposée par un invité est préparée en plusieurs qualités, et le lecteur monte ou descend tout seul selon ce que le réseau supporte à cet instant. C'est le mécanisme des grandes plateformes de vidéo, appliqué à un album de mariage : personne ne choisit une qualité, personne ne reste devant une roue qui tourne, et la vidéo reste regardable quand deux cents personnes rallument leur téléphone en même temps.