Migrer d'une structure plate vers une structure N-niveaux

La plupart des églises commencent avec une structure plate — tout le monde est juste "membre", il y a un site et l'organigramme est dans la tête de quelqu'un. Cela fonctionne jusqu'à ce que le deuxième campus ouvre, que le premier responsable de cellule ait besoin d'une portée, ou que les anciens veuillent des répartitions démographiques par région.

Cette page parcourt la migration : d'une organisation à un seul palier (ou d'une configuration héritée à trois niveaux branche/centre/bascenta) au modèle N-niveaux que GCM utilise aujourd'hui.

Deux points de départ

Vous êtes probablement dans l'une de ces positions :

• Nouvelle organisation GCM avec un niveau défini. Vous avez ajouté quelques unités au niveau 1 (ou simplement laissé le niveau Branche par défaut ensemencé) et maintenant vous voulez ajouter les niveaux 2 et 3 sans déranger les membres déjà au niveau 1.
• Organisation GCM existante d'avant la sortie de N-niveaux. Vos données sont déjà dans org_units — le modèle hérité à trois niveaux a été migré par GCM lors d'une mise à jour de la plateforme. Vous n'avez pas besoin de migrer les données ; vous pourriez vouloir renommer ou restructurer.

Les deux suivent la même forme. Les différences sont appelées là où elles importent.

La forme de la migration

1. Auditez ce que vous avez. Listez chaque unité existante et le nombre de membres affectés.
2. Concevez l'arbre cible sur papier. Décidez les noms de niveau, quelles unités existantes deviennent quelles nouvelles unités, et où atterrissent les membres.
3. Ajoutez les nouveaux niveaux dans Paramètres. Les niveaux d'abord, les unités ensuite.
4. Créez les nouvelles unités. Commencez au niveau supérieur et descendez.
5. Réaffectez les membres. Déplacez-les du niveau 1 vers le niveau feuille approprié.
6. Archivez les anciennes unités si elles ne sont plus nécessaires.
7. Re-restreignez les utilisateurs afin que les bergers voient la bonne tranche.
8. Vérifiez la cohérence des rapports avant d'annoncer.

Vous pouvez le faire de manière incrémentale — il n'y a pas de "mode migration". L'organisation continue de tourner tout au long.

Étape 1 : auditer

Ouvrez la page Structure organisationnelle et notez chaque unité active. Notez le badge de comptage de membres sur chacune. Exportez la liste de membres filtrée par unité (/members?org_unit=<id>) en CSV si vous voulez une piste papier.

Choses à signaler :

• Unités avec zéro membre — candidates à la suppression avant de commencer.
• Unités sans responsable — candidates à la correction pendant que vous y êtes de toute façon.
• Unités nommées en double sous différents parents — faciles à mélanger pendant la réaffectation.

Étape 2 : concevoir la cible

Croquez le nouvel arbre avant de toucher l'interface. Une cible courante :

Branche (niveau 1)
└── Centre (niveau 2)
    └── Cellule (niveau 3)

Pour chaque unité existante, décidez sur quelle unité de niveau feuille ses membres atterriront. Si tout le monde est actuellement au niveau 1 ("Branche Acacia") et que vous ajoutez des cellules, vous devez savoir quelle cellule chaque membre rejoint. C'est une décision pour votre équipe, pas pour GCM.

Documentez le mappage dans un tableur :

Unité actuelle (niveau 1)	Nouvelle unité (niveau 3)	Comptage de membres
Branche Acacia	Cellule Acacia A	45
Branche Acacia	Cellule Acacia B	38
Branche Acacia	Cellule Acacia C	22

Étape 3 : ajouter de nouveaux niveaux dans Paramètres

Allez dans Paramètres → Hiérarchie organisationnelle et ajoutez les niveaux que vous n'avez pas encore. Voir Définir des niveaux pour la procédure champ par champ.

Nommez-les comme votre église parle. Enregistrez. Ne vous inquiétez pas encore de la création d'unités — les niveaux doivent juste exister.

Étape 4 : créer les nouvelles unités

Ouvrez l'arbre organisationnel. Étendez l'unité de niveau 1 sous laquelle vous voulez imbriquer. Utilisez le menu trois-points pour ajouter des unités enfants un niveau en dessous. Répétez pour le niveau 3.

Pour beaucoup d'unités à la fois, entrez dans la page de niveau (/hierarchy/2) et ajoutez-les carte par carte. C'est plus rapide que la danse de la boîte de dialogue sur l'arbre.

Définissez les adresses et les emplacements sur carte au passage — le module carte se peuplera dès que le géocodeur aura rattrapé.

Étape 5 : réaffecter les membres

C'est la partie où la plupart des églises perdent patience. Deux options :

Option A — une unité à la fois, dans l'interface

1. Ouvrez la page de détails de la nouvelle cellule.
2. Cliquez sur Ajouter un membre, cherchez, choisissez, confirmez.
3. Répétez pour chaque membre qui appartient à la cellule.

Lent mais visible. Bon pour les petites organisations (< 100 membres).

Option B — en masse via la liste des membres

1. Allez dans Membres et filtrez aux membres prévus pour la cellule (par nom, par statut de visiteur, par tout ce que vous voulez).
2. Sélectionnez toutes les lignes.
3. Actions en masse → Affecter à une unité → choisissez la cellule.

GCM upserts les affectations. Les lignes existantes de niveau 3 sont remplacées ; si le niveau 1 était déjà défini, cette ligne reste intacte. (Pour effacer le niveau 1 en masse aussi, lancez d'abord Désaffecter du niveau 1.)

Pour les grandes migrations, vous pouvez aussi cuire l'affectation d'unité dans un import CSV unique, mais vous ré-importeriez des données déjà dans le système — généralement plus de travail que l'action en masse.

La réaffectation est une-par-niveau, pas plusieurs-par-unité

Un membre au niveau 1 sans affectation de niveau 3 obtient une nouvelle ligne de niveau 3 ajoutée — rien n'est remplacé. Mais un membre déjà sur le niveau 3 Cellule Acacia A que vous réaffectez à Cellule Acacia B remplace la ligne. L'index unique garantit qu'il n'y a pas de doublons.

Étape 6 : archiver les anciennes unités

Si votre ancienne Branche Acacia de niveau 1 a encore des membres directement affectés après la migration, vous avez deux chemins :

• Laissez-les là. Les membres au niveau branche cascadent toujours vers le haut correctement. Vos rapports d'agrégation continuent de fonctionner.
• Déplacez-les avec Actions en masse → Désaffecter du niveau 1 et laissez-les seulement au niveau feuille.

Vous ne voulez probablement pas archiver la Branche Acacia de niveau 1 — c'est toujours votre unité de niveau supérieur, juste maintenant avec des descendants. Mais si vous restructurez vraiment (par exemple Branche Acacia et Branche Érable fusionnent en Branche Arbre), voir Archiver et restaurer pour les règles de cascade.

Étape 7 : re-restreindre les utilisateurs

Les bergers que vous aviez précédemment restreints à Branche Acacia voient maintenant tout le sous-arbre Acacia par défaut. Si c'est ce que vous voulez, aucune action.

Si vous voulez qu'un responsable de cellule soit restreint uniquement à sa cellule :

1. Allez dans Utilisateurs et rôles → Utilisateurs et ouvrez l'utilisateur.
2. Cliquez sur Modifier les affectations.
3. Décochez l'affectation de niveau branche et cochez celle de niveau cellule.
4. Enregistrez.

Le prochain chargement de page reprend la nouvelle portée. Voir Affecter des responsables et des bergers pour le modèle complet.

Étape 8 : vérifier la cohérence

Avant d'annoncer le changement à votre équipe, vérifiez :

• Le comptage total de membres sur le tableau de bord correspond à ce que vous aviez avant.
• Le comptage de membres par branche correspond à la somme de ses descendants.
• La connexion d'un berger ne montre que les membres de sa cellule.
• Le rapport de présence de la semaine dernière se résout toujours — les événements historiques utilisent l'id d'unité, qui n'a pas changé.
• La carte affiche les nouvelles unités épinglées à leurs adresses.

Les divergences viennent généralement d'affectations de niveau 1 restantes dont vous n'aviez pas conscience. Ré-exportez la liste de membres, triez par unité et cherchez les blancs.

Ce que vous n'avez pas à migrer

Le modèle de colonnes héritées à trois niveaux branche/centre/bascenta est entièrement supprimé du code de l'application depuis la dernière mise à jour de la plateforme. Si vos anciennes données réfèrent à ces colonnes, GCM a déjà migré les lignes dans org_units lors de la mise à niveau. Les étiquettes ont été préservées comme niveaux 1, 2, 3 avec les noms d'origine. Vous n'avez rien à faire pour "compléter" la migration — le nouveau modèle est le seul modèle.

Les références du système de types aux colonnes héritées survivent dans src/integrations/supabase/types.ts parce que ce fichier est auto-généré depuis la base de données, et les colonnes n'ont pas été supprimées. L'application les ignore.

Questions courantes

Puis-je faire cette migration par étapes sur des semaines ? Oui. Il n'y a pas de "bascule". Vous pouvez ajouter le niveau 2 aujourd'hui, le niveau 3 le mois prochain. Assurez-vous simplement que les membres sont placés avant qu'un rapport ne dépende de la nouvelle structure.

Que se passe-t-il pour les lignes de présence et de dons existantes qui réfèrent aux anciennes unités ? Elles sont indexées par id d'unité, pas par niveau. Tant que l'id d'unité existe (que ce soit au niveau 1 ou en tant qu'entité renommée), la ligne se résout toujours. Archiver ou supprimer l'ancienne unité est ce qui casserait les rapports historiques — donc faites-le avec soin.

Dois-je supprimer ou archiver après la migration ? Archivez. Toujours archivez. Vous pouvez toujours changer d'avis et désarchiver ; la suppression est finale depuis l'interface.

Étapes suivantes

• Définir des niveaux — configurer les noms de palier cibles.
• Créer des unités — peupler les nouveaux niveaux.
• Affecter des membres — rattacher les personnes aux bonnes feuilles.