Optimiser la bande passante utilisée par la synchronisation cloud
Dans le guide sur la synchronisation multi-device, on a parlé de synchroniser quatre machines sans conflit. Mais il y a un aspect qu’on oublie souvent jusqu’à ce qu’il devienne un problème : la bande passante. Si vous synchronisez 10 Go de fichiers modifiés sur une connexion ADSL à 5 Mbps en upload, c’est 4,5 heures de transfert. Pendant ce temps, vos visioconférences lagent, vos pages web mettent 10 secondes à charger, et vos collègues pensent que vous avez coupé votre caméra par politesse. Le test de débit Ookla permet de vérifier votre bande passante réelle avant de configurer les limites.
La bonne nouvelle : les clients cloud modernes offrent des contrôles de bande passante précis. La mauvaise nouvelle : personne ne les configure, parce que « ça devrait marcher tout seul ». Ça ne marche pas tout seul. Ça marche quand vous avez pris 5 minutes pour régler les limites.
Les trois leviers de contrôle
Le premier levier est le throttling (limitation de débit). Dans les paramètres du client kDrive, vous pouvez définir une limite maximale en upload et en download, en kilo-octets par seconde. La règle empirique : ne laissez pas la synchronisation utiliser plus de 70% de votre bande passante en upload. Si votre connexion fait 10 Mbps en upload (soit environ 1 250 Ko/s), limitez la sync à 875 Ko/s. Les 30% restants gardent vos autres activités réseau fluides.
En download, c’est moins critique parce que la plupart des connexions sont asymétriques (beaucoup plus de download que d’upload). Mais si vous êtes sur une connexion fibre symétrique en entreprise et que cinq personnes synchronisent en même temps, limiter le download a aussi du sens.
Le deuxième levier est la planification horaire. Certains clients permettent de définir des plages horaires pendant lesquelles la synchronisation est active ou limitée. Par exemple : sync illimitée entre 20h et 8h (quand personne n’utilise la connexion), sync limitée à 500 Ko/s pendant les heures de bureau. C’est particulièrement utile dans les petites entreprises qui partagent une connexion Internet modeste.
Le troisième levier est le LAN sync. Si deux machines sur le même réseau local doivent synchroniser les mêmes fichiers, le transfert peut se faire directement entre elles, sans passer par le serveur cloud. Au lieu de : machine A → Internet → serveur cloud → Internet → machine B, le chemin devient : machine A → réseau local → machine B. Le réseau local est typiquement 10 à 100 fois plus rapide que la connexion Internet, et le transfert ne consomme pas de bande passante Internet du tout.
Comment les conflits de sync sont liés à la bande passante
Un point que peu de gens relient : une bande passante mal gérée augmente les conflits de synchronisation. Si la sync prend 30 minutes pour envoyer une modification (parce que la bande passante est saturée), la fenêtre pendant laquelle quelqu’un d’autre peut modifier le même fichier est de 30 minutes. Si la sync prend 3 secondes, la fenêtre est de 3 secondes. Plus la sync est rapide, moins il y a de conflits. C’est mathématique.
Inversement, une bande passante trop généreuse (pas de limite) peut provoquer des à-coups. Le client envoie un fichier volumineux à pleine vitesse, la connexion sature pendant 10 secondes, votre appel Teams se coupe. Puis la sync se termine, tout redevient normal. C’est pire qu’une limitation constante, parce que c’est imprévisible.
Le delta-sync et la compression : les économies invisibles
Le fonctionnement du client de synchronisation desktop explique le delta-sync en détail. Son impact sur la bande passante est considérable. Sans delta-sync, modifier une ligne dans un fichier de 100 Mo = transférer 100 Mo. Avec delta-sync, seul le bloc modifié est transféré — typiquement quelques centaines de kilo-octets.
La compression des transferts est un autre gain transparent. Les fichiers texte (documents, tableurs, présentations) se compressent bien — un fichier Word de 5 Mo peut être réduit à 1 Mo pendant le transfert. Les fichiers déjà compressés (ZIP, JPEG, vidéo) ne bénéficient pas de cette optimisation. Si votre kDrive est principalement composé de photos et de vidéos, la compression ne vous aidera pas beaucoup.
Diagnostic : ma sync est lente, que vérifier ?
Si la synchronisation semble anormalement lente, vérifiez dans l’ordre :
La bande passante disponible. Faites un test de débit. Si votre upload est à 1 Mbps, un fichier de 500 Mo prendra 70 minutes. Ce n’est pas un problème de kDrive, c’est un problème de connexion.
Les limites de throttling. Vérifiez que vous n’avez pas configuré une limite trop basse. Une limite à 100 Ko/s qui date de l’époque où vous aviez de l’ADSL et que vous avez oubliée de mettre à jour quand vous êtes passé à la fibre.
Le nombre de fichiers. Synchroniser 100 000 petits fichiers est beaucoup plus lent que synchroniser un seul fichier de taille équivalente. Chaque fichier nécessite une requête HTTP distincte, avec sa latence réseau. Si vous synchronisez un projet de développement avec des node_modules (des centaines de milliers de fichiers de quelques ko), excluez ce dossier et comptez sur npm install pour le recréer.
Le VPN. Si vous travaillez via un VPN d’entreprise, tout votre trafic passe peut-être par le serveur VPN, y compris la sync kDrive. Le VPN ajoute de la latence et réduit le débit. Certains VPN permettent le « split tunneling » : le trafic vers kDrive passe directement par Internet, le reste passe par le VPN. Configurez-le si votre entreprise l’autorise.
Le proxy ou pare-feu. Certains pare-feux d’entreprise inspectent le trafic HTTPS, ce qui ajoute de la latence. D’autres limitent la bande passante par application. Vérifiez avec votre service IT si kDrive est bien dans la liste blanche.
La synchronisation initiale (première installation ou ajout d’un gros volume de données) est toujours la plus lente. Ne jugez pas la performance du service sur ce premier transfert. Une fois l’état de base établi, les synchronisations quotidiennes ne transfèrent que les modifications — généralement quelques mégaoctets, même si votre cloud fait plusieurs centaines de gigaoctets.