Synchronisation & sécurité

ResearchOS se synchronise via un serveur que vous contrôlez, et ce serveur ne stocke jamais que du chiffré. Cette page explique précisément ce que cela signifie.

Local d'abord, toujours

Votre espace de travail sur disque est la source de vérité. L'application fonctionne entièrement hors ligne ; la synchronisation est une couche de réplication. Chaque changement ajoute aussi une opération à un journal local, au sein de la même transaction de base de données. Synchroniser, c'est pousser vos nouvelles opérations et récupérer celles des autres.

La hiérarchie des clés

• Votre phrase secrète dérive une clé (argon2id) qui enveloppe une clé maîtresse aléatoire — la clé maîtresse n'existe jamais en clair ailleurs que sur vos appareils.
• Un code de récupération, affiché une seule fois à l'inscription — conservez-le en lieu sûr — enveloppe la même clé maîtresse. Phrase secrète oubliée ? Le processus de récupération déverrouille la clé maîtresse sur votre appareil et définit une nouvelle phrase secrète. Perdez les deux, et vos données synchronisées sont irrécupérables — par conception, pour tout le monde, y compris l'opérateur du serveur.
• Chaque espace de travail synchronisé possède sa propre clé d'espace, enveloppée par votre clé maîtresse. Les opérations et les fichiers sont chiffrés avec elle (XSalsa20-Poly1305) avant de quitter votre machine.
• Chaque appareil est enregistré sous votre compte et listé dans Réglages → Appareils (et ros account devices) ; révoquer un appareil coupe son accès immédiatement. Le téléphone peut se connecter en scannant un QR code depuis l'application de bureau plutôt qu'en saisissant les informations.

Ce que voit le serveur

Cette cécité est garantie par des tests automatisés qui exportent la base de données du serveur après une synchronisation complète et y cherchent du texte en clair connu.

Il existe une exception, délibérée et clairement signalée : si vous sélectionnez le fournisseur d'IA crédits de l'offre, cette question (et le contexte de l'espace de travail dont elle a besoin) est relayée en clair par le serveur de synchronisation au fournisseur du modèle — puis oubliée, jamais stockée ni journalisée. Cela ne se produit que lorsque vous choisissez explicitement ce fournisseur ; avec votre propre clé API, la requête va directement de votre machine au fournisseur, et avec un modèle local au labo, elle ne quitte jamais le réseau du labo. La synchronisation elle-même n'est jamais concernée.

Fichiers du projet

En option, les fichiers de travail de l'espace (scripts, données, brouillons — jusqu'à 50 Mo par fichier par défaut) empruntent le même canal chiffré : activez Synchroniser les fichiers du projet dans les réglages ou avec ros sync files on (un ordinateur qui rejoint l'espace l'obtient automatiquement), et gérez les exclusions via un fichier .rosignore. Les éditions en conflit ne sont jamais perdues : la version perdante reste à côté du fichier en nom.conflict-<appareil>. Cela complète git sans le remplacer (.git est toujours ignoré) — et comme le serveur ne conserve que du chiffré, il fait aussi office de sauvegarde chiffrée hors site de vos fichiers de travail.

Runs à distance

Mettez un run en file depuis un ordinateur ; un autre de vos ordinateurs qui a donné son accord l'exécute et le résultat revient par la synchronisation comme un run ordinaire. Activez l'exécuteur sur la machine qui a les données (Réglages → Sync → « Autoriser les runs à distance sur cet ordinateur », ou ros sync remote-exec on — un choix propre à chaque machine, jamais synchronisé), puis mettez en file depuis le dialogue de lancement ou de relance (« Exécuter sur un autre ordinateur ») ou avec ros run --remote "python train.py". Les requêtes sont des entités chiffrées de bout en bout comme tout le reste — le serveur ne voit jamais vos commandes. Avec la synchronisation des fichiers du projet activée, vos scripts fraîchement modifiés arrivent sur l'exécuteur avant le lancement. L'exécuteur résout l'environnement de votre projet sur son propre disque — un .venv de l'espace de travail, un environment.yml (conda), un uv.lock ou un poetry.lock est détecté automatiquement — et s'il n'a pas le nom exact de l'interpréteur (python vs python3 selon les systèmes), le démon le remplace. Quand la version de Python de l'exécuteur diffère de celle que votre machine aurait utilisée, le run s'exécute quand même mais porte une étiquette env-mismatch visible qui consigne les deux versions. Le démon démarre à la connexion sur les installations Linux et Windows : l'exécuteur fonctionne donc application fermée.

