> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Conflits de Game Saves

> Résolvez les conflits de PlayFab Game Saves lorsque les données de sauvegarde locales et cloud divergent, à l'aide de stratégies de synchronisation qui protègent la progression des joueurs entre appareils.

# Conflits de Game Saves et unités atomiques

## Vue d'ensemble

Des conflits de sauvegarde se produisent lorsque vous modifiez les mêmes données de jeu sur plusieurs appareils. Le système doit alors décider quelle version conserver. Pour concevoir la structure de vos données de sauvegarde, vous devez comprendre comment le système détecte et résout les conflits.

## Quand des conflits se produisent-ils ?

Des conflits se produisent pendant l'opération de synchronisation (`PFGameSaveFilesAddUserWithUiAsync`) uniquement lorsque toutes les conditions suivantes sont remplies :

1. **Des modifications locales existent** : vous avez modifié des fichiers localement depuis la dernière synchronisation.
2. **Des modifications cloud existent** : un autre appareil a chargé des données plus récentes depuis la dernière synchronisation.
3. **Même unité atomique** : les deux modifications se trouvent dans le même dossier de premier niveau.

### Matrice de détection des conflits

| Modifications sur l'appareil local | Le cloud contient des modifications dans la même unité atomique | Résultat |
| - | - | - |
| Fichiers modifiés | Oui | **CONFLIT** |
| Fichiers supprimés | Oui | **CONFLIT** |
| Aucune modification | Oui | Le téléchargement a lieu |
| Fichiers modifiés | Non | Le chargement a lieu |
| Fichiers supprimés | Non | La suppression a lieu |

## Qu'est-ce qu'une unité atomique ?

Certains systèmes de synchronisation de fichiers traitent les conflits fichier par fichier : si le même fichier doit être chargé et téléchargé, il y a conflit. Dans Game Saves, chaque sous-dossier de premier niveau est traité comme une *unité atomique*.

<Note>
  **Chaque sous-dossier de premier niveau constitue une unité atomique.**
</Note>

Si des fichiers ou sous-dossiers d'un sous-dossier de premier niveau doivent être téléchargés et que des fichiers ou dossiers de ce même sous-dossier racine doivent être chargés, l'ensemble de l'unité atomique est en conflit.

Cette approche vous permet de :

* **Préserver l'intégrité des données** : les fichiers interdépendants restent cohérents entre eux
* **Assurer l'isolation** : les données indépendantes placées dans des dossiers distincts se synchronisent sans conflit
* **Réduire les conflits** : les modifications apportées à différentes unités atomiques sur différents appareils sont fusionnées automatiquement

### Exemple de structure de sauvegarde

```
SaveRoot/
├── save.dat              ← Atomic unit: root
├── player.dat            ← Atomic unit: root
├── Save1/
│   ├── stats.json        ← Atomic unit: Save1
│   └── inventory.json    ← Atomic unit: Save1
├── Save2/
│   ├── stats.json        ← Atomic unit: Save2
│   └── inventory.json    ← Atomic unit: Save2
└── WorldState/
    ├── map.dat           ← Atomic unit: WorldState
    └── npcs/
        └── positions.dat ← Atomic unit: WorldState
```

### Scénarios de conflit

| Modifications de l'appareil A | Modifications de l'appareil B | Conflit ? | Pourquoi |
| - | - | - | - |
| `Save1/stats.json` | `Save1/inventory.json` | **OUI** | Même unité atomique : Save1 |
| `Save1/stats.json` | `Save2/stats.json` | Non | Unités différentes : Save1 et Save2 |
| `WorldState/map.dat` | `WorldState/npcs/positions.dat` | **OUI** | Même unité atomique : WorldState |
| `save.dat` | `Save1/stats.json` | Non | Unités différentes : racine et Save1 |
| `player.dat` | `save.dat` | **OUI** | Même unité atomique : racine |

## Fichiers de premier niveau : un cas particulier

