RP - Migration des dossiers usagers
Procédure technique - Juin 2025. Workflow complet de traitement des tickets de migration de dossiers usagers sur Reconnect Pro.
Cette procédure s'applique à chaque ticket Trello de type « Migration des dossiers usagers ». Suivre les étapes dans l'ordre.
La commande
La commande Symfony utilisée pour migrer les dossiers est :
php bin/console app:migrate-individuals-to-other-organization -o {ORIGINE_ID} -d {DESTINATION_ID} -f {CHAMP_MIGRATION} -t "{VALEUR_CIBLE}"
Options disponibles
Option | Nom long | Description | Exemple |
|---|---|---|---|
|
| ID du centre d'origine (celui qui perd des suivis) |
|
|
| ID du centre de destination (celui qui reçoit les suivis) |
|
|
| Slug du champ personnalisé utilisé comme critère de migration |
|
|
| Valeur du champ qui déclenche la migration (doit correspondre exactement à la valeur saisie dans le dossier) |
|
| - | Migrer tous les individus du centre d'origine, sans condition sur un champ. Incompatible avec
/
. |
|
| - | Inclure les individus supprimés (soft-deleted) dans la migration |
|
| - | Migrer également les hébergements liés aux individus migrés. Voir section dédiée ci-dessous. |
|
| - | Mode simulation : aucune donnée modifiée. Toujours lancer en premier. |
|
Logique de ciblage : seuls les dossiers du centre d'origine dont le champ -f contient exactement la valeur -t sont migrés. Les dossiers avec le champ vide restent dans le centre initial. La valeur est recherchée d'abord sur le membre principal du foyer, puis sur les autres membres si non trouvée.
Migration avec hébergements (--withAccommodations)
Lorsque l'option --withAccommodations est activée, la commande migre également les hébergements (Accommodation) liés aux individus migrés : l'hébergement est réaffecté au centre de destination.
Cas problématique - hébergement partagé : si un hébergement contient à la fois des individus migrés et des individus non migrés (restant dans le centre d'origine), la commande le détecte et affiche un tableau d'alerte en dry-run. Ce cas nécessite une décision manuelle avant de lancer la migration réelle.
Output dry-run avec hébergements
Le dry-run affiche, en plus du tableau des suivis, un récapitulatif des hébergements :
- Le nombre total d'hébergements qui seraient migrés
- Si des hébergements problématiques existent : un tableau listant pour chaque hébergement les individus migrés et les individus non migrés encore rattachés
Exemple de sortie en cas de problème :
Hébergements à migrer: 3
Problème: Hébergements avec individus non migrés rattachés
------------ ---------------- ---------------------- -----------------
Centre ID Hébergement ID Individus non migrés Individus migrés
------------ ---------------- ---------------------- -----------------
4537 892 1042, 1078 1035
------------ ---------------- ---------------------- -----------------
En présence d'hébergements problématiques, ne pas lancer la migration réelle sans avoir tranché : soit on accepte de migrer l'hébergement (les individus non migrés se retrouveront sans hébergement dans le centre d'origine), soit on exclut --withAccommodations et on traite les hébergements manuellement.
Comportement sans --withAccommodations
Par défaut (sans l'option), les individus migrés sont décrochés de leur hébergement avant migration, leur spot d'hébergement est réinitialisé. L'hébergement lui-même reste dans le centre d'origine.
Procédure
Étape 1 - Lire le ticket et construire les commandes
Le ticket Trello contient la liste des centres d'origine et leurs règles de migration. Pour chaque règle, construire une commande dédiée.
Exemple de lecture d'un ticket
Ticket : « Centre initial = France Fraternités - CHU 75 (ID 4537) - lorsque le champ = CHU 77 → vers France Fraternités - CHU 77 (ID 5644) »
→ Commande correspondante (sans hébergements) :
php bin/console app:migrate-individuals-to-other-organization -o 4537 -d 5644 -f migration-des-donnees -t "CHU 77"
→ Commande correspondante (avec hébergements) :
php bin/console app:migrate-individuals-to-other-organization -o 4537 -d 5644 -f migration-des-donnees -t "CHU 77" --withAccommodations
Cas de croisement : si deux centres d'origine s'échangent des suivis (ex : CHU 75 → CPH et CPH → CHU 75), traiter les deux groupes séparément et séquentiellement, terminer et vérifier le premier groupe avant de lancer le second. Ne jamais les lancer en parallèle.
Étape 2 - Lancer les simulations (dry-run)
Avant toute migration réelle, lancer toutes les commandes en mode --dry-run sur la preprod pour vérifier les volumes. Ajouter --withAccommodations si le ticket concerne aussi les hébergements.
Exemple :
php bin/console app:migrate-individuals-to-other-organization -o 4537 -d 5644 -f migration-des-donnees -t "CHU 77" --dry-run
La commande affiche un tableau récapitulatif des suivis :
Rôle | Centre ID | Centre Nom | Nb. suivis | Après migration |
|---|---|---|---|---|
Origine | 4537 | France Fraternités - CHU 75 | 160 | 119 (- 41 migrés) |
Destination | 5644 | France Fraternités - CHU 77 | 0 | 41 (+ 41 entrants) |
Si --withAccommodations est passé, un second bloc s'affiche avec le nombre d'hébergements impactés et les éventuels conflits. Résoudre tous les conflits d'hébergement avant de continuer.
Répéter pour chaque commande du ticket. Copier tous les outputs console.
Étape 3 - Synthèse et validation PO
Une fois toutes les simulations effectuées (et les éventuels conflits d'hébergement résolus), transmettre les résultats au PO pour validation avant migration réelle. Deux formats possibles :
Option A — Message Slack directe au PO
Rédiger un message structuré avec les volumes par migration.
Centre d'origine : France Fraternités - CHU 75 (ID 4537) - 160 suivis au total
→ vers CHU 77 (ID 5644) : 41 migrés | reste 119
→ vers CPH (ID 4960) : 10 migrés | reste 150
→ vers DAHAR (ID 5634) : 19 migrés | reste 141
→ vers TEH (ID 5645) : 7 migrés | reste 153
Centre d'origine : France Fraternités - CPH (ID 4960) - 180 suivis au total
→ vers CHU 75 (ID 4537) : 21 migrés | reste 159
→ vers CHU 77 (ID 5644) : 37 migrés | reste 143
→ vers DAHAR (ID 5634) : 35 migrés | reste 145
→ vers TEH (ID 5645) : 17 migrés | reste 163
Hébergements : [X hébergements migrés — aucun conflit détecté / ou décrire les conflits et la décision prise]
Option B - Excel de simulation
Générer le fichier Excel de simulation nommé simulation_migration_{NOM_CENTRE}.xlsx et contient un tableau par centre d'origine avec décompte progressif.
Déposer le fichier dans le Drive à l'emplacement :
Z-NEW RECONNECT > 4- Technique > Reconnect Pro > Migration des dossiers usagers
Partager le lien Drive sur le ticket Trello et ping PO.
Étape 4 - Mise à jour du ticket Trello
Une fois la validation PO reçue, coller dans le ticket Trello les commandes finales à exécuter sans --dry-run pour la preprod et la prod.
Format à utiliser dans le ticket :
Centre initial = [Nom centre] (ID XXXX)
Commande 1 :
php bin/console app:migrate-individuals-to-other-organization -o XXXX -d YYYY -f migration-des-donnees -t "VALEUR"
Commande 2 :
...
Toujours exécuter et vérifier sur la preprod en premier, puis reproduire sur la prod. Ne jamais lancer directement en prod sans validation preprod.
En cas de croisement entre deux centres, respecter l'ordre défini dans le ticket et attendre la fin du premier groupe avant de lancer le second, même en prod.