Données invité, connexion et changement de compte : où vont les données d'un projet
SlateX place les données de l'état invité et celles de l'état connecté dans deux bases de données physiques séparées, qui utilisent le même modèle de données mais ne sont pas le même fichier. La base invité ne porte que les fiches de l'état non connecté ; la base du compte porte les fiches après connexion, et seule la base du compte est configurée avec une base privée dans le nuage. Au changement de compte, l'appartenance n'est pas traitée non plus comme « qui est connecté à cet instant, et à qui vont toutes les fiches », mais jugée fiche par fiche selon des conditions d'identité Apple.
Des bases séparées répondent à « de quel côté tombent les données », et ne valent aucune garantie de sécurité, de confidentialité ni de résultat inter-appareils.
La base invité et la base du compte sont deux fichiers
La base invité et la base du compte se trouvent toutes deux dans un sous-répertoire dédié du répertoire Application Support de l'app. Cet emplacement n'est pas un emplacement Documents que l'utilisateur parcourt directement dans l'app Fichiers, et on ne peut donc pas comprendre « retrouver le fichier de base de données » comme déjà détenir tous les médias, pas plus qu'écrire une sauvegarde isolée du fichier de base de données comme une solution de sauvegarde complète.
Les deux bases partagent la même instance de modèle de données, et les objets projet, scènes, fiches de prise et médias de continuité restent donc exprimés selon la même structure. La différence est le point de stockage : les données invité entrent dans la base invité, et les données du compte, après connexion, entrent dans la base du compte. Le code ne configure une base privée dans le nuage que pour la base du compte ; la base invité ne porte aucune configuration d'envoi vers le nuage pendant tout son cycle de vie. Ce qui est dit ici est un fait de configuration du code, et non une conclusion de test du type « vérifié sur l'appareil, rien ne partira au nuage ».
Photos et vidéos ne sont pas la même chose dans la base
Le corps des données d'une photo est conservé comme données binaires dans la base de données, et il voyage donc avec la fiche de base de données. Une vidéo est différente : la base conserve un chemin pointant vers un fichier local, et non le fichier vidéo lui-même dans un champ de la base.
Cette différence veut dire que la fiche d'une photo et le chemin d'une vidéo ne doivent pas être compris comme le même mécanisme d'un appareil à l'autre. Le code peut dire ce que la base de données conserve respectivement, mais ne peut pas s'en servir pour promettre « on l'aura forcément après un changement d'appareil » ni « on ne l'aura forcément pas ». Le destinataire ne peut y voir que deux formes de stockage distincts, et non tenir la synchronisation de la base pour l'arrivée déjà faite des fichiers médias.
Une fiche de média dans la base de données ne veut pas dire que le fichier local correspondant est déjà apparu sur un autre appareil.
Après connexion, l'appartenance ne change pas la base entière de maître
Du côté du compte, l'appartenance des données est jugée fiche par fiche selon des conditions d'identité Apple. Un projet et les fiches atteignables depuis lui doivent pouvoir retomber sur le chemin d'appartenance correspondant à l'identité courante, et le seul fait qu'un compte soit connecté à cet instant ne permet pas de tenir tout le contenu de la base comme appartenant à ce compte.
Ce jugement influence aussi si une fiche peut continuer d'être lue, migrée ou supprimée lors d'un changement de compte. Autrement dit, l'état de connexion n'est qu'une des conditions définissant dans quel environnement de données on entre ; à qui appartient une fiche précise dépend encore de la chaîne de relations par laquelle cette fiche peut remonter jusqu'à une identité.
Les données invité ne migrent qu'à une connexion volontaire
Le transfert des fiches invité vers la base du compte ne se produit pas en passant lorsque la connexion est rétablie. Seul le chemin où l'utilisateur lance lui-même la connexion permet de démarrer la migration invité ; quand l'app rétablit une connexion à partir d'identifiants déjà présents, elle ne déplace pas la base invité automatiquement.
La migration elle-même s'exécute par phases : d'abord un instantané de la base invité, puis l'écriture des objets migrables dans la base du compte, ensuite une vérification attribut par attribut, relation par relation et appartenance par appartenance dans un nouveau contexte. Ce n'est que la vérification réussie que les fiches invité du côté source sont nettoyées. Si une phase échoue, le côté source n'entre pas dans l'étape de nettoyage.
Si la vérification échoue, l'original est conservé : mieux vaut ne rien bouger que bouger à moitié. Cette phrase décrit l'ordre de migration actuel, et ne veut dire ni que le réseau, ni que le nuage, ni qu'un autre appareil ait achevé une vérification supplémentaire.
Jusqu'où cette page peut répondre
Ce mécanisme répond à : dans quelle base tombent respectivement les fiches invité et les fiches de compte, quelle base est configurée avec une base privée dans le nuage, sous quelle forme les médias apparaissent dans la base, et comment les données invité migrent après contrôle lors d'une connexion volontaire. Il ne peut pas prouver un modèle de chiffrement particulier ni une garantie de confidentialité générale, ne peut pas prouver que personne ne peut les lire, et ne peut pas transformer une configuration de code en audit de sécurité déjà mené sur l'appareil.
Si la question devient « un autre appareil affichera-t-il le même média au même moment », « pourra-t-on restaurer après avoir supprimé l'app » ou « telle réglementation est-elle satisfaite de ce fait », cette page décrit seulement la façon dont les répertoires de données de cet appareil local sont réellement organisés, et n'extrapole pas à ces situations.
FAQ
L'état invité et l'état connecté utilisent-ils la même base de données ?
Non. Les deux états utilisent des fichiers de base de données physiques séparés, mais partagent la même instance de modèle de données ; les fiches invité entrent dans la base invité et les fiches après connexion dans la base du compte.
La base invité passe-t-elle aussi dans la base privée du nuage ?
Le code actuel ne configure aucun envoi vers le nuage pour la base invité ; seule la base du compte est configurée avec une base privée dans le nuage. Cette phrase décrit une configuration de code, et ne vaut pas un test sur appareil ayant prouvé tous les comportements réseau.
Pourquoi photos et vidéos ne relèvent-elles pas de la même attente inter-appareils ?
Parce que le corps des données d'une photo est conservé dans un champ de la base, tandis que la base ne conserve pour une vidéo qu'un chemin local. Les deux formes de stockage diffèrent, et la seule existence d'une fiche dans la base ne permet pas d'inférer qu'un autre appareil a déjà reçu le fichier correspondant.
Quand les données invité passent-elles au compte connecté ?
Seul un lancement volontaire de la connexion par l'utilisateur permet de démarrer la migration invité ; la restauration d'un état de connexion déjà existant ne migre rien automatiquement. La migration passe par écriture puis vérification, et les fiches source sont conservées si la vérification échoue.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.