**Tous les fichiers situés à la racine de la sauvegarde partagent une même unité atomique.**

Le système regroupe en une seule unité atomique tous les fichiers que vous placez directement à la racine de la sauvegarde (en dehors de tout sous-dossier). Si vous modifiez localement un fichier de premier niveau et qu'un autre appareil modifie un autre fichier de premier niveau, cette différence déclenche un conflit.

| Appareil A (local) | Appareil B (cloud) | Même unité atomique ? | Résultat |
| - | - | - | - |
| Modifie `rootfile1.txt` | Modifie `rootfile2.txt` | ✅ OUI | **CONFLIT** |
| Modifie `rootfile1.txt` | Modifie `save1/config.ini` | ❌ NON | Aucun conflit, les deux se synchronisent |
| Supprime `save.dat` | Modifie `progress.dat` | ✅ OUI | **CONFLIT** |

## Options proposées à l'utilisateur

En cas de conflit, les joueurs choisissent entre :

* **Use Local Data (Keep Local)** : conserver les données de sauvegarde actuelles de l'appareil.
* **Use Cloud Data (Keep Cloud)** : télécharger et utiliser les données de sauvegarde cloud.

### Important : la résolution est globale

<Note>
  ⚠️ **Important** : si les unités atomiques déterminent *quand* un conflit est détecté, le choix de résolution du conflit effectué par l'utilisateur s'applique à **l'ensemble de la sauvegarde**, et non à chaque unité atomique.
</Note>

### Exemple : scénario de conflit mixte

```
SaveRoot/
├── SlotA/ ← Local: modified, Cloud: modified  → CONFLICT
├── SlotB/ ← Local: modified, Cloud: unchanged → Local-only change
├── SlotC/ ← Local: unchanged, Cloud: modified → Cloud-only change
└── SlotD/ ← Local: modified, Cloud: unchanged → Local-only change
```

**L'utilisateur voit une invite de conflit** (en raison de SlotA).

| Choix de l'utilisateur | SlotA | SlotB | SlotC | SlotD |
| - | - | - | - | - |
| **Keep Local** | ✅ Version locale conservée | ✅ Version locale chargée | ❌ Modification cloud **PERDUE** | ✅ Version locale chargée |
| **Keep Cloud** | ✅ Version cloud téléchargée | ❌ Modification locale **écrasée** | ✅ Version cloud téléchargée | ❌ Modification locale **écrasée** |

### Pourquoi c'est important

1. **Keep Local entraîne la perte des modifications présentes uniquement dans le cloud** : si vous choisissez "Keep Local" en raison d'un conflit dans SlotA, vous ne recevez pas la mise à jour cloud de SlotC effectuée par un autre appareil.

2. **Keep Cloud entraîne la perte des modifications présentes uniquement en local** : si vous choisissez "Keep Cloud", l'état cloud écrase vos modifications locales de SlotB et SlotD.

3. **Restauration possible** : les deux choix conservent la branche écartée afin de permettre une restauration ultérieure.

### Récapitulatif de la conception

| Aspect | Granularité |
| - | - |
| **Détection** des conflits | Par unité atomique (sous-dossier racine) |
| **Résolution** des conflits | Ensemble de la sauvegarde (globale) |

Cette approche globale simplifie l'expérience des joueurs. Bien qu'une résolution par unité atomique préserve techniquement la cohérence des données (puisque les unités atomiques définissent les limites de cohérence), elle pose des problèmes d'expérience utilisateur :

