ADR 0001 : Initialisation du projet et choix d'architecture de persistance

• Statut : Accepté
• Décideurs : Marco (Commanditaire), Julien (Commanditaire), Antigravity (Architecte Logiciel)
• Date : 6 juillet 2026

Contexte et Problème

L'application existante "Plateforme MJY Holding" est actuellement contenue dans un unique fichier monolithique index.html. Elle utilise React 18 et Babel en mode autonome (standalone) chargés depuis des CDN, compilant le JSX à la volée dans le navigateur. Les données sont stockées localement via localStorage.

Ce modèle présente des limitations majeures :

1. Absence de collaboration : Les données dans localStorage sont propres à chaque navigateur/appareil. Aucune synchronisation n'est possible entre les collaborateurs (ex: Marco, Julien, Léo, My Tam, etc.).
2. Volatilité des données : Si le cache du navigateur est vidé ou si l'utilisateur navigue en mode privé, toutes les tâches et configurations sont perdues.
3. Problème de performance et de maintenance : Le code fait plus de 4 000 lignes dans un seul fichier, ce qui rend la maintenance difficile, favorise les régressions et empêche le travail collaboratif des développeurs sur le code source.
4. Défaillance de l'infrastructure transitoire : La solution de contournement consistant à utiliser Netlify Blobs via des fonctions serverless (storage.js) souffre de race conditions chroniques (écrasement mutuel des données lors des pollings toutes les 4s) et est actuellement hors service suite à des déploiements incomplets.

Nous devez restructurer le projet pour en faire une application collaborative, temps réel, robuste et modulaire.

Facteurs de Décision

• Persistance collaborative robuste : Deux utilisateurs modifiant deux tâches différentes en même temps ne doivent pas s'écraser mutuellement.
• Mise à jour en temps réel : Une tâche créée sur un navigateur A doit apparaître sur le navigateur B en moins de 5 secondes sans rechargement de page.
• Maîtrise technologique existante : La stack doit être familière pour l'équipe (le groupe MJY Holding utilise déjà Supabase pour l'application GestionRH).
• Maintenantabilité et modularité : Séparation propre des composants et des services logicielle pour faciliter le développement futur.
• Sécurité : Gestion de l'authentification par PIN et contrôle d'accès aux données (Row Level Security - RLS).

Options Envisagées

Option A : Remise en route de Netlify Blobs (Key-Value)

Réparation et déploiement complet des Netlify Functions v2 existantes et de index.html pour utiliser Netlify Blobs comme magasin de données clé-valeur.

• Avantage : Rapide à mettre en place (quelques heures).
• Inconvénient : Persistance fragile, basée sur le polling (pas de vrai temps réel), risque élevé de conflits d'écrasement de données (le state complet d'un projet est stocké dans un gros blob JSON), pas de gestion granulaire des droits.

Option B : Migration vers Supabase (Recommandée)

Refonte complète de la couche d'accès aux données pour utiliser une base de données relationnelle PostgreSQL hébergée sur Supabase, avec activation de Supabase Realtime et configuration de la sécurité RLS.

• Avantage : Résout définitivement la persistance et la synchronisation simultanée (real-time sans polling), pas d'écrasement croisé (stockage par ligne et par table : projects, phases, tasks, task_notes, members), stack déjà maîtrisée en interne.
• Inconvénient : Nécessite une migration de données et plus de temps de développement initial (1-2 jours).

Décision Retenue

L'Option B : Migration vers Supabase a été retenue.

Justification

L'Option B est la seule qui répond aux critères d'acceptation stricts du brief (synchro en moins de 5s, pas d'écrasement concurrent, résilience au vidage de cache). La stack Supabase étant déjà exploitée pour l'application GestionRH du groupe, la courbe d'apprentissage est minimale.

En parallèle, le code source sera découpé en composants React standardisés à l'aide d'un outillage moderne (Vite, NPM) pour éliminer le monolithe index.html.

Conséquences

Positives

• Véritable collaboration temps réel grâce au canal Realtime de Supabase (les modifications sont propagées instantanément via Websockets).
• Intégrité des données : Les écritures se font au niveau des lignes de table (ex: modification d'une note de tâche), empêchant l'écrasement de tout le projet par un autre utilisateur.
• Architecture propre et extensible : Le code source est structuré en sous-dossiers (src/components, src/hooks, src/services) facilitant le travail de plusieurs développeurs.
• Sécurité accrue : Possibilité d'activer des politiques RLS (Row Level Security) pour restreindre l'écriture et la lecture selon les rôles.

Négatives

• Nécessite la configuration et la maintenance d'un projet Supabase dédié.
• Nécessite l'écriture d'un script de migration ponctuel pour injecter les données actuelles de localStorage/Blobs vers le nouveau schéma SQL.