Open source · AGPL-3.0 · sans compte

Votre PC,
dans l'onglet.
Sans détour.

RDT ouvre un PC Windows ou Linux dans votre navigateur. Vous voyez l'écran, vous prenez la souris, vous passez des fichiers. Tout est chiffré, et il n'y a pas de compte à créer.

Windows 10/11 · Debian/Ubuntu · ARM64 · X25519 · ChaCha20-Poly1305

rdt-test.pages.dev E2E
session · atelier
CONNEXION CHIFFRÉE

Votre bureau,
ici.

Trois codes pour ouvrir la session, aucun compte à créer.

CPU18%
RAM3.2G
RÉSEAU42K/s
SystèmeFichiersTerminalClavierPresse-papiers
✓
Session chiffréeLe serveur ne voit rien en clair.
3codessite · déploiement · appareil
0comptepas d'e-mail, pas d'annuaire
1empreinte par sessionaucun contenu lisible
20appareils par groupeun tableau de bord, pas un serveur

01 / Ce qu'il y a dedans

Écran, fichiers,
terminal, son.

Les outils utiles au quotidien, sans détour par une usine à gaz.

◫

Écran, souris, clavier

Windows ou Linux. Plusieurs écrans, qualité réglable, molette, raccourcis. Le pointeur du PC et le vôtre ont chacun leur couleur.

multi-écranscurseur PCpointeur visiteurclavier virtuel
⌁

Chiffré de bout en bout

Les clés sont créées à chaque session. Le serveur de passage transporte des données qu'il ne peut pas lire.

⌘

Presse-papiers du PC

Les trois derniers textes copiés sur le PC distant. Vous modifiez, puis vous renvoyez le texte sur le PC.

▤

Fichiers directs

Parcourir, envoyer, télécharger. Les fichiers passent dans la session, pas chez un hébergeur.

≡

Terminal sans écran

Un serveur sans écran ? Le navigateur ouvre un terminal. La connexion reste chiffrée.

◈

Le son du PC

Le son du PC arrive dans le navigateur. Volume et indicateur de niveau dans la barre d'outils.

⌁

Le système en direct

CPU, mémoire, disques, réseau, batterie, températures, processus. Les chiffres bougent en direct, avec des graphes lisibles.

◉

Sessions Windows

Sur un PC partagé, chaque session Windows peut apparaître séparément. Vous choisissez la bonne dans le tableau de bord.

↻

Redémarre tout seul

Un .exe Windows ou un .deb Linux. L'agent redémarre tout seul. Pas de pilote, pas de service système.

02 / Dans la session

Ce qui tourne
sous le bureau.

Le panneau Système montre ce qui chauffe, ce qui sature et ce qui consomme.

  • CPU cœur par cœur, charge 1/5/15 min
  • RAM, cache, swap, disponible
  • Disques : espace et I/O par seconde
  • Réseau : interface, adresses, RX/TX, erreurs
  • GPU NVIDIA, batterie, capteurs
  • Processus : top CPU et top mémoire
  • OS, noyau, virtualisation, utilisateurs

Les stats restent dans la session chiffrée. Le serveur de passage ne les voit pas et ne les garde pas.

SYSTÈME3 s
CPU14 %
RAM3.0 / 8.0 G
RÉSEAU ↓42 K/s
DISQUE I/O1.2 M/s
BATTERIE76 %
GPUNVIDIA · 31 %
ACTIVITÉ RÉSEAU↓ 42K/s · ↑ 18K/s
/dev/sda112 / 64 G
eth0↓ 42K/s ↑ 18K/s
demo-app4.2 % CPU · 120M

03 / Le modèle

Ce que le serveur
peut voir.

Le serveur de passage transporte les données entre le navigateur et le PC. Il ne peut pas les lire, les modifier ni les rejouer.

DÉRIVATIONcôté navigateur + agent
roomHash = SHA-256("rdt/room/v2|" + sync + "|" + site + "|" + deploy + "|" + device)
sessionKey = HKDF-SHA256(X25519(viewer, agent), roomHash)
frames = ChaCha20-Poly1305(sessionKey, counter, plaintext)
Le code de déploiement n'est jamais envoyé au serveur. Le tableau de bord ne stocke rien : il teste les numéros un par un.
X25519échange de clés éphémère
HKDF-SHA256dérivation liée au salon
ChaCha20-Poly1305confidentialité + intégrité
0base de données
0télémétrie
1empreinte de session visible

04 / Installer

Windows et Linux.
Sans compte.

Les binaires sont dans GitLab Releases. Le code source aussi.

05 / Le vôtre

Déployer
votre serveur.

  1. 01

    Copier le projet

    Le projet complet : agent, serveur, site et installateurs.

  2. 02

    Serveur de passage

    Dossier signal/. Il met les deux machines en contact, sans base de données.

  3. 03

    Site statique

    Pages, build npm ci && npm run build, sortie dist.

  4. 04

    Créer les codes

    GitLab génère les codes. Gardez le code de déploiement pour vous.

Cloudflare peut publier directement depuis GitLab.

Pages → GitLab ↗ Guide pas à pas ↗
À savoir
  • Ce n'est pas un remplacement certifié de RDP.
  • Pour 10 000 sessions, la vidéo devra passer en peer-to-peer.
  • Wayland n'est pas encore capturé nativement. X11 fonctionne.
  • Le code est ouvert, mais pas encore audité par un tiers.

06 / Questions courtes

Réponses courtes.

Pourquoi pas de compte ?

Un compte, c'est un annuaire, un mot de passe à réinitialiser et une base à fuiter. RDT te donne trois codes à garder. Si tu les perds, tu changes de codes.

Le serveur voit quoi ?

Une empreinte de session et du trafic chiffré. Pas ton code de déploiement, pas ton écran, pas tes fichiers, pas tes stats.

Les fichiers passent par où ?

Par la même session chiffrée que l'écran. Le serveur transporte les octets, il ne les garde pas.

La démo, c'est ton serveur ?

Non. La démo est une page statique entièrement simulée dans ton navigateur : écran, fichiers, terminal, statistiques. Aucune connexion, aucune commande réelle.

Et plusieurs sessions Windows ?

Chaque session utilisateur lance son propre agent. Le dashboard sonde les numéros et affiche le nom d'utilisateur et l'ID de session. allow_sessions limite les sessions autorisées.

Ça marche sur un VPS sans écran ?

Oui. --headless désactive l'écran et garde le terminal web, les fichiers et le chat. Même tunnel.