# Phase 2 — Design (post-SAGIP'26) Document de cadrage des chantiers reportés après SAGIP'26 (Bordeaux, 10-12 juin 2026). Ces chantiers sont **liés au SIS hiérarchique SAGIP** et au système d'authentification : les implémenter avant d'avoir posé proprement le modèle SIS produit du jetable. --- ## 1 · Hiérarchie SIS SAGIP (préalable à tout le reste) ``` sis://sagip-france ← organisation racine ├── sis://sagip-chapitre-automatique ← 3 chapitres ├── sis://sagip-chapitre-genie-industriel (Automatique, Productique/GI, ├── sis://sagip-chapitre-ifac IFAC France NMO) │ ├── sis://sagip-ct-ingefutur ← 28 CTs (un SIS par CT) ├── sis://sagip-ct-jnum chaque CT appartient à ├── sis://sagip-ct-ifsa 1+ chapitre (recoupement) │ … │ ├── sis://sagip-conf-2026 ← édition annuelle │ ├── sessions/ les sessions du programme │ ├── communications/ les 257 com individuelles │ └── participants/ amorces SIS local des participants │ └── sis://sagip-membres-permanent ← annuaire long terme (un slug par membre, indep. édition) ``` **Stockage** : adapter le pattern tarba-en-canta — un répertoire par SIS sous `/home/bece1793/_hosted/organisations/_by-region/fr/sagip-france/`, chaque SIS contient `_config.yaml`, sous-dossiers `personnes/`, `is/` (IS pairs), `_log/append-only.jsonl`. **Chiffrement PII at-rest** : AES-256-GCM avec clé maître par SIS (cf. `tarba/_lib/storage.php`). --- ## 2 · Authentification (réutilisable depuis tarba) ### Modèle codes 6 chiffres - Mint d'un code par un super-admin / responsable CT (via console admin) - Code porte `{role, person_slug, person_label, ct?}` → `redeem` crée un IS pair `active` - Multi-use (re-redeem par le même slug = ajout d'un device) - TTL 14 jours par défaut ### Modèle pair (multi-device, déjà phase 1) - Code 6 chiffres TTL 15 min single-use pour resynchroniser deux devices d'**un même** participant non-authentifié. ### Validation d'identité (3 modes possibles) 1. **Présentielle via console admin** : admin saisit le nom du participant, génère un code, lui dicte. Participant le saisit dans l'app → IS pair `active` + `associated_to_person`. 2. **Asynchrone par message** : participant envoie un message d'amorce (avec identité réclamée) → admin valide depuis la console. 3. **Auto-validation par code distribué en amont** : codes pré-mintés (équivalents aux invitations physiques imprimées sur badge SAGIP'26). ### Rôles attendus - `super-admin` : tout - `responsable-ct` : gère son CT (sessions, communications, animateurs) - `chair-session` : modère questions d'une session précise - `presentateur` : auteur d'une communication (lecture des questions adressées) - `membre-permanent` : amorce SIS local stable entre éditions - `participant-edition` : amorce SIS limitée à l'édition courante --- ## 3 · Messagerie admin ↔ SIS / personnes / groupes ### Trigger UX souhaité > Clic droit (ou long-press) sur un élément cliquable (carte personne, carte CT, ligne note, ligne profil) → menu contextuel avec actions : *Envoyer un message*, *Valider l'identité*, *Promouvoir*, *Archiver*… ### Pattern à reprendre de tarba - Chaque IS pair a `participants/host/` et `participants//` avec `inbox.json` + `outbox.json` (cf. `tarba/_lib/storage.php`). - Messages append-only signés HMAC. - Audience d'un message : individu (1 IS pair), groupe (CT), broadcast édition. - `tarba/admin/chat.php` + `tarba/admin/broadcast.php` = endpoints types à adapter. ### UI admin proposée - Sidebar "Conversations" listée par récence - Panneau central : timeline de messages avec rich text minimal (markdown léger) - Onglet "Validations en attente" : amorces SIS sans identité confirmée --- ## 4 · Édition du programme côté admin ### Permissions | Action | super-admin | responsable-ct | chair-session | |---|---|---|---| | Créer / supprimer session | ✓ | ✗ | ✗ | | Modifier horaire / salle d'une session du CT | ✓ | ✓ (CT propre + sessions communes selon liste) | ✗ | | Réordonner communications d'une session CT | ✓ | ✓ | ✓ (jour J seulement) | | Ajouter résumé / lien papier à une communication | ✓ | ✓ | ✓ | | Annoncer un changement de salle (broadcast) | ✓ | ✓ | ✓ | | Modérer / annuler une question | ✓ | ✓ | ✓ | ### Stockage - Édition courante : `sis://sagip-conf-2026/sessions/.yaml` (lieu mutable) - Source initiale (immutable) : `editions/2026/programme.json` (committed) - Diffs/overrides : `sis://sagip-conf-2026/programme-overrides/.yaml` - Broadcast : append-only `_log/programme-changes.jsonl` + push WebPush ou polling 60s ### UI - Vue Programme côté admin : reprend la timeline du client, mode édition inline - Bouton "Annoncer ce changement" → broadcast WebPush + indication dans le client --- ## 5 · Annuaire post-édition (longue durée) ### Concept Permettre au participant SAGIP'26 de **rester connecté avec ses contacts** après la conférence : un annuaire opt-in où chacun choisit ce qui reste visible (nom, institution, CT, email). ### Stockage - `sis://sagip-membres-permanent//profil.yaml` (PII chiffrés) - Visibilité contrôlée par contrat opt-in : - `public` (visible par tous les SAGIP), `chapitre` (mon chapitre), `ct` (mon CT), `prive` (rien) - Lien "SIS friend" entre deux SIS = autorise vue privilégiée ### Migration depuis SAGIP'26 À la fin de l'édition, popup : *"Voulez-vous garder votre profil sur l'annuaire SAGIP long terme ?"* → si oui, transfert depuis `sagip-conf-2026/participants/` vers `sagip-membres-permanent/`. --- ## 6 · Concept relay (vs host dédié) ### Pourquoi un relay > Pour ne pas dépendre d'un host central qui devient un SPOF. SAGIP-france comme **relay** : route les messages entre SIS player (participants) et SIS organisationnels (chapitres / CTs / édition) sans stocker les PII en clair. ### Mécanisme proposé - Chaque participant a son SIS player local (IndexedDB), expose une clé pub. - Le relay SAGIP-france maintient : - registry minimal : `client_id → sis-player-id → identité validée (optionnel)` - boîtes de routage : message entrant pour `sis-player-X` → push notification ou récupération au prochain pull - Validation d'identité côté SIS organisationnel = signature d'un certificat lié au sis-player. **Implication archi** : passer d'un modèle stockage centralisé (actuel) à un modèle routage léger. Gros chantier — à phaser après une démo réussie phase 1. --- ## 7 · Découpage proposé phase 2 | Sprint | Contenu | |---|---| | **S1 — Fondation SIS** (1 semaine) | Créer la hiérarchie SIS physique. Importer 28 CTs depuis programme.json. Skeleton `_lib/storage.php` adapté. | | **S2 — Auth codes** (1 semaine) | Adapter `codes.php` + `redeem-code.php` tarba pour SAGIP. Migration des amorces existantes vers IS pairs. | | **S3 — Messagerie** (1 semaine) | Inbox/outbox HMAC par IS pair. UI admin clic-droit. Modération questions live signée. | | **S4 — Validation identité** (3-5 jours) | 3 modes (présentiel, message, code pré-minté). Workflow waiting-room. | | **S5 — Édition programme** (1 semaine) | UI admin édition programme par rôle. Broadcast changements. WebPush MAJ horaires/salles. | | **S6 — Annuaire long terme** (5 jours) | `sagip-membres-permanent` + migration opt-in fin SAGIP'26. | | **S7 — Relay** (~2 semaines, optionnel) | Bascule modèle vers routage léger. | --- ## 8 · Compléments issus du retour 2026-06-06 (post-livraison v0.3) ### 8.1 Questions — chat + transfert présentateur - Modifier / supprimer une question **côté serveur** déjà OK (append-only via PATCH/DELETE, traçabilité conservée). - **Reste à faire** : conversation type chat sur une question (réponses chair + auteur + autres participants). Modèle : threads append-only par `q-id`. - **Transfert d'une question à un présentateur** : le chair peut "router" une question vers le SIS du présentateur (qui voit son inbox). Dépend du SIS hiérarchique + identité présentateurs. ### 8.2 Notes — partage entre utilisateurs - **Export/import JSON** déjà OK (bundle complet : profil + notes + questions + favoris). - **Reste à faire** : partager une note avec un autre SIS (1-to-1 ou groupe CT) → endpoint `notes/share.php`, droits lecture/écriture selon contrat. Pourrait reprendre le pattern messagerie `participants/host/` + `participants//` de tarba. - **Fusion notes multi-auteurs** : sur une même session, agréger les notes publiques. Modèle SIS-friend nécessaire. ### 8.3 Admin — dédup amorces SIS multiples - En page admin actuellement, un même participant peut apparaître plusieurs fois (1 amorce par device sans matching identity). - **À faire** : dédup côté serveur via clé email/(prenom+nom+institution) avec score de confiance + UI fusion manuelle pour admin. - Lié au workflow `validation d'identité` (§ 2.3). ### 8.4 SIS enrollment — fiches préexistantes vs saisie libre - **Tension** : remplir soi-même (long mais à jour) vs partir des fiches scraping (rapide mais imparfait — 326 personnes + 195 labos extraits, qualité variable, cf. `personnes-citees.json` / `labos-cites.json`). - **Proposition de workflow** : 1. Au scan code participant, présenter la fiche scrapée pré-remplie (si match nom). 2. Participant valide / corrige / complète → devient fiche officielle SAGIP. 3. Si pas de match : saisie libre + flag "nouveau". - Idem labos : fiche labo pré-remplie depuis `labos-cites.json` (auteurs, occurrences) à valider par un correspondant désigné. - **À faire** : UI participant "C'est moi / corriger / je ne suis pas dans la liste". ### 8.5 Cartographie labos — page labo (SIS espace) - Chaque labo de `labos-cites.json` deviendrait un mini-SIS `sis://sagip-labo-` : - liste membres - correspondant SAGIP (un membre désigné) - publications du labo dans le programme - lien vers fiche externe (HAL, site labo) - Lié à la hiérarchie SIS (§ 1). ### 8.6 Gestion live du programme (super-admin) - Décalage d'horaire, changement de salle, ajout résumé / lien papier / info complémentaire (ex : "Gala 19h, code vestiaire ABC"). - Push diff au client via WebPush ou polling sur `programme-overrides/`. - Voir matrice permissions § 4. ### 8.7 Intégration site SAGIP + bouton connexion - Aujourd'hui : PWA isolée à `cedreek.fr/sagip/sagip26/` (staging) + `sagip2026.symb.yt/dev/client/` (cible). - **Cible** : sur `sagip.symb.yt` (site refondu), bouton "Connexion" → ouvre PWA → après login (code 6 chiffres / magic-link), retour des feedbacks loupe routés comme messages IS vers `sis://sagip-group` + `sis://cedrick-beler`. - **À faire** : page profil dédiée (au-delà du SIS local actuel), bandeau live persistant côté site également pendant les jours de conf. ### 8.8 Bascule production sagip.org Une fois validation effectuée : - `sagip.org` (domaine racine) → site principal - `app.sagip.org` ou `programme.sagip.org` → PWA conférence - `.sagip.org` ou `chapitres.sagip.org/` → sous-SIS --- ## 9 · Lien avec autres chantiers - [`tool-orgholo/`](../../../tool-orgholo/) — modélisation holonique : la hiérarchie SAGIP est un cas d'usage du moteur. À garder synchro. - [`sis/`](../../../sis/) — concepts SIS transverses. - [`recherche-these-symbiosis/`](../../../recherche-these-symbiosis/) — terrain de thèse, SAGIP-france alimente le corpus. - [tarba-en-canta-2026/server/api/](../../../../_symbiotic-livrables/202605-tarbes-animations/3-code/instances/tarba-en-canta-2026/server/api/) — pattern source à généraliser.