* Les joueurs doivent comprendre la notion d'unité atomique et de limites de dossiers.
* Des résultats mixtes (certains dossiers issus de la version locale, d'autres du cloud) peuvent laisser les joueurs dans le doute quant à l'état final.
* Demander une confirmation séparée pour chaque unité atomique en conflit rend la résolution des conflits fastidieuse.

En proposant un choix unique entre **Keep Local** et **Keep Cloud**, les joueurs prennent une seule décision claire sans avoir à comprendre la structure sous-jacente de la sauvegarde.

## Quand aucun conflit ne se produit

### Suppression des deux côtés

Si les deux appareils suppriment le même fichier (ou des fichiers de la même unité atomique), **aucun conflit ne se produit**. Le système reconnaît que les deux appareils s'accordent sur la suppression du fichier.

### Modifications dans des unités atomiques différentes

Si l'appareil A modifie des fichiers dans `SlotA/` et que l'appareil B modifie des fichiers dans `SlotB/`, aucun conflit ne se produit. La synchronisation fusionne automatiquement les deux modifications.

## Bonnes pratiques

### 1. Concevez soigneusement la structure des dossiers

Utilisez des sous-dossiers pour les unités de sauvegarde indépendantes :

```
SaveRoot/
├── Slot1/           ← Each slot is independent
│   └── save.dat
├── Slot2/
│   └── save.dat
```

Un système de sauvegarde de jeu par emplacements, dans lequel chaque emplacement est un sous-dossier de premier niveau, est un exemple simple d'utilisation efficace des unités atomiques.

Autres exemples :

* **Données de référence partagées** : stockez les données susceptibles d'être utilisées par n'importe quel emplacement de sauvegarde, comme le contenu débloqué ou les succès, dans un sous-dossier dédié afin qu'elles se synchronisent indépendamment des emplacements de sauvegarde individuels.
* **Grandes collections de ressources** : si votre jeu stocke de grands ensembles de fichiers mis à jour indépendamment, comme des packs de contenu téléchargés ou des niveaux créés par les utilisateurs, envisagez de les répartir dans plusieurs sous-dossiers racine afin que les mises à jour d'une collection n'entrent pas en conflit avec celles d'une autre.

### 2. Évitez les fichiers de premier niveau pour les données fréquemment modifiées

Tous les fichiers de premier niveau partagent une même unité atomique. Évitez de placer à la racine des fichiers fréquemment modifiés si vous souhaitez les synchroniser indépendamment.

**Au lieu de :**

```
SaveRoot/
├── autosave.dat     ← All root files = 1 atomic unit
└── save1.dat
└── save2.dat
```

**Envisagez :**

```
SaveRoot/
├── AutoSave/
│   └── autosave.dat     ← Independent unit
└── Save1/
    └── gamesave.dat ← Independent unit
```

### 3. Regroupez les données associées

Utilisez le même dossier pour les fichiers qui doivent rester cohérents entre eux.

```
SaveRoot/
├── Save1/
│   ├── stats.json       ← These files are interdependent
│   ├── inventory.json   ← and should conflict together
│   └── quests.json
```

### 4. Réduisez les conflits

Effectuez des chargements fréquents pour réduire le risque de conflits. Plus vous synchronisez souvent, moins il est probable que deux appareils présentent des modifications divergentes.

### 5. Surveillez les taux de conflit

Utilisez les [événements PlayStream](/fr/services/playfab/player-progression/game-saves/playstream-events) pour suivre la fréquence des conflits et la façon dont les joueurs les résolvent. Un taux de conflit en hausse ou une forte prédominance de "keep local" par rapport à "keep remote" peut signaler des problèmes d'expérience utilisateur ou de cadence de sauvegarde qui méritent d'être examinés.


## Related topics

- [Démarrage rapide de Game Saves](/fr/services/playfab/player-progression/game-saves/quickstart.md)
- [Restauration de Game Saves](/fr/services/playfab/player-progression/game-saves/rollback.md)
- [Rappels d'interface utilisateur de Game Saves](/fr/services/playfab/player-progression/game-saves/ui-callbacks.md)
- [FAQ sur la gestion des erreurs de Game Saves](/fr/services/playfab/player-progression/game-saves/error-handling-faq.md)
- [Stratégies de liaison de comptes pour PlayFab Game Saves](/fr/services/playfab/player-progression/game-saves/linking.md)