Comment fonctionne le client de synchronisation desktop kDrive
Dans le guide sur la synchronisation multi-device, on a vu que la sync entre quatre machines est un problème distribué. Le client desktop est la pièce maîtresse de ce système — c’est lui qui fait le gros du travail. Mais dire « il synchronise vos fichiers » est aussi informatif que dire « un avion vole ». La question intéressante, c’est comment. L’algorithme rsync, créé en 1996, a posé les bases du transfert différentiel de fichiers. Les clients cloud modernes s’en inspirent, même s’ils n’utilisent pas rsync directement.
Le client desktop kDrive fait trois choses en permanence : surveiller les changements locaux, les comparer avec l’état du serveur, et transférer uniquement les différences. Tout le reste — interface utilisateur, notifications, gestion des erreurs — est de la plomberie autour de ces trois fonctions fondamentales.
La mécanique interne du client de synchronisation
La première étape de toute synchronisation est la détection des changements. Le client ne compare pas bêtement tous les fichiers à intervalles réguliers (ce serait lent et gourmand en CPU). Il utilise les API du système d’exploitation pour être notifié des changements en temps réel.
Sur Windows, c’est ReadDirectoryChangesW. Sur macOS, FSEvents. Sur Linux, inotify. Chaque API a ses particularités. inotify, par exemple, a une limite sur le nombre de « watches » (répertoires surveillés). Si vous avez 10 000 dossiers synchronisés et que la limite est à 8 192, le client ne sera pas notifié des changements dans les dossiers excédentaires. Il basculera alors sur un scan périodique pour ces dossiers, ce qui est plus lent.
Quand un changement est détecté, le client calcule un hash du fichier modifié et le compare avec le hash stocké en base locale. Si le hash diffère, le fichier entre dans la file d’attente de synchronisation. Cette file d’attente est ordonnée par priorité : les fichiers ouverts par l’utilisateur passent en premier, les fichiers modifiés par un processus automatique (compilation, logs) passent après.
Le delta-sync est la fonctionnalité qui fait la vraie différence en termes de performance. Au lieu de transmettre le fichier entier à chaque modification, le client découpe le fichier en blocs (typiquement 4 Mo), calcule un hash par bloc, et ne transmet que les blocs qui ont changé. Si vous modifiez une cellule dans un tableau Excel de 80 Mo, seul le bloc contenant cette cellule est envoyé — quelques centaines de kilo-octets au lieu de 80 Mo.
La synchronisation cross-platform et ses subtilités
Le client desktop est le même logiciel sur les trois OS, mais il doit s’adapter aux différences de chaque plateforme. La synchronisation sur Windows, macOS et Linux détaille ces différences du point de vue utilisateur. Du point de vue technique, les principaux défis sont : la casse des noms de fichiers (Windows et macOS sont case-insensitive, Linux est case-sensitive), les caractères interdits (différents selon l’OS), et les attributs étendus (timestamps, permissions, ACL).
Le verrouillage de fichiers est un autre cas délicat. Quand vous ouvrez un fichier Word, Windows pose un verrou exclusif dessus. Le client kDrive ne peut pas lire le fichier tant qu’il est verrouillé. Deux stratégies possibles : attendre que le verrou soit libéré (risque de retarder la sync indéfiniment), ou lire une copie shadow du fichier via le Volume Shadow Copy Service (VSS). La plupart des clients cloud modernes utilisent la deuxième approche.
Quand le réseau freine : la gestion intelligente du débit
Le client ne se contente pas d’envoyer les fichiers aussi vite que possible. Il doit partager la bande passante avec le reste de vos activités réseau. Optimiser la bande passante de synchronisation couvre les réglages côté utilisateur. Côté client, le mécanisme est un système de throttling adaptatif : le client mesure la latence réseau et réduit son débit quand il détecte une congestion.
Le LAN sync est une optimisation souvent sous-estimée. Si deux machines sur le même réseau local synchronisent les mêmes fichiers, le client peut transférer les données directement entre les deux machines sans passer par le serveur cloud. C’est particulièrement utile en entreprise, où la bande passante Internet est partagée mais le réseau local est rapide.
La base de données locale : la mémoire du client
Le client maintient une base de données SQLite locale qui contient l’état de tous les fichiers synchronisés : chemin, taille, date de modification, hash, état de synchronisation. Cette base est consultée à chaque démarrage pour détecter les fichiers modifiés pendant que le client était éteint. Si la base est corrompue (crash du disque, arrêt brutal), le client doit recalculer l’état de tous les fichiers — ce qui explique pourquoi un premier démarrage après un crash peut être lent.
La journalisation des opérations est aussi stockée localement. Chaque modification, conflit, ou erreur est loguée. Si vous avez un problème de synchronisation, les logs du client sont le premier endroit où chercher. Sur Windows, ils sont généralement dans %APPDATA%\kDrive\logs. Sur macOS, ~/Library/Application Support/kDrive/logs. Sur Linux, ~/.config/kDrive/logs (ou $XDG_CONFIG_HOME/kDrive/logs).
Un dernier détail technique qui a son importance : le client kDrive est développé en C++ avec Qt pour l’interface graphique. C’est un logiciel natif, pas une application Electron déguisée en app desktop (contrairement à certains concurrents qui font tourner un navigateur web en arrière-plan et consomment 500 Mo de RAM pour afficher une icône dans la barre des tâches). Le résultat : une empreinte mémoire raisonnable et des performances de synchronisation qui ne dépendent pas de la santé de Chromium.