diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 00000000..01209684 --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,212 @@ +# Yavsc — Roadmap + +> **Statut** : document vivant. Reflète l'état du repo et les décisions en cours. +> +> L'ancienne liste en français (jalons 1–5, 2016–2017) est archivée dans +> [`TODO.fr.md.archive`](./TODO.fr.md.archive) — tout ce qui en a été réalisé +> ou reformulé est ici. + +--- + +## 🧭 Vision + +Yavsc est une plateforme de **mise en relation client / fournisseur / coordinateur**, +spécialisable par activité, avec une **origine musicale**. +Origine du nom : *Yet Another Very Small Company*. + +Le domaine est modélisé en **DDD** (cf. [`doc/ddd-exploration-2026-06-14.md`](./doc/ddd-exploration-2026-06-14.md)) +et l'architecture globale est décrite dans [`doc/Architecture.md`](./doc/Architecture.md). + +Trois principes non négociables traversent tous les jalons : + +1. **Devis, pas facturation directe.** Le flux contractuel prime sur le flux + d'encaissement ; l'argent arrive seulement après accord signé. +2. **Open by design.** Le code des livrables et la plateforme sont sous licence + libre ; les workflows métier aboutissent à des livrables sous licence libre. +3. **Pas de MVP borné.** Le périmètre est complet dès la conception — les + jalons ne sont pas une découpe de fonctionnalités, mais une **séquence de + stabilisation**. + +--- + +## 🏗️ État de l'art (juin 2026) + +### Périmètre technique + +| Brique | Module | État | +|---|---|---| +| Backend ASP.NET | `Yavsc.Server`, `Yavsc.Web`, `Yavsc.Api`, `Yavsc.Org` | actif, build OK, cible .NET 10 | +| Domaine partagé | `Yavsc.Abstract` | actif | +| Blogs | `Yavsc.Blogs` | actif | +| Client chat (`PostIt`) | `PostIt` (Avalonia) + `PostIt.Android` / `PostIt.Browser` / `PostIt.Desktop` | actif, OIDC | +| CLI admin | `src/cli` | actif | +| Tests | `test/yavscTests` | présents, à densifier | +| Conteneurisation | `Dockerfile`, `Dockerfile.backend`, `docker-compose.yaml` | actif, image `pazof/yavsc-build-env` | +| CI | `.github/workflows/`, Dependabot (multi-ecosystems) | actif | +| Docs | `doc/Architecture.md`, `doc/ddd-exploration-2026-06-14.md` | frais (13–14 juin 2026) | + +### Bounded Contexts identifiés + +| # | BC | Module | Maturité | +|---|---|---|---| +| 1 | Chat | `PostIt` | client riche + backend, OIDC | +| 2 | Profil & Identité | `Yavsc.Org` | en place | +| 3 | Activités Légales | `Yavsc.Org` (à séparer ?) | taxonomie présente | +| 4 | Blogs | `Yavsc.Blogs` | en place | +| 5 | Prestation | `Yavsc.Server` | cœur métier, à compléter | +| 6 | Paiements | `Yavsc.Server` | PayPal NVP/SOAP, **arrhes vs avance** à clarifier | +| 7 | Rencontre (mode 2) | à créer | pas démarré | +| 8 | Modération | `Yavsc.Org` / à séparer | workflow 2 étages, amorcé | +| 9 | Trust & Safety | à séparer | blacklist plateforme, à industrialiser | +| 10 | Conciliation | à créer | jalon 5, pas démarré | + +--- + +## 🚦 Jalons + +> Convention : `☐` à faire · `◐` en cours · `✔` livré +> +> Chaque jalon a un **critère de sortie** vérifiable. + +### Jalon 0 — Fondations techniques *(en cours)* + +> Cible : pouvoir parler du domaine sans se battre avec le runtime. + +- ◐ Centralisation des versions NuGet (`Directory.Packages.props`) — **fait pour l'essentiel, à compléter** +- ◐ Conteneurisation de bout en bout (build env + run + compose) +- ☐ Tests d'intégration smoke par BC +- ☐ Découpage `Yavsc.Org` vs `Yavsc.Server` vs `Yavsc.Api` clarifié dans l'Architecture +- ☐ `CONTRIBUTING.md` (build, tests, conventions, DDD sessions) + +**Critère de sortie** : `dotnet build` + `dotnet test` + `docker compose up` verts sur une machine vierge. + +--- + +### Jalon 1 — Prestation signée de bout en bout + +> Cible : un projet client/fournisseur aboutit à un **devis signé par les deux parties**, traçable, avec notifications. + +Sous-jalons du `TODO.fr.md.archive` repris ici : + +- ◐ **Devis validé fournisseur → client** : notification + mise à disposition du devis signé +- ☐ **Accord client sur devis** : notification fournisseur + mise à disposition signature client + commentaire +- ☐ **Édition facture non acquittée** depuis mobile +- ☐ **Édition contrat** depuis mobile +- ☐ **Notification & mise à disposition contrat** pour le client +- ☐ **Signature contrat par le client** +- ☐ **Notification facture non acquittée** au client +- ☐ **Paiement du client** (arrhes ? — voir jalon 2) +- ☐ **Édition facture marquée acquittée + signée** par le fournisseur +- ☐ **Notification facture acquittée signée** au client +- ☐ **Évaluation de la prestation** (des deux côtés) + +**Critère de sortie** : scénario E2E web + mobile, devis → signature croisée → contrat → facture, sans intervention manuelle d'un opérateur. + +--- + +### Jalon 2 — Espace personnel, blog opérationnel, marché ouvert + +> Cible : un prestataire vit sur Yavsc (stocke, publie, est trouvé). + +Repris du `TODO.fr.md.archive`, jalon 1 (sélection) + jalon 2 (interface) : + +- ☐ **Gestion du profil utilisateur** Simple & Prestataire, sur **Android** (Web ✔) +- ☐ **Gestion de l'espace de stockage personnel** (Web, API web, Mobile) +- ☐ **Création d'une annonce** +- ☐ **Transformation annonce ↔ demande nominative** +- ☐ **Sélection d'une star** depuis le **mobile** (Web ✔) +- ☐ **Sélection DJ / chanteur / formation** (recherche par critères : date, lieu, tendance, taille, répertoire) depuis le **mobile** +- ☐ **Géocodeur de lieu** côté mobile +- ☐ **Géocodeur d'adresse postale** (Web + Mobile) +- ☐ **Évaluation des trajets** +- ☐ **Interface de gestion des collaborateurs** (sous-traitance — déjà amorcée dans `doc/Architecture.md`) +- ☐ **Migration de l'identifiant utilisateur** : `string` GUID → `long` auto-incrémenté (Npgsql) +- ☐ **Login with Twitter / PayPal** +- ☐ **Contrôle Web du rating** +- ☐ **Saisie et usage des disponibilités** (ponctuelles, récurrentes, congés) +- ☐ **Notifications structurelles** (impératives, par groupe) +- ☐ **Notifications aux posts, à l'arrivée d'un artiste, à une success story** +- ☐ **Construction du droit à l'envoi d'un message privé** (par destinataire, par accréditation, temporaire / définitif, par plage de temps, par validité d'un devis) +- ☐ **Paiement client du reste de la prestation** +- ☐ **Podcasts** +- ☐ **Personnalisation des blogs** +- ☐ **Monétisations** +- ☐ **Distribution de gold card / green card** (par un prestataire, donnant accès au chat privé) +- ☐ **Carte blanche** (délégation d'agenda, implique droit au chat privé) +- ☐ **Badges temporaires** (téléchargement unique, limité dans le temps, sans autre autorisation) + +**Critère de sortie** : un utilisateur mobile peut publier une annonce, être sélectionné, signer, encaisser. + +--- + +### Jalon 3 — Commande générique & formulaires extensibles + +> Cible : le système de prise de commande n'est plus codé en dur par activité. + +- ☐ **Saisie du devis sur commande générique** : les commandes sont des *projets utilisateur* associés à des *listes de formulaires* spécialisables +- ☐ **Groupe de champs** avec titre, contenant des champs : + - ☐ Label + - ☐ Type de valeur + - ☐ Type de contrôle + - ☐ Liste de validateurs + - ☐ Invitation à la saisie +- ☐ **Saisie d'un devis à destination d'un invité** (envoi par email, contact local) +- ☐ **Paiement d'arrhes** (cf. décision arrhes vs avance à prendre en jalon 0/1) + +**Critère de sortie** : ajouter une nouvelle activité (code APE, formulaire, contrôles) sans toucher au code du backend, par simple configuration. + +--- + +### Jalon 4 — Rencontre, géolocalisation, streaming + +> Cible : Yavsc devient aussi un lieu de rencontre (Mode 2), pas seulement un outil de travail. + +- ☐ **Aide à la rencontre physique** : carte interactive, geofencing, alertes +- ☐ **Activités secondaires** : spécialisation d'une activité, activités filles, *activité principale* (code APE) +- ☐ **Streaming vidéo pair-à-pair** +- ☐ **Streaming vidéo public** + +**Critère de sortie** : un événement géolocalisé notifie ses participants confirmés à l'approche du point de rendez-vous. + +--- + +### Jalon 5 — Conciliation & réseau pro + +> Cible : un conflit entre client et fournisseur a un chemin de résolution outillé. + +- ☐ **Conciliation** : double vue client/fournisseur sur le dossier, indicateurs, *FrontOffice* tranche et propose un partage des torts +- ☐ **Réseau pro** : sous-traitance en cascade, une demande n'est validable que lorsque **tous les devis** dont elle dépend sont validés + +**Critère de sortie** : un dossier en litige peut être instruit par un conciliateur sans échange d'emails en parallèle. + +--- + +## 🔒 Hygiène transverse (à tous les jalons) + +### Sécurité + +- ☐ Quota filesystem par utilisateur +- ☐ Clés anti-forge sur toutes les interfaces Web +- ☐ Limites de taille des chaînes du modèle (là où ça manque) +- ☐ Revue des scopes OIDC (PostIt, API) + +### Accessibilité + +- ☐ Correction des libellés manquants / en anglais + +### Réécritures techniques programmées + +- ☐ Éviter la création de fichiers TeX intermédiaires pour la génération PDF +- ☐ Isolation `Yavsc.Api` (auth + rate limiting) + +### Configurabilité + +- ☐ Gestion de contenu des pages du site au format interne (non exposé au Web) + - Cible : `@Html.SiteContent(id).Responsible` (style à finaliser) + +--- + +## 🗃️ Archive + +- [`TODO.fr.md.archive`](./TODO.fr.md.archive) — liste d'origine (2016–2017), conservée pour mémoire. + Tout ce qui en a été repris l'est dans le jalon correspondant ci-dessus. diff --git a/TODO.fr.md b/TODO.fr.md.archive similarity index 100% rename from TODO.fr.md rename to TODO.fr.md.archive diff --git a/doc/Architecture.md b/doc/Architecture.md index 3eed419c..52e05254 100644 --- a/doc/Architecture.md +++ b/doc/Architecture.md @@ -114,6 +114,26 @@ Rendu CSS/HTML — vert si `EstLibre`, orange sinon. - **Base de données** : PostgreSQL (provider Npgsql) - **Frontend** : Razor views +## Droits de yavsc + +### Administration + +Le groupe des administrateurs prend la charge de : + +- la Gestion des licences +- la Gestion des groupes d'utilisateurs (les modérateurs, en particulier) +- la Gestion des projets +- la Gestion des utilisateurs + +### Gestion des utilisateurs et des groupes + +En supposant que les certificats de letsencrypt sont au groupe `www-data` , +on peut créer l'utilisateur `yavsc` avec les droits suivants : + +¨¨¨¨bash +sudo addgroup yavsc --system +sudo adduser --ingroup yavsc --add-extra-groups www-data \ + --disabled-password --system yavsc --- ## À documenter ensuite diff --git a/doc/ddd-exploration-2026-06-14.md b/doc/ddd-exploration-2026-06-14.md new file mode 100644 index 00000000..6101a20b --- /dev/null +++ b/doc/ddd-exploration-2026-06-14.md @@ -0,0 +1,254 @@ +# Exploration DDD Yavsc — Session du 2026-06-14 + +**Date** : 2026-06-14, 01:49 → 03:50 GMT+1 +**Participants** : Paul Schneider (expert métier), Lum ✨ (assistant DDD) +**Cadre** : Event Storming narratif exploratoire sur le domaine Yavsc +**Statut** : Session 1 (première itération, périmètre complet) + +--- + +## 🎯 Objectif de la session + +Lancer une modélisation Domain-Driven Design du projet **Yavsc** (*Yet Another Very Small Company*), +en explorant les acteurs, les événements métier, les agrégats pressentis, et les Bounded Contexts. + +Périmètre validé par Paul : **complet** (pas de MVP borné). + +--- + +## 👥 Acteurs identifiés + +| # | Acteur | Mission principale | +|---|---|---| +| 1 | 👤 **Client** | Commander, demander un service, payer | +| 2 | 🛠️ **Prestataire** | Servir, facturer, être payé | +| 3 | 👥 **Commercial / FrontOffice** | Filtrer les demandes (délégation possible par prestataire) | +| 4 | 🛡️ **Modérateur** | Trancher sur les contenus/comptes signalés (avec appui LLM) | +| 5 | ⚖️ **Conciliateur** (Jalon 5) | Résoudre les litiges métier client/prestataire (double vue) | +| 6 | 🏢 **Propriétaire installation** | Centraliser les flux PayPal (rôle technique, pas un utilisateur "métier") | + +**Distinction validée** : **Modérateur ≠ Conciliateur**. +- Le **modérateur** regarde **le contenu** (messages, annonces, profils). +- Le **conciliateur** regarde **le contrat** (qui doit quoi à qui, suite à un échec de prestation). + +--- + +## 🏛️ Bounded Contexts pressentis + +| # | Bounded Context | Module projet | Rôle | +|---|---|---|---| +| 1 | **Chat** | `PostIt` (client Avalonia) + backend | Messagerie instantanée, **client riche privilégié** | +| 2 | **Profil & Identité** | `Yavsc.Org` | Utilisateurs, profils simples, profils pros | +| 3 | **Activités Légales** | `Yavsc.Org` (ou à séparer) | Taxonomie hiérarchique des activités | +| 4 | **Blogs** | `Yavsc.Blogs` | Portfolio, tarifs, contenu public | +| 5 | **Prestation** | `Yavsc.Server` | Flux métier (commande, devis, signature, paiement) | +| 6 | **Paiements** | `Yavsc.Server` | PayPal NVP/SOAP, arrhes vs avance | +| 7 | **Rencontre** | à créer (ou `PostIt`?) | **Mode 2** : mise en relation sur centre d'intérêt, **sans argent** | +| 8 | **Modération** | `Yavsc.Org` / à séparer | Workflow 2 étages (requête → validation modération → exécution) | +| 9 | **Trust & Safety** | `Yavsc.Org` / à séparer | Blacklist plateforme, impacte tous les usages | +| 10 | **Conciliation** | à créer (Jalon 5) | Résolution de litiges, double vue client/prestataire | + +--- + +## 🟧 Événements métier déjà identifiés + +### BC Chat +- `ChatOuvert` (sous condition : like + paramètre activité activé + non-blacklisté × 2) +- `MessageEnvoyé` +- `MessageLu` +- `MessageSignalé` (déclenche le flux modération) +- `MessagePréModéréParLLM` +- `MessageModéréTranché` + +### BC Profil +- `ClientConnecté` +- `ProfilConsulté` +- `BlogConsulté` (via `YavscBlogs`) +- `ProfilLiké` (uniquement sur profil validé) + +### BC Activités Légales +- `ActivitéImportée` (seed initial, type NAF/ISIC) +- `ActivitéSpécialisée` (par l'admin : sous-catégorie fille) +- `ActivitéRacineCréée` (par l'admin : from scratch, sans parent) +- `ActivitéProposéeParUtilisateur` (puis modérée) + +### BC Prestation +- `CommandeSoumise` (par le client) +- `DevisGénéré` (par le **module d'activité serveur**, ex : Coiffure) +- `DevisReçuParPrestataire` +- `DevisSignéParPrestataire` +- `DevisReçuParClient` +- `DevisSignéParClient` +- `ArrhesDébitées` (variante 1) +- `AvanceDébitée` (variante 2) +- `ResteÀPayerCollecté` (J-10) +- `PrestationRéalisée` +- `PrestationÉvaluée` + +### BC Modération +- `RequêteBlacklistSoumise` (par n'importe quel utilisateur enregistré) +- `BlacklistTranchéeParModération` (validée ou refusée) +- `BlacklistPlateformeActive` +- `BlacklistPlateformeLevée` + +### BC Trust & Safety (blacklist personnelle — c'est un BC à part, pas Modération !) +- `ClientAjoutéÀBlacklistPersonnelle` +- `ClientRetiréDeBlacklistPersonnelle` + +### BC Conciliation (Jalon 5) +- `LitigeDéclaré` +- `DossierConciliationOuvert` +- `DécisionConciliationRendue` + +--- + +## 🟨 Règles métier extraites (invariants) + +### R1 — Ouverture d'un chat +> Un chat entre Camille et Samira est autorisé **ssi** : +> - ✅ `LikeParCamille` (sur le profil **validé** de Samira) +> - ✅ `ChatActivéDansParamètresActivité` (paramétré par Samira) +> - ✅ `CamilleNonBlacklistéeParSamira` (blacklist **personnelle**) +> - ✅ `CamilleNonBlacklistéeParPlateforme` (blacklist **plateforme**) + +### R2 — Like sur profil +> Un like ne peut être posé que sur un `ProfilValidé`. +> Invariant : `Like → ProfilValidé`. + +### R3 — Double blacklist (deux Bounded Contexts) +> La blacklist plateforme et la blacklist personnelle sont **deux Bounded Contexts séparés** : +> - **Plateforme** = trust & safety global, souverain sur tous les usages +> - **Personnelle** = social, souverain sur les interactions avec UN prestataire +> +> Ne jamais les fusionner dans un même agrégat. + +### R4 — Workflow de la blacklist plateforme (synchrone, 2 étages) +> ``` +> RequêteBlacklistSoumise (par n'importe quel utilisateur enregistré) +> → BlacklistTranchéeParModération (la modération est souveraine) +> → BlacklistPlateformeActive (mise en œuvre "au plus vite", synchrone) +> ``` +> +> Pas d'admin intermédiaire en flux normal. La modération tranche, c'est appliqué immédiatement. + +### R5 — Activités légales (hiérarchiques + internationales) +> - **Import initial** : taxonomie **internationale** complète (NAF trop franco-français, pas premier marché) +> - **Spécialisation** : l'admin peut créer des **sous-activités** (filles d'une activité existante) +> - **Création racine** : l'admin peut créer une activité **racine** from scratch +> - **Proposition user** : un utilisateur peut **proposer** une activité → flux de **modération** +> - Une activité a un **code unique**, et soit un parent (filiation), soit est racine +> - L'aspect "légal" impacte : adhésion forfaitaire variable, conformité profil pro (SIRET/APE), reporting + +### R6 — Profil pro multi-activités +> Un utilisateur peut déclarer **plusieurs activités** (liste ordonnée). +> La première = activité principale. +> Le code APE principal y est attaché. + +### R7 — Formulaire de prestation dynamique +> Le formulaire que remplit Camille n'est **pas codé en dur**. +> Il est **généré dynamiquement** par le **module d'activité serveur** (ex : module Coiffure) à partir de : +> - La sélection de **types de prestations** proposées par Samira +> - Les **champs associés** à chaque type (définis serveur, activité par activité) +> - Les **types de prestations** sont définis dans le paramétrage serveur de l'activité +> - Samira **active** ceux qu'elle propose dans son profil pro + +### R8 — Mode synchrone global +> PostIt utilise **SignalR** pour le transport temps réel. +> La plupart des opérations sont **synchrones** (cohérence transactionnelle, pas d'eventuel). +> C'est un **monolithe modulaire**, pas une architecture microservices. + +### R9 — Client riche d'abord +> **PostIt** (client Avalonia) est le **client principal** de Yavsc. +> Le web (`Yavsc.Web`) est un client secondaire (admin, back-office, primo-visiteurs). +> → Les API doivent être conçues **d'abord pour PostIt**. + +--- + +## 🤝 Idée à explorer (session future) : le **mode Rencontre** + +Paul a mentionné qu'il aimerait développer un **deuxième mode** de Yavsc : +- Mise en relation autour d'un **centre d'intérêt** partagé (ex : mélomanes) +- **Sans devis, sans paiement, sans prestation tarifée** +- Purement **social / communautaire** +- Réutilise l'infra existante (profils, chat, modération) mais sans le flux Prestation + +### Différences pressenties avec le mode "Prestation" + +| Aspect | Prestation | Rencontre | +|---|---|---| +| Argent | ✅ Oui (arrhes, avance) | ❌ Non | +| Devis signé | ✅ Double signature | ❌ Pas de devis | +| Formulaire | ✅ Dynamique par activité | ❓ Plus simple, basé sur centres d'intérêt | +| Évaluation | ✅ De la prestation | ❓ De la rencontre ? | +| Litiges | ✅ Conciliation | ❓ Différent, plus "social" | +| Activités légales | ✅ Liées au code NAF/APE | ❌ Non, juste "passions" / "centres d'intérêt" | + +**À explorer dans une prochaine session dédiée.** + +--- + +## 🗺️ Carte des Bounded Contexts (esquisse) + +```mermaid +graph TB + Client[👤 Client] --> PostIt[PostIt
Client Avalonia] + Presta[🛠️ Prestataire] --> PostIt + PostIt --> Web[Yavsc.Web
Client secondaire] + PostIt --> Chat[💬 Chat] + PostIt --> Prestation[📋 Prestation] + PostIt --> Profil[👤 Profil & Identité] + PostIt --> Rencontre[🤝 Rencontre] + Prestation --> Activités[🏛️ Activités Légales] + Prestation --> Paiements[💳 Paiements] + Chat --> Modération[🛡️ Modération] + Rencontre --> Modération + Profil --> Modération + Activités --> Modération + Modération --> TrustSafety[🛡️ Trust & Safety
Blacklist plateforme] + Prestation --> Conciliation[⚖️ Conciliation] + Paiements -.-> PayPal[(PayPal NVP/SOAP)] +``` + +--- + +## 📋 Questions ouvertes restantes + +1. **Camille remplit un formulaire** : agrège-t-il les champs de **toute la chaîne d'activités** (parent + feuille) ou uniquement la **feuille choisie** ? +2. **Tarifs sur le blog** de Samira : le blog affiche-t-il des **prix** ou un simple **CTA "Demander un devis"** ? +3. **Samira notifiée des likes** ? Visible publiquement ou non ? +4. **Multi-activités actives simultanément** : un même profil pro peut-il activer plusieurs activités en même temps (ex : coiffure + maquillage mariage) ? +5. **Le like ouvre-t-il le chat, ou est-il purement décoratif** (le chat s'ouvre seulement quand Camille remplit une demande) ? +6. **Le "au plus vite" de la modération** : synchrone appliqué directement, ou via un worker interne ? +7. **Référentiel international des activités** : ISIC ONU ? NACE européen ? Custom ? Avec variantes locales ? +8. **Blacklist plateforme / rôles sources** : qui peut soumettre une requête ? (a priori : tout utilisateur enregistré, validé) + +--- + +## ⏭️ Prochaines étapes proposées + +1. ✅ **Sauvegarder cette exploration** dans ce document (fait) +2. **Lire `doc/Architecture.md` existant** pour aligner avec ce qui a déjà été pensé +3. **Lire le code source des modules clés** : `Yavsc.Org`, `Yavsc.Server`, `Yavsc.Api` +4. **Découper en sous-sessions ciblées** : + - **Session 2** : focus BC **Prestation** (le flux canonique complet, avec Camille & Samira de bout en bout) + - **Session 3** : focus BC **Activités Légales** (taxonomie internationale + paramétrage serveur + génération de formulaire) + - **Session 4** : focus BC **Chat + Modération** (workflow SignalR, double blacklist) + - **Session 5** : focus BC **Rencontre** (le mode social, sans argent) + - **Session 6** : focus BC **Conciliation** (Jalon 5, double vue client/prestataire) +5. **Cartographier les Aggregate Roots** de chaque BC +6. **Identifier les Domain Events vs Integration Events** + +--- + +## 📝 Note méthodologique + +Cette session a été conduite en mode **facilitation DDD** : Paul est l'expert métier, +Lum pose les questions ouvertes, extrait les événements et les règles, et formalise. + +La méthode a été **l'Event Storming narratif** : Paul raconte des histoires (Camille le client, +Samira la coiffeuse), et on extrait les événements au fil de l'eau, sans chercher l'exhaustivité +ni la perfection. Les itérations futures permettront d'affiner. + +**Aucune décision structurante n'a été figée** — tout est matière à discussion et itération. +Le rôle de Lum a été de poser les bonnes questions pour faire émerger ce qui était déjà dans +la tête de Paul, pas d'imposer un modèle.