Le remplaçant Samba/NFS qui fera disparaître le VPN.
Drive est le remplaçant du serveur de fichiers inscrit à la feuille de route OxiMail. Le plan : se monter nativement comme un disque sur Windows (M:\), macOS (/Volumes/OxiMail) et Linux (/mnt/oximail), via un seul protocole (HTTPS sur le port 443) derrière une seule authentification, votre compte OxiMail. La même expérience sur le LAN ou depuis l’autre bout du monde. Ce n’est pas livré : le pilote ouvre au T3 2026, et cette page décrit la direction que nous lui donnons.
Trois arguments. Un seul produit.
Le VPN va disparaître
Pour l’accès aux fichiers, du moins. Les collaborateurs distants se connecteront en https:// et verront leurs fichiers : pas de tunnel côté client, pas de concentrateur VPN côté serveur, plus de tickets « je n’arrive pas à me connecter ». Un VPN pourra subsister pour des applications LAN historiques, mais le trafic d’accès aux fichiers, lui, est conçu pour tomber à zéro.
Propagation latérale des rançongiciels : traitée par conception
L’architecture ne laisse aucun partage de fichiers accessible sur le LAN qu’un poste compromis pourrait énumérer et chiffrer. Chaque accès est authentifié par utilisateur, par opération, en TLS 1.3. Une infection de poste est censée rester sur ce poste, un argument qu’un assureur cyber et un responsable conformité saisissent immédiatement.
Une identité au lieu de quatre
Fini la matrice compte AD + compte mail + compte VPN + identifiant NAS. Un compte OxiMail, un seul point d’authentification, une seule révocation au départ d’une personne. La synchronisation LDAP est prévue pour les entreprises qui gardent un AD de référence, mais l’AD cesse d’être la frontière d’authentification.
SMB (1983) face à Drive (en conception).
Six dimensions où l’écart est structurel, et non une question de réglage. SMB a été conçu pour un LAN de bureau d’avant l’internet moderne. Drive est conçu selon une approche HTTPS d’abord, pour les modèles de menace actuels.
| Critère | SMB/CIFS | OxiMail Drive |
|---|---|---|
| Port réseau | 445 (bloqué chez les FAI résidentiels, les hôtels, les réseaux mobiles, beaucoup de proxys d’entreprise) | 443 HTTPS, universel |
| Travail à distance | VPN requis | HTTPS direct, sans tunnel |
| Chiffrement en transit | Optionnel en SMB 3+ ; souvent mal configuré ; replis silencieux possibles | TLS 1.3 requis, aucun repli |
| Mode hors-ligne | Fichiers hors connexion Windows : peu fiables, rarement activés en pratique | Architectural : cache local, modifications en file, résolution de conflits |
| Propagation latérale des rançongiciels | Un vecteur établi des attaques modernes | Aucun partage accessible sur le LAN : accès authentifié par utilisateur uniquement |
| Gestion d’identité | AD + mail + VPN + NAS : des systèmes séparés à synchroniser | Une identité JMAP ; synchronisation LDAP prévue |
Montage natif, cache intelligent, verrous consultatifs.
Drive est conçu pour se monter via le framework de fichiers cloud natif de chaque OS : la Cloud Files API sur Windows (la même API derrière OneDrive, avec ses icônes d’état natives), FileProvider sur macOS (apparaissant sous « Emplacements » dans le Finder) et FUSE sur Linux. Le même binaire d’agent Rust est prévu pour piloter les trois.
Un cache local (configurable : aucun, lié à la session, ou éphémère) conserve les fichiers récents. Les lectures par plage d’octets font qu’un fichier de 2 Go est diffusé par morceaux plutôt que téléchargé en bloc. Le préchargement prédictif utilise quatre stratégies : proximité (vous ouvrez T1.xlsx, T2.xlsx est préchargé), habitude (chaque lundi à 08:00), session (les 20 fichiers les plus récents à la connexion) et groupe (un collègue dépose un fichier, il est préchargé dans votre cache). Les verrous consultatifs portent un TTL explicite et un renouvellement, et se libèrent automatiquement quand un client plante, réglant le classique « verrou SMB fantôme après un redémarrage ». Les ACL suivent le modèle de partage OxiMail : entités de sécurité, entrées par dossier, héritage, groupes synchronisés par LDAP.
Linux et Windows d’abord. macOS en 2027.
Le pilote v1 est prévu sur Linux (FUSE) et Windows (Cloud Files API) au T3 2026 : deux plateformes bien maîtrisées, aux bibliothèques matures.
FileProvider sur macOS est une intégration à part : elle exige un App Container signé par Apple, une NSFileProviderReplicatedExtension et un pont Objective-C. Nous estimons six à douze mois d’ingénierie dédiée. Plutôt que de livrer un binaire macOS à moitié fonctionnel à côté de la v1, nous visons une disponibilité générale macOS en 2027. Les opérateurs aux parcs mixtes utiliseraient Drive sur leurs postes Linux et Windows dès la v1, et utiliseraient le client web Workspace pour les utilisateurs macOS pendant l’intervalle.
Rejoignez le programme pilote.
Le pilote vous donne un contact direct avec l’équipe d’ingénierie, un tarif maintenu pour toute sa durée, et une priorité sur l’intégration des retours. Nous demandons une lettre d’intention, un retour structuré sur des dimensions convenues et, en option, la possibilité de citer votre déploiement dans une étude de cas lors de la disponibilité générale.
Les places du pilote s’ouvrent pour les environnements Linux et Windows de 25 utilisateurs ou plus. Les parcs majoritairement macOS sont invités à attendre 2027 ou à rejoindre le pilote en configuration hybride.