Un code QR. Ou un fichier qui passe par la lumière.

À travers une chaîne de caméra simulée, à 10 images par seconde, avec des codes remplissant la majeure partie de l’image à 3-5 pixels de caméra par module, les quatre configurations sont sorties avec hash vérifié : noir et blanc sur une bande 15,8 KB/s, noir et blanc sur quatre bandes 37,7 KB/s, couleur sur une bande 40,1 KB/s, couleur sur quatre bandes 115,7 KB/s. La couleur sur une seule bande bat le noir et blanc sur quatre. Le taux d’échec a été nul partout. Retenez d’où viennent les chiffres : cadres géométriques parfaits, sans objectif et sans mouvement. Un vrai téléphone n’a pas encore été placé devant eux.

La caméra est demandée en 1920x1080 à 30 images par seconde, avec préférence pour celle à l’arrière ; si Android refuse la contrainte, nous tombons sur n’importe quelle caméra. Chaque image capturée est réduite à 1280 px sur le côté long avant le décodage. Ce qui compte vraiment, ce n’est pas la résolution, mais combien de pixels du capteur tombent sur un module : le noir et blanc a besoin d’environ trois, la couleur d’environ le double, parce que la chaîne vidéo du téléphone fournit généralement du 4:2:0 et divise par deux les deux plans de couleur dans les deux directions. Le détail fin de couleur est la première chose qu’une vraie caméra détruit.

Parce que la seule chose que l’appareil qui envoie peut mesurer est combien de symboles ses propres encodeurs ont produits par rapport à combien lui en ont été demandés — une affirmation sur un processeur, pas sur une caméra située à deux paumes. Un ordinateur portable ne rate jamais une marche, donc un contrôleur qui lit « zéro ratés » comme « continue » monte jusqu’au sommet et met à l’écran quatre codes qui changent trente fois par seconde, que rien ne peut scanner. Cela a réellement été livré une fois, et une personne l’a trouvé en une minute. Maintenant, le mode automatique est plafonné à une bande, noir et blanc, version 26 et 15 images par seconde. 15 n’est pas un chiffre rond : une caméra de téléphone enregistre à 30 et n’est pas synchronisée avec l’écran, donc une image doit rester affichée pendant deux expositions consécutives — 67 ms — pour être capturée entière.

Rien de spécial, et c’est tout l’intérêt. Il n’y a pas de numéros d’ordre à récupérer. L’encodeur produit des paquets de réparation à hauteur de 2x par rapport aux symboles source — mesuré sur ce code : à 60% de perte d’images, un ensemble d’environ 2x K récupère 2 MB sans que la liste soit jamais rejouée une deuxième fois. Le plafond absolu est de 60.000 paquets ; au-delà, l’expéditeur reprend simplement la liste plus souvent, ce qui coûte du temps, pas de la mémoire. Si malgré tout quelque chose se passe mal, le hash SHA-256 le détecte et le transfert échoue explicitement au lieu de livrer un fichier corrompu.

Non, et ce n’est pas une omission. Il n’existe pas de canal de retour — un écran émet de la lumière, et la lumière ne revient pas avec des confirmations. La finalisation se voit sur l’appareil qui reçoit. Toute interface qui prétendrait le contraire mentirait, et nous avons déjà eu une fois un test qui fournissait exactement cette preuve que le produit n’a jamais : la simulation calculait son taux d’échec à partir de ce que la caméra simulée parvenait à résoudre. C’est un canal de retour. Quand un test et le code livré ne sont pas d’accord sur ce qu’il est possible de savoir, c’est le test qui ment.

32 MB, refusé à la sélection s’il est plus grand. La limite ne vient pas du protocole, mais de la mémoire d’un onglet de navigateur : RaptorQ matérialise tous les paquets d’un coup, et un fichier de 50 MB avec un rapport de 2x représenterait 150 MB de tableaux vivants, assez pour tuer l’onglet d’un téléphone. Le codage s’exécute de manière synchrone sur le fil principal, mesuré à 2,5 secondes pour 32 MB sur ordinateur. Ce qui circule effectivement n’est pas la taille du fichier : l’enveloppe est compressée avec gzip avant RaptorQ, donc un tableau de 1 MB représente quelques kilooctets de paquets, et une photo de 1 MB représente un mégaoctet de paquets.

Ni l’un ni l’autre. Il n’y a pas de compte et il n’y a pas d’abonnement. Après la première visite, les pages fonctionnent sans réseau, car tout — y compris les deux binaires WebAssembly — est servi depuis leur propre domaine. Il vaut aussi la peine de préciser ce que nous avons appris en route : un service worker enregistré ne signifie pas prise en charge hors ligne. Au premier chargement, la page et ses ressources sont récupérées avant que le worker ne prenne le contrôle, donc son handler ne les voit jamais. La page signale ses propres ressources via l’API Performance au lieu de supposer.