Decimen transmet des codes QR à près de 190 KB/s sans réseau

Tom Hardware a mis en lumière une expérience dans un navigateur qui, selon les informations rapportées, transfère des fichiers entre téléphones à près de 190 KB/s grâce à des codes QR évoluant rapidement. Le transfert ne nécessite ni réseau partagé, ni appairage Bluetooth, ni application dédiée, ni compte. Un appareil affiche les données, tandis que l’autre les capture avec sa caméra.

C’est cette combinaison qui crée le véritable enjeu. Les transferts téléphoniques conventionnels offrent des vitesses bien plus élevées, mais ils dépendent de radios, de services du système d’exploitation, d’autorisations pour les appareils à proximité ou d’une infrastructure cloud. Decimen Optical Transfer remplace ces dépendances par un canal optique visible par les utilisateurs.

Le projet reste une preuve de concept, et non un remplacement direct d’AirDrop. Ses performances annoncées proviennent également de tests réalisés par le développeur dans des conditions favorables. L’expérience montre néanmoins que les écrans et les caméras peuvent constituer un chemin local de données pratique lorsque la connectivité habituelle est indisponible, restreinte ou indésirable.

Tom Hardware replace l’affirmation sur le transfert optique dans son contexte

L’élément important n’est pas que les codes QR peuvent contenir des fichiers. C’est qu’un navigateur peut en diffuser suffisamment pour créer une connexion unidirectionnelle utilisable.

Le développeur bashalarmistalt a publié Decimen Optical Transfer comme démonstration open source. Selon le projet, un navigateur affiche une suite ininterrompue d’images encodées. Un second navigateur lit ces images via sa caméra et reconstruit le fichier original.

La couverture originale a été publiée le 31 juillet 2026. Elle rapportait environ 128 KB/s lors de transferts téléphone-à-téléphone à main levée. Le fait de stabiliser les deux appareils aurait fait monter le débit à environ 186 KB/s.

Ces chiffres sont des mesures du développeur, et non un benchmark indépendant en laboratoire. La position des appareils compte, car les mouvements obligent l’autofocus à chercher sa mise au point et brouillent certaines images. La documentation du projet décrit les tremblements de la main comme le principal problème de débit.

Le développeur indique que l’idée est née lors de la création d’un lecteur de musique web avec cache. Il souhaitait déplacer des fichiers audio entre des téléphones qui n’étaient pas connectés au même réseau. Des codes QR clignotant rapidement ont fourni un canal qui ne dépendait pas de la détection mutuelle des deux téléphones.

Ce chemin transporte davantage qu’un lien de téléchargement. Le contenu binaire du fichier sélectionné est découpé, encodé, affiché, capturé et reconstruit sur l’appareil de réception. La charge utile elle-même traverse la lumière visible entre un écran et une caméra.

La preuve de concept publiée utilise une configuration plus prudente que l’expérience principale. Elle peut transmettre une image de 512 KB ou une image sélectionnable de 2 MB. Le dépôt décrit un transfert fonctionnant à 129 KB/s lors d’une démonstration.

Le plafond supérieur rapporté provient d’images QR plus denses, de codes empilés et d’un canal couleur avec correction d’erreurs. Le développeur a utilisé un écran ProMotion à 120 Hz pour ces tests. Les performances rapportées ont atteint environ 128 KB/s à main levée et 186 KB/s lorsque les appareils restaient immobiles.

Cette distinction est importante. Le chiffre du titre décrit le meilleur résultat de l’expérience plus large, tandis que la preuve de concept publique privilégie une lecture plus facile. Les lecteurs ne doivent pas supposer que toute combinaison de téléphone et de navigateur reproduira immédiatement 186 KB/s.

Même le débit inférieur change toutefois la manière de classer cette approche. Un unique code QR statique sert généralement de raccourci pour ouvrir un site web ou importer un petit identifiant. Decimen transforme le QR en support de transport continu.

Une image de 2 MB à 129 KB/s prend approximativement le temps attendu pour une courte transmission locale, et non pour un envoi d’archive. Les grandes vidéos resteraient peu pratiques. Les documents, extraits audio, lots de configuration, identifiants et fichiers d’urgence s’adaptent plus naturellement à ce canal.

Le projet est également délibérément unidirectionnel. Le récepteur n’envoie pas d’accusés de réception, ne négocie pas de connexion et ne révèle pas son identité à l’émetteur. Cela simplifie la mise en place, mais crée le problème technique qui définit l’ensemble du système.