Le run revient entier. À la fin de l'exécution, l'exécuteur renvoie les logs stdout/stderr du run et ses fichiers d'artefacts (jusqu'à 100 Mo par fichier) par le même canal chiffré que les blobs, et vos autres appareils les écrivent aux mêmes chemins relatifs à l'espace de travail — un run à distance ressemble alors exactement à un run local, onglet Logs compris. Les logs arrivent en fin de run ; le streaming en direct pendant un run à distance n'existe pas encore. Et si vous avez activé deux exécuteurs, une réclamation est confirmée par un aller-retour de synchronisation avant l'exécution : la machine dont la réclamation perd la fusion se retire, et la demande ne s'exécute qu'une seule fois.

Conflits

La fusion se fait champ par champ : le changement le plus récent gagne, ordonné par des horloges logiques hybrides pour que « le plus récent » soit bien défini même entre appareils hors ligne. Pour les textes longs, la version perdante est conservée comme révision — rien n'est écarté en silence. Les suppressions voyagent sous forme de tombstones.

Le partage est explicite

Les espaces de chaque utilisateur sont isolés — par l'autorisation côté serveur et par la cryptographie (les données d'un autre utilisateur resteraient un chiffré indéchiffrable même si l'autorisation échouait ; des tests tentent exactement cela). Le partage ne passe que par des invitations en sealed box : la clé d'espace est chiffrée vers la clé publique de l'appareil de l'invité, relayée — illisible — par le serveur.

Les conversations et le labo

Messages directs, discussions de groupe et annonces sont des espaces chiffrés ordinaires qui se trouvent ne contenir que des messages — aucune mécanique nouvelle, les mêmes clés et les mêmes invitations en sealed box que tout le reste. Écrire à un collègue crée l'espace à deux et scelle sa clé vers ses appareils ; son application accepte automatiquement. La conséquence mérite d'être dite sans détour : le labo ne peut jamais lire les messages directs. Il n'existe aucune clé au niveau de l'organisation capable d'ouvrir les espaces d'un membre — un admin de labo ne lit que les espaces dont il est membre, comme tout le monde. Ce qu'un labo voit, c'est sa couche d'organisation, des métadonnées côté serveur par nécessité (on ne peut pas découvrir des personnes à travers du chiffré) : noms du labo et des équipes, appartenance, rôles, et les profils d'expertise opt-in que les membres publient à la main. La supervision des admins se construit sur ces métadonnées — compteurs d'activité, piste d'audit — plus les rapports d'avancement que les membres choisissent explicitement de publier dans un espace partagé. Hors d'un labo, le serveur impose une seule règle aux conversations : vous ne pouvez en démarrer une qu'avec quelqu'un avec qui vous partagez déjà un espace.

Entrées de carnet de bord scellées

Le scellement calcule un hash sha-256 du contenu canonique de l'entrée, chaîné au sceau précédent. Le stockage refuse toute modification ou suppression ultérieure ; la vérification recalcule la chaîne et localise l'altération à l'entrée exacte. Au-delà de la chaîne locale, une entrée scellée peut être ancrée auprès d'une autorité d'horodatage RFC 3161 (ros note timestamp) — preuve indépendante que le sceau existait à ce moment-là — et exportée en dossier de preuve autonome (ros note probative) qu'un tiers peut vérifier sans ResearchOS. L'horodatage par un prestataire qualifié (eIDAS) est prévu pour l'offre Pro.

Si le serveur meurt

Rien n'est perdu : les données locales sont la vérité, sur chaque appareil. Recréez l'espace et n'importe quel appareil renvoie tout l'historique.