Why iCloud Fails: The Category Mistake of Cloud Synchronization

Ce papier démontre que les échecs d'iCloud, notamment dans les flux de travail de développement, résultent d'une erreur de catégorie fondamentale consistant à projeter un graphe causal distribué sur une chaîne temporelle linéaire, et propose que les sémantiques transactionnelles de l'Open Atomic Ethernet offrent une solution structurelle en alignant les protocoles sur la réalité physique.

L'essentiel

🍎 iCloud : Le Magicien qui fait disparaître vos fichiers (et pourquoi c'est de sa faute)

Imaginez que vous avez un coffre-fort numérique (votre ordinateur) et un nuage magique (iCloud). Apple vous promet que tout ce que vous mettez dans le coffre-fort apparaît instantanément dans le nuage, et vice-versa, comme par magie. C'est ce qu'on appelle une "synchronisation transparente".

Ce document, écrit par Paul Borrill, explique pourquoi cette magie est en réalité un tour de passe-passe dangereux. Selon l'auteur, iCloud ne fonctionne pas comme un simple disque dur, mais comme un système de négociation complexe qui essaie de cacher ses erreurs.

Voici les points clés, expliqués avec des analogies simples :

1. Le Grand Malentendu : Le "Catégorie Mistake"

L'auteur utilise un terme technique : Category Mistake (erreur de catégorie).

• L'analogie : Imaginez que vous essayez de ranger des livres dans une bibliothèque en utilisant les règles d'un jeu de cartes.
  • Votre ordinateur fonctionne comme une bibliothèque stricte : si le livre est sur l'étagère, il est là. Si vous le déplacez, il est déplacé. C'est logique et prévisible.
  • iCloud fonctionne comme un jeu de cartes en ligne : les cartes peuvent changer de place, disparaître ou être dupliquées en fonction de la "négociation" entre les joueurs (vos appareils).
• Le problème : iCloud vous montre une fausse étagère (une interface de fichier) qui ressemble à une vraie bibliothèque, mais qui obéit aux règles du jeu de cartes. Quand vous essayez d'utiliser des outils sérieux (comme Git pour les codeurs ou Time Machine pour les sauvegardes), ils s'attendent à des règles de bibliothèque, mais ils se heurtent aux règles du jeu de cartes. Résultat : chaos.

2. Le Problème du "Dernier à écrire gagne" (Last-Writer-Wins)

iCloud résout les conflits (quand deux appareils modifient le même fichier en même temps) en regardant l'heure de la modification.

• L'analogie : Imaginez deux amis qui écrivent une lettre ensemble. L'un est à Paris, l'autre à Tokyo. Leurs montres ne sont pas parfaitement synchronisées.
  • iCloud dit : "Celui dont la montre indique l'heure la plus tardive a raison."
  • La catastrophe : Si la montre de l'ami de Tokyo a 5 minutes d'avance, iCloud effacera le travail de l'ami de Paris, même si le texte de Paris était meilleur. Pire, si les montres sont synchronisées à la seconde près, iCloud peut choisir au hasard, effacer un fichier important et le remplacer par une version vide ou corrompue, sans vous prévenir.

3. Les Fichiers "Fantômes" (Dataless Files)

Depuis quelques années, iCloud utilise une astuce pour économiser de l'espace : il garde le "nom" du fichier sur votre ordinateur, mais supprime le "contenu" (les données) jusqu'à ce que vous en ayez besoin.

• L'analogie : C'est comme si votre bibliothèque affichait le titre "Harry Potter" sur l'étagère, mais que le livre était vide. Quand vous essayez de le lire, la bibliothèque doit courir chercher le vrai livre dans un entrepôt lointain.
• Le danger : Si vous êtes un robot (un programme informatique) ou un outil de sauvegarde, vous voyez le titre sur l'étagère et vous pensez : "Ah, le livre est là, je vais le copier." Mais quand vous essayez de le prendre, il n'y a rien dedans. Votre sauvegarde échoue, ou votre programme plante, et vous ne savez même pas pourquoi.

4. La Preuve par l'Expérience : Le Cas des 366 Go

L'auteur raconte son propre cauchemar. Après des années d'utilisation normale, il a découvert que son iCloud avait créé un "dossier archive" de 366 Go rempli de fichiers en double, de fichiers effacés silencieusement et de versions divergentes.

• L'analogie : C'est comme si vous aviez rangé vos vêtements dans un placard, et que le placard avait commencé à dupliquer certains vêtements, à en jeter d'autres sans vous le dire, et à mélanger les tiroirs. Pour remettre de l'ordre, il a fallu des semaines de travail manuel et des scripts informatiques pour comparer chaque fichier un par un.

5. Pourquoi cela arrive-t-il ? (La physique du problème)

Le document explique que le vrai problème vient de la façon dont le réseau fonctionne.

• Le problème : Quand votre ordinateur se déconnecte (vous fermez le capot de votre Mac, vous entrez dans un tunnel), il y a une "partition réseau". Les deux appareils ne se parlent plus.
• L'erreur d'iCloud : iCloud essaie de forcer une histoire linéaire (une seule version de la vérité) alors que, dans la réalité, il y a deux histoires différentes qui se sont déroulées en parallèle. En essayant de les fusionner de force, il détruit des données.
• La solution proposée (OAE) : L'auteur suggère une nouvelle façon de faire les choses (Open Atomic Ethernet). Au lieu de dire "Je suis sûr que c'est ça", le système devrait dire : "Je ne suis pas sûr, alors je m'arrête et j'attends que nous soyons tous d'accord avant de continuer." C'est comme un accord bilatéral : "Tu as reçu mon message ?" "Oui, je l'ai reçu." -> Alors on continue.

En résumé

iCloud est conçu pour être facile pour l'humain moyen (qui ne fait que regarder des photos), mais il est dangereux pour les données précises (code, documents de travail, sauvegardes).

Il commet une erreur fondamentale : il essaie de faire passer un système complexe et incertain (le nuage) pour un système simple et certain (votre disque dur). Quand vous essayez de faire des choses sérieuses avec, le système "ment" en vous montrant des fichiers qui n'existent pas encore, en effaçant des versions importantes, ou en bloquant vos outils.

Le message final : Ne faites pas confiance aveuglément à iCloud pour vos données critiques. Considérez-le comme un système de "synchronisation approximative" et gardez toujours une copie de sécurité ailleurs, car iCloud peut effacer votre travail sans même vous le dire.

Résumé technique

1. Le Problème : L'Erreur de Catégorie dans la Synchronisation Cloud

Le document identifie une faille fondamentale dans la conception d'iCloud Drive (et des systèmes de synchronisation similaires). Bien qu'iCloud présente une interface de système de fichiers transparente, il implémente une sémantique de synchronisation distribuée qui contredit les attentes POSIX.

• L'Erreur de Catégorie (Category Mistake) : Le problème central n'est pas un bug d'implémentation, mais une erreur conceptuelle : projeter un graphe causal distribué (les événements asynchrones de plusieurs appareils) sur une chaîne temporelle linéaire unique (le système de fichiers local).
• Conséquences : Cette projection suppose un ordre total là où seul un ordre partiel existe. Elle conduit à :
  • La perte d'information sur la provenance des conflits et la lignée de concurrence.
  • La destruction silencieuse de données (remplacement de versions par « Last-Writer-Wins » basé sur des horloges non synchronisées).
  • L'incompatibilité avec les outils qui reposent sur la cohérence immédiate et les verrous POSIX (Time Machine, Git, chaînes d'outils automatisées).