Si une caméra de réception manque un fragment numéroté conventionnel, l’émetteur ne sait pas qu’il doit le répéter. Decimen résout ce problème avec du codage fontaine plutôt qu’avec un protocole de retransmission de type réseau.

Les codes fontaine transforment les images manquées en délai plutôt qu’en échec

Decimen fonctionne parce que le récepteur n’a besoin ni de chaque image QR, ni même de l’ordre de transmission d’origine.

L’émetteur commence par diviser un fichier en blocs source. Il génère ensuite un flux continu de blocs encodés, chacun combinant un sous-ensemble pseudorandom des données source. Le récepteur collecte suffisamment de combinaisons distinctes pour récupérer le fichier.

Cette technique est appelée code fontaine. Son nom reflète le comportement du récepteur : il peut recueillir les données encodées comme des gouttes jusqu’à en avoir assez pour reconstruire la source. Il n’a pas besoin qu’une goutte précise arrive à un moment précis.

Decimen utilise le codage par transformée de Luby, l’une des premières conceptions pratiques de code fontaine. Le sous-ensemble de chaque image est dérivé de son numéro de séquence à l’aide d’une distribution soliton robuste. Le récepteur aurait besoin d’environ 1,15 fois le nombre initial de blocs avant la récupération.

Une image QR perdue coûte donc du temps, pas de l’exactitude. Le récepteur peut ignorer les images floues, dupliquées ou illisibles et continuer à collecter les images suivantes. Cette propriété rend le système bien adapté à un canal optique sans voie de retour.

Le dépôt du projet explique que chaque image transporte un en-tête de 20 octets. Cet en-tête identifie la session, le numéro de séquence, le nombre de blocs, la taille des blocs, la longueur du fichier et le hachage du fichier.

Des images auto-descriptives permettent au récepteur de rejoindre un flux actif après le début de la transmission. Le redémarrage de l’émetteur crée un nouvel identifiant de session, ce qui indique au récepteur de se réinitialiser automatiquement. Aucun échange d’appairage n’est nécessaire.

Le hachage donne au côté réception un moyen de vérifier le fichier reconstruit. Il ne garantit pas que l’émetteur est digne de confiance, mais il peut détecter un résultat qui diffère de la charge utile transmise.

Ce mécanisme est différent de la simple affichage de fragments numérotés en boucle. Avec une lecture séquentielle, manquer une image peut forcer le récepteur à attendre que toute la séquence se répète. Les fichiers plus longs créent des délais de récupération plus importants.

Le codage fontaine continue plutôt à produire des combinaisons utiles. L’émetteur n’a pas besoin de savoir quels symboles sont arrivés, et le récepteur n’a pas besoin de demander les symboles manquants. Cela élimine le canal de retour normalement attendu dans les protocoles de transfert fiables.

Le concept est antérieur à ce projet. L’expérience TXQR de 2018 associait déjà des codes QR animés au codage fontaine. La bibliothèque qram de Digital Bazaar a ensuite exploré des flux QR codés LT pour transmettre des données arbitraires à travers un support avec pertes.

La contribution de Decimen consiste à intégrer l’idée autour des écrans, caméras, API de navigateur et WebAssembly des téléphones actuels. WebAssembly, souvent abrégé en WASM, permet aux navigateurs d’exécuter du code compilé à une vitesse proche du natif.

Le récepteur utilise une version WASM de ZXing-C++, une bibliothèque établie de décodage de codes-barres. Les images de la caméra sont réparties entre des workers, ce qui permet d’exécuter plusieurs tâches de décodage sans bloquer l’interface principale du navigateur.

Les workers occupés peuvent simplement abandonner les images excédentaires de la caméra. Sur un canal séquentiel normal, ce comportement menacerait le transfert. Ici, la couche fontaine absorbe ces pertes et permet aux symboles lisibles suivants de faire progresser la reconstruction.

L’implémentation gère aussi un problème de compatibilité moins visible. Les moteurs JavaScript ne garantissent pas des approximations identiques au bit près pour chaque fonction mathématique. Une faible différence dans la distribution fontaine pourrait amener deux navigateurs à choisir des blocs source différents pour le même numéro de séquence.

Le projet inclut donc un logarithme déterministe fondé sur des opérations IEEE 754 explicitement définies. Cela maintient l’alignement entre les navigateurs basés sur V8 et JavaScriptCore de Safari lorsqu’ils génèrent la même distribution.

Ce détail illustre pourquoi l’étiquette « navigateur uniquement » ne doit pas être confondue avec une simple astuce de page web. La page coordonne la capture caméra, le décodage parallèle, le codage déterministe, la gestion des sessions et la vérification du hachage. Il s’agit en pratique d’une pile de transport construite au-dessus d’images visibles.

Le résultat explique également pourquoi une génération plus rapide de codes QR ne garantit pas à elle seule un transfert de fichiers plus rapide. L’émetteur doit afficher chaque image suffisamment longtemps pour que la caméra capture une image nette. Le récepteur doit ensuite disposer d’une capacité de traitement suffisante pour la décoder avant que sa file de workers ne se remplisse.

Le rafraîchissement de l’écran, l’exposition de la caméra, l’autofocus, l’ordonnancement du navigateur et la vitesse de décodage façonnent tous le débit final. Le codage fontaine ne peut pas éliminer ces contraintes. Il empêche leurs pertes inévitables de casser le transfert.

Le véritable adversaire est l’établissement de la connexion, pas la vitesse d’AirDrop

Le transfert optique perd largement en bande passante brute, mais il évite les étapes de découverte et de confiance requises par les alternatives basées sur la radio.

AirDrop, Quick Share, Bluetooth, Wi-Fi Direct, WebRTC, les applications de messagerie et les disques cloud peuvent tous déplacer des fichiers plus rapidement. Ils constituent une mauvaise référence de performance si le problème central est que deux appareils ne peuvent pas établir un chemin conventionnel.

Apple et Google passent depuis des années à réduire les frictions visibles liées au partage à proximité. Leurs systèmes dépendent néanmoins de la prise en charge par le système d’exploitation, d’appareils compatibles, de radios sans fil, de services de découverte et d’un accès approuvé par l’utilisateur.

Un service web peut utiliser WebRTC pour une communication directe entre navigateurs, mais les pairs ont généralement besoin d’une signalisation avant de pouvoir se connecter. Les politiques réseau, les routes incompatibles ou les pare-feu restrictifs peuvent compliquer ce processus.

Decimen évite complètement la découverte. L’émetteur affiche l’information publiquement, et tout récepteur compatible à portée optique peut la collecter. Aucun appareil n’a besoin de l’adresse ou de l’identité de l’autre.

Ce modèle convient aux appareils endommagés ou isolés. Un téléphone peut disposer d’un écran et d’un navigateur fonctionnels même lorsque sa connexion cellulaire, Wi-Fi, Bluetooth ou câble est indisponible. Si sa caméra fonctionne encore, il peut également recevoir un flux optique.

Les systèmes isolés du réseau constituent un autre cadre potentiel. Un air gap sépare un appareil des réseaux de communication ordinaires afin de réduire l’exposition. Les administrateurs ont néanmoins besoin de méthodes contrôlées pour transférer des mises à jour, journaux, clés ou autres fichiers au-delà de cette frontière.

Les flux QR sont déjà utilisés dans certains flux de travail de signature hors ligne et de sécurité, car le canal est observable. Un utilisateur peut voir quand des données franchissent la frontière, même si cette visibilité ne révèle pas si la charge utile elle-même est sûre.

L’approche par navigateur réduit les frictions de déploiement car elle ne nécessite aucune installation dédiée. L’utilisateur accorde l’accès à la caméra à la page de réception, tandis que l’émetteur n’a besoin que d’un écran.

Cette affirmation exige une précision. La page du navigateur doit être initialement disponible sur l’appareil. Decimen peut être mis en cache pour une utilisation ultérieure, mais le premier accès nécessite normalement un serveur, un hôte de développement local ou un autre chemin d’installation.

L’accès à la caméra exige également un contexte de navigateur sécurisé. Le projet utilise HTTPS durant le développement, car les navigateurs bloquent généralement getUserMedia, l’interface d’accès à la caméra, sur les origines distantes non sécurisées.

Safari crée une difficulté d’implémentation supplémentaire, car il n’a pas intégré l’interface BarcodeDetector utilisée par certains outils QR pour navigateur. Le ticket WebKit pertinent demeure au cœur de l’explication de compatibilité du projet.

Decimen comble cette lacune en intégrant son propre décodeur ZXing via WASM. Cette conception améliore le contrôle entre navigateurs, mais ajoute aussi du code et du traitement qu’un service natif de plateforme pourrait éviter.

Le système présente des avantages de confidentialité dans un sens technique limité. Selon le développeur, le contenu des fichiers reste dans les deux navigateurs et ne transite pas par un serveur de téléversement. L’expéditeur ne reçoit aucune information sur la personne ayant capturé le flux.

Toutefois, une transmission optique n’est pas automatiquement privée. Toute personne disposant d’une caméra adaptée et d’une vue dégagée sur l’écran peut tenter de recevoir les mêmes données. Le canal actuel se comporte davantage comme une diffusion visible que comme un lien appairé confidentiel.

Les transferts sensibles nécessiteraient un chiffrement avant l’encodage. La documentation publique met l’accent sur la fiabilité du transport et la vérification des fichiers, non sur un système complet d’identité, d’autorisation ou de gestion des clés.

L’expéditeur ne peut pas non plus confirmer que le destinataire prévu a terminé le transfert. Il n’existe aucun canal d’accusé de réception. Les utilisateurs doivent s’appuyer sur une coordination visuelle ou sur une méthode distincte pour confirmer la fin de l’opération.

Ces limites sont acceptables au regard de la promesse principale du projet. Il ne cherche pas à remplacer toutes les piles réseau. Il offre une solution de repli lorsque l’établissement d’une connexion constitue le principal obstacle.

Cette distinction remet le résultat de Tom Hardware en perspective. Près de 190 KB/s reste modeste face au Wi-Fi, mais surprenant pour un lien optique à faibles autorisations construit à partir de primitives de navigateur. L’expérience échange l’abondance de bande passante contre une indépendance vis-à-vis de l’infrastructure réseau.

Ce que le résultat de 186 KB/s ne prouve pas

Le débit maximal est une mesure d’ingénierie prometteuse, et non la preuve de performances fiables sur des téléphones et dans des environnements ordinaires.

Le développeur identifie la stabilité physique comme une variable majeure. Un récepteur immobile aurait approché 186 KB/s, tandis qu’une utilisation à main levée serait restée proche de 128 KB/s. Cet écart montre à lui seul à quel point les mouvements affectent le canal.

L’autofocus peut se déplacer lorsque les mains de l’utilisateur bougent. Les obturateurs roulants peuvent capturer une partie d’une image affichée et une partie de la suivante. Les reflets, une faible luminosité, l’angle de vue, la mise à l’échelle de l’écran et la lumière ambiante peuvent réduire le contraste.

Les fréquences d’images de la caméra et de l’écran ajoutent une autre complication. Le récepteur peut demander 60 FPS, mais n’en recevoir que 30. Le projet note qu’iOS peut délivrer silencieusement une fréquence inférieure lorsque les applications effectuent une requête idéale.

Sa solution consiste à demander une fréquence exacte lorsque cela est pris en charge, puis à inspecter les réglages de la piste caméra. Même cette approche ne peut pas faire fournir des images supplémentaires par un matériel incompatible.

La preuve de concept utilise par défaut 24 images transmises par seconde. Chaque image QR bénéficie ainsi d’au moins deux cycles de rafraîchissement sur un écran typique, ce qui augmente les chances qu’une caméra la capture proprement.

Chaque image par défaut transporte 1 465 octets de charge utile avec un code QR de version 27. Selon le dépôt, les images plus denses de version 40 peuvent transporter 2 953 octets lors de tests sur téléphone à courte distance.

Un code plus dense n’est pas toujours plus rapide en pratique. Les modules visuels plus petits sont plus difficiles à résoudre pour les caméras, en particulier en mouvement ou avec une mise au point imparfaite. Une image transportant deux fois plus de données a peu de valeur si le décodeur la rejette.

L’expéditeur peut régler la fréquence d’images, le nombre d’octets par image, le niveau de correction d’erreurs et la taille d’affichage. Le récepteur peut ajuster la largeur de capture, la fréquence de la caméra et le nombre de workers de décodage. Ces contrôles montrent que le projet n’a pas encore réduit ses choix de performances à un profil automatique universel.

La correction d’erreurs QR est réglée sur le niveau L, le niveau standard le plus bas, dans la configuration documentée. Ce choix laisse davantage de place aux données dans chaque image.

Le code fountain et la correction d’erreurs QR traitent des modes de défaillance différents. La correction QR tente de réparer une corruption au sein d’un symbole capturé. La couche fountain gère les symboles qui n’ont jamais été décodés.

Decimen privilégie l’abandon des images défectueuses et la production de davantage de symboles fountain. Ce choix est logique lorsque des images nettes arrivent fréquemment, mais un éclairage médiocre pourrait exiger un autre équilibre.

Le débit rapporté exclut également les coûts du flux de travail dans son ensemble. L’utilisateur doit toujours avoir les deux pages prêtes, accorder les autorisations appropriées, assurer un bon alignement et disposer de suffisamment de mémoire libre pour conserver le fichier reconstruit. Pour un petit transfert, ces étapes peuvent dominer l’expérience.

Les fichiers volumineux posent un problème différent. À 186 KB/s, le transfert de centaines de mégaoctets reste long. L’utilisation continue de la caméra, la luminosité maximale de l’écran et le décodage permanent consommeront la batterie et généreront de la chaleur.

Les navigateurs peuvent suspendre le travail en arrière-plan ou récupérer de la mémoire sous pression. Les systèmes d’exploitation mobiles peuvent également modifier le comportement de la caméra selon les appareils et les versions. Un outil de production nécessiterait des tests de compatibilité étendus.

La sécurité mérite la même prudence. Un hash correct confirme que les octets reçus correspondent aux octets transmis. Il ne détermine pas qui les a créés ni s’ils contiennent du contenu malveillant.

Une page proposant des téléchargements automatiques doit traiter les noms de fichiers, les métadonnées MIME, les tailles de fichiers et les buffers reconstruits comme des entrées non fiables. Le statut open source du projet facilite l’examen, mais ne remplace pas une évaluation formelle de la sécurité.

Le dépôt présente actuellement le code comme une preuve de concept minimale. Son historique réduit et sa population de test limitée rendent prématurées les affirmations générales sur la fiabilité. Le résultat mis en avant n’a pas été reproduit indépendamment sur une matrice d’appareils publiée.

Le projet ne dispose pas non plus d’une protection intrinsèque contre l’observation par-dessus l’épaule. Un observateur à proximité peut enregistrer l’écran et décoder le flux plus tard, sauf si la charge utile a été chiffrée au préalable.

Ce risque joue dans les deux sens pour les usages en environnement isolé du réseau. Un canal optique visible peut être plus facile à surveiller qu’une connexion radio invisible. Il peut aussi fuiter vers toute caméra ayant une ligne de visée.

L’absence d’appairage réduit les frictions, car l’expéditeur n’authentifie pas les récepteurs. Cette même propriété élimine le contrôle d’accès au niveau de la couche de transport.

Aucun de ces points n’invalide l’expérience. Ils définissent sa véritable réussite. Decimen montre qu’un transport optique basé sur un navigateur peut atteindre des vitesses utiles dans certaines conditions, tout en laissant sans réponse la fiabilité produit, le réglage automatique et la conception de sessions sécurisées.

Les précédents projets QR illustrent à la fois l’opportunité et le plafond

Decimen s’inscrit dans une longue lignée d’expériences de transfert optique, mais l’amélioration du matériel des téléphones rend cette ancienne idée plus pratique.

Le transfert par QR animé est apparu dans des projets de recherche, des bibliothèques open source, des portefeuilles de cryptomonnaies et des outils de signature hors ligne. Ces systèmes partagent une observation de base : une séquence d’images lisibles par machine peut transporter bien plus de données qu’un symbole statique unique.

Les premiers projets utilisaient souvent des fragments séquentiels. Cette méthode est simple à mettre en œuvre, mais un symbole manqué peut retarder la fin jusqu’à la répétition de la séquence. Les codes fountain ont rendu le canal plus tolérant aux pertes et à la réception dans le désordre.

TXQR a combiné des codes QR animés et le codage fountain en Go en 2018. La bibliothèque qram de Digital Bazaar utilisait des codes LT pour empaqueter des données arbitraires dans des paquets QR répétés. Ces deux projets ont établi une grande partie de la base conceptuelle de Decimen.

D’autres implémentations abandonnent entièrement le QR standard. Libcimbar utilise des codes visuels colorés personnalisés, conçus pour une densité optique supérieure. Des formats spécialisés peuvent concentrer davantage d’informations dans une zone d’écran, mais ils perdent les logiciels de reconnaissance matures qui entourent le QR standard.

Ce compromis est important sur les téléphones. Le décodage QR bénéficie de décennies de travail sur la détection, la correction de perspective, les symboles endommagés et les variations d’éclairage. Un système de couleurs personnalisé doit résoudre ces problèmes tout en gérant la balance des blancs et le traitement des couleurs par la caméra.

RaptorQR représente une autre approche actuelle. Son développeur rapporte un transfert de 6,5 MB en 36 secondes, soit 183,6 KB/s, avec un iPhone 16 et Safari. Il combine le codage RaptorQ, le rendu WASM et le balayage ZXing.

RaptorQ est un code fountain standardisé décrit dans la RFC 6330. Sa conception vise une récupération efficace après perte de paquets, avec une faible surcharge. Decimen documente à la place une implémentation de code LT utilisant une distribution soliton robuste.

Ces projets ne doivent pas être considérés comme des benchmarks comparatifs contrôlés. Ils utilisent des charges utiles, des dispositions de codes, des appareils, des fréquences d’images et des conditions de test différents. Leurs débits similaires suggèrent néanmoins que le transfert optique sur téléphone a atteint une plage de performances pratique.

Les expériences de la communauté montrent aussi l’écart qui subsiste avec les réseaux ordinaires. Des développeurs travaillant sur le transfert QR dans le navigateur ont décrit des voies Wi-Fi et WebRTC mesurées en mégaoctets par seconde. Le transfert optique reste généralement dans les centaines de kilooctets par seconde.

La comparaison renforce le bon adversaire. Il ne s’agit pas d’un concours de bande passante face au partage sans fil local. C’est un concours face aux échecs de connexion, aux radios indisponibles, aux plateformes incompatibles et aux politiques qui interdisent les réseaux ordinaires.

Les codes QR fondés sur des standards confèrent également à Decimen un avantage de déploiement. Le projet peut s’appuyer sur des marqueurs visuels familiers et des bibliothèques de décodage établies. Les utilisateurs n’ont pas besoin d’un matériel de caméra spécial.

Les téléphones modernes améliorent presque chaque étape de la chaîne. Les écrans à haute fréquence de rafraîchissement peuvent afficher davantage de symboles. De meilleures caméras résolvent des codes plus denses. Des processeurs mobiles plus rapides décodent davantage d’images en parallèle. La prise en charge de WASM par les navigateurs intègre des bibliothèques natives optimisées dans une page web.

Ces améliorations expliquent pourquoi un concept ancien peut produire un nouveau résultat. La théorie de l’information sous-jacente n’a pas changé. Le matériel grand public a atteint un niveau où l’ensemble de la chaîne optique peut fonctionner de manière interactive.

Le développement assisté par IA a également influencé le processus d’implémentation. Le développeur affirme que Claude Code a aidé à construire la preuve de concept fonctionnelle. Ce fait est intéressant, mais secondaire par rapport aux choix de conception vérifiables visibles dans le dépôt.

L’IA n’a inventé ni les codes fountain, ni la reconnaissance QR, ni WASM, ni la capture caméra dans le navigateur. Elle a aidé un développeur à combiner rapidement ces composants autour d’un problème personnel précis.

Ce schéma devient courant dans les logiciels expérimentaux. Les développeurs peuvent assembler des standards, des bibliothèques et des API d’appareils en prototypes ciblés avant qu’une équipe produit classique ne justifie le travail.

Le code résultant nécessite toujours une revue humaine, des tests matériels, une analyse des menaces et une maintenance. La valeur de Decimen vient du système qu’il met en évidence, non de l’idée que du code généré par IA serait automatiquement fiable.

Les lecteurs de Tom Hardware devraient donc considérer le projet comme la preuve d’une voie en maturation, plutôt que comme une démonstration isolée. Plusieurs équipes convergent vers le transfert optique codé par fountain parce que les appareils actuels peuvent enfin l’exécuter à des débits utiles.

Trois signaux détermineront si le transfert optique quitte le laboratoire

La prochaine épreuve consistera à déterminer si Decimen peut transformer une démonstration favorable en un comportement reproductible sur les téléphones, navigateurs et environnements réels.

Le premier signal sera un benchmark de compatibilité indépendant. Le projet a besoin de résultats sur des iPhone, téléphones Android, tablettes et ordinateurs portables récents, en testant à la fois les rôles d’émetteur et de récepteur.

Un benchmark utile distinguerait l’utilisation à main levée de l’utilisation stationnaire. Il devrait signaler les réglages réels de la caméra, les fréquences de rafraîchissement de l’écran, la distance, l’éclairage, la taille de la charge utile, les tentatives échouées et le débit soutenu.

Une reproduction proche de 186 KB/s sur plusieurs appareils renforcerait l’affirmation centrale sur les performances. De fortes variations ou des échecs fréquents de transfert montreraient que les conditions optiques dominent encore la conception logicielle.

Le deuxième signal est l’ajustement automatique. Un récepteur prêt pour la production devrait mesurer la fréquence de sa caméra et sa capacité de décodage, puis indiquer à l’émetteur quelle densité et quelle vitesse de lecture fonctionnent de manière fiable.

Decimen évite actuellement tout canal de retour ; cette coordination nécessiterait donc un choix de conception. Le récepteur pourrait afficher un petit QR code de contrôle à destination de l’émetteur, ou les utilisateurs pourraient sélectionner manuellement un profil détecté.

Un mode visuel bidirectionnel ajouterait des accusés de réception, du contrôle de flux et une négociation des capacités. Il compliquerait aussi la promesse fondatrice d’une diffusion simple à sens unique.

Le projet n’a pas besoin d’un transfert duplex pour rester utile. Toutefois, des profils automatiques réduiraient les tentatives échouées et rendraient les performances moins dépendantes de réglages d’expert.

Le troisième signal est un modèle de sécurité adapté aux vrais fichiers. Le chiffrement, l’authentification de l’émetteur, les limites de charge utile, une gestion sûre des téléchargements et des indicateurs de session explicites feraient évoluer le concept au-delà d’une démonstration technique.

Le chiffrement devrait intervenir avant l’encodage fountain, afin que les images enregistrées ne révèlent aucune donnée de fichier exploitable sans la clé. L’authentification aiderait les récepteurs à confirmer qu’une charge utile reconstruite provient bien de l’émetteur attendu.

Ces ajouts doivent préserver le principal avantage du canal. Si une configuration sécurisée exige des comptes, des services cloud ou un appairage poussé, le transfert optique commence à recréer les dépendances qu’il a été conçu pour éviter.

L’issue la plus convaincante serait d’offrir des modes de sécurité facultatifs. Les transferts occasionnels pourraient rester immédiats, tandis que les flux de travail sensibles utiliseraient des clés prépartagées ou de courts codes de vérification visuels.

Les développeurs devraient également surveiller le comportement des caméras dans les navigateurs. Un meilleur accès aux contrôles de fréquence d’images et à la détection native de codes-barres réduirait la complexité de mise en œuvre. Des régressions dans la planification sur mobile ou les contraintes liées à la caméra pourraient produire l’effet inverse.

Pour les utilisateurs ordinaires, la question immédiate est plus simple : quand cette méthode surpasserait-elle un outil de partage existant ? La réponse est lorsqu’un outil habituel ne parvient pas à établir une connexion, demande des autorisations inacceptables ou dépend d’une infrastructure absente.

Cela inclut les appareils isolés, le matériel sans fil défaillant, la récupération multiplateforme, les transferts supervisés sur réseau isolé, les salles de classe aux réseaux restreints et les diffusions un-à-plusieurs depuis un grand écran.

La méthode reste mal adaptée aux sauvegardes volumineuses ou au partage courant de vidéos. Elle exige également de la prudence avec les données confidentielles, car toute personne à portée de caméra peut observer un flux non chiffré.

Tom Hardware a mis en évidence une preuve crédible que les écrans et les caméras de téléphone peuvent prendre en charge davantage que des liens et des jetons de paiement. Le résultat de près de 190 KB/s doit désormais être reproduit plus largement, bénéficier d’un réglage plus simple et s’appuyer sur une couche de sécurité définie.

Essayez d’évaluer l’idée à l’aune de son cas d’échec prévu. Si le Wi-Fi, le Bluetooth, les câbles et les services cloud disparaissaient, un canal de navigateur visible vous aiderait-il à récupérer un fichier important ? La réponse déterminera si les QR codes en streaming restent une expérience captivante ou deviennent une voie de secours standard entre appareils.