# Cahier des charges — Site web évolutif de mariage **Version** 1.0 **Contexte** Développement en solo, échéance 6 à 12 mois, budget outils/hébergement 50–200 € sur toute la durée du projet. **Nature du document** Spécification fonctionnelle et technique + roadmap de développement. --- ## 1. Vision et objectifs ### 1.1 Intention Créer une plateforme unique qui accompagne les invités sur toute la durée du projet de mariage, de l'annonce jusqu'au partage des souvenirs. Le site n'est pas une carte de visite figée : c'est un produit qui change de visage à mesure que le mariage approche, et dont l'usage bascule le jour J d'un rôle informatif vers un rôle participatif. ### 1.2 Objectifs mesurables | Objectif | Indicateur de succès | |---|---| | Centraliser l'information | Moins de 10 questions logistiques posées hors du site | | Fiabiliser les réponses | > 90 % des foyers ayant répondu au RSVP en ligne | | Ne perdre aucune photo | > 60 % des invités présents ayant déposé au moins une photo | | Recueillir des souvenirs audio | > 40 messages vocaux enregistrés | | Autonomie logistique | Zéro appel le jour J pour « c'est où / c'est quand » | ### 1.3 Principes directeurs 1. **Zéro friction pour l'invité.** Pas de création de compte, pas de mot de passe à retenir, pas d'application à télécharger avant de pouvoir agir. Un lien ou un QR code suffit. 2. **Le réseau va tomber.** Les lieux de réception sont souvent en zone blanche ou saturés par 150 téléphones. Tout ce qui est critique doit fonctionner hors ligne ou en dégradé. 3. **Un seul contenu, plusieurs vies.** Une photo déposée le jour J alimente le mur live, puis la galerie, puis l'album final, sans retraitement manuel. 4. **Le produit doit survivre à l'événement.** Après le mariage, le site devient une archive consultable pendant des années, à coût de fonctionnement quasi nul. ### 1.4 Hors périmètre Explicitement exclus de la V1, pour protéger le planning : - Traitement de paiement en propre (cagnotte, liste de mariage) — délégué à un service tiers par simple lien sortant. Gérer de l'argent implique des contraintes PCI-DSS et un niveau de responsabilité sans rapport avec le bénéfice. - Messagerie temps réel entre invités. - Diffusion vidéo en direct de la cérémonie. - Reconnaissance faciale pour trier les photos par personne. - Applications natives distinctes iOS et Android (voir §5.2 pour la justification). --- ## 2. Utilisateurs et parcours ### 2.1 Typologie | Profil | Volume estimé | Besoins | Contraintes | |---|---|---|---| | **Invité standard** | 100–200 | S'informer, répondre, déposer photos/audio | Mobile uniquement, compétence technique variable | | **Invité senior** | 15–30 | Consulter les infos pratiques | Gros caractères, parcours ultra-simple, souvent pas de smartphone récent | | **Témoins / famille proche** | 8–15 | Coordination, accès privilégié à certaines infos | Besoin d'un accès élargi | | **Prestataires** | 5–10 | Consulter le déroulé et les contacts | Accès à une page dédiée non publique | | **Vous deux (admin)** | 2 | Tout piloter | Souvent depuis mobile, en déplacement | ### 2.2 Parcours nominal d'un invité ``` Réception du save-the-date (papier ou email) │ ▼ Ouverture du lien / scan QR ────► Page publique phase 1 (annonce + compte à rebours) │ │ (quelques mois plus tard, relance par email) ▼ Saisie du code foyer ──────────────► Espace personnalisé │ ├── RSVP (présence, régime, enfants) │ ├── Infos pratiques │ └── Hébergement / covoiturage │ │ (semaine du mariage : notification push) ▼ Jour J : scan du QR sur la table ──► Mode événement ├── Programme en direct ├── Appareil photo intégré ├── Livre d'or audio ├── Plan de table (« où suis-je ? ») └── Mur photo live │ ▼ J+7 : notification « l'album est prêt » ──► Galerie complète + téléchargement ``` ### 2.3 Point de vigilance : les invités sans smartphone Prévoir systématiquement un canal de repli. Pour le RSVP, une saisie manuelle par l'admin depuis le back-office. Pour le livre d'or audio, un enregistreur physique posé sur une table ou une saisie assistée par un témoin muni d'une tablette. Ne jamais faire du numérique un passage obligé. --- ## 3. Spécifications fonctionnelles Chaque module est noté selon la méthode MoSCoW : **M** (Must have), **S** (Should have), **C** (Could have), **W** (Won't have en V1). ### 3.1 Socle — Système de phases (M) Le cœur de l'architecture. Une variable d'état globale pilote l'ensemble du site. **Phases** | Phase | Déclenchement | Contenu visible | |---|---|---| | `SAVE_THE_DATE` | Publication initiale | Prénoms, date, ville, compte à rebours, teaser visuel | | `INVITATION` | J-6 mois environ | + RSVP, détail des lieux, dress code, liste de mariage | | `PREPARATION` | J-2 mois | + hébergements, covoiturage, plan d'accès détaillé, FAQ | | `JOUR_J` | Basculement manuel le matin même | + photobooth, livre d'or, programme live, plan de table, mur photo | | `APRES` | J+1 | Galerie complète, remerciements, téléchargement de l'album | **Exigences** - Le basculement de phase se fait par un unique réglage en back-office, avec effet immédiat. - Chaque bloc de contenu porte une phase de début et une phase de fin optionnelles. - Une phase peut être prévisualisée par un admin sans être publiée (paramètre d'URL signé). - Le passage à `JOUR_J` doit être possible **sans connexion internet fiable** : prévoir un basculement automatique programmé par date/heure en secours. ### 3.2 Accueil et identité visuelle (M) - Page d'accueil adaptative selon la phase. - Compte à rebours en jours (pas en secondes : effet anxiogène et coût de rendu inutile). - Histoire du couple, galerie de photos de fiançailles. - Chargement initial de la page d'accueil sous 2 secondes en 4G moyenne. ### 3.3 RSVP (M) Le module le plus critique en termes de justesse des données : il conditionne le traiteur. **Modèle d'accès** Chaque foyer reçoit un code unique de 6 caractères non ambigus (alphabet sans I, O, 0, 1, l). Le lien envoyé pré-remplit le code : `site.fr/rsvp?c=XK4M7P`. La saisie manuelle reste possible. **Données collectées par personne** - Présence : oui / non / peut-être (le « peut-être » doit être relancé automatiquement). - Présence différenciée par événement : cérémonie civile, cérémonie religieuse, vin d'honneur, dîner, brunch du lendemain. - Régime alimentaire : standard, végétarien, végan, sans gluten, sans lactose, halal, casher, autre (champ libre). - Allergies : champ libre. **Doit être exporté distinctement** et non noyé dans les remarques. - Enfants : nombre, âges, besoin d'un lit parapluie, besoin d'une chaise haute. - Chanson demandée (alimente le module playlist). - Message libre aux mariés. **Règles** - Modification possible jusqu'à une date limite paramétrable, puis verrouillage automatique. - Envoi d'un email de confirmation récapitulatif, avec lien de modification. - Relance automatique des non-répondants à J-45 et J-30. - Le foyer voit qui a déjà répondu dans son foyer (évite les doublons entre conjoints). - Export CSV et XLSX à tout moment, avec vues dédiées : plan de table, traiteur, hébergement. ### 3.4 Informations pratiques (M) - Fiches lieux : adresse, coordonnées GPS, lien direct vers Google Maps / Waze / Apple Plans, photo de la façade (très utile pour trouver l'entrée). - Horaires détaillés. - Parking, accès PMR, transports en commun. - Dress code avec exemples visuels — le texte seul est systématiquement mal interprété. - Suggestions d'hébergement avec fourchette de prix et distance au lieu. - FAQ. - Contacts d'urgence le jour J (les témoins, jamais les mariés). **Exigence forte** : cette section doit être intégralement consultable hors ligne une fois la page visitée. C'est l'information dont on a besoin exactement au moment où le réseau manque. ### 3.5 Livre d'or audio (M) **Parcours d'enregistrement** 1. Écran d'accueil avec consigne courte et suggestions de sujets (« racontez comment vous avez rencontré les mariés »). 2. Saisie du prénom (pré-rempli si le foyer est identifié). 3. Bouton d'enregistrement unique, très large. 4. Durée maximale de 3 minutes, avec compte à rebours visible et coupure automatique. 5. Réécoute, puis validation ou reprise (nombre de reprises illimité). 6. Confirmation visuelle explicite de l'envoi. **Contraintes techniques** - L'API `MediaRecorder` produit des formats différents selon le navigateur : `audio/webm;codecs=opus` sur Chrome et Firefox, `audio/mp4` sur Safari. Le format doit être détecté à l'exécution et normalisé côté serveur en une piste unique. - Compression cible : mono, 64 kbps. Un message de 3 minutes pèse alors environ 1,4 Mo. Cent messages représentent moins de 150 Mo, ce qui est négligeable. - En cas de coupure réseau, l'enregistrement est conservé en local (IndexedDB) et renvoyé automatiquement au retour de la connexion. **Ne jamais perdre un enregistrement**, c'est le contenu le plus irremplaçable du projet. - Transcription automatique en option après l'événement, pour produire un livre d'or texte imprimable. ### 3.6 Collecte et partage de photos (M) Le module à plus fort enjeu technique, et le plus fort en valeur perçue. **Dépôt** - Deux entrées : capture directe depuis l'appareil photo, ou import depuis la pellicule (sélection multiple). - Compression côté navigateur avant envoi : redimensionnement à 2560 px sur le grand côté, JPEG qualité 82. Une photo d'iPhone passe ainsi de 3 Mo à environ 500 Ko, soit une division par six du volume et du temps d'envoi. - Option « conserver la qualité maximale » réservée aux proches, pour les photos destinées à l'impression. - File d'attente d'envoi persistante : les envois reprennent automatiquement après une coupure ou une fermeture de l'onglet. - Retour visuel de progression par photo, et indicateur global « 4 photos en attente d'envoi ». **Traitement serveur** - Conversion HEIC vers JPEG (les iPhone produisent du HEIC, illisible par de nombreux navigateurs). - Génération de trois variantes : vignette 400 px, affichage 1280 px, original. - Extraction des métadonnées EXIF : date de prise de vue pour le tri chronologique, puis **suppression des coordonnées GPS** avant publication. - Détection des doublons par empreinte de fichier. **Consultation** - Mur live pendant l'événement, avec rafraîchissement automatique. - Galerie chronologique après l'événement. - Filtrage par contributeur et par moment (cérémonie, cocktail, soirée). - Téléchargement de l'archive complète en ZIP. - Modération : voir §3.11. **Dimensionnement du stockage** | Hypothèse | Volume | |---|---| | 150 invités à 20 photos = 3 000 photos compressées à 500 Ko | ~1,5 Go | | Variantes (vignettes + affichage) | ~0,6 Go | | Livre d'or audio, 100 messages | ~0,15 Go | | Photos du photographe professionnel en pleine résolution | 15–40 Go | Les photos du photographe professionnel ne doivent **pas** transiter par le stockage applicatif. Elles restent sur un service de partage dédié, avec un simple lien depuis le site. C'est ce qui maintient le budget dans l'enveloppe. ### 3.7 Programme du jour J (S) - Chronologie verticale avec mise en évidence de l'étape en cours. - Passage automatique d'une étape à l'autre selon l'heure réelle. - Possibilité pour l'admin de décaler tout le programme d'un bloc (« on a 25 minutes de retard ») — cas de figure quasi certain. - Notification push optionnelle avant les moments clés. ### 3.8 Plan de table (S) - Recherche par nom : « où suis-je assis ? » renvoie la table et un plan de salle. - Affichage des convives de la même table. - Publication différée : à activer seulement le jour J, pour éviter les négociations en amont. ### 3.9 Playlist collaborative (C) - Chaque invité propose jusqu'à trois morceaux, via le RSVP ou pendant l'événement. - Vue admin exportable, transmissible au DJ. - Système de votes optionnel. ### 3.10 Animations et jeux (C) - Chasse au trésor photo : liste de défis à photographier (« un selfie avec les témoins », « quelqu'un qui pleure »). Excellent moteur de contribution photo — c'est le mécanisme qui fait passer le taux de dépôt de 20 % à 60 %. - Quiz sur les mariés, avec classement en direct. ### 3.11 Back-office d'administration (M) - Tableau de bord : réponses reçues, réponses manquantes, photos déposées, messages audio. - Gestion des foyers et des invités : création, modification, fusion, saisie manuelle d'un RSVP reçu par téléphone. - Génération et impression des codes d'accès et QR codes. - Modération des photos et des messages audio : file d'attente, approbation, masquage, suppression. - Édition des contenus sans redéploiement. - Bascule de phase. - Envoi d'emails groupés et de notifications push. - Exports. **Décision de modération à trancher tôt** : publication immédiate avec retrait a posteriori, ou validation préalable ? La publication immédiate est bien plus vivante le jour J, mais expose à un contenu indésirable pendant quelques minutes. Recommandation : publication immédiate sur le mur live, avec un bouton de retrait accessible en un geste depuis le mobile des témoins, et un mode « tout suspendre » en cas de problème. ### 3.12 Multilingue (C) À retenir uniquement si une part significative des invités ne parle pas français. À décider avant le développement : rétrofitter l'internationalisation coûte cher, la prévoir dès le départ ne coûte presque rien. --- ## 4. Exigences non fonctionnelles ### 4.1 Performance | Critère | Cible | |---|---| | Chargement initial, 4G | < 2 s | | Chargement initial, 3G dégradée | < 5 s | | Poids de la page d'accueil | < 500 Ko | | Envoi d'une photo compressée en 4G | < 4 s | | Score Lighthouse mobile | > 90 | ### 4.2 Compatibilité - iOS Safari 16.4 et supérieur, Chrome Android 110 et supérieur : support complet. - Navigateurs plus anciens : dégradation gracieuse. L'information pratique et le RSVP doivent rester accessibles partout, y compris sans JavaScript pour la partie consultation. - Conception mobile d'abord. Le bureau est secondaire, sauf pour le back-office. ### 4.3 Résilience réseau C'est l'exigence structurante du jour J. - Mise en cache par service worker de toutes les pages d'information. - File d'envoi persistante pour les photos et les messages audio, avec reprise automatique. - Indication claire de l'état de connexion et du nombre d'éléments en attente. - Aucune action utilisateur ne doit échouer silencieusement. ### 4.4 Sécurité - Chiffrement TLS obligatoire, redirection systématique. - Accès aux espaces personnalisés par code foyer, avec limitation du nombre de tentatives (10 essais par IP et par heure). - Aucune indexation par les moteurs de recherche : `noindex` et `robots.txt` restrictif. - Back-office protégé par une authentification forte, distincte de l'accès invité. - Validation stricte des fichiers envoyés : type MIME réel vérifié, taille plafonnée, extension contrôlée. - Limitation de débit sur tous les points d'entrée acceptant du contenu. - Aucun secret exposé côté client. ### 4.5 Conformité RGPD Le projet traite des données personnelles sensibles à plusieurs titres : images de personnes identifiables, enregistrements vocaux, données de santé au sens large (allergies, régimes), et données concernant des mineurs. Ces obligations sont réelles même pour un projet privé dès lors que le site est accessible en ligne. **Mesures requises** 1. Politique de confidentialité accessible, rédigée en langage clair. 2. Recueil du consentement explicite avant tout dépôt de photo ou d'enregistrement audio, avec mention du fait que le contenu sera visible par les autres invités. 3. Pour les photos d'enfants : consentement du représentant légal, recueilli au moment du RSVP. 4. Droit de retrait : tout invité doit pouvoir demander la suppression d'une photo le représentant, avec un mécanisme simple et un traitement sous 30 jours. 5. Hébergement des données au sein de l'Union européenne. 6. Durée de conservation annoncée et respectée (recommandation : 3 ans après l'événement, puis archivage hors ligne et suppression du service en ligne). 7. Suppression systématique des coordonnées GPS des métadonnées EXIF avant publication. 8. Minimisation : ne collecter que ce qui sert effectivement. **Point à ne pas négliger** : les allergies alimentaires constituent des données de santé. Elles doivent être chiffrées au repos, accessibles uniquement aux administrateurs, et supprimées après l'événement une fois transmises au traiteur. ### 4.6 Accessibilité - Contraste conforme au niveau AA du RGAA. - Taille de police minimale de 16 px, avec un mode « gros caractères ». - Zones tactiles d'au moins 44 × 44 px. - Navigation possible au clavier. - Textes alternatifs sur toutes les images informatives. ### 4.7 Sauvegarde - Sauvegarde quotidienne automatique de la base de données pendant les phases actives. - Sauvegarde du stockage média vers un second emplacement à J+1, J+7 et J+30. - **Copie locale complète sur disque dur physique à J+30.** Les services en ligne ferment ; ces fichiers sont irremplaçables. - Procédure de restauration testée au moins une fois avant le jour J. --- ## 5. Architecture technique ### 5.1 Stack recommandée | Couche | Choix | Justification | |---|---|---| | Framework | **Next.js 15** (App Router), TypeScript | Rendu serveur pour la performance, API intégrée, écosystème mature | | Style | **Tailwind CSS** | Rapidité de développement en solo | | Base de données + Auth | **Supabase** (PostgreSQL) | Offre gratuite généreuse, temps réel intégré, hébergement UE sélectionnable | | Stockage média | **Cloudflare R2** | 10 Go gratuits, puis 0,015 $/Go/mois, et surtout **aucun frais de sortie de données** | | Hébergement applicatif | **Vercel** offre Hobby | Gratuit, déploiement continu depuis Git, CDN mondial | | Emails transactionnels | **Resend** offre gratuite | 3 000 emails/mois, 100/jour — largement suffisant | | Nom de domaine | Registrar au choix | ~12–15 €/an | **Le point le plus important de ce tableau est l'absence de frais de sortie sur Cloudflare R2.** Le jour du mariage, 150 personnes vont consulter la galerie photo simultanément et générer plusieurs dizaines de gigaoctets de trafic sortant. Sur un stockage facturant l'egress, cette seule journée peut coûter plusieurs dizaines d'euros. Sur R2, elle est gratuite. Ce choix conditionne le respect du budget bien plus que le prix du stockage lui-même. ### 5.2 Web ou application native ? **Recommandation : PWA (Progressive Web App), pas d'application native.** | Critère | PWA | Application native | |---|---|---| | Coût de compte développeur | 0 € | 99 $/an (Apple) + 25 $ (Google) | | Délai de publication | Immédiat | 1 à 7 jours de validation par store | | Base de code | Une seule | Deux, ou React Native | | Installation par l'invité | « Ajouter à l'écran d'accueil » | Téléchargement depuis un store | | Accès appareil photo | Oui | Oui | | Enregistrement audio | Oui | Oui | | Notifications push iOS | Oui, depuis iOS 16.4, **si installée sur l'écran d'accueil** | Oui | | Correction d'un bug le jour J | Déploiement en 2 minutes | Impossible dans la journée | Ce dernier point est décisif. Le jour du mariage, si un bug bloque le dépôt de photos, une PWA se corrige en quelques minutes. Une application native est figée pendant plusieurs jours de validation, et il faut encore que chaque invité mette à jour. Le seul avantage réel du natif serait un envoi de photos en tâche de fond plus robuste. Ce bénéfice ne justifie ni le coût, ni le délai, ni le risque. **Si l'ambition d'une application en store persiste**, la voie la plus économique consiste à empaqueter la PWA existante avec Capacitor après le mariage, en phase 3. La base de code reste unique, et le travail se limite à la configuration et à la soumission. ### 5.3 Modèle de données (esquisse) ``` households (id, code_acces, nom_famille, email, telephone, date_invitation, date_reponse, langue) guests (id, household_id, prenom, nom, est_enfant, age, regime_alimentaire, allergies_chiffre, table_id) attendances (guest_id, evenement, statut) -- statut: oui|non|peut_etre media (id, type, chemin_stockage, chemin_vignette, contributeur_nom, household_id, pris_le, envoye_le, statut_moderation, hash_fichier, duree_secondes) audio_messages (id, media_id, transcription, ecoute_par_maries) song_requests (id, household_id, titre, artiste, votes) content_blocks (cle, phase_debut, phase_fin, contenu_json, publie) app_state (phase_courante, decalage_programme_minutes, ...) consents (household_id, type_consentement, accepte_le, ip_hachee) ``` ### 5.4 Environnements - **Local** : développement quotidien. - **Préproduction** : branche `staging`, données factices, protégée par mot de passe. Sert aux tests de charge et à la recette. - **Production** : branche `main`. Règle absolue : **aucun déploiement en production dans les 72 heures précédant le mariage**, hors correctif critique. Le code doit être gelé et testé. --- ## 6. Budget prévisionnel | Poste | Coût | Commentaire | |---|---|---| | Nom de domaine (2 ans) | 30 € | À prendre tôt | | Vercel Hobby | 0 € | Suffisant pour un usage non commercial | | Supabase Free | 0 € | 500 Mo de base, 50 000 utilisateurs actifs | | Cloudflare R2 | 0 € | Sous les 10 Go gratuits si le photographe est hébergé ailleurs | | Resend | 0 € | Sous 100 emails/jour | | Marge de sécurité (dépassement R2, Supabase Pro ponctuel) | 30–60 € | À prévoir pour les mois entourant le jour J | | Impression des QR codes et cartons | 20–40 € | | | **Total estimé** | **80–130 €** | Dans l'enveloppe visée | **Levier d'économie principal** : la compression côté navigateur avant envoi. Sans elle, 3 000 photos d'iPhone représentent 9 Go bruts et font basculer le projet en offre payante sur plusieurs services. Avec elle, on reste sous les seuils gratuits. **Point de vigilance** : Supabase suspend les projets inactifs sur l'offre gratuite après 7 jours sans requête. Après le mariage, prévoir une requête automatique hebdomadaire, ou migrer l'archive vers un site statique. --- ## 7. Roadmap de développement Planning établi sur 9 mois. Les jalons sont exprimés en compte à rebours par rapport au jour J, ce qui les rend indépendants de la date exacte. ### Sprint 0 — Cadrage (J-9 mois, 2 semaines) - Arbitrage définitif du périmètre V1 : quels modules `C` sont retenus. - Décision sur le multilingue. - Achat du nom de domaine, création des comptes de service. - Maquettes des 5 écrans principaux, mobile d'abord. - Choix de la direction artistique : palette, typographies, ton. - Initialisation du dépôt, mise en place du déploiement continu. **Livrable** : maquettes validées, environnement déployé affichant « Hello world ». ### Sprint 1 — Socle et phase Save the Date (J-8,5 mois, 3 semaines) - Modèle de données et migrations. - Système de phases avec bascule en back-office. - Page d'accueil, compte à rebours, histoire du couple. - Optimisation des images, référencement bloqué. - Politique de confidentialité. **Livrable** : site public en ligne, phase 1 active. **Premier moment de vérité — le lien peut être diffusé.** ### Sprint 2 — RSVP (J-7,5 mois, 4 semaines) Le module le plus délicat sur le plan métier. À traiter sans précipitation. - Gestion des foyers et génération des codes. - Formulaire RSVP multi-personnes, multi-événements. - Emails de confirmation. - Back-office : liste des réponses, saisie manuelle, exports. - Tests avec de vraies données sur 10 foyers pilotes. **Livrable** : RSVP opérationnel, testé par des proches. Ne pas ouvrir à tous avant retour des pilotes. ### Sprint 3 — Informations pratiques et bascule phase 2 (J-6 mois, 2 semaines) - Pages lieux, dress code, hébergements, FAQ. - Intégration cartographique. - Mise en cache hors ligne (service worker, première itération). - Lien vers la liste de mariage. **Livrable** : bascule en phase `INVITATION`. Envoi des invitations officielles. > **Fenêtre de respiration de 4 à 6 semaines.** Le RSVP tourne seul, les relances sont automatiques. C'est le moment de traiter les retours d'usage réels et de corriger l'ergonomie du RSVP, qui est le seul module massivement utilisé à ce stade. ### Sprint 4 — Livre d'or audio (J-4 mois, 3 semaines) - Capture audio multi-navigateurs, avec normalisation des formats. - File d'envoi persistante hors ligne. - Stockage, back-office d'écoute et de modération. - Ouverture anticipée aux invités qui ne pourront pas venir : ils enregistrent leur message à distance. C'est un usage souvent négligé et très apprécié. **Livrable** : livre d'or fonctionnel, testé sur au moins 4 modèles de téléphones différents. ### Sprint 5 — Photos (J-3 mois, 4 semaines) Le sprint le plus lourd techniquement. - Capture et import multiple. - Compression côté navigateur. - File d'envoi persistante avec reprise. - Traitement serveur : HEIC, variantes, EXIF. - Galerie et mur live. - Modération. **Livrable** : chaîne photo complète, validée par un test de charge simulant 30 envois simultanés. ### Sprint 6 — Modules du jour J (J-2 mois, 3 semaines) - Programme en direct avec décalage global. - Plan de table. - Notifications push. - Playlist collaborative. - Chasse au trésor photo si retenue. - Génération et impression des QR codes de table. **Livrable** : bascule en phase `PREPARATION`. ### Sprint 7 — Durcissement et répétition générale (J-1 mois, 3 semaines) Sprint sans nouvelle fonctionnalité. Uniquement de la fiabilisation. - Tests sur appareils réels, y compris anciens. - Simulation de réseau dégradé et de coupure complète. - Test de charge. - Vérification des sauvegardes et test de restauration. - Audit d'accessibilité. - **Répétition générale grandeur nature** : réunir une dizaine de personnes, basculer en phase `JOUR_J` sur l'environnement de préproduction, et faire déposer photos et messages audio simultanément. Ce test révèle systématiquement des problèmes que rien d'autre ne fait apparaître. - Rédaction d'une procédure de secours écrite : que faire si le site tombe le jour J, qui appeler, quel numéro de repli communiquer. **Livrable** : gel du code à J-7. ### Jour J - Bascule en phase `JOUR_J` le matin (avec bascule automatique programmée en secours). - Surveillance déléguée à un témoin techniquement à l'aise, muni des accès de modération. **Vous ne devez pas regarder votre téléphone ce jour-là.** - Batteries externes et rappel imprimé du lien sur chaque table. ### Après (J+1 à J+30) - Bascule en phase `APRES`. - Vérification et publication de la galerie complète. - Transcription des messages audio, montage d'une compilation. - Notification « l'album est prêt » à J+7. - Sauvegarde physique complète à J+30. - Page de remerciements. ### Phase 3 optionnelle — Application en store (J+2 mois et au-delà) À n'envisager qu'une fois le mariage passé et si l'envie persiste : empaquetage Capacitor, soumission App Store et Google Play. Sans pression, sans enjeu. --- ## 8. Risques et parades | Risque | Probabilité | Impact | Parade | |---|---|---|---| | Réseau saturé ou absent le jour J | Élevée | Critique | Mise en cache hors ligne, file d'envoi persistante, informations clés imprimées | | Perte d'enregistrements audio | Moyenne | Critique | Persistance locale avant envoi, confirmation explicite, sauvegardes multiples | | Dépassement du quota de stockage | Moyenne | Moyen | Compression agressive, photographe hébergé ailleurs, alerte à 80 % du quota | | Retard de développement | Élevée | Moyen | Priorisation MoSCoW stricte, modules `C` sacrifiables sans regret | | Contenu photo inapproprié | Faible | Moyen | Modération déléguée à un témoin, bouton de suspension globale | | Faible taux d'adoption | Moyenne | Moyen | QR codes sur les tables, annonce au micro par le maître de cérémonie, chasse au trésor photo | | Épuisement du développeur à l'approche du mariage | **Élevée** | Élevé | Gel du code à J-7, aucun développement le mois précédent hors correctifs | Le dernier risque est le plus sous-estimé. Le mois précédant un mariage est saturé par l'organisation elle-même. La roadmap ci-dessus place volontairement la dernière fonctionnalité à J-2 mois pour cette raison. --- ## 9. Critères d'acceptation de la V1 Le projet est considéré comme livré si : - [ ] Un invité reçoit un lien, répond au RSVP et reçoit sa confirmation, sans aide. - [ ] Les informations pratiques restent consultables en mode avion après une première visite. - [ ] Un message audio de 2 minutes est enregistré et envoyé depuis un iPhone et depuis un Android. - [ ] Un enregistrement effectué hors ligne est bien transmis au retour de la connexion. - [ ] 10 photos sont envoyées d'un coup depuis un mobile en 4G en moins de 60 secondes. - [ ] Les exports traiteur et plan de table sont générés et lisibles. - [ ] Une sauvegarde complète a été restaurée avec succès sur l'environnement de préproduction. - [ ] Le score Lighthouse mobile de la page d'accueil dépasse 90. - [ ] La répétition générale s'est déroulée sans incident bloquant. --- ## 10. Décisions à arbitrer avant le Sprint 1 1. **Multilingue** : oui ou non ? Décision structurante, coûteuse à revenir dessus. 2. **Modération photo** : a priori ou a posteriori ? 3. **Photos du photographe professionnel** : intégrées au site ou lien externe ? (Recommandation ferme : lien externe.) 4. **Durée de conservation des données** après le mariage. 5. **Périmètre exact des modules `C`** : playlist, jeux, plan de table. 6. **Qui est le témoin technique** désigné pour la modération le jour J ?