• Le Masquage : L'interface utilisateur cache cette impossibilité théorique (démontrée par Parker et al. en 1983 concernant la partition réseau) derrière une façade de « fluidité », transformant des problèmes connus en destruction de données silencieuse.

2. Méthodologie et Analyse

L'auteur utilise une approche combinant analyse théorique des systèmes distribués, étude d'architecture logicielle et preuves empiriques concrètes.

• Analyse Architecturale : Déconstruction des couches d'iCloud (NSFileCoordinator, fileproviderd, CloudKit/FoundationDB). L'analyse montre que bien que le serveur utilise des transactions ACID, le daemon client projette cet état riche sur un système de fichiers local incapable de le représenter, effaçant les garanties ACID.
• Étude de Cas Empirique (366 Go) : L'auteur documente une accumulation de 366 Go de divergence d'état (« iCloud Drive (Archive) ») résultant d'une utilisation normale sur plusieurs appareils. L'analyse a révélé :
  • Des dossiers existant uniquement dans l'archive (suppression silencieuse du magasin principal).
  • Des fichiers avec des noms identiques mais des sommes de contrôle MD5 différentes (dérive de version silencieuse).
  • La nécessité d'outils personnalisés pour fusionner les données sans perte.
• Expérimentation et Logs : Le document inclut une annexe détaillée avec 10 incidents observés (corruption de dépôts Git, blocage de fichiers Keynote, suppression de dossiers partagés, corruption de noms de fichiers par des préfixes aléatoires).
• Contrôle Négatif : Une expérience comparative a été menée entre iCloud Drive (avec « Optimiser le stockage Mac » activé) et un système de fichiers local (ext4). Cela a prouvé que les échecs (fichiers listés mais non lisibles, permissions bloquées) sont spécifiques au daemon fileproviderd d'iCloud et non à l'environnement d'exécution ou aux outils.

3. Contributions Clés

Le papier apporte plusieurs contributions techniques majeures :

1. Identification de l'Incompatibilité Structurelle : Démonstration que les systèmes de synchronisation cloud actuels (FITO - Forward-In-Time-Only) sont intrinsèquement incompatibles avec les outils de développement modernes (Git, Time Machine, agents IA) qui supposent des sémantiques POSIX strictes (verrous atomiques, visibilité immédiate des écritures).
2. Preuve de la « Catastrophe Silencieuse » : Documentation de la manière dont les partitions réseau et les stratégies de résolution de conflits basées sur les horodatages entraînent une perte de données permanente et non détectée (90 % des échecs dans les études citées sont silencieux).
3. Le Concept de « Fuite d'État Intermédiaire » : Explication de la façon dont iCloud propage des états de fichiers incomplets (fichiers « dataless » ou placeholders) avant que les applications n'aient terminé leurs opérations atomiques, corrompant ainsi les outils automatisés.
4. Proposition de Solution : OAE (Open Atomic Ethernet) : Introduction d'un modèle de sémantique transactionnelle basé sur :
   • Transactions Bilatérales : Les deux extrémités d'un lien maintiennent un état conjoint.
   • Réversibilité Symétrique : Toute opération peut être annulée proprement si l'incertitude survient, sans fuite d'état partiel.
   • Conservation de l'Information : Aucune donnée n'est jamais « perdue » ; elle est soit livrée, soit explicitement rejetée.
   • Topologie en Triangle : Utilisation de liens directs entre nœuds pour former des triangles de consensus, permettant la détection de pannes et la récupération sans dépendre d'un serveur central ou d'une couche de réseau commuté opaque.

4. Résultats Observés

• Échecs Documentés :
  • Git : Corruption des index et des fichiers de verrouillage (.git/index.lock), création de branches orphelines, impossibilité d'initialiser un dépôt dans iCloud.
  • Time Machine : Échec des sauvegardes dû à des dépendances circulaires avec le daemon de synchronisation qui modifie constamment l'état du système de fichiers.
  • Outils Automatisés (IA/Build) : Lecture de fichiers « dataless » (métadonnées présentes, données absentes) entraînant des échecs de compilation ou de traitement.
  • Métadonnées : Perte silencieuse des attributs étendus (extended attributes) et des fourches de ressources (resource forks).
• Preuve de l'Échec de la Résolution Actuelle : Les solutions de contournement actuelles (ex: stocker les dépôts Git hors iCloud) sont des admissions d'échec structurel plutôt que des corrections.
• Validation Théorique : Les résultats empiriques confirment les prédictions théoriques de Parker et al. (1983) sur l'impossibilité de maintenir la cohérence mutuelle lors de partitions réseau avec des protocoles FITO.

5. Signification et Implications

Ce document est une critique radicale de l'architecture actuelle du cloud computing grand public.

• Changement de Paradigme : Il suggère que le problème n'est pas technique (manque de bande passante ou de puissance de calcul) mais fondamental (mauvaise modélisation mathématique de la causalité et du temps).
• Au-delà d'iCloud : Le problème s'étend à tous les systèmes de synchronisation (Dropbox, OneDrive, Google Drive) et aux réseaux de données à grande échelle (fluctuation des liens ou link flapping dans les clusters IA), où l'incertitude transitoire est mal gérée, provoquant des effondrements systémiques.
• La Voie de la Résolution (OAE) : L'auteur propose que la solution ne réside pas dans des correctifs logiciels en surface (overlay networks), mais dans une refonte des protocoles de liaison (Layer 2) pour intégrer la réversibilité, la confirmation bilatérale et la conservation de l'information. Cela alignerait le comportement du protocole avec la réalité physique, où l'incertitude doit arrêter la progression plutôt que de corrompre l'état.
• Conclusion : Le papier conclut que tant que le « Catégorie Mistake » (traiter un ordre partiel comme un ordre total, traiter l'incertitude comme une erreur) ne sera pas résolu, la synchronisation transparente et fiable restera impossible. La solution existe dans la structure même de la physique des liens directs, mais elle nécessite un abandon des modèles de cloud centralisé actuels au profit de maillages locaux résilients.