Référence Détaillée des Améliorations CRM - Aaperture

Note : Ce document est une référence détaillée organisée par domaine fonctionnel. Pour les priorités de développement, consultez PRIORITES.md qui est la source de vérité pour la planification.

Ce document consolide toutes les améliorations futures identifiées dans la documentation et propose de nouvelles suggestions basées sur l'analyse du système actuel, organisées par domaine fonctionnel.

Gouvernance de la documentation produit

• Les décisions CRM actives restent dans ce document et dans docs/PRIORITES.md.
• Les anciens plans non actifs doivent être retirés de docs/ (contenu fusionné ou abandonné) ; l’historique détaillé reste dans git.
• Toute nouvelle évolution CRM doit mettre à jour:
  • ce document (détail),
  • PRIORITES.md (priorisation),
  • docs/README.md (index).

📝 Changelog docs

• 2026-07-24: Vague A cleanup — progression/gamification + Cmd+K recommendations deleted; SMS UI hidden (provider future); Friends KEEP + port aaperture-mobile via /mobile/network; Gmail FREEZE; billing = export CSV (not Pennylane); Insights CREATE_TASK navigates deepLink. See APP_CLEANUP_MAP.md.
• 2026-04-20: requalification de la stratégie facturation/conformité: Aaperture reste la source de vérité métier, mais la conformité fiscale et la facturation externe passent dans un lot Billing externalisé / Pennylane au lieu d’un chantier principal de certification interne complète. Ajout du lot Storage abstraction / Scaleway, révision de la roadmap par horizon et réalignement des priorités actives.
• 2026-04-07: le plan docs/GMAIL_PLUGIN_IMPLEMENTATION_PLAN.md est recadré pour verrouiller le vrai lot Plugin Gmail: un Google Workspace Add-on utilisé dans Gmail, avec Aaperture comme moteur CRM/Iris. Décision explicite: pas d’inbox Gmail embarquée dans l’app web.
• 2026-04-06: le lot Proposal / expérience client avance visiblement côté frontend: builder Proposal (Share & Send) et étapes publiques confirm/final repris avec des surfaces plus sobres, une meilleure lisibilité des statuts/liens et une fin de flow client plus claire.
• 2026-04-06: le lot Assistant CRM / chat workspace passe de refonte de shell à stabilisation produit: contexte unifié, mémoire conversationnelle courte, rendu messages/formulaires/résultats largement harmonisé, et ajout du lot messages / inbox workspace dans les surfaces CRM livrées.
• 2026-03-31: ajout du lot Assistant CRM / chat workspace dans la planification active. Décision produit: arrêter de traiter le chat agent comme un simple panneau technique et le faire converger vers un vrai workspace conversationnel partagé (sidebar, window, mobile, fullscreen) avec pièces jointes, actions et résultats au même niveau de finition.
• 2026-03-14: clôture formelle du lot modales create/edit dans la planification active: la migration modal-first couvre maintenant les écrans documents, CRM contextualisé et data/settings les plus fréquents (quotes, invoices, contracts, organizations, user session types, user providers, rates, payment plans, task types). Le lot quitte le focus principal et passe en finition opportuniste sur les écrans secondaires restants.
• 2026-03-14: lot modales create/edit suffisamment avancé pour sortir du focus immédiat: pattern FormEntityModal étendu à quotes, invoices, contracts, organizations, user session types, user providers, rates, payment plans et task types, avec duplication locale pour rates et payment plans, formulaires rendus compatibles isModal / onClose / onSaved, et harmonisation visuelle des contenus modaux sans cadres internes redondants.
• 2026-03-14: panneau détail pipeline passé en mode plus contextuel et mobile-friendly: édition contact en modale, conversion lead -> session avec ouverture immédiate de la session en modale, consultation soumission lead form en modale, et clics timeline session / devis / facture qui ouvrent désormais les éditeurs correspondants en modale sans quitter le pipeline.
• 2026-03-14: lot modales create/edit démarré côté documents commerciaux: les listes quotes et invoices ouvrent désormais leurs vrais formulaires (QuoteFormPage, InvoiceFormPage) dans FormEntityModal, avec fermeture propre après sauvegarde, scroll modal corrigé, et conservation d’une étape de sélection contact/session avant ouverture du formulaire.
• 2026-03-13: panneau détail pipeline enrichi avec actions suggérées contextuelles sans nouveau backend: création rapide d’un item pipeline depuis un contact existant, assignation de la première étape commerciale et planification d’une relance rapide.
• 2026-03-13: lot CRM pipeline unifié partiellement livré et documenté: soumission lead form -> upsert pipeline, navigation bidirectionnelle pipeline/soumission, badges statut/étape sur les soumissions, édition rapide depuis le détail de soumission, aperçu structuré de la soumission et timeline d’activité contact en lecture seule dans le panneau pipeline. Le prochain incrément prioritaire devient la densification du panneau détail, pas une nouvelle refonte large.
• 2026-03-13: panneau détail pipeline densifié sans nouveau backend: cartes dernière activité / prochaine action, résumé compact de l’activité (sessions, devis, factures, emails) et timeline recentrée sur les événements les plus utiles.
• 2026-03-09: priorités CRM resserrées après stabilisation lead forms / emails. Le lot "lead forms reliability" sort du focus immédiat; le prochain focus recommandé redevient Proposal v3 + tableau de suivi clientèle + migration create/edit en modales.
• 2026-03-07: gouvernance docs mise à jour (index simplifié, source de vérité par domaine, nouveaux SKILLs .agents/frontend-performance et .agents/docs-performance).
• 2026-03-06: ajout du plan "Visual Day Planner mariage" basé sur scheduler React (FullCalendar), avec publication client et workflow de propositions/review.
• 2026-03-05: ajout du plan "relation clientèle" (tableau de suivi clientèle, migration création/édition en modales, plugin Gmail pour demandes entrantes), aligné avec docs/PRIORITES.md.
• 2026-02-22: Proposal v2 (socle) documenté puis DELETED du produit (FE/BE) — historique git ; day-planner proposals KEEP. Voir APP_CLEANUP_MAP.md Vague C.
• 2026-02-24: Proposal v3 documenté puis DELETED du produit (FE/BE) — historique git. Voir APP_CLEANUP_MAP.md Vague C.
• 2026-02-21: refonte graphique/typographique des emails transactionnels (wrappers shared + wordmark typographique Aaperture, palette light premium, CTA/containers harmonisés), normalisation des sujets sans crochets (Aaperture · ...), et amélioration visuelle des statuts Ops (up/down/protected) dans l'admin.
• 2026-02-21: gestion des doublons contacts améliorée avec synchronisation URL des filtres (groupBy, q, showIgnored) et factorisation UI ListHeaderActions sur les listes Contacts/Sessions/Quotes/Invoices/Contracts.
• 2026-02-21: alerting applicatif observabilité enrichi avec détection de spike queue_jobs_total{status="failed"} (scheduler) en plus des spikes HTTP.
• 2026-02-21: observabilité renforcée avec alertes SLO HTTP (warning/critical sur error rate) et dashboard Grafana enrichi (success rate, error budget remaining, burn rate SLO).
• 2026-02-21: correctif frontend des limites admin sur listes sessions/contacts (normalisation ADMIN_ACCESS => limite illimitée), avec test unitaire dédié pour éviter la régression "limit=0".
• 2026-02-21: refresh des pages légales publiques (Privacy Policy / Terms of Use / GDPR), harmonisation FR/EN, dates de mise à jour 2026, et standardisation du footer légal sur les pages non loguées.
• 2026-02-21: mise à jour Dashboard Hub + Session Wizard (multi-étapes), clarification workflow/type de session/prestation/plan de paiement, résumé de validation lisible, et création automatique de ligne prestation sur devis/facture.
• 2026-02-16: ajout des axes Hub Projet (pivot), multi-sessions, merge projets, wizard projet, collaborateurs/permissions et moodboards projet.
• 2026-02-18: suppression du concept Projet — collaborateurs et moodboards rattachés directement aux sessions. Simplification des rôles (VIEWER/EDITOR/ADMIN).

Décisions structurantes 2026

1) Externalisation de la conformité / facturation via Pennylane

• Décision produit : Aaperture ne doit plus porter seul, à court terme, toute la complexité réglementaire de facturation France/UE comme axe principal.
• Positionnement cible :
  • Aaperture = source de vérité métier
  • Pennylane = source de vérité fiscale / facturation externe
• Conséquence roadmap :
  • le socle billing interne existant reste stratégique pour les devis, l’expérience commerciale, les montants, les statuts métier, les paiements visibles et l’historique côté CRM/portail,
  • l’ancien axe "conformité fiscale complète portée en interne" est requalifié : il n’est pas supprimé, mais déplacé vers un chantier d’encadrement, d’intégration provider et de relais d’états.
• Chantier explicite à ouvrir :
  • BillingModule
  • BillingProvider
  • PennylaneProvider
  • synchronisation des factures externes,
  • stockage des IDs externes, statuts, PDF et métadonnées.

2) Migration du stockage objet vers Scaleway ⏸️ (en pause, on reste sur R2)

• Décision plateforme : le stockage objet devient un axe infra produit officiel avec migration progressive vers une solution française / souveraine.
• Principe d’architecture :
  • le stockage reste S3-compatible,
  • les modules applicatifs ne connaissent pas le provider concret,
  • StorageProvider devient le contrat d’accès unifié,
  • R2StorageProvider et ScalewayStorageProvider coexistent pendant la transition.
• Périmètre concerné :
  • documents,
  • fichiers du portail,
  • galeries,
  • assets de slideshow / rendu vidéo.

3) Conséquence sur la roadmap et les priorités

• Court terme :
  1. Billing / export comptable CSV ✅ (Pennylane in-app deleted)
  2. Storage abstraction ✅ + migration Scaleway ⏸️ (en pause)
  3. Relances automatiques
  4. Cleanup Vague D (orphan schema + galleries F002) — APP_CLEANUP_MAP.md
• Moyen terme :
  • portail client V2 enrichi avec documents,
  • analytics business,
  • Iris proactive V1.
• Long terme :
  • relais des statuts de facturation électronique,
  • Iris avancée,
  • marketplace de templates,
  • élargissement multi-métiers.

Soldé : produit commercial Proposal — DELETED FE/BE/DB (0277). Day-planner proposals KEEP.

📋 Légende

• ✅ Implémenté - Fonctionnalité complètement implémentée et opérationnelle
• ⚠️ Partiellement implémenté - Fonctionnalité en partie implémentée, nécessite des améliorations
• 🚀 En cours / Priorité - Fonctionnalité en cours de développement ou priorisée
• Non implémenté - Fonctionnalité proposée mais pas encore développée

🎯 Focus Actuel

IA Proactive Insights (LOT A - MVP) - ✅ 100% COMPLÉTÉ (2026-01-27) - Système d'insights proactifs opérationnel avec 8 règles déterministes, génération automatique quotidienne, notifications, et interface complète. Toutes les fonctionnalités MVP sont implémentées et testées.

Global Search & Intelligence Artificielle - Développement d'un assistant IA intégré au Global Search pour permettre aux utilisateurs de builder des vues personnalisées et d'exécuter des actions complexes via des prompts en langage naturel. ✅ Phase 1 et 2 complétées.

🧭 Mise à jour Produit (2026-02)

Priorités actives validées pour le repositionnement produit et la cohérence des flux:

• ✅ Sessions comme entité pivot (complété)

  • sessions est l'entité métier principale — le concept "projet" a été supprimé.
  • Collaborateurs et moodboards rattachés directement aux sessions.

• ✅ Collaborateurs session & permissions (complété)

  • Rôles simplifiés : VIEWER, EDITOR, ADMIN.
  • Identification flexible : user existant, email invité, ou prestataire lié.
  • Invitation/recherche unifiée (utilisateurs existants, prestataires, email).

• ✅ Moodboards session (complété)

  • Plusieurs moodboards par session.
  • Upload multiple d'images (max 10 à la fois).
  • Partage avec le client (is_shared_with_client).
  • Catégorisation optionnelle des items.
  • Édition côté utilisateur et côté portail client.

• ✅ Accueil Dashboard = Hub simplifié (complété)

  • Réduction de la densité d’information en page d’accueil.
  • Les vues spécialisées restent dans les pages métier dédiées.
  • Les actions clés sont exposées via un bloc Quick Actions direct.

• ✅ Session Wizard opérationnel (complété)

  • Modal multi-étapes orientée exécution rapide:
    • Session
    • Configuration
    • Documents
    • Validation
  • Logique de préremplissage par type de session (workflow et plan de paiement par défaut).
  • Cohérence UX sur les dépendances (champs activés/désactivés selon prérequis).
  • Si devis/facture est demandé, la prestation sélectionnée est ajoutée en ligne d’item à la création.

• ✅ Conformité pages légales publiques (complété)

  • Footer légal unifié sur les écrans non logués:
    • Privacy Policy
    • Terms of Use
    • GDPR
    • copyright + année courante
  • Terminologie FR harmonisée (Politique de confidentialité).
  • lastUpdatedDate synchronisée FR/EN (Février 2026 / February 2026).

🆕 Plan d'amélioration relation clientèle (2026-03)

Objectif: réduire les pertes de contexte, accélérer le traitement des demandes entrantes, et centraliser le suivi commercial dans un flux unique.

Lot CRM unifié - état actuel

Le lot d’unification CRM est maintenant partiellement livré.

Travail déjà livré :

• soumission de lead form -> upsert d’un item pipeline CRM,
• navigation pipeline -> soumission,
• navigation soumission -> pipeline,
• badges statut / étape CRM visibles sur les soumissions,
• édition rapide du statut et de l’étape depuis le détail de soumission,
• aperçu structuré de la soumission dans le panneau latéral pipeline,
• timeline d’activité contact en lecture seule dans le panneau latéral pipeline,
• panneau pipeline désormais modal-first pour les actions contextuelles principales:
  • modifier le contact,
  • ouvrir la soumission,
  • convertir en session puis finaliser la session,
  • ouvrir depuis la timeline une session, un devis ou une facture,
• densité mobile corrigée dans le panneau détail (cartes et actions empilées sur petit écran).

Prochain incrément recommandé :

• enrichir le panneau pipeline avec une activité plus dense et plus actionnable,
• sans ouvrir un nouveau chantier CRM transverse ni créer de backend dédié supplémentaire à ce stade.

Compléments déjà livrés sur ce prochain incrément :

• cartes compactes dernière activité et prochaine action,
• résumé d’activité agrégé dans le panneau pipeline,
• timeline recentrée sur les événements récents les plus utiles,
• bloc actions suggérées pour accélérer les prochaines actions sans quitter le panneau détail,
• résumé santé du lead (coordonnées + rythme de suivi) pour aider à prioriser rapidement.

1) Tableau de suivi clientèle (Priorité Haute) 🚀

• But produit : disposer d'une vue pipeline unique lead -> contact qualifié -> session/devis.
• État actuel : le socle unifié est lancé et partiellement livré ; le prochain incrément prioritaire est maintenant la densification du panneau détail (activité, contexte, prochaines actions), pas une nouvelle refonte large.
• Périmètre MVP :
  • colonnes par statut (Nouveau, Qualifié, En attente, Converti, Fermé),
  • cartes avec source de demande, dernière interaction, propriétaire, prochaine action,
  • actions rapides (changer statut, assigner, créer session/devis).
• Source de vérité :
  • activités commerciales et relances restent traçables dans les entités existantes (contacts/sessions/tasks),
  • le tableau est une projection opérationnelle, pas une duplication métier.
• KPI cible :
  • délai moyen de première réponse,
  • taux de conversion lead -> session,
  • volume de demandes non traitées > 48h.

2) Création/édition en modales (Lot largement livré) ✅

• But produit : éviter les ruptures de navigation et accélérer les micro-opérations de saisie.
• État actuel : le lot est désormais formellement refermé sur les écrans les plus fréquents; il ne reste plus qu’une finition opportuniste sur quelques écrans secondaires.
• Décision UX :
  • remplacer les pages de création/édition fréquentes par des modales (create / edit) avec formulaire réutilisable,
  • conserver une page dédiée uniquement pour les formulaires longs/avancés.
• Règles d'implémentation :
  • même schéma de validation entre modal et formulaire existant,
  • sauvegarde inline + retour immédiat à la vue d'origine,
  • support mobile via full-screen modal quand nécessaire.
• Livré récemment :
  • quotes, invoices, contracts, organizations, user session types, user providers, rates, payment plans, task types sont maintenant passés sur le pattern FormEntityModal,
  • duplication locale gardée quand utile (rates, payment plans),
  • compat modal/page harmonisée (forcedId, isModal, onClose, onSaved) et rendu modal nettoyé sans wrappers internes redondants.
• Reste éventuel :
  • garder les écrans secondaires restants pour une passe opportuniste, sans relancer un chantier transversal dédié,
  • conserver une vraie page dédiée uniquement pour les formulaires longs ou les flux guidés spécifiques.

3) Plugin Gmail natif dans Gmail — FREEZE / deferred (Vague A)

• Statut : not active; see docs/GMAIL_PLUGIN_IMPLEMENTATION_PLAN.md (FREEZE banner).
• But produit (when reopened) : aider l’utilisateur à traiter les emails entrants directement dans Gmail, avec le contexte CRM Aaperture et les actions Iris disponibles au bon moment.
• Plan dédié : docs/GMAIL_PLUGIN_IMPLEMENTATION_PLAN.md
• Périmètre initial :
  • panneau latéral Aaperture dans Gmail,
  • lecture du contexte du thread courant,
  • matching déterministe vers contact/lead/session,
  • création ou liaison rapide sans quitter Gmail,
  • appel à Iris pour next step, angle de réponse et follow-up.
• Contraintes techniques :
  • contraintes propres aux Google Workspace Add-ons,
  • auth propre entre Gmail et Aaperture,
  • respecter un MVP sans sync de boîte ni client mail embarqué.
• Risques :
  • sur-scoper vers une inbox ou une sync Gmail complète,
  • complexifier trop tôt l’UI si on part sur une extension Chrome au lieu d’un add-on natif.
• Approche recommandée :
  • MVP en Google Workspace Add-on,
  • Aaperture comme backend métier,
  • enrichissement progressif après validation usage réel.

Séquencement transversal recommandé

1. Livrer le tableau de suivi clientèle (valeur business immédiate).
2. Garder les modales create/edit en chantier de finition opportuniste, plus comme lot principal.
3. Brancher le plugin Gmail natif sur un périmètre minimal utile puis étendre.

4) Assistant CRM / chat workspace (Priorité Haute) 🚀

• But produit : faire du chat agent un vrai espace de conversation/action CRM, et non un panneau secondaire difficile à lire.
• Problème actuel :
  • divergence entre sidebar, window, mobile et fullscreen,
  • rendu encore trop “outil technique” sur certaines surfaces,
  • pièces jointes et résultats d’actions pas assez intégrés dans la logique conversationnelle,
  • markdown et blocs système visuellement trop proches d’un dump brut.
• Décision UX :
  • shell unique du chat quel que soit le mode d’affichage,
  • messages, pièces jointes, formulaires inline et résultats d’action traités comme des objets de conversation de même niveau,
  • composer plus clair, plus dense, et plus orienté action.
• Périmètre MVP du lot :
  • unifier la composition header / messages / composer,
  • harmoniser les surfaces de message user / assistant / système,
  • revoir les cartes de fichiers et l’état vide,
  • clarifier les actions de shell (close, switch mode, minimize),
  • fiabiliser les uploads agent avec stratégie presigned URL en chemin principal et fallback backend en sécurité.
• État actuel :
  • le shell et le rendu conversationnel sont désormais largement livrés,
  • le lot ne se pilote plus comme une refonte visuelle générale,
  • le prochain incrément utile est la stabilisation métier: scénarios E2E, actions CRM plus prescriptives, et derniers cas de contexte/runtime.
• Règles d’implémentation :
  • une source de vérité de composition (AgentPanelContent ou équivalent),
  • ne pas multiplier les variantes stylistiques locales par mode,
  • conserver des actions compactes et cohérentes avec le reste de l’app,
  • garder les comportements temps réel et upload robustes pendant la refonte.
• E2E recommandé :
  • ouvrir le chat,
  • envoyer un message,
  • joindre un fichier image,
  • vérifier l’apparition du fichier dans la conversation,
  • couvrir le cas de fallback upload si l’upload signé échoue.

5) Messages / inbox workspace (Lot livré, suivi opportuniste) ✅

• But produit : faire de Messages un vrai espace de travail quotidien cohérent avec Iris, pipeline et les autres workspaces métier.
• Livré :
  • shell page allégé,
  • liste de conversations densifiée,
  • threads client/ami harmonisés,
  • panneau fichiers clarifié,
  • modal nouvelle conversation restructurée autour du choix du destinataire puis du premier message.
• Suite éventuelle :
  • correctifs opportunistes,
  • scénarios E2E ciblés si la messagerie entre dans la suite critique CI,
  • meilleures actions contextuelles entre conversation, contact, session et assistant.

🆕 Visual Day Planner mariage (2026-03)

Objectif: fournir un builder visuel de journée mariage co-utilisable par photographe et client, sans duplication de source, avec validation côté photographe avant publication.

Décisions verrouillées

• Vue principale: timeline verticale journée.
• Collaboration client: modèle "proposition -> validation photographe" (pas d’override direct client).
• Activation initiale: sessions mariage.
• Stack: FullCalendar React (@fullcalendar/react, @fullcalendar/core, @fullcalendar/timegrid, @fullcalendar/interaction).

Périmètre MVP

1. Builder interne:

• template de journée mariage pré-rempli,
• CRUD des blocs (titre, début/fin, lieu, responsable, notes, catégorie),
• drag/drop + resize + snap 10 minutes.

2. Portail client:

• lecture de la version publiée,
• action "Proposer une modification" vers une proposition séparée.

3. Review:

• inbox de propositions côté photographe,
• accepter/refuser/ajuster puis publier la version client.

Backend/API

• Endpoints:
  • GET /api/sessions/:id/planning/day?scope=internal|published|proposals
  • POST /api/sessions/:id/planning/day/template/apply
  • POST /api/sessions/:id/planning/day/publish
  • POST /api/sessions/:id/planning/day/proposals
  • PUT /api/sessions/:id/planning/day/proposals/:proposalId/review
  • GET /api/client-accounts/me/sessions/:sessionId/planning/day?scope=published|proposals
  • POST /api/client-accounts/me/sessions/:sessionId/planning/day/proposals
• Modèle (extension session_planning_items):
  • end_date, category, responsible,
  • visibility, source, review_status,
  • parent_item_id, reviewed_at, reviewed_by.

Frontend/UX

• Session > Planning & Logistics:
  • sous-section Day Planner avec FullCalendar custom tokens premium.
  • actions compactes: + bloc, Template, Publier, ....
• Portail client:
  • timeline publiée en lecture seule,
  • modal de proposition de modification.

Séquencement recommandé

1. Sprint 1: intégration scheduler + CRUD interne + template.
2. Sprint 2: propositions client + review + publication.
3. Sprint 3: mobile touch, accessibilité clavier, export PDF jour J, analytics d’adoption.

🆕 Billing externalisé / Pennylane

Contexte

Le socle facturation Aaperture est déjà robuste côté métier, mais le produit ne doit plus viser à court terme une internalisation croissante de la conformité fiscale comme avantage principal. La décision 2026 consiste à garder Aaperture comme cockpit commercial et documentaire, tout en déléguant la vérité réglementaire de facturation à un provider externe spécialisé.

Objectif produit

Permettre au photographe de continuer à piloter ses devis, sa conversion commerciale et son portail client dans Aaperture, tout en externalisant la création et le cycle fiscal des factures vers Pennylane sans rupture de parcours.

Périmètre MVP

• création d’une facture externe Pennylane depuis un devis accepté,
• récupération du PDF de facture,
• affichage de la facture externe dans la session, les écrans documents et le portail client,
• stockage des identifiants et métadonnées minimales pour relier le document externe au CRM.

Architecture cible

• BillingModule orchestre le workflow métier de facturation dans le backend NestJS.
• BillingProvider définit le contrat métier commun:
  • createInvoiceFromQuote,
  • getInvoice,
  • getInvoicePdf,
  • listInvoicesForSession|Contact,
  • syncInvoiceStatus.
• PennylaneProvider implémente ce contrat via API externe.
• Aaperture conserve la relation métier:
  • organisation,
  • contact,
  • session,
  • quote,
  • invoice intent / invoice mirror.
• Le frontend React/TanStack consomme une API Aaperture stable, pas l’API Pennylane directement.

Impacts backend

• nouveau module NestJS dédié au provider billing,
• services de mapping quote -> payload Pennylane,
• endpoints de création et de lecture des factures externes,
• jobs BullMQ pour sync asynchrone, retries, récupération PDF et refresh des métadonnées,
• garde multi-tenant par organisation sur tous les objets synchronisés.

Impacts frontend

• CTA métier dans les écrans devis pour "créer la facture externe",
• visualisation claire du statut brouillon externe / envoyée / payée / partiellement payée / annulée via l’API Aaperture,
• lien PDF et bloc de provenance externe dans les vues invoice, session, contact si pertinent,
• distinction explicite entre état métier interne et état fiscal/provider quand les deux coexistent.

Impacts portail client

• affichage des factures externes dans /portal/documents et la vue séance,
• téléchargement du PDF Pennylane sans exposer directement le provider,
• base UX inchangée pour le client: Aaperture reste la surface de consultation.

Impacts data / DB

• table ou extension de modèle pour stocker:
  • billing_provider,
  • external_invoice_id,
  • external_status,
  • external_number,
  • external_pdf_key|url,
  • external_payload_snapshot,
  • last_synced_at,
  • sync_error,
  • organization_id, session_id, quote_id, invoice_id si miroir local.
• conserver un mapping fort organisation/provider pour rester multi-tenant.
• prévoir des index par organization_id, external_invoice_id et quote_id.
• Plan dédié : docs/ACCOUNTING_EXPORT_GUIDE.md (export comptable; sync Pennylane in-app retiré)

Risques

• divergence entre données métier Aaperture et états Pennylane si la sync est incomplète,
• dépendance externe sur disponibilité API/provider,
• complexité de mapping taxes/avoirs/paiements partiels si le MVP est sur-scopé,
• confusion UX si les statuts externes remplacent trop tôt les statuts métier existants.

Séquencement recommandé

1. MVP:
   • contrat BillingProvider,
   • PennylaneProvider,
   • création facture depuis devis accepté,
   • récupération PDF,
   • affichage app + portail.
2. Phase suivante:
   • webhooks,
   • sync statuts,
   • paiements,
   • avoirs,
   • paiements partiels.
3. Long terme:
   • relais des statuts de facturation électronique,
   • conservation des métadonnées de conformité sans réinternaliser la logique réglementaire.

⏸️ Storage abstraction / Scaleway

Statut (2026-10-23) : étape 1 livrée (abstraction sur R2). Migration Scaleway en pause : on reste sur R2. Point ouvert à la reprise : stratégie de dual-read pour les URLs signées (fallback par existence + cache de localisation, ou copie en masse puis bascule).

Contexte

Le produit repose déjà largement sur du stockage objet pour les documents, fichiers du portail, galeries et rendus média. La décision 2026 consiste à repositionner ce socle vers un fournisseur français / souverain, sans casser les modules applicatifs existants ni réécrire les usages S3.

Objectif technique

Rendre le stockage transparent pour les modules métier via une abstraction stable, puis migrer progressivement de R2 vers Scaleway en gardant une compatibilité S3 complète.

Architecture cible

• StorageProvider comme contrat principal:
  • upload,
  • download,
  • delete,
  • signed URL,
  • copy / move,
  • metadata lookup.
• R2StorageProvider pour l’existant.
• ScalewayStorageProvider pour la cible.
• StorageService et les modules applicatifs consomment uniquement l’interface commune.
• Les clés métier et conventions de chemins restent stables quel que soit le provider.

Stratégie de migration

• nouveaux uploads dirigés vers Scaleway dès que le provider est prêt,
• dual-read temporaire:
  • lecture d’abord sur Scaleway,
  • fallback sur R2 pour l’existant,
• lazy migration:
  • recopier à la lecture ou par batch worker selon le type de fichier,
• extinction progressive de R2 quand les taux de fallback deviennent marginaux.

Impacts backend / workers / fichiers / galeries

• backend:
  • refactor des accès stockage pour éliminer les dépendances directes à R2,
  • conservation des URLs signées et règles d’accès existantes.
• workers BullMQ:
  • jobs de migration batch,
  • copie/réconciliation d’objets,
  • vérification checksums et métadonnées.
• documents:
  • PDFs générés,
  • exports,
  • pièces jointes.
• portail:
  • upload/download fichiers client,
  • lecture de documents et médias.
• galeries et slideshow:
  • origin files,
  • dérivés,
  • assets de rendu vidéo et médias publiés.

Risques

• dette de chemin d’accès si des modules continuent à appeler R2 en direct,
• coût/performance variable pendant la phase dual-read,
• edge cases de signed URLs et headers S3-compatibles selon provider,
• migration incomplète sur les objets rarement lus sans batch complémentaire.

Séquencement recommandé

1. ✅ (2026-10-23) Introduire StorageProvider et le brancher sur R2 sans changement fonctionnel.
   • un seul S3CompatibleStorageProvider (backend/src/storage/providers/), configuré par provider : R2 aujourd'hui, Scaleway demain (pas de classe dédiée par provider) ;
   • plus aucun accès S3 direct hors storage/providers/ : streaming vidéo galeries via StorageService.getObjectStream (helper partagé galleries-slideshow-stream.utils.ts), file_objects.provider/bucket renseignés par FileObjectsService depuis le provider actif ;
   • restant pour le dual-read : r2:// et clés nues ne portent pas le provider (seul file_objects le fait) ; URLs publiques/signées stockées dans les colonnes *_url ; proxyImage n'autorise que cloudflarestorage.com ; CSP mediaSrc 'self'.
2. Ajouter ScalewayStorageProvider et basculer les nouveaux uploads.
3. Activer dual-read et lazy migration pour l’existant.
4. Ajouter un worker BullMQ de migration/réconciliation pour les buckets volumineux.
5. Mesurer fallback, erreurs et latence avant extinction de R2.

État Actuel du Global Search

✅ Fonctionnalités Implémentées :

• Recherche unifiée dans sessions, contacts, devis, factures, et Notion
• Recherche en temps réel avec debounce (300ms)
• Intégration Notion avec recherche dans pages et bases de données
• Navigation complète au clavier (Cmd+K / Ctrl+K, flèches, Enter, Escape)
• Actions rapides (créer session, créer contact)
• Résultats groupés par catégorie avec compteurs
• Interface utilisateur optimisée avec états de chargement séparés

✅ Phase 1 Complétée :

• ✅ Assistant conversationnel IA intégré
• ✅ Builder de vues personnalisées via prompts
• ✅ Génération d'actions complexes
• ✅ Traduction de requêtes en langage naturel en filtres

✅ Phase 2 Complétée :

• ✅ Création assistée par IA d'entités
• ✅ Génération de rapports intelligents
• ✅ Rédaction assistée

🚀 Phase 3 (plan détaillé) : Voir GLOBAL_SEARCH_PHASE3_PLAN.md.

• Priorité haute : Suggestions d’actions contextuelles (selon la route), lien Insights ↔ Global Search/Agent (bloc « Insights récents »).
• Priorité moyenne : Résumé et synthèse (commande/intention « Résumer session/contact »).
• Reporté : Affinage conversationnel multi-tour, prédictions/recommandations (Phase 3.1/3.2).
• Note : L’analyse et insights automatiques sont déjà couverts par le système IA Proactive Insights (LOT A).

📊 Analytics & Reporting

Améliorations identifiées dans la documentation

• ✅ Custom date range presets - Présélections de plages de dates (semaine, mois, trimestre, année)
  • Implémenté : Frontend avec presets (week, month, quarter, year, all) dans AnalyticsPage.tsx
• ⚠️ Scheduled report generation - Génération automatique de rapports planifiés
  • Partiellement implémenté : Les emails peuvent être planifiés (devis, factures, contrats), mais pas la génération automatique de rapports analytics
• ⚠️ Email delivery of reports - Envoi automatique de rapports par email
  • Partiellement implémenté : Les emails de devis/factures peuvent être envoyés/planifiés, mais pas les rapports analytics
• ✅ Export to other formats - Export vers Excel, CSV en plus du PDF
  • Implémenté : Backend ExportService supporte CSV, Excel (XLSX), JSON et PDF
• ⚠️ Custom metrics and KPIs - Métriques personnalisables par l'utilisateur
  • À vérifier : Les métriques semblent fixes, pas de personnalisation visible
• ⚠️ Comparison between periods - Comparaison entre différentes périodes (mois vs mois précédent, année vs année précédente)
  • À vérifier : Support de date range mais pas d'interface claire pour comparer des périodes

Suggestions supplémentaires

• Tableaux de bord personnalisables - Permettre aux utilisateurs de créer leurs propres tableaux de bord avec les métriques qu'ils souhaitent
• Alertes sur métriques - Notifications automatiques lorsque certaines métriques atteignent des seuils (ex: revenu mensuel > X€)
• Graphiques interactifs - Graphiques cliquables pour explorer les données en détail
• Analyse de tendances prédictives - Utiliser les données historiques pour prédire les tendances futures
• Rapports comparatifs multi-utilisateurs - Comparer les performances entre différents utilisateurs (pour les admins)

📤 Export & Import

Améliorations identifiées dans la documentation

• ✅ Système d'export centralisé - Système unifié pour tous les exports
  • Implémenté : Service centralisé ExportService avec support multi-formats
  • Formats supportés : PDF, Word (DOCX), CSV, Excel (XLSX), JSON
  • Entités : Sessions, Contacts, Quotes, Invoices, Conversations, Roadmaps, Contract Templates
  • Documentation : docs/EXPORT_SYSTEM.md
• ✅ Exports multi-formats - Support de plusieurs formats pour chaque type d'export
  • Implémenté : Tous les exports supportent maintenant PDF, Word, CSV, Excel selon le contexte
  • Backend : Endpoints unifiés avec paramètre format
  • Frontend : Composant ExportFormatDialog réutilisable
• ✅ Import functionality for CSV/Excel - Fonctionnalité d'import depuis CSV/Excel
  • Implémenté : Service d'import complet avec support CSV et Excel (XLSX, XLS)
  • Backend : ImportService pour parser les fichiers, services spécialisés pour chaque entité
  • Entités supportées : Contacts, Sessions, Quotes, Invoices
  • Endpoints :
    • POST /api/import/contacts - Import de contacts
    • POST /api/import/sessions - Import de sessions
    • POST /api/import/quotes - Import de quotes
    • POST /api/import/invoices - Import d'invoices
  • Fonctionnalités : Auto-détection de mapping, validation des données, rapport d'erreurs détaillé, import incrémental
  • Renforcement (2026-02-09) : compatibilité Google Contacts améliorée (headers standards) + warnings de déduplication assistée pendant l'import contacts
  • Renforcement (2026-02-09, v2) : étape de revue avant import contacts avec pré-analyse backend (/import/contacts/preview) et décision par ligne (create/update/skip)
  • Frontend : Composants ImportButton et dialogs spécialisés (ImportContactsDialog, ImportSessionsDialog, ImportQuotesDialog, ImportInvoicesDialog) intégrés dans toutes les pages de liste
  • Documentation : backend/src/import/, docs/IMPORT_SYSTEM.md
• ✅ Scheduled exports - Exports planifiés automatiques
  • Implémenté : Système complet avec table scheduled_exports, scheduler, et support de récurrence
  • Fonctionnalités : Récurrence (daily/weekly/monthly/yearly), envoi par email automatique, gestion des statuts
  • Endpoints : GET/POST/PUT/DELETE /api/scheduled-exports
  • Documentation : backend/src/scheduled-exports/
• ✅ Email delivery of exports - Envoi automatique d'exports par email
  • Implémenté : Support complet dans le processor d'export avec pièces jointes
  • Fonctionnalités : Envoi automatique avec sujet et message personnalisables
  • Intégration : Utilise UserEmailSenderService pour l'envoi
• ✅ Custom field selection - Sélection personnalisée des champs à exporter
  • Implémenté : Support via paramètre fields dans les endpoints d'export
  • Format : Liste de champs séparés par virgules (ex: ?fields=id,title,email)
  • Disponible pour : Sessions, Contacts, Quotes, Invoices
• ✅ Export templates - Templates d'export pré-configurés
  • Implémenté : Système complet avec table export_templates
  • Fonctionnalités : Templates réutilisables avec champs sélectionnés, templates par défaut
  • Endpoints : GET/POST/PUT/DELETE /api/export-templates
  • Documentation : backend/src/export-templates/

Suggestions supplémentaires

• ✅ Import avec validation - Validation des données importées avec rapport d'erreurs
  • Implémenté : Validation complète avec rapport d'erreurs détaillé par ligne
• ✅ Import incrémental - Possibilité de mettre à jour des données existantes via import
  • Implémenté : Support via paramètre updateExisting=true, matching par email ou nom
• ✅ Mapping de champs personnalisé - Permettre le mapping de colonnes CSV vers les champs du CRM
  • Implémenté : Auto-détection automatique + support de mapping personnalisé via paramètre JSON
• ❌ Import depuis autres sources - Import depuis Google Contacts, Outlook, etc.
  • Non implémenté : À venir
• ❌ Synchronisation bidirectionnelle - Synchronisation automatique avec des sources externes
  • Non implémenté : À venir

🔍 Recherche & Filtrage

Recherche Globale (Global Search)

• ✅ Recherche globale unifiée - Recherche unifiée dans toutes les entités (sessions, contacts, devis, factures, Notion)
• ✅ Recherche en temps réel - Recherche avec debounce pour optimiser les performances
• ✅ Intégration Notion - Recherche dans les pages et bases de données Notion
• ✅ Navigation au clavier - Navigation complète au clavier (Cmd+K / Ctrl+K, flèches, Enter)
• ✅ Actions rapides - Actions rapides depuis la recherche (créer session, créer contact)
• ✅ Résultats groupés - Résultats organisés par catégorie avec compteurs
• ⚠️ Recherche sémantique - Recherche intelligente basée sur le sens (partiellement implémenté via filtrage Notion)
• ⚠️ Historique de recherche - Conserver l'historique des recherches récentes (non implémenté)

🤖 Global Search & Intelligence Artificielle

Phase 1 : Assistant IA pour la construction de vues et actions (Priorité Haute) ✅

• ✅ Assistant conversationnel intégré - Un chatbot IA accessible directement depuis le Global Search (Cmd+K) pour répondre aux questions et exécuter des commandes
  • Exemple : "Quel est le revenu total du mois dernier ?", "Montre-moi les sessions avec Jean Dupont."
  • Implémenté : Détection multilingue (français/anglais), vérification OpenAI, traitement automatique
• ✅ Création assistée par IA de vues personnalisées - Générer des vues filtrées et personnalisées à partir de prompts en langage naturel
  • Exemple : "Crée une vue des sessions de mariage du mois de juillet avec un montant supérieur à 2000€"
  • Exemple : "Affiche tous les contacts qui n'ont pas eu de session depuis 6 mois"
  • Exemple : "Montre-moi les devis en attente pour les sessions de type 'portrait'"
  • Implémenté : Génération de filtres intelligents, application automatique des filtres
• ✅ Génération d'actions complexes - L'IA peut générer et exécuter des actions complexes basées sur des prompts
  • Exemple : "Crée une facture pour toutes les sessions payées du mois dernier"
  • Exemple : "Je veux créer une session pour Fred Le Marquier pour son mariage le 22 août 2026"
  • Exemple : "Créez moi un contact et un devis de 2000€ pour cette session"
  • Implémenté : Auto-exécution des actions, actions composites (contact + session + devis), notifications automatiques
• ✅ Builder de filtres intelligents - L'IA traduit les requêtes en langage naturel en filtres complexes
  • Exemple : "Sessions de mariage en été 2024 avec montant > 3000€" → Filtres automatiques appliqués
  • Implémenté : Traduction automatique en filtres structurés, application aux requêtes DB
  • Exemple : "Contacts actifs avec au moins 2 sessions cette année" → Filtres et agrégations automatiques

Phase 2 : Création assistée par IA (Priorité Moyenne) ✅

• ✅ Création assistée par IA d'entités - Générer des brouillons de sessions, contacts, devis, factures à partir de prompts
  • Exemple : "Crée une nouvelle session photo pour le mariage de Marie et Pierre le 15 juillet 2024 à Paris, avec un devis de 2500€."
  • Implémenté : Service AiCreationService avec endpoint POST /api/ai-assistant/draft
  • Fonctionnalités : Génération de brouillons pour sessions, contacts, devis, factures avec suggestions et avertissements
  • Fichiers : backend/src/ai-assistant/ai-creation.service.ts
• ✅ Génération de rapports intelligents - Demander des rapports personnalisés via des prompts, l'IA agrège les données et génère le rapport
  • Exemple : "Génère un rapport PDF des revenus par type de session pour le dernier trimestre."
  • Implémenté : Service AiReportService avec endpoint POST /api/ai-assistant/report
  • Fonctionnalités : Génération de rapports avec sections, insights, recommandations basées sur les données fournies
  • Fichiers : backend/src/ai-assistant/ai-report.service.ts
• ✅ Rédaction assistée - Utiliser l'IA pour générer des ébauches d'emails, de descriptions de sessions, de notes de contact, etc.
  • Exemple : "Rédige un email de suivi pour le devis #2024-001 en rappelant les avantages de notre offre."
  • Implémenté : Service AiWritingService avec endpoint POST /api/ai-assistant/writing
  • Fonctionnalités : Génération d'emails, descriptions, notes avec support de contexte, ton, langue
  • Fichiers : backend/src/ai-assistant/ai-writing.service.ts
• Statut : ✅ Complété (2025-01-XX)
• Documentation : backend/src/ai-assistant/README.md, docs/AI_SEARCH_ARCHITECTURE.md

Phase 3 : Intelligence avancée (plan révisé 2026-02-28)

Voir le plan détaillé GLOBAL_SEARCH_PHASE3_PLAN.md.

• Analyse et insights automatiques : Déjà couvert par le système IA Proactive Insights (LOT A). Phase 3 = lien Global Search/Agent vers les insights (bloc « Insights récents »).
• Suggestions d'actions contextuelles : À implémenter – selon la route/page actuelle, afficher des actions rapides (ex. « Créer une session », « Voir les devis ») dans le Global Search ou l’Agent.
• Recherche conversationnelle : Partiellement couverte (requêtes en langage naturel). Affinage multi-tour reporté en Phase 3.1.
• Prédictions et recommandations : Reporté (Phase 3.2), chantier métier/ML dédié.
• Résumé et synthèse : À implémenter – commande/intention « Résumer session/contact » via le service d’écriture IA existant.

🤖 Chat agent & commandes (Priorité)

• ✅ Complété (2026-02-06) : Refonte du chat avec commandes en / (ex. /contact, /session, /devis, /facture, /aide) et auto‑complétion. Détection backend, routage vers form builder structuré. Frontend : suggestions à la saisie, navigation clavier, tokens inline (actions/contexte).
• ✅ Complété (2026-02-06) : Dual‑mode (commandes vs conversation libre) + fichiers de conversation avec OCR pour enrichir le contexte IA.
• Objectifs : Sécurisation des insertions, UX guidée, réduction des données incomplètes ou en double.
• Documentation : REFONTE_CHAT_AGENT.md

Sécurisation des insertions (agent & commandes)

• ✅ Complété (2026-02-06) :
  • Contact : email requis pour toute création via l’agent (création uniquement via form builder).
  • Session : start_date, title, location obligatoires via l’agent.
• Doublons : Interdiction de créer un contact dont l’email existe déjà pour le même owner. Pas d’option "Créer quand même" pour l’email ; seule action proposée : "Utiliser le contact existant". L’option "Créer quand même" est conservée uniquement pour le doublon par nom (similarité prénom/nom), avec confirmation explicite. Optionnel : même règle pour le numéro de téléphone.

Gestion des doublons (contacts)

• Accès : Bouton "Gérer les doublons" en haut de la liste des contacts et sur le dashboard d’accueil.
• Regroupement : Détection des groupes de contacts susceptibles d’être la même personne par email (même email normalisé) ou par numéro de téléphone (même numéro normalisé). Vue par critère (email, téléphone, ou combinée).
• Fusion : Pour chaque groupe, prévisualisation des fiches et des données liées (sessions, devis, factures, documents, etc.). L’utilisateur choisit le contact à conserver ; le système réattribue toutes les entités liées au contact conservé puis supprime les anciennes fiches (avec confirmation explicite, optionnellement soft-delete + délai de restauration).
• État d’implémentation (2026-02-08) :
  • ✅ UI workspace frontend/src/pages/contacts/ContactDuplicatesPage/ContactDuplicatesPage.tsx : tri, recherche, badges de confiance, prévisualisation.
  • ✅ Endpoint preview POST /contacts/merge/preview : conflits de champs + réattributions.
  • ✅ Endpoint merge enrichi POST /contacts/merge : fieldOverrides + réponse détaillée reassignedEntities.
  • ✅ Audit enrichi sur fusion (MERGE CONTACT) avec metadata (IDs fusionnés et métriques de réattribution).
  • ✅ E2E frontend/e2e/contacts-duplicates.spec.ts (wizard de preview).
  • ✅ Liste contacts : sélection multiple + suppression en lot + raccourci "Fusionner la sélection".
  • ✅ Dashboard : CTA vers dédoublonnage masqué automatiquement quand aucun doublon n’est détecté.
  • ✅ Liste sessions : mode sélection + suppression en lot + règles UI harmonisées (colonne actions conservée, menu désactivé en mode sélection).
  • ✅ Listes quotes & invoices : mode sélection + suppression en lot + comportement UI aligné avec les autres listes.
  • ✅ Nettoyage OCR list views : bloc "Documents avec OCR" retiré des vues Session et Contact pour alléger l'UX.
  • ✅ Page /documents retirée du frontend (routes + navigation nettoyées).
  • ✅ Documents liés (SessionView + ContactView) : mode sélection + suppression en lot branchés via FileList.
  • ✅ Standard de sélection factorisé : composant partagé ListHeaderActions branché sur Contacts/Sessions/Quotes/Invoices/Contracts.
  • ✅ Workspace dédoublonnage : filtres synchronisés à l'URL (groupBy, q, showIgnored) pour restauration/partage de l'état.
• Documentation : Référence dans PRIORITES.md.

💬 Messagerie & Communication

État actuel

• ✅ Messagerie globale (app) : vue centralisée avec liste de contacts + amis, tri par dernier message, pastilles non‑lus, actions rapides
• ✅ Messages portail client : fil de discussion client avec notifications UI et gestion “compte client non créé”
• ✅ Fichiers en conversation : pièces jointes client ↔ photographe, previews images sécurisées via URL signées, modal plein écran
• ✅ Upload résilient : presigned URL + fallback backend en cas de CORS
• ✅ Temps réel : événements WebSocket communs pour messages + fichiers (rafraîchissement conversations et fichiers)
• ✅ Routes agnostiques : endpoints app en /client-messages/app/* (alias legacy conservé)
• ✅ Invitations auto : si le client n’a pas de compte, l’email d’invitation est envoyé avec aperçu du message
• ✅ Notifications différées : email d’alerte sur le 1er message non‑lu après délai, annulé si lecture
• ✅ Préférences utilisateur : toggle pour activer/désactiver ces notifications dans une sidebar settings

Améliorations futures

• ⚠️ Présence temps réel complète : WebSocket + last_seen_at plus précis pour clients et amis
• ⚠️ Recherche avancée : recherche plein‑texte dans conversations et messages
• ⚠️ Archivage : archivage/restauration de conversations côté app et portail

Suggestions supplémentaires

• Filtres sauvegardés - Sauvegarder des combinaisons de filtres fréquemment utilisées
• Recherche par tags - Recherche et filtrage avancé par tags avec opérateurs logiques (ET, OU, SAUF)
• Suggestions de recherche - Autocomplétion intelligente basée sur les données existantes

💡 Insights Proactifs & Intelligence

LOT A : IA Proactive Insights (MVP Production) ✅ 100% COMPLÉTÉ

Objectif : Générer des insights actionnables basés sur les données CRM (devis, factures, sessions, bookings, checklists, emails), les pousser en notifications in-app + push, et les afficher dans un panneau Insights.

Approche MVP : Règles déterministes (pas de LLM au début) pour garantir la fiabilité et la performance.

Statut : ✅ 100% complété (2026-01-27) - Toutes les fonctionnalités MVP implémentées et opérationnelles

Documentation : PLAN_AMELIORATIONS_CRM.md (sections Insights / lots livrés)

Fonctionnalités implémentées :

• ✅ 8 règles d'insights (QuoteStale, InvoiceOverdue, InvoicePartiallyPaid, SessionPrepMissing, SessionPostprodLag, SessionWithoutDelivery, BookingUpcoming, ChecklistIncomplete)
• ✅ Génération automatique quotidienne (scheduler 3h du matin)
• ✅ Génération réactive via events (quote status changed, invoice created, etc.)
• ✅ Queue BullMQ avec processor et retry/backoff
• ✅ API complète (7 endpoints REST)
• ✅ Interface utilisateur avec filtres avancés
• ✅ Notifications in-app + WebSocket + push
• ✅ Badge compteur dans sidebar
• ✅ Tests unitaires (>80% coverage)
• ✅ i18n FR/EN complet
• ✅ Vague A: action CREATE_TASK navigates to deepLink (no inline task create from Insights card)

A1. Modèle & Persistence

• Tables : ai_insights, ai_insight_events, ai_insight_feedback
• Enums : insight_type, insight_severity, insight_status, insight_feedback_rating, insight_event_type
• Indexes : Optimisés pour requêtes par owner_id, status, type, severity
• Déduplication : Contrainte unique sur (unique_key, owner_id) pour éviter les doublons
• Migrations : Liquibase avec up/down
• Types : Kysely types complets

Types d'insights prévus :

• QUOTE_STALE - Devis envoyés > N jours sans réponse
• INVOICE_OVERDUE - Factures en retard
• INVOICE_PARTIALLY_PAID - Factures partiellement payées
• SESSION_PREP_MISSING - Sessions proches sans checklist complète
• SESSION_POSTPROD_LAG - Sessions passées sans tâche post-prod
• SESSION_WITHOUT_DELIVERY - Sessions passées sans livraison
• BOOKING_UPCOMING - Réservations à venir
• CHECKLIST_INCOMPLETE - Checklists incomplètes pour sessions proches

A2. Génération "Rules First"

• Engine de règles : InsightRuleEngineService orchestrant toutes les règles
• Règles isolées : Chaque règle dans un fichier séparé, testable individuellement
• 0 appel OpenAI : Approche déterministe en MVP pour garantir la fiabilité
• Structure :
  • backend/src/insights/generation/rules/ - Toutes les règles
  • backend/src/insights/generation/insight-rule-engine.service.ts - Engine principal
  • backend/src/insights/generation/insights-generator.service.ts - Service de génération

Exemple de règle : QuoteStaleRule détecte les devis envoyés depuis plus de 7 jours sans réponse, calcule la sévérité (INFO/WARN/CRITICAL) selon le nombre de jours, génère un insight avec actions suggérées (voir devis, envoyer rappel).

A3. Job + Queue + Notifications

• Queue BullMQ : ai-insights avec processor dédié
• Scheduler quotidien : Génération automatique à 2h du matin pour tous les utilisateurs actifs
• Triggers event-driven : Génération immédiate sur événements (quote status changed, invoice overdue, session date approaching)
• Notifications :
  • Notification in-app via NotificationsService
  • WebSocket event insights:new pour updates temps réel
  • Push notification (si activé)
• Idempotence : Unique jobId pour éviter les exécutions multiples
• Retry/Backoff : Gestion des erreurs avec retry exponentiel

A4. API + UI

Backend :

• GET /api/insights - Liste paginée avec filtres (status, severity, type)
• GET /api/insights/unread-count - Compteur d'insights non lus
• POST /api/insights/:id/read - Marquer comme lu
• POST /api/insights/:id/archive - Archiver
• POST /api/insights/:id/feedback - Feedback utilisateur (UP/DOWN)
• POST /api/insights/run - Déclencher génération manuelle (debug/admin)

Frontend :

• Page Insights Center : /insights avec onglets (Open / Read / Archived)
• Composant InsightCard : Affichage avec titre, résumé, sévérité, actions suggérées
• Badge compteur : Dans le header avec nombre d'insights non lus
• Filtres : Par type, sévérité, statut
• Actions : Deep links vers entités, CTA pour actions suggérées
• WebSocket : Updates temps réel lors de création d'insights

Fonctionnalités :

• ✅ Déduplication automatique via unique_key
• ✅ TTL logique avec expires_at pour insights obsolètes
• ✅ Feedback utilisateur pour améliorer la pertinence
• ✅ Audit trail complet via ai_insight_events

Corrections Post-MVP (2026-01-27)

Problèmes résolus :

• ✅ Correction des noms de colonnes SQL (invoice_number → number)
• ✅ Correction des références aux alias dans les clauses having
• ✅ Sérialisation JSONB explicite pour éviter les erreurs de double sérialisation
• ✅ Gestion des paramètres de requête avec valeurs par défaut
• ✅ Configuration complète de la navigation et breadcrumbs

LOT B : Insights v2 - LLM-assisted summarization ✅ 100% COMPLÉTÉ

Statut : ✅ 100% complété (2026-01-27) - Service d'enrichissement LLM opérationnel

Objectif : Enrichir (pas remplacer) les insights générés par les règles avec :

• ✅ Titre plus naturel et contextuel
• ✅ Résumé court (1-2 lignes) généré par LLM
• ⚠️ Recommandations plus intelligentes basées sur le contexte (futur)
• ⚠️ Déduplication sémantique (détecter des insights similaires) (futur)

Fonctionnalités implémentées :

• ✅ Service InsightEnrichmentService pour enrichir les insights avec LLM
• ✅ Cache des résultats (7 jours) pour éviter les appels répétés
• ✅ Anonymisation des données avant envoi à OpenAI (IDs remplacés par [ID])
• ✅ Fallback gracieux sur les valeurs originales en cas d'erreur
• ✅ Gestion des timeouts avec withTimeout
• ✅ Intégration dans InsightsGeneratorService avec dégradation gracieuse
• ✅ Activation automatique basée sur la présence d'une clé OpenAI dans les métadonnées utilisateur
• ✅ Tests unitaires complets (11 tests, 100% passants)

Contraintes respectées :

• ✅ Ne remplace pas les règles déterministes (garantie de fiabilité)
• ✅ Utilise OpenAI uniquement pour l'enrichissement
• ✅ Cache des résultats LLM pour éviter les coûts répétés
• ✅ Fallback sur les valeurs générées par les règles si LLM échoue
• ✅ Appels OpenAI uniquement pour enrichissement, sur payload minimal + anonymisé
• ✅ Cache TTL (7 jours) + timeouts configurés

Activation :

• L'enrichissement LLM est automatiquement activé si l'utilisateur a une clé OpenAI configurée dans ses métadonnées
• Si la clé OpenAI n'est pas configurée, les valeurs originales (générées par les règles) sont utilisées
• Aucune configuration supplémentaire n'est nécessaire

Documentation : PLAN_AMELIORATIONS_CRM.md (sections Insights / lots livrés) - Section "LOT B"

LOT C : Support Multi-Tenant ✅ 100% COMPLÉTÉ

Statut : ✅ 100% complété (2026-01-27) - Support multi-tenant opérationnel

Objectif : Étendre le système d'insights pour supporter les organisations.

Fonctionnalités implémentées :

• ✅ Génération d'insights au niveau organisation (insights partagés entre membres)
• ✅ Filtrage par organisation dans l'API et l'UI
• ✅ Permissions : Vérification de l'appartenance à l'organisation avant accès
• ✅ Notifications : Tous les membres de l'organisation sont notifiés des nouveaux insights
• ✅ Déduplication : Insights personnels et organisation séparés avec clés uniques distinctes
• ✅ Backward compatibility : Par défaut, affichage des insights personnels uniquement
• ✅ Listener WebSocket insights:new dans le frontend pour mise à jour en temps réel

Comportement :

• Insights personnels : organization_id = null, visibles uniquement par le propriétaire
• Insights organisation : organization_id = "org-1", visibles par tous les membres de l'organisation
• Lors de la génération, les insights sont créés à la fois au niveau personnel ET au niveau de chaque organisation de l'utilisateur
• Le frontend permet de filtrer entre insights personnels et insights d'organisation via un sélecteur

Documentation : PLAN_AMELIORATIONS_CRM.md (sections Insights / lots livrés) - Section "LOT C"

LOT D : Personnalisation et Configuration ✅ 100% COMPLÉTÉ

Statut : ✅ 100% complété (2026-01-27) - Système de configuration complet et opérationnel

Objectif : Permettre aux utilisateurs de personnaliser les règles d'insights et les notifications.

Fonctionnalités implémentées :

• ✅ Configuration des seuils (ex: nombre de jours pour "devis en attente")
• ✅ Activation/désactivation de règles spécifiques
• ✅ Configuration des emails d'insights :
  • ✅ Activation/désactivation de l'envoi d'emails par utilisateur ou organisation
  • ✅ Configuration du contenu : types d'insights à inclure (par type, sévérité)
  • ✅ Configuration de l'heure de diffusion (ex: résumé quotidien à 8h, hebdomadaire le lundi)
  • ✅ Format : résumé quotidien/hebdomadaire ou notification immédiate pour insights critiques
  • ✅ Templates HTML avec statistiques et liens directs
• ✅ Support multi-tenant (settings personnels et organisation, avec fusion intelligente)
• ✅ Intégration dans le rule engine (seuils configurables appliqués automatiquement)
• ⚠️ Règles personnalisées (futur : permettre aux utilisateurs de créer leurs propres règles)

Détails emails d'insights :

• ✅ Niveau utilisateur : Configuration personnelle dans les paramètres utilisateur
• ✅ Niveau organisation : Configuration partagée pour tous les membres (gérée par OWNER/ADMIN)
• ✅ Types de diffusion :
  • ✅ Résumé quotidien : tous les insights du jour à une heure configurée
  • ✅ Résumé hebdomadaire : tous les insights de la semaine à un jour/heure configuré
  • ✅ Notification immédiate : uniquement pour insights critiques (optionnel)
• ✅ Filtres configurables :
  • ✅ Types d'insights (QUOTE_STALE, INVOICE_OVERDUE, etc.)
  • ✅ Niveaux de sévérité (INFO, WARN, CRITICAL)
  • ✅ Scope : personnels uniquement, organisation uniquement, ou les deux
• ✅ Template email : HTML avec liste des insights, liens directs vers chaque insight, statistiques

Implémentation :

• ✅ Table insight_settings avec JSONB pour flexibilité
• ✅ Repository et Service avec fusion intelligente des settings personnels/organisation
• ✅ API REST complète (5 endpoints)
• ✅ Service d'envoi d'emails avec templates HTML
• ✅ Scheduler automatique (cron horaire)
• ✅ Interface de configuration dans le frontend (dialog avec onglets)
• ✅ Intégration dans le rule engine pour appliquer les seuils configurables

Documentation : PLAN_AMELIORATIONS_CRM.md (sections Insights / lots livrés) - Section "LOT D"

LOT E : Analytics et Intelligence (Priorité Basse)

Objectif : Analyser l'utilisation des insights pour améliorer le système.

Fonctionnalités :

• Dashboard analytics : Quels insights sont les plus utiles (feedback UP/DOWN)
• Métriques : Taux de résolution, temps moyen de résolution
• Recommandations basées sur l'historique
• Détection de patterns : Identifier les situations récurrentes

Estimation : 2-3 semaines

LOT F : Nouvelles Règles d'Insights (Priorité Moyenne)

Objectif : Ajouter de nouvelles règles pour couvrir plus de cas d'usage.

Règles candidates :

• CONTACT_NO_ACTIVITY - Contacts sans interaction depuis X jours
• QUOTE_EXPIRING - Devis proches de leur date d'expiration
• INVOICE_PAYMENT_REMINDER - Rappels de paiement automatiques
• SESSION_FOLLOWUP_MISSING - Sessions terminées sans suivi client
• CONTRACT_EXPIRING - Contrats proches de leur expiration
• RECURRING_SESSION_MISSING - Sessions récurrentes non créées

Estimation : 1 semaine par règle

Améliorations UI/UX (Priorité Moyenne)

Fonctionnalités :

• Graphiques et visualisations : Tendances des insights sur le temps
• Vue calendrier : Afficher les insights sur un calendrier
• Groupement intelligent : Grouper les insights similaires
• Actions en lot : Marquer plusieurs insights comme lus/archivés en une fois
• Filtres sauvegardés : Permettre de sauvegarder des filtres personnalisés
• Export des insights : Exporter la liste des insights en CSV/Excel
• Listener WebSocket en temps réel : ✅ IMPLÉMENTÉ - Mise à jour automatique de l'UI lors de nouveaux insights

Amélioration globale : Settings contextuels avec Sidebar (Priorité Haute) - ✅ PARTIELLEMENT COMPLÉTÉ (2026-01-29)

Objectif : Décharger les pages de settings en permettant un accès direct aux configurations depuis les vues contextuelles.

Statut :

• ✅ InsightsPage : Sidebar de settings complétée (règles, emails, règles personnalisées)
• ✅ UserViewPage : Sidebar de settings complétée (profile, subscription, permissions)
• ❌ AdminPanelPage : Sidebar retirée (2026-01-29) - La page Admin est déjà une page de configuration, les tabs restent inline
• ✅ SessionViewPage : Sidebar de settings complétée (type de session, notifications) - 2026-01-29
• ✅ OrganizationViewPage : Sidebar de settings complétée (membres, ressources partagées) - 2026-01-29
• ✅ DashboardPage : Sidebar de settings complétée (widgets, rafraîchissement) - 2026-01-29

Fonctionnalités :

• ✅ Sidebar depuis la droite : Panneau latéral qui apparaît au clic sur le bouton Settings
• ✅ Fond foncé overlay : Overlay semi-transparent au-dessus du contenu principal pour mettre en évidence la sidebar
• ✅ Bouton Settings (icône roue crantée) dans header :
  • Bouton icon-only (size="icon") avec variant outline
  • Icône Settings de lucide-react (h-4 w-4)
  • Texte sr-only pour l'accessibilité
  • Positionné dans le header à droite, à côté des autres actions
  • Pattern uniforme : <Button size="icon" variant="outline" onClick={() => setSettingsSidebarOpen(true)}><Settings className="h-4 w-4" /><span className="sr-only">{t("common.settings")}</span></Button>
• ✅ Configuration par domaine : La sidebar affiche uniquement les settings pertinents au contexte
• ✅ Footer fixe avec actions : Boutons Cancel/Save fixés en bas de la sidebar

Exemples d'utilisation implémentés :

• ✅ Page Insights : Bouton Settings → Sidebar avec : activation/désactivation de règles, configuration des seuils, paramètres d'emails, règles personnalisées
• ✅ Page User : Bouton Settings → Sidebar avec : profile (display name, status), subscription (Stripe), permissions (overrides)
• ✅ Page Session : Bouton Settings → Sidebar avec : type de session (durée par défaut, validation automatique, paiement en ligne), notifications (à venir)
• ✅ Page Organisation : Bouton Settings → Sidebar avec : membres (gestion des rôles), ressources partagées (sessions, quotes, invoices, contracts, contacts)
• ✅ Page Dashboard : Bouton Settings → Sidebar avec : widgets (affichage/masquage des sections), rafraîchissement (à venir)

Avantages :

• ✅ Réduction du nombre de clics pour accéder aux configurations courantes
• ✅ Meilleure découverte des options de configuration
• ✅ Décharge des pages Settings principales (utilisateur et admin)
• ✅ Expérience plus contextuelle et intuitive
• ✅ Pattern uniforme avec ContextualSettingsSidebar réutilisable

Fichiers créés :

• frontend/src/pages/users/UserViewPage/components/UserSettingsSidebarContent.tsx
• frontend/src/pages/sessions/SessionViewPage/components/SessionSettingsSidebarContent.tsx
• frontend/src/pages/organizations/OrganizationViewPage/components/OrganizationSettingsSidebarContent.tsx
• frontend/src/pages/dashboard/DashboardPage/components/DashboardSettingsSidebarContent.tsx

✅ COMPLÉTÉ (2026-01-29) - Toutes les vues principales ont maintenant des sidebars de settings contextuels

Recommandation d'ordre d'implémentation :

1. ✅ LOT C (Multi-tenant) - ✅ COMPLÉTÉ (2026-01-27)
2. ✅ LOT B (LLM summarization) - ✅ COMPLÉTÉ (2026-01-27)
3. LOT D (Personnalisation et Configuration) - Permet aux utilisateurs d'adapter le système à leurs besoins, incluant la configuration des emails d'insights
4. Améliorations UI/UX - Améliore l'utilisation quotidienne, incluant les Settings contextuels avec Sidebar Hover (amélioration globale)
5. LOT F (Nouvelles règles) - Étend la couverture du système
6. LOT E (Analytics) - Nice-to-have pour optimiser le système

LOT C : Analytics Business (Futur)

• Table session_costs (temps, travel, subcontract)
• KPIs : marge brute / type / saison
• Prévisionnel trésorerie 3/6/12 mois

LOT D : Système d'Authentification Client 🚀 EN PLANIFICATION

Objectif : Créer un système d'authentification client complet permettant aux clients de voir tous leurs projets avec tous leurs photographes depuis une interface unifiée, avec messagerie, espace fichiers personnel et préférences sauvegardées.

Statut : 🚀 En planification - Architecture et plan d'implémentation détaillés disponibles

Vision :

Le système d'authentification client transforme l'accès client de token-only vers un système hybride :

• Accès Token (existant) : Accès rapide sans compte pour voir/signer un document spécifique
• Compte Client (nouveau) : Compte authentifié avec login/mot de passe pour une expérience complète

Contexte métier :

Pour le Client :

• Vue unifiée : Toutes ses séances avec tous les photographes au même endroit
• Historique persistant : Retrouver ses documents, messages, fichiers même après des années
• Communication directe : Messagerie avec chaque photographe
• Espace personnel : Stockage de fichiers (photos reçues, documents importants)
• Préférences : Notifications, thème, timezone personnalisés

Pour le Photographe :

• Clients engagés : Meilleure conversion et fidélisation
• Communication centralisée : Historique des échanges avec chaque client
• Professionnalisme : Image "studio premium" avec portail client dédié
• Réduction des emails : Moins de "Où en est-on ?" grâce au portail

Architecture :

• ClientAccount est global (un email = un compte, système entier)
• Contact reste local au photographe (owner_id)
• La table client_account_contacts fait la liaison

Tables DB :

• client_accounts : Comptes clients globaux (email unique, password_hash, status, etc.)
• client_account_contacts : Liaison ClientAccount ↔ Contact
• client_messages : Messages client ↔ photographe
• client_files : Espace fichiers personnel du client
• client_preferences : Préférences (notifications, thème, timezone)
• client_password_reset_tokens : Tokens de reset password
• client_refresh_tokens : Refresh tokens JWT

Modules Backend :

• client-auth : Register, login, logout, forgot-password, reset-password, refresh
• client-accounts : CRUD profil, liaison contacts, séances, documents
• client-messages : Messagerie client ↔ photographe
• client-files : Upload/download fichiers personnels

Endpoints principaux :

• Auth : /api/client-auth/register, login, logout, forgot-password, reset-password, refresh
• Compte : /api/client-accounts/me, /me/photographers, /me/sessions, /me/documents
• Messages : /api/client-messages/conversations, /conversations/:contactId
• Fichiers : /api/client-files/, /upload, /:fileId
• Photographe : /api/contacts/:id/invite-to-create-account, /:id/messages

Frontend :

• Layout : ClientPortalLayout avec header/sidebar dédiés
• Pages : Login, Register, Dashboard, Sessions, Documents, Messages, Files, Settings
• Hooks : useClientAuth, useClientSessions, useClientMessages, useClientFiles

Sécurité :

• JWT séparés : Tokens client (type: "client") distincts des tokens user
• Guards séparés : ClientAuthGuard vs AuthGuard
• Rate limiting : Login (5/15min), Register (3/h/IP), Reset (3/h/email)
• Liaison sécurisée : Vérification email match avant liaison Contact ↔ ClientAccount

Compatibilité :

• ✅ Tokens existants : L'accès token continue de fonctionner indépendamment
• ✅ Pas de migration forcée : Les Contacts existants restent tels quels
• ✅ Liaison progressive : Le photographe peut inviter ses clients quand il le souhaite

Phases d'implémentation :

1. Phase 1 - MVP Auth (2-3 sem) : Register, login, logout, forgot-password, reset-password
2. Phase 2 - Expérience (2 sem) : Vue séances multi-photographes, documents, timeline
3. Phase 3 - Messagerie (1-2 sem) : Communication directe client-photographe
4. Phase 4 - Fichiers (1-2 sem) : Espace personnel, préférences
5. Phase 5 - Photographe (1 sem) : Invitation clients, indicateur compte actif

Documentation complète : docs/CLIENT_AUTHENTICATION_PLAN.md

👥 Gestion des Contacts

Suggestions basées sur l'analyse

Séquence produit validée (2026-02-09)

• ✅ Backlog noté : relances automatiques devis/factures impayés (email + timeline + opt-out).

• 🚧 Lot prioritaire suivant (en cours) : timeline unifiée contact/session (historique centralisé de toutes les interactions).

  • ✅ Filtres sur la timeline contact (recherche + type d’événement).
  • ✅ Réutilisation en vue session, limitée à la session active.
  • ✅ Enrichissement sessionId sur les événements timeline backend (quotes/invoices/emails) pour un filtrage cohérent.
  • ✅ Test e2e de présence/interaction des filtres timeline.

• 🎯 Lot suivant : renforcement export/journal fiscal pour contrôle (archive ZIP, manifest/hash, export audit).

• 🚧 Après ces deux lots (en cours) : revue de la brique workflows (UX + moteur + exploitation).

  • 🎯 Lot 0 à exécuter en premier: nettoyage de l'existant (audit, repair safe, classification template/custom/legacy).
  • 🎯 Flows par défaut en base: templates versionnés + seed idempotent.
  • Plan détaillé: WORKFLOWS_REVIEW_PLAN.md

• ❌ Segmentation avancée - Créer des segments de contacts avec critères complexes

  • Non implémenté : Pas de système de segmentation de contacts

• ❌ Scoring de contacts - Système de scoring pour identifier les contacts les plus prometteurs

  • Non implémenté : Pas de système de scoring automatique des contacts

• ⚠️ Historique d'interactions - Timeline complète de toutes les interactions avec un contact

  • Partiellement implémenté : Système de tracking d'emails (ouvertures, clics) via email_tracking table
  • Fonctionnalités : Tracking des emails envoyés (OPEN, LINK_CLICK), association avec contacts/quotes/invoices
  • Manquant : Timeline complète centralisée (emails, sessions, appels, notes), vue dédiée dans l'interface contact

• ❌ Relations entre contacts - Gérer les relations entre contacts (famille, amis, collègues)

  • Non implémenté : Pas de système de gestion des relations entre contacts

• ❌ Import depuis réseaux sociaux - Import automatique depuis Instagram, Facebook, etc.

  • Non implémenté : Pas d'intégration avec les réseaux sociaux pour l'import de contacts

• ⚠️ Détection de doublons améliorée - Algorithme plus intelligent pour détecter les doublons

  • Partiellement implémenté : Détection automatique de contacts similaires lors de la création via l'agent IA (ConflictDetectionHelper.findSimilarContacts)
  • Fonctionnalités : Recherche par nom (prénom, nom, combinaisons), filtrage des contacts similaires, détection de conflits avant création
  • Limitations : Détection uniquement lors de la création via agent IA, pas d'interface dédiée pour détecter les doublons existants

• ❌ Fusion de contacts - Outil pour fusionner des contacts en doublon

  • Non implémenté : Pas d'outil de fusion de contacts (seulement détection de doublons)

📅 Gestion des Sessions & Réservations

Fonctionnalités implémentées

• ✅ Gestion de disponibilité - Système de gestion des créneaux disponibles/bloqués avec support des créneaux récurrents
  • Création de créneaux uniques ou récurrents (hebdomadaire, quotidien)
  • Support des jours spécifiques via byDay (MO, TU, WE, etc.)
  • Date de fin de récurrence optionnelle
  • Expansion automatique des créneaux récurrents en occurrences individuelles
• ✅ Synchronisation calendrier - Sync bidirectionnelle avec Google Calendar (toutes les 5 minutes) avec résolution de conflits intelligente
  • Synchronisation automatique des événements
  • Gestion des conflits et résolution intelligente
  • Support des événements récurrents
• ✅ Système de réservation publique - Interface publique pour permettre aux clients de réserver des créneaux
  • ✅ Mise en avant sur la landing page - Section dédiée ajoutée avec présentation des avantages (2026-01-XX)
  • Interface publique : Page de réservation accessible via URL publique (/booking/:userId)
  • Calendrier interactif : Affichage des créneaux disponibles par mois avec navigation
  • Formulaire de réservation : Nom, email, téléphone (obligatoire), type de rendez-vous (téléphone/vidéo), notes
  • Création d'événements Google Calendar : Les réservations créent directement des événements (pas de sessions)
  • Préfixe [MEETING] : Identification claire des rendez-vous dans le calendrier
  • Filtrage intelligent : Exclusion automatique des créneaux déjà réservés
  • Cache temporaire : Gestion du délai de propagation Google Calendar (5 minutes)
  • Tokens d'annulation : Tokens sécurisés et encryptés pour annuler les réservations
  • Emails automatiques : Confirmation au client et notification au User
  • Notifications in-app et push : Notifications en temps réel pour le User
  • Interface de gestion : Panel de gestion des bookings avec statistiques (total, upcoming, past)
  • Édition et suppression : Modification et suppression des bookings depuis l'interface User
  • Documentation OpenAPI : Documentation complète des endpoints publics
  • Tests unitaires : Couverture >80% pour les services critiques
  • Statut : ✅ Production-ready (56% des améliorations planifiées complétées)

Suggestions basées sur l'analyse

• ✅ Calendrier visuel amélioré - Vue calendrier avec drag & drop, vue mensuelle/semaine/jour
  • Complété : Vue timeline pour la semaine et le jour avec grille horaire (0h-23h), positionnement précis des événements/sessions, affichage des créneaux de disponibilité, visualisation des chevauchements, légende interactive, filtres visuels, vue agenda/liste, drag & drop dans toutes les vues (Month, Week, Day)
  • Documentation : CALENDAR_SYNC_ARCHITECTURE.md (calendrier), APP_OVERVIEW.md
• ✅ Planification récurrente - Sessions récurrentes (hebdomadaire, mensuelle, quotidienne)
  • Statut : ✅ Complété
  • Description : Permettre de créer des sessions récurrentes avec des patterns de récurrence similaires aux créneaux de disponibilité
  • Fonctionnalités implémentées :
    • ✅ Patterns de récurrence : Quotidien, hebdomadaire (avec jours spécifiques via byDay), mensuel, annuel avec intervalle personnalisable
    • ✅ Date de fin : Date de fin de récurrence optionnelle
    • ✅ Gestion des occurrences :
      • ✅ Génération automatique des occurrences individuelles lors de la création d'une session récurrente (6 mois à l'avance)
      • ✅ Génération dynamique des occurrences dans le calendrier pour affichage au-delà de la période générée
      • ✅ Possibilité de modifier/supprimer une occurrence spécifique sans affecter les autres
      • ✅ Possibilité de modifier toutes les occurrences d'une série
      • ✅ Visualisation de la série récurrente dans le calendrier avec indicateur visuel (icône Repeat, couleur violette)
    • ✅ Synchronisation Google Calendar :
      • ✅ Création d'événements récurrents dans Google Calendar avec recurrence (RRULE)
      • ✅ Gestion des exceptions pour modifications d'occurrences individuelles (updateRecurringSessionOccurrence)
      • ✅ Gestion des exceptions pour suppressions d'occurrences individuelles (deleteRecurringSessionOccurrence)
    • ✅ Interface utilisateur :
      • ✅ Option "Récurrent" lors de la création/modification de session (RecurrenceSelector)
      • ✅ Sélecteur de fréquence (quotidien, hebdomadaire, mensuel, annuel)
      • ✅ Sélection des jours de la semaine pour récurrence hebdomadaire (checkboxes)
      • ✅ Intervalle personnalisable (toutes les X semaines/mois/etc.)
      • ✅ Date de fin de récurrence
      • ✅ Indicateur visuel dans le calendrier pour les sessions récurrentes
      • ✅ Dialog de confirmation pour actions sur occurrences individuelles vs série complète (RecurringSessionActionDialog)
  • Architecture technique implémentée :
    • ✅ Base de données : Migration Liquibase ajoutant is_recurring, recurrence_pattern (JSON), recurrence_end_date, parent_session_id à la table sessions
    • ✅ Backend :
      • ✅ Helper RecurringSessionExpander pour générer les occurrences (similaire à RecurringSlotExpander)
      • ✅ Modification de SessionsService pour gérer la création/mise à jour/suppression de sessions récurrentes
      • ✅ Méthode updateSingleSession pour encapsuler la logique de mise à jour d'une session
      • ✅ Support de updateAllOccurrences dans le endpoint de mise à jour
      • ✅ Support de deleteAllOccurrences dans le endpoint de suppression
      • ✅ GoogleCalendarService.createRecurringSessionEvent pour créer des événements récurrents avec RRULE
      • ✅ GoogleCalendarService.updateRecurringSessionOccurrence pour créer des exceptions lors de modifications individuelles
      • ✅ GoogleCalendarService.deleteRecurringSessionOccurrence pour créer des exceptions lors de suppressions individuelles
    • ✅ Frontend :
      • ✅ Composant RecurrenceSelector dans le formulaire de création/modification de session
      • ✅ Composant RecurringSessionActionDialog pour gérer les actions sur occurrences vs série
      • ✅ Helper expandRecurringSessions pour générer dynamiquement les occurrences dans le calendrier
      • ✅ Modification de useCalendarData pour fusionner occurrences existantes et générées dynamiquement
      • ✅ Affichage visuel des sessions récurrentes dans DraggableSession et CalendarLegend
  • Cas d'usage :
    • Sessions de coaching hebdomadaires (tous les lundis à 10h)
    • Séances photo mensuelles (premier samedi de chaque mois)
    • Sessions de suivi quotidiennes pendant une période
    • Événements annuels récurrents
  • Fichiers principaux :
    • backend/src/sessions/recurring-session-expander.helper.ts
    • backend/src/google-calendar/google-calendar.service.ts (méthodes récurrentes)
    • backend/src/sessions/sessions.service.ts (logique de gestion)
    • frontend/src/pages/sessions/SessionFormPage/components/RecurrenceSelector.tsx
    • frontend/src/pages/calendar/CalendarPage/helpers/expandRecurringSessions.ts
    • frontend/src/pages/calendar/CalendarPage/hooks/useCalendarData.ts
  • Améliorations implémentées récemment :
    • ✅ Prévisualisation des occurrences : Afficher une liste de prévisualisation des occurrences qui seront générées dans le formulaire de création
      • Statut : ✅ Complété
      • Description : Composant RecurrencePreview intégré dans le formulaire de création/modification de session, affichant jusqu'à 20 occurrences avec mise à jour en temps réel lors des changements de pattern ou de dates
      • Fichiers : frontend/src/pages/sessions/SessionFormPage/components/RecurrencePreview.tsx
    • ✅ Modification de recurrence_end_date : Supprimer automatiquement les occurrences au-delà de la nouvelle date de fin
      • Statut : ✅ Complété
      • Description : Lors de la modification de la date de fin de récurrence d'une session parent récurrente, suppression automatique des occurrences futures au-delà de la nouvelle date, avec nettoyage des événements Google Calendar et fichiers associés
      • Fichiers : backend/src/sessions/sessions.service.ts (méthode updateSingleSession)
    • ✅ Modification du pattern de récurrence : Régénérer les occurrences si le pattern de récurrence est modifié
      • Statut : ✅ Complété
      • Description : Détection automatique des changements de pattern de récurrence, suppression de toutes les occurrences existantes (et leurs événements Google Calendar, fichiers, etc.), régénération des occurrences avec le nouveau pattern, copie automatique des tags/contacts/providers aux nouvelles occurrences, mise à jour de l'événement Google Calendar récurrent
      • Fichiers : backend/src/sessions/sessions.service.ts (méthode regenerateOccurrencesForParent)
    • ✅ Génération périodique des occurrences : Job cron pour générer automatiquement les occurrences futures dans la DB (au-delà de 6 mois) pour améliorer les performances de recherche/statistiques
      • Statut : ✅ Complété
      • Description : Scheduler RecurringSessionsScheduler exécuté quotidiennement à 2h du matin, générant automatiquement les occurrences jusqu'à 12 mois à l'avance pour toutes les sessions récurrentes actives. Génération uniquement si la dernière occurrence est dans moins de 6 mois. Copie automatique des tags/contacts/providers aux nouvelles occurrences.
      • Fichiers : backend/src/sessions/recurring-sessions.scheduler.ts, backend/src/sessions/sessions.service.ts (méthode generateFutureOccurrences)
  • Améliorations complétées récemment :
    • ✅ Synchronisation bidirectionnelle depuis Google Calendar : Synchronisation complète des modifications d'événements récurrents depuis Google Calendar vers le CRM
      • Statut : ✅ Complété
      • Description : Le scheduler de synchronisation Google Calendar détecte et synchronise les modifications d'événements récurrents, y compris les exceptions et suppressions
      • Fonctionnalités implémentées :
        • ✅ Détection des occurrences modifiées dans Google Calendar (exceptions)
        • ✅ Synchronisation des modifications vers les occurrences CRM correspondantes
        • ✅ Création automatique d'occurrences manquantes si modifiées dans Google Calendar
        • ✅ Détection et suppression des occurrences supprimées dans Google Calendar
        • ✅ Gestion des conflits pour éviter d'écraser les modifications récentes du CRM
        • ✅ Support des événements récurrents avec gestion des EXDATE (occurrences supprimées)
      • Fichiers : backend/src/google-calendar/google-calendar-sync.scheduler.ts (méthodes syncRecurringException et syncRecurringParentDeletedOccurrences)
• ✅ Checklist de session - Checklists personnalisables par type de session
  • Statut : ✅ Complètement implémenté (Backend + Frontend)
  • Description : Système complet de gestion des checklists personnalisables par type de session pour s'assurer que toutes les étapes sont complétées
  • Backend : ✅ Complété
    • Service complet avec CRUD pour templates et items (SessionChecklistsService)
    • Endpoints API fonctionnels (/session-checklists/*)
    • Tables de base de données créées
    • Utilisée dans session-roadmap.service.ts pour générer les roadmaps avec checklist
  • Frontend : ✅ Complété
    • Onglet "Checklist" dans la vue de session (premier onglet)
    • Affichage et gestion des items de checklist (groupés par statut)
    • Application de templates à une session
    • Modification du statut des items (checkbox)
    • Création/modification/suppression d'items manuels
    • Indicateurs visuels pour les items en retard
  • Fonctionnalités implémentées :
    • ✅ Templates de checklists par type de session (mariage, séance photo, événement, etc.)
    • ✅ Checklist personnalisable par utilisateur
    • ✅ Items de checklist avec statut (PENDING, IN_PROGRESS, COMPLETED, SKIPPED)
    • ✅ Assignation d'items à des membres de l'équipe
    • ✅ Dates d'échéance pour les items
    • ✅ Application de templates à des sessions
    • ✅ Interface utilisateur complète avec dialogs pour créer/modifier
    • ✅ Groupement automatique des items par statut
    • ✅ Badges de statut avec support dans StatusBadge component
  • Fichiers backend :
    • ✅ backend/src/session-checklists/session-checklists.service.ts
    • ✅ backend/src/session-checklists/session-checklists.controller.ts
    • ✅ backend/src/session-checklists/session-checklists.module.ts
    • ✅ backend/src/session-checklists/dto/*.ts
  • Fichiers frontend :
    • ✅ frontend/src/client/session-checklists/useSessionChecklists.ts (hooks API React Query)
    • ✅ frontend/src/pages/sessions/SessionViewPage/components/ChecklistTab.tsx (onglet checklist)
    • ✅ Intégration dans SessionTabs.tsx et SessionViewPage.tsx
    • ✅ Support du type "checklist" dans StatusBadge.tsx
    • ✅ Traductions françaises complètes
  • Accès : /sessions/$id → Onglet "Checklist" (premier onglet)
  • Date de complétion : 2025-01-XX
• Rappels automatiques - Rappels par email/SMS avant les sessions
  • Description : Système de rappels automatiques pour notifier les utilisateurs avant les sessions
  • Fonctionnalités proposées :
    • Configuration des délais de rappel (24h avant, 1h avant, etc.)
    • Rappels par email et/ou SMS
    • Rappels personnalisables par type de session
    • Rappels pour les participants (contacts) de la session
    • Template de messages personnalisables
    • Intégration avec le système de notifications existant
  • Priorité : Moyenne
  • Estimation : 3-4 jours de développement
• ✅ Vue calendrier améliorée - Améliorations supplémentaires de l'interface calendrier
  • Statut : ✅ Complété
  • Fonctionnalités implémentées :
    • ✅ Vue multi-calendrier : Affichage parallèle des sessions, disponibilités et événements Google Calendar dans toutes les vues
    • ✅ Recherche dans le calendrier : Recherche rapide de sessions/événements directement depuis la vue calendrier avec navigation vers la date
    • ✅ Filtres avancés : Filtres par statut de session, type de session, contact, tags avec interface dédiée
    • ✅ Vue liste améliorée : Vue agenda/liste avec tri chronologique et filtres, groupement par jour
    • ✅ Export calendrier : Export au format iCal/ICS pour import dans d'autres calendriers (Google Calendar, Outlook, etc.)
    • ✅ Impression : Impression du calendrier avec vue formatée optimisée pour l'impression (pleine page, sans interface)
    • ✅ Vue année : Vue annuelle pour planification à long terme avec 12 mois affichés
    • ✅ Indicateurs visuels : Badges pour sessions en retard, sessions sans contact, sessions sans devis/facture
    • ✅ Optimisation des performances : Utilisation de placeholderData et staleTime pour éviter les rechargements inutiles lors du changement de vue
    • ✅ Refactoring : Refactorisation de CalendarPage.tsx en hooks et composants plus petits pour améliorer la maintenabilité
  • Fichiers principaux :
    • frontend/src/pages/calendar/CalendarPage/CalendarPage.tsx (refactorisé)
    • frontend/src/pages/calendar/CalendarPage/components/CalendarSearch.tsx
    • frontend/src/pages/calendar/CalendarPage/components/AdvancedCalendarFilters.tsx
    • frontend/src/pages/calendar/CalendarPage/components/CalendarActions.tsx (export iCal)
    • frontend/src/pages/calendar/CalendarPage/components/PrintCalendarView.tsx
    • frontend/src/pages/calendar/CalendarPage/components/YearView.tsx
    • frontend/src/pages/calendar/CalendarPage/hooks/useCalendarState.ts
    • frontend/src/pages/calendar/CalendarPage/hooks/useCalendarHandlers.ts
    • frontend/src/pages/calendar/CalendarPage/components/CalendarContent.tsx
    • frontend/src/pages/calendar/CalendarPage/components/CalendarViewRenderer.tsx
    • frontend/src/pages/calendar/CalendarPage/components/CalendarSidebar.tsx
  • Documentation : CALENDAR_SYNC_ARCHITECTURE.md (calendrier), APP_OVERVIEW.md
• ✅ Gestion des conflits - Verrouillage Redis pour éviter les doubles réservations simultanées
  • Statut : ✅ COMPLÉTÉ - Production-ready
  • Implémentation :
    • Verrouillage distribué avec Redis (CacheService.acquireLock() / releaseLock())
    • Utilisation de Redis SET NX EX pour un verrouillage atomique
    • Verrou avec expiration automatique (60 secondes) pour éviter les verrous orphelins
    • Clé de verrou unique : booking:lock:{userId}:{startDate}:{endDate}
    • Nettoyage automatique des verrous dans le bloc finally
    • Message d'erreur clair si le créneau est déjà pris
  • Fichiers : backend/src/cache/cache.service.ts, backend/src/booking/booking.controller.ts
  • Tests : Tests unitaires complets dans backend/src/__tests__/cache/cache.service.spec.ts et tests d'intégration dans backend/src/__tests__/booking/booking-conflict-integration.spec.ts
• ✅ Statistiques avancées - Graphiques, export, filtres avancés pour les bookings
  • Statut : ✅ COMPLÉTÉ - Production-ready
  • Implémentation :
    • Dashboard avec statistiques avancées (réservations par jour, semaine, mois)
    • Taux d'annulation calculé à partir des tokens d'annulation
    • Créneaux les plus populaires (par heure de la journée)
    • Heures de pointe (top 3 heures)
    • Export des données (CSV, Excel, JSON) avec upload sur R2 et signed URLs
    • Filtrage par période (timeMin, timeMax) avec presets (semaine, mois, trimestre, année, tout)
    • Graphiques Recharts avec visualisations interactives
  • Fichiers : backend/src/booking/bookings.controller.ts (endpoints /analytics et /export), frontend/src/pages/booking/BookingAnalyticsPage/
  • Note : Filtrage actuellement limité à la plage de dates. Les filtres avancés par statut, contact, etc. peuvent être ajoutés ultérieurement si nécessaire.
• ✅ Personnalisation - Personnalisation des couleurs et du thème de la page de réservation
  • Statut : ✅ COMPLÉTÉ - Production-ready
  • Implémentation :
    • Personnalisation des couleurs (couleur principale personnalisable via hex)
    • Message d'accueil personnalisé (remplace le message par défaut)
    • Messages de confirmation personnalisés
    • Application de la couleur principale via CSS variables
    • Interface d'administration complète (BookingSettingsPage) pour gérer les settings
    • Validation des couleurs (format hex) et des longueurs de messages (max 2000 caractères)
  • Fichiers : backend/src/booking/booking-settings.service.ts, frontend/src/pages/settings/BookingSettingsPage/, infra/liquibase/changes/0107_create_booking_settings/
• ✅ Gestion des timezones - Détection automatique et conversion des timezones
  • Statut : ✅ COMPLÉTÉ - Production-ready
  • Implémentation :
    • Détection automatique du timezone du client via Intl.DateTimeFormat().resolvedOptions().timeZone
    • Affichage des heures dans le timezone local du client
    • Indication du timezone utilisé (abréviation : CET, EST, PST, etc.)
    • Conversion automatique lors de l'affichage dans tous les composants (calendrier, formulaire, confirmation)
    • Dates stockées en UTC dans la base de données (comportement standard)
  • Fichiers : frontend/src/utils/timezone.utils.ts, frontend/src/pages/booking/BookingPage/components/BookingCalendar.tsx, frontend/src/pages/booking/BookingPage/components/BookingConfirmation.tsx

💰 Gestion Financière

Fonctionnalités implémentées

• ✅ Intégration Stripe complète - Système complet de gestion des paiements et abonnements
  • ✅ Gestion des abonnements : Création, annulation et reprise d'abonnements (FREE, BASIC, PRO)
    • Plans configurables via l'interface admin
    • Support mensuel et annuel
    • Gestion des cycles de facturation
  • ✅ Paiement des factures : Paiement sécurisé des factures via Stripe Payment Intents
    • Interface utilisateur avec Stripe Elements
    • Confirmation de paiement en temps réel
    • Mise à jour automatique du statut des factures via webhooks
  • ✅ Collecte de méthodes de paiement : SetupIntent pour collecter les méthodes de paiement
    • Endpoint POST /api/stripe/setup-intent pour créer un SetupIntent
    • Intégration avec Stripe Elements pour la collecte sécurisée
    • Support des cartes bancaires
  • ✅ Attachement de méthodes de paiement : Attachement automatique au client Stripe
    • Endpoint POST /api/stripe/payment-methods/:paymentMethodId/attach
    • Définition automatique comme méthode de paiement par défaut
    • Utilisé pour les abonnements récurrents
  • ✅ Webhooks Stripe : Synchronisation automatique des événements
    • customer.subscription.created/updated/deleted
    • payment_intent.succeeded/failed
    • Mise à jour automatique des statuts dans la base de données
  • ✅ Historique des paiements : Suivi complet de tous les paiements
    • Endpoint GET /api/stripe/payments/history
    • Association avec les factures
    • Traçabilité complète des transactions
  • ✅ Interface utilisateur : Formulaires et gestion complète
    • Page de sélection des plans d'abonnement
    • Formulaires de paiement sécurisés avec Stripe Elements
    • Gestion des abonnements dans le profil utilisateur
    • Onboarding avec collecte de méthode de paiement
  • Documentation : backend/src/stripe/README.md

💰 Facturation Robuste et Conforme

✅ Système de Facturation Robuste - 100% COMPLÉTÉ (2024-12-19)

• ✅ Numérotation séquentielle atomique - Format YYYY-000001 pour factures, AV-YYYY-000001 pour avoirs
  • Protection contre les doublons même en concurrence
  • Transaction atomique avec SELECT FOR UPDATE
  • Service : InvoiceNumberingService
• ✅ Immutabilité vérifiable - Factures immutables dès émission
  • Snapshots complets (vendeur, acheteur, totaux, TVA, conditions paiement)
  • PDF avec hash SHA-256 stocké à l'émission
  • Guards API et service pour bloquer modifications
  • Service : InvoiceIssuanceService
• ✅ Conformité France/UE - Validation complète des mentions obligatoires
  • Validation SIREN/SIRET (warnings)
  • Validation totaux et calculs
  • Endpoint /invoices/:id/compliance pour vérification
  • Service : InvoiceComplianceService avec règles détaillées
• ✅ Calculs précis - Utilisation de decimal.js via wrapper Money
  • Arrondi bancaire au centime
  • Support multiples taux de TVA
  • Calculs synchronisés frontend/backend
  • Service : InvoiceTotalsService
• ✅ Avoirs (Credit Notes) - Service complet de gestion des avoirs
  • Génération PDF avec hash
  • Impact automatique sur solde dû
  • Numérotation séquentielle dédiée
  • Service : CreditNotesService
• ✅ Paiements unifiés - Service unifié pour tous les paiements
  • Support Stripe, PayPal, Manual
  • Paiements partiels avec réconciliation automatique
  • Calcul automatique balance_due
  • Statuts : PARTIALLY_PAID, PAID, OVERDUE
  • Services : PaymentsService, PaymentReconciliationService
• ✅ Export comptable - Export CSV avec plan comptable français
  • Mapping comptes personnalisable par utilisateur
  • Export factures, paiements et avoirs
  • Format compatible logiciels comptables
  • Service : AccountingExportService, AccountMappingService
• ✅ Audit trail complet - Traçabilité de tous les événements
  • Événements : émission, paiements, avoirs, génération PDF
  • Métadonnées enrichies pour chaque événement
  • Service : BillingAuditService
• ✅ Endpoints admin - Administration de la facturation
  • POST /admin/invoices/:id/regenerate-pdf - Régénérer PDF
  • GET /admin/invoices/:id/verify - Vérifier intégrité PDF
  • Controller : BillingAdminController
• ✅ Préparation E-invoicing - Structure prête pour facturation électronique
  • Champs préparatoires en base de données
  • Types TypeScript complets
  • Statuts : NONE, PENDING, SUBMITTED, ACCEPTED, REJECTED, CANCELLED
• ✅ Tests complets - 14 fichiers de tests
  • 12 tests unitaires couvrant tous les services (tous les mocks corrigés)
  • 2 tests d'intégration (concurrence, réconciliation)
  • Tests validation, edge cases, erreurs
  • Dernière mise à jour : Correction complète des mocks Kysely dans credit-notes.service.spec.ts (7/7 tests passent)
  • Statistiques : 425 tests passent, 1 test ignoré (test complexe de réconciliation)
• Documentation complète :
  • docs/BILLING_LIFECYCLE.md - Cycle de vie des documents
  • docs/BILLING_INVENTORY.md - Inventaire du système actuel
  • docs/BILLING_VALIDATION.md - Guide de validation
  • docs/BILLING_CALCULATIONS.md - Règles de calcul détaillées
  • docs/BILLING.md - Vue d'ensemble facturation
  • BILLING.md — facturation et conformité

Requalification stratégique 2026

• Le socle interne ci-dessus reste un actif produit important: workflow devis/factures, montants, audit, portail client, export et traçabilité métier.
• En revanche, la priorité active n’est plus une certification ou une extension interne exhaustive de la conformité fiscale.
• La priorité devient l’intégration d’un provider externe de facturation, avec Pennylane comme cible initiale.
• La préparation e-invoicing existante est conservée comme base de données et de statuts, mais son rôle devient un relais d’information vers et depuis le provider externe, pas une réinternalisation complète de la logique réglementaire.

Suggestions d'amélioration (futures)

• Billing externalisé / Pennylane (priorité active) - Création de facture externe depuis devis accepté, récupération PDF, statuts externes et synchronisation initiale
• Automatisation de facturation - Génération automatique de factures récurrentes côté logique métier si le provider le permet
• Intégration bancaire - Import automatique des transactions bancaires
• Prévisions financières - Prévisions de revenus basées sur les devis en attente
• Gestion des acomptes - Gestion avancée des acomptes et soldes
• Multi-devises amélioré - Conversion automatique et suivi multi-devises
• Rapports fiscaux - Génération automatique de rapports pour la comptabilité
• E-invoicing complet - Relais des statuts et métadonnées de facturation électronique sans refaire en interne la couche réglementaire complète

📧 Communication & Notifications

Relances / Email Sequences — RETIRÉ

Cette fonctionnalité a été retirée du codebase. Les tables DB associées ont été supprimées via la migration 0164_drop_email_sequences. Le système d'invitation et de communication client passe désormais par le Portail Client (client-auth, client-accounts).

Portail Client — ✅ Livré

• ✅ Auth client complète (register/login/refresh/forgot/reset/verify)
• ✅ Expérience client : séances, documents, timeline, messagerie
• ✅ Messagerie portail alignée avec l’app : fichiers, previews signées, modal image plein écran, chargements unifiés
• ✅ Harmonisation UI portail ↔ accès client : header aligné, heading “Votre espace sécurisé” + “Bienvenue, {{name}}” sur les pages d’accueil
• ✅ Galeries côté portail : route /portal/galleries, navigation + compteur dashboard, galerie visible dans la vue séance
• ✅ Paiement par virement côté portail : bloc visible dans /portal/documents (onglet factures + section factures) et dans la vue séance, même sans IBAN
• ✅ Fichiers & préférences : upload/download, notifications, thème, timezone
• ✅ Invitations photographe : création, statut, validation token, re‑invitation
• ✅ Routes : /portal/login, /portal/dashboard, /portal/sessions, /portal/documents, /portal/messages, /portal/files, /portal/settings, /portal/galleries

📧 Communication & Notifications (suite)

Fonctionnalités implémentées récemment

• ✅ Surveillance d'inactivité des formulaires publics - Alertes automatiques lorsque les formulaires n'enregistrent plus de soumissions.
  • Backend : champs monitor_inactivity, inactivity_threshold_days, last_submission_at, scheduler quotidien (LeadFormsScheduler) et service (LeadFormsMonitoringService) envoyant les emails d'alerte et historisant last_inactivity_alert_sent_at.
  • API : endpoint POST /lead-forms/{id}/acknowledge-inactivity + OpenAPI mis à jour, DTO (CreateLeadFormDto, UpdateLeadFormDto) enrichis, service de soumissions qui réinitialise les compteurs lors de chaque nouvelle soumission.
  • Frontend : configuration dans LeadFormEditPage (section "Surveillance d'inactivité"), calcul dans useDashboard et affichage dans RequestsSection avec bouton "Marquer comme vérifié".
  • 🔜 Suivi recommandé : monitorer visuellement les formulaires sur d'autres écrans (liste complète des formulaires, notifications in-app), et exposer l'historique des alertes pour auditer les périodes sans trafic.

Suggestions basées sur l'analyse

• ❌ Templates d'email personnalisés - Éditeur visuel pour créer des templates d'email
  • Non implémenté : Pas d'éditeur visuel pour les templates d'email (templates existants mais pas d'éditeur visuel)
• ❌ Campagnes email / Email Sequences - Retiré du codebase (migration 0164)
• ⚠️ SMS integration - Envoi de SMS pour les rappels et notifications
  • Vague A (2026-07) : UI SMS hidden ; provider production = future backlog (BE sms-templates kept).
  • Partiellement implémenté :
    • Tâches AUTOMATIC_SMS exécutées par le moteur workflow
    • Templates SMS utilisateur + templates système par défaut
    • Variables SMS (placeholders) insérables dans l'éditeur et rendues à l'exécution
    • API de gestion des templates SMS (/api/sms-templates) — settings UI hidden
  • Manquant / deferred :
    • Provider SMS de production (Twilio/Vonage actuellement non finalisés, mode log/dev)
    • Monitoring métier dédié des délivrabilités SMS (au-delà des logs d'exécution workflow)
    • Re-surface UI when provider is ready
• Notifications personnalisables - Permettre aux utilisateurs de configurer leurs préférences de notification
  • Non implémenté : Pas de système de préférences de notifications par type
• Notifications groupées - Regrouper les notifications similaires
  • Non implémenté : Les notifications sont affichées individuellement
• ⚠️ Historique de communication - Vue centralisée de toutes les communications avec un contact
  • Partiellement implémenté : Tracking des emails (voir "Historique d'interactions" ci-dessus)
  • Manquant : Vue centralisée dans l'interface contact, intégration de tous les canaux (email, SMS, appels)

Notifications Push

• ✅ Notifications push navigateur - Implémentation des notifications push via Service Worker
• ✅ Permissions et abonnements - Gestion des permissions et des abonnements push
• ✅ Types de notifications - Notifications pour différents événements (nouveau devis, facture payée, rappel session, etc.)
• ✅ Notifications IA - Notifications automatiques (in-app + push) pour toutes les actions exécutées par l'IA
  • Création de contact, session, devis, facture
  • Actions composites (plusieurs actions en séquence)
  • Notifications de succès et d'échec avec détails
• ✅ Actions rapides - Actions rapides dans les notifications (marquer comme lu, ouvrir directement)
• ✅ Notifications en arrière-plan - Recevoir des notifications même quand l'application n'est pas ouverte
• ✅ Badge de notification - Badge sur l'icône de l'application indiquant le nombre de notifications non lues
  • Implémenté : Badge affiché sur le bouton de notification dans le header (NotificationCenter.tsx ligne 130-137)
• Préférences granulaires - Permettre aux utilisateurs de choisir quels types de notifications recevoir
• Son et vibration - Options pour personnaliser le son et la vibration des notifications
• Notifications programmées - Planifier des notifications pour des événements futurs
• Historique des notifications - Consulter l'historique des notifications envoyées

🔐 Sécurité & Conformité

Suggestions basées sur l'analyse

• ❌ Authentification à deux facteurs (2FA) - Ajout de l'2FA pour renforcer la sécurité
  • Non implémenté : Pas d'authentification à deux facteurs
• ❌ Gestion des sessions actives - Voir et gérer les sessions actives de l'utilisateur
  • Non implémenté : Pas d'interface pour voir/gérer les sessions actives (tokens JWT)
• ⚠️ Logs d'audit améliorés - Export des logs d'audit, alertes sur actions suspectes
  • Partiellement implémenté : Système d'audit complet avec logging automatique, filtrage, pagination, interface admin (/admin → Audit Logs)
  • Fonctionnalités implémentées : Logging automatique via @AuditLog() decorator, filtrage par action/entité/date, pagination, interface admin complète
  • Manquant : Export des logs d'audit (CSV, Excel, JSON), alertes automatiques sur actions suspectes
• ✅ Conformité RGPD renforcée - Outils pour gérer les demandes RGPD (droit à l'oubli, portabilité)
  • Implémenté : Module GDPR complet avec tous les droits RGPD (ACCESS, RECTIFICATION, ERASURE, PORTABILITY, OBJECTION, RESTRICTION)
• ⚠️ Chiffrement de bout en bout - Chiffrement des données sensibles
  • Partiellement implémenté : Chiffrement des tokens sensibles (Google OAuth, tokens de validation) via EncryptionService
  • Manquant : Chiffrement de bout en bout pour toutes les données sensibles (notes, messages, etc.)
• ⚠️ Backup automatique - Sauvegarde automatique avec restauration point-in-time
  • Partiellement implémenté : Script de backup manuel (infra/backup-db.sh), endpoint API pour déclencher les backups
  • Manquant : Sauvegardes automatiques planifiées, restauration point-in-time, rétention configurable

GDPR / RGPD ✅

• ✅ Portail de gestion des données - Interface dédiée pour les utilisateurs pour gérer leurs données personnelles
  • Implémenté : Portail complet accessible depuis le menu utilisateur (/gdpr-info pour la page publique d'information, /gdpr pour le portail authentifié)
• ✅ Droit à l'oubli (ERASURE) - Fonctionnalité complète pour supprimer toutes les données d'un utilisateur
  • Implémenté : Suppression FULL, PARTIAL et ANONYMIZATION avec logs d'audit
• ✅ Export des données (portabilité) - Export complet des données utilisateur dans un format structuré (JSON, CSV, XML)
  • Implémenté : Export en JSON, CSV (avec protection injection) et XML avec URLs signées valides 30 jours
• ✅ Consentement explicite - Système de gestion des consentements pour le traitement des données
  • Implémenté : Gestion complète des consentements (NECESSARY, FUNCTIONAL, ANALYTICS, MARKETING, THIRD_PARTY)
• ✅ Journalisation des consentements - Traçabilité de tous les consentements donnés/révoqués
  • Implémenté : Logs complets avec IP, user agent, dates de grant/revoke
• ✅ Droit d'accès (ACCESS) - Permettre aux utilisateurs de consulter toutes leurs données personnelles
  • Implémenté : Requêtes ACCESS génèrent automatiquement un export de données avec email de notification
• ✅ Droit de rectification (RECTIFICATION) - Interface pour modifier/corriger les données personnelles
  • Implémenté : Formulaire de rectification avec vérification par email, validation de sécurité, validation d'unicité de l'email
• ✅ Droit d'opposition (OBJECTION) - Permettre aux utilisateurs de s'opposer au traitement de certaines données
  • Implémenté : Type de requête OBJECTION supporté dans le système
• ✅ Suppression automatique - Politique de rétention avec suppression automatique des données après expiration
  • Implémenté : Exports expirent après 30 jours, logs de suppression conservés
• ✅ Anonymisation des données - Outils pour anonymiser les données tout en conservant les statistiques
  • Implémenté : Type de suppression ANONYMIZATION disponible
• ✅ Audit de conformité - Rapports d'audit pour vérifier la conformité RGPD
  • Implémenté : Logs de suppression (gdpr_deletion_logs) avec sauvegarde des données avant suppression
• ⚠️ Cookies et tracking - Gestion transparente des cookies et du tracking avec consentement
  • Partiellement implémenté : Système de consentement en place, intégration frontend à compléter
• ⚠️ Politique de confidentialité dynamique - Politique de confidentialité mise à jour automatiquement
  • Partiellement implémenté : Pages de politique disponibles, mise à jour automatique à implémenter
• ✅ Demandes RGPD automatisées - Traitement automatisé des demandes RGPD avec notifications
  • Implémenté : Traitement automatique avec emails de vérification et notifications

Documentation : Voir backend/src/gdpr/README.md pour la documentation complète du module GDPR.

🤝 Collaboration & Partage

✅ Système d'Organisations - 100% COMPLÉTÉ (2026-01-16)

Backend :

• Création et gestion d'organisations : Les utilisateurs peuvent créer des organisations et inviter d'autres utilisateurs
• Gestion des membres : Rôles (OWNER, ADMIN, MEMBER, VIEWER) avec permissions granulaires
• Partage de ressources : Partage de sessions, devis, factures, contrats, contacts avec permissions (read, write, delete)
• Système d'invitations : Invitations par email avec tokens sécurisés
• Vérification d'accès : Service helper OrganizationAccessService pour vérifier l'accès aux ressources via organisations
• Intégration dans les services existants : Support du partage via verifyResourceAccess dans tous les services CRUD
• Architecture :
  • Tables : organizations, organization_members, organization_resource_shares, organization_invitations, organization_settings
  • Services : OrganizationsService, OrganizationMembersService, OrganizationResourcesService, OrganizationPermissionsService, OrganizationInvitationsService, OrganizationAccessService

Frontend :

• Hooks React Query : Tous les hooks nécessaires pour la gestion des organisations (useOrganizations, useOrganization, useOrganizationMembers, useOrganizationResources, mutations complètes)

• Pages : Liste, création, édition, vue détaillée avec onglets (Overview, Members, Resources)

• Composants : CreateOrganizationDialog, MembersTab, ResourcesTab avec gestion complète

• Routes : Intégration complète dans le router (/organizations, /organizations/new, /organizations/$id, /organizations/$id/edit)

• Formulaires : Utilisation de react-hook-form avec validation Zod et composant Form shadcn/ui

• Traductions : Toutes les traductions i18n pour les organisations

• Optimistic updates : Mises à jour optimistes et invalidation du cache React Query

• Documentation : backend/src/organizations/README.md

✅ Système d'Invitations et d'Amis - KEEP (web + BE) — port mobile BACKLOG

Vague A : Friends kept. Port UX to aaperture-mobile via /mobile/network*. Progression rewards obsolete.

Backend :

• Système d'invitations :
  • Chaque utilisateur a 5 invitations de base (gain via progression obsolete)
  • Création d'invitations par email avec token (lien) et code unique (6 caractères)
  • Acceptation via token ou code lors de l'inscription
  • Gestion du solde : suivi des invitations gagnées, utilisées et disponibles
  • Expiration automatique après 7 jours
• Système d'amis :
  • Demandes d'amis mutuelles (acceptation requise)
  • Amitié automatique lors de l'acceptation d'invitation
  • Gestion complète : liste, acceptation, rejet, suppression
  • Intégration avec organisations : limitation de l'ajout aux amis uniquement
• Récompenses référent :
  • XP / coins via progression — N/A (progression deleted)
• Visibilité utilisateur :
  • Paramètre is_visible dans user_metadata pour contrôler la visibilité
  • Les utilisateurs non visibles peuvent être vus par leurs amis
• Architecture :
  • Tables : user_invitations, user_invitation_balance, user_friends
  • Modifications : users.referrer_id, user_metadata.is_visible
  • Services : InvitationsService, FriendsService
  • Controllers : InvitationsController, FriendsController
  • Mobile contract : /mobile/network*

Frontend :

• RightSidebar : Panneau latéral avec onglets Chat/Amis pour basculer entre les deux

• FriendsList : Liste des amis avec recherche et actions rapides

• InvitationsPage : Page complète pour gérer les invitations (solde, création, liste, codes)

• FriendsPage : Page complète pour gérer les amis (liste, demandes, ajout)

• Hooks React Query : useInvitations, useFriends avec toutes les mutations

• Modification MembersTab : Filtrage pour n'afficher que les amis dans la sélection

• Intégration DashboardLayout : RightSidebar remplace Agent avec onglets

• Documentation : backend/src/invitations/README.md, backend/src/friends/README.md

Suggestions basées sur l'analyse

• ✅ Partage de ressources - Partage de sessions, contacts, devis, factures, contrats entre utilisateurs via organisations
  • Implémenté : Système complet d'organisations avec partage de ressources et permissions granulaires (voir section ci-dessus)
• ❌ Commentaires et notes - Système de commentaires sur les entités
  • Non implémenté : Pas de système de commentaires (seulement notes sur contacts/sessions)
• ❌ Mentions - Mentionner des utilisateurs dans les commentaires
  • Non implémenté : Pas de système de mentions
• ⚠️ Équipes et rôles - Gestion d'équipes avec rôles personnalisés
  • Partiellement implémenté : Système de permissions basé sur les abonnements (FREE, BASIC, PRO), permissions granulaires par fonctionnalité
  • Manquant : Gestion d'équipes multi-utilisateurs, rôles personnalisés par équipe
• ⚠️ Permissions granulaires - Permissions plus fines par entité et action
  • Partiellement implémenté : Système de permissions par fonctionnalité (voir PERMISSIONS_ARCHITECTURE.md)
  • Manquant : Permissions par entité individuelle (ex: partager une session spécifique), permissions par action fine (ex: modifier mais pas supprimer)
• ✅ Activité en temps réel - Voir les modifications en temps réel (via WebSocket)
  • Implémenté : Système WebSocket complet avec Socket.IO pour notifications en temps réel
  • Fonctionnalités : Notifications instantanées (in-app + push), événements agent IA en streaming, connexion automatique avec reconnexion
  • Documentation : backend/src/websocket/README.md, frontend/src/client/websocket/README.md

📱 Mobile & PWA

Suggestions basées sur l'analyse

• ❌ Application mobile native - Développer des apps iOS et Android
  • Non implémenté : Pas d'application mobile native (PWA disponible mais pas d'app native)
• ⚠️ Mode hors ligne amélioré - Synchronisation intelligente en mode hors ligne
  • Partiellement implémenté : PWA avec Service Worker et cache, support offline basique
  • Manquant : Synchronisation intelligente des modifications hors ligne, résolution de conflits lors de la reconnexion
• ✅ Notifications push améliorées - Notifications push avec actions rapides
  • Implémenté : Notifications push navigateur complètes avec actions rapides (voir section "Notifications Push" ci-dessus)
  • Fonctionnalités : Actions rapides dans les notifications (marquer comme lu, ouvrir directement), notifications en arrière-plan, badge de notification
• ✅ Navigation mobile améliorée - Menu utilisateur optimisé pour mobile
  • Implémenté : Menu utilisateur en plein écran sur mobile avec sous-menus expansibles
  • Composants : UserMenuMobile pour affichage full-screen, UserDropdown détecte automatiquement mobile
  • Fonctionnalités : Contenu scrollable, sous-menus avec chevrons, navigation tactile optimisée
• ⚠️ Vues responsive améliorées - Amélioration de la responsivité des pages
  • En cours : Améliorations progressives de la responsivité des vues principales
  • À faire : Audit complet et améliorations des pages pour mobile
• ❌ Géolocalisation - Utiliser la géolocalisation pour les sessions et contacts
  • Non implémenté : Pas d'intégration géolocalisation
• ❌ Photo depuis l'app - Prendre des photos directement depuis l'app mobile
  • Non implémenté : Pas de fonctionnalité de capture photo (upload de fichiers disponible)
• ❌ Signature électronique - Signature de contrats directement depuis mobile
  • Non implémenté : Pas de système de signature électronique

🔧 Automatisation & Workflows

Suggestions basées sur l'analyse

• ⚠️ Workflows visuels - Éditeur visuel pour créer des workflows
  • Partiellement implémenté : Module workflows existe avec système de workflows basique
  • Manquant : Éditeur visuel pour créer/modifier les workflows, interface graphique
• ⚠️ Déclencheurs personnalisés - Créer des déclencheurs basés sur des conditions complexes
  • Partiellement implémenté : Système de workflows avec déclencheurs basiques
  • Manquant : Déclencheurs complexes personnalisables, conditions avancées
• ⚠️ Actions automatiques - Automatiser les tâches répétitives (ex: créer facture après acceptation devis)
  • Partiellement implémenté : Système de workflows avec actions automatiques basiques
  • Manquant : Actions automatiques avancées, règles métier complexes
• ❌ Intégrations webhooks - Webhooks pour intégrer avec des services externes
  • Non implémenté : Pas de système de webhooks sortants (webhooks entrants Stripe existent)
• ❌ API publique - API publique pour permettre des intégrations tierces
  • Non implémenté : Pas d'API publique documentée (API interne avec authentification JWT)
• ❌ Zapier/Make integration - Intégration avec Zapier ou Make pour automatisations
  • Non implémenté : Pas d'intégration Zapier/Make

🎮 Progression & Engagement

❌ Système de Progression — DELETED (Vague A, 2026-07)

Gamification (XP, badges, défis, coins, leaderboards) removed from application code. Historical detail below is archive-only; do not reimplement without a new product decision.

• Tables (candidates for later DB drop): user_progression, badges, user_badges, challenges, xp_transactions, aaperture_coins_transactions, user_aaperture_coins, leaderboard_cache, progression_settings — see DB_CLEANUP_AUDIT.md / APP_CLEANUP_MAP.md.
• Cmd+K recommendations (related cleanup): also deleted.

Historical feature list (pre-deletion)

✅ Système de Progression - 100% COMPLÉTÉ (2026-01-16)

• Système d'XP et niveaux : 7 niveaux (Apprenti → Légende) avec progression exponentielle
• Badges / Défis / Classements / Aaperture Coins / Boutique : see git history
• Documentation : backend/src/progression/ removed

Suggestions d'amélioration (futures)

• N/A until product reopens gamification. Invitations/Friends continue without progression badges.

📊 Tableaux de Bord & Interface

Suggestions basées sur l'analyse

• ❌ Widgets personnalisables - Permettre aux utilisateurs d'ajouter/supprimer/réorganiser les widgets
  • Non implémenté : Pas de système de widgets personnalisables (dashboard fixe)
• ✅ Thèmes personnalisables - Thèmes clair/sombre et personnalisation des couleurs
  • Implémenté : Mode sombre/clair avec détection automatique, persistance des préférences (voir section "Dark / Light Mode" ci-dessous)
• ❌ Vues personnalisées - Créer et sauvegarder des vues personnalisées de listes
  • Non implémenté : Pas de système de sauvegarde de vues personnalisées (filtres disponibles mais pas sauvegardables)
• ⚠️ Raccourcis clavier - Raccourcis clavier pour les actions fréquentes
  • Partiellement implémenté : Raccourcis pour la recherche globale (Cmd+K/Ctrl+K), navigation avec flèches (↑↓), Enter pour sélectionner, Escape pour fermer
  • Fonctionnalités : Recherche globale accessible via Cmd+K/Ctrl+K, navigation au clavier dans les résultats, actions rapides depuis la recherche
  • Manquant : Raccourcis pour autres actions fréquentes (créer session, créer contact, etc.)
• ❌ Mode focus - Mode focus pour réduire les distractions
  • Non implémenté : Pas de mode focus
• ⚠️ Accessibilité améliorée - Améliorer l'accessibilité (WCAG 2.1 AA)
  • Partiellement implémenté : Navigation au clavier basique, attributs ARIA sur certains composants
  • Manquant : Conformité WCAG 2.1 AA complète, tests d'accessibilité automatisés, support lecteurs d'écran amélioré

Dark / Light Mode

• ✅ Mode sombre complet - Implémentation d'un thème sombre pour toute l'application (CSS avec variables Tailwind)
• ✅ Détection automatique - Détection automatique des préférences système (prefers-color-scheme) - Support "system" dans Zustand store
• ✅ Persistance des préférences - Sauvegarde du choix de thème dans les préférences utilisateur (Zustand persist + backend settings)
• ✅ Transition fluide - Transitions animées lors du changement de thème (gérées automatiquement par Tailwind CSS)
• ⚠️ Personnalisation avancée - Permettre aux utilisateurs de personnaliser les couleurs du thème (non implémenté - utilise les couleurs par défaut du design system)
• ✅ Thème par défaut - Définir un thème par défaut pour les nouveaux utilisateurs ("system" par défaut dans Zustand store)

🔗 Intégrations

Suggestions basées sur l'analyse

• ❌ Intégration comptabilité - Intégration avec des logiciels de comptabilité (QuickBooks, Xero)
  • Non implémenté : Pas d'intégration avec logiciels de comptabilité
• ❌ Intégration CRM externe - Import/export vers d'autres CRM (HubSpot, Salesforce)
  • Non implémenté : Pas d'intégration avec autres CRM (export CSV/Excel/JSON disponible mais pas d'intégration directe)
• ❌ Intégration réseaux sociaux - Intégration avec Instagram, Facebook pour importer les contacts
  • Non implémenté : Pas d'intégration avec réseaux sociaux
• ❌ Intégration email marketing - Intégration avec Mailchimp, Sendinblue pour les campagnes
  • Non implémenté : Pas d'intégration avec plateformes email marketing
• ⚠️ Intégration stockage - Intégration avec Dropbox, Google Drive pour les fichiers
  • Partiellement implémenté : Stockage Cloudflare R2 (S3-compatible) pour les fichiers
  • Manquant : Intégration directe avec Dropbox, Google Drive (upload depuis ces services)
• ✅ Intégration calendrier - Synchronisation avec Google Calendar, Outlook, Apple Calendar
  • Implémenté : Synchronisation bidirectionnelle complète avec Google Calendar
    • ✅ Synchronisation CRM → Google Calendar (création/mise à jour automatique des événements)
    • ✅ Synchronisation Google Calendar → CRM (toutes les 5 minutes via scheduler)
    • ✅ Gestion des événements récurrents avec exceptions et suppressions
    • ✅ Résolution de conflits intelligente
    • ✅ Gestion de disponibilité (créneaux disponibles/bloqués)
  • Documentation : docs/CALENDAR_SYNC_ARCHITECTURE.md
  • Manquant : Synchronisation avec Outlook et Apple Calendar

📈 Performance & Scalabilité

Améliorations implémentées récemment

• ✅ Gestion des erreurs de connexion PostgreSQL - Retry automatique pour les erreurs de connexion dans les jobs cron
  • Implémenté : Fonction retryQuery dans ScheduledEmailsService avec détection des erreurs de connexion
  • Configuration du pool : Pool PostgreSQL configuré avec gestion d'erreurs, timeouts et limites appropriées
  • Bénéfices : Réduction des erreurs "Connection terminated unexpectedly" dans les schedulers
  • Fichiers : backend/src/db/db.service.ts, backend/src/scheduled-emails/scheduled-emails.service.ts

Suggestions basées sur l'analyse

• ⚠️ Cache intelligent - Améliorer le système de cache avec invalidation intelligente

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Système de cache Redis avec CacheService (getOrSet pattern recommandé)
    • ✅ Invalidation par pattern (deletePattern)
    • ✅ Verrouillage distribué (acquireLock / releaseLock) pour éviter les conflits
    • ✅ Cache pour les réponses IA (OpenAI) avec TTL configurables (5-10 minutes)
    • ✅ Cache pour les permissions utilisateur
    • ✅ Fallback gracieux si Redis est désactivé
  • Manquant :
    • ❌ Invalidation intelligente basée sur les dépendances (ex: invalider les sessions quand un contact est modifié)
    • ❌ Cache hiérarchique (multi-niveaux)
    • ❌ Stratégies de cache avancées (LRU, LFU, etc.)
  • Fichiers : backend/src/cache/cache.service.ts, backend/src/cache/README.md
  • Documentation : docs/AI_SEARCH_OPTIMIZATION.md (optimisations cache pour IA)

• ⚠️ Pagination améliorée - Pagination infinie avec virtualisation pour les grandes listes

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Système de pagination backend complet avec buildPaginatedQuery (utilitaires centralisés)
    • ✅ Composant Pagination réutilisable côté frontend
    • ✅ Pagination standard avec navigation page par page
    • ✅ Sélection du nombre d'éléments par page (limit configurable, max 100)
    • ✅ Composant ListPageContent pour affichage table/card
    • ✅ Support de la recherche et des filtres dans la pagination
    • ✅ Hooks React Query pour pagination (usePaginatedList, useListQuery)
  • Manquant :
    • ❌ Pagination infinie (scroll infini) pour améliorer l'UX
    • ❌ Virtualisation avec react-window ou react-virtual pour grandes listes (>1000 éléments)
    • ❌ Cursor-based pagination pour meilleures performances sur très grandes listes
  • Fichiers : backend/src/common/db-pagination.utils.ts, frontend/src/components/molecules/Pagination.tsx, frontend/src/hooks/usePagination.ts

• ⚠️ Optimisation des requêtes - Optimiser les requêtes complexes avec des index appropriés

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Index sur colonnes fréquemment utilisées (owner_id, created_at, user_id, etc.)
    • ✅ Index sur clés étrangères pour améliorer les JOINs
    • ✅ Utilisation de Kysely query builder pour optimiser les requêtes
    • ✅ Pagination backend pour éviter de charger toutes les données
  • Manquant :
    • ❌ Analyse automatique des requêtes lentes (logging des requêtes >Xms)
    • ❌ Optimisation automatique basée sur les patterns de requêtes
    • ❌ Index composites pour requêtes complexes fréquentes
    • ❌ Monitoring des performances de requêtes (EXPLAIN ANALYZE)
  • Fichiers : Migrations Liquibase dans infra/liquibase/changes/

• ❌ CDN pour les assets - Utiliser un CDN pour servir les assets statiques

  • Statut : ❌ Non implémenté
  • Description : Pas de CDN configuré actuellement. Les assets sont servis directement par le serveur.
  • Recommandation : Configurer Cloudflare CDN ou similaire pour les assets statiques (images, fonts, JS/CSS) en production
  • Bénéfices : Réduction de la latence, meilleure scalabilité, cache distribué

• ⚠️ Compression des réponses - Compression gzip/brotli pour les réponses API

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Compression gzip pour les exports (export.service.ts avec compression: true)
    • ✅ Compression gzip pour les backups (backup.service.ts avec createGzip)
    • ✅ Compression pour les uploads R2 (Cloudflare R2 gère la compression automatiquement)
  • Manquant :
    • ❌ Compression automatique des réponses HTTP API (middleware Express/NestJS avec compression)
    • ❌ Support Brotli pour meilleure compression (nécessite middleware)
    • ❌ Configuration de la compression par type de contenu
  • Recommandation : Ajouter compression middleware NestJS pour compresser automatiquement toutes les réponses JSON/HTML

• ⚠️ Lazy loading - Chargement paresseux des modules et composants

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Lazy loading des images (loading="lazy" dans FileGallery et autres composants)
    • ✅ Code splitting basique dans Vite (vendor chunks automatiques)
    • ✅ Configuration Vite avec build.rollupOptions.output.manualChunks pour séparer les vendors
  • Manquant :
    • ❌ Lazy loading des routes React avec React.lazy() (toutes les routes sont chargées statiquement)
    • ❌ Lazy loading des composants lourds (dialogs, modals, etc.)
    • ❌ Suspense boundaries pour améliorer l'UX pendant le chargement
  • Fichiers : frontend/src/router.tsx (routes statiques), frontend/vite.config.ts (code splitting)
  • Recommandation : Implémenter React.lazy() pour les routes non-critiques (admin, settings, etc.)

• ⚠️ Monitoring et observabilité - Système de monitoring complet pour les performances et erreurs

  • Statut : 🚧 En cours (MVP observabilité complété)
  • Implémenté :
    • ✅ Logging structuré avec ExtendedLoggerService (scopes, emojis, niveaux)
    • ✅ Logs de performance pour certaines opérations (timing, latence)
    • ✅ Rate limiting avec monitoring (compteurs Redis)
    • ✅ Health check basique (/api/health)
    • ✅ Readiness/Liveness probes (/api/health/ready, /api/health/live)
    • ✅ Vérification Redis dans la readiness (ping + latence + statut ok/down/disabled)
    • ✅ Endpoint /api/metrics Prometheus (scrape + instrumentation HTTP/jobs)
    • ✅ Alerting applicatif (scheduler) sur health/ready down + spikes http_request_errors_total (Slack + email)
    • ✅ Dashboard Grafana minimal provisionné (latence API p95, erreurs HTTP, jobs failed, durée jobs p95)
    • ✅ Endpoints admin ops: GET /api/ops/status + POST /api/observability/alerts/test
    • ✅ Carte "Ops Status" dans l'Admin (état queues/grafana/prometheus + action test alerte)
    • ✅ Sous-domaines ops prod (queues.*, grafana.*, prometheus.*) documentés et sécurisés
    • ✅ Intégration Sentry pour le tracking d'erreurs automatique (backend + frontend + workers)
  • Manquant :
    • ❌ Logs centralisés (ELK Stack ou CloudWatch)
    • ⚠️ Intégration Alertmanager/PagerDuty/opsgenie (actuellement Slack+email via scheduler backend)
    • ⚠️ Dashboard de monitoring avancé (actuellement dashboard Grafana minimal)
  • Recommandation : Prioriser logs centralisés + alerting on-call + dashboard avancé (Prometheus/Grafana MVP déjà en place)

• ⚠️ Health checks améliorés - Endpoints de health check plus détaillés

  • Statut : ⚠️ Partiellement implémenté
  • Implémenté :
    • ✅ Endpoint /api/health basique qui vérifie la connexion PostgreSQL
    • ✅ Retour du timestamp DB pour vérifier la synchronisation
    • ✅ Statut OK/NOK simple
    • ✅ Endpoint /api/database-info pour informations détaillées DB
    • ✅ Vérification Redis (connexion/ping) via endpoint /api/health/ready
    • ✅ Endpoint /api/health/ready pour readiness probe (Kubernetes)
    • ✅ Endpoint /api/health/live pour liveness probe (Kubernetes)
    • ✅ Health check dégradé (status: ok|degraded|down) selon dépendances
  • Manquant :
    • ❌ Vérification des services externes (Google Calendar API, Gmail API, OpenAI API)
    • ❌ Métriques détaillées par service (latence, statut, dernière vérification)
  • Fichiers : backend/src/app.service.ts (méthode health()), backend/src/app.controller.ts
  • Recommandation : Étendre /api/health pour vérifier Redis et services externes avec timeout

• ✅ Gestion des timeouts - Timeouts configurables pour toutes les opérations longues

  • Statut : ✅ Complété (2025-01-XX)
  • Implémenté :
    • ✅ Configuration centralisée - Module TimeoutConfig avec toutes les valeurs configurables via variables d'environnement
    • ✅ Timeouts pour le pool PostgreSQL (DB_CONNECTION_TIMEOUT, DB_IDLE_TIMEOUT configurables)
    • ✅ Timeouts configurables pour les requêtes DB individuelles (DB_QUERY_TIMEOUT) - ✅ Appliqué
    • ✅ Timeouts configurables pour les appels API externes (OpenAI, Google Calendar, Gmail, OAuth) - ✅ Appliqué dans tous les services
    • ✅ Timeouts pour les jobs cron (CRON_JOB_TIMEOUT configurable) - ✅ Appliqué dans tous les schedulers
    • ✅ Variables d'environnement pour chaque timeout (plus de valeurs hardcodées)
    • ✅ Timeout global pour les requêtes HTTP (middleware TimeoutMiddleware) - ✅ Appliqué
    • ✅ Timeouts pour migrations et backups dans les scripts shell - ✅ Appliqué
    • ✅ Utilitaires de timeout (withTimeout, executeWithTimeoutAndRetry) - ✅ Disponibles et utilisés
  • Fichiers :
    • backend/src/common/timeout.config.ts (configuration centralisée)
    • backend/src/common/timeout.utils.ts (utilitaires)
    • backend/src/common/timeout.middleware.ts (middleware HTTP)
    • backend/src/common/timeout.module.ts (module NestJS)
    • backend/src/db/db.service.ts (timeouts pool et requêtes appliqués)
    • infra/migrate-improved.sh (timeout appliqué)
    • infra/backup-db.sh (timeout appliqué)
    • backend/src/agent/*.ts (timeouts OpenAI appliqués)
    • backend/src/search/*.ts (timeouts OpenAI appliqués)
    • backend/src/extraction/services/llm.service.ts (timeouts OpenAI appliqués)
    • backend/src/openai/openai.service.ts (timeouts OpenAI appliqués)
    • backend/src/google-calendar/google-calendar.service.ts (timeouts Google Calendar appliqués avec helper withCalendarTimeout)
    • backend/src/quotes-invoices/gmail.service.ts (timeouts Gmail appliqués)
    • backend/src/*/*.scheduler.ts (timeouts cron appliqués dans tous les schedulers)
  • Documentation :
    • docs/TIMEOUT_MANAGEMENT.md (guide complet)
    • docs/ENV_VARIABLES_TIMEOUT.md (liste complète des variables d'environnement)
    • docs/ENV_TIMEOUT_EXAMPLE.txt (exemple à copier dans .env.example)

• ⚠️ Circuit breaker pattern - Protection contre les cascades d'erreurs

  • Statut : ❌ Non implémenté
  • Description : Pas de circuit breaker pour les services externes actuellement
  • Services concernés : Google Calendar API, Gmail API, OpenAI API
  • Implémenté :
    • ✅ Gestion d'erreurs basique avec retry dans certains services
    • ✅ Rate limiting pour protéger contre la surcharge
    • ✅ Cache pour réduire les appels API externes
  • Manquant :
    • ❌ Circuit breaker pattern (open/closed/half-open states)
    • ❌ Fallback automatique en cas d'échec répété
    • ❌ Dégradation gracieuse des fonctionnalités non critiques
    • ❌ Monitoring de l'état des circuits
  • Recommandation : Implémenter circuit breaker avec bibliothèque comme opossum ou brakes pour NestJS
  • Bénéfices : Évite la surcharge en cas de panne d'un service externe, améliore la résilience

🧪 Tests & Qualité

Améliorations implémentées récemment

• ✅ Gestion centralisée des types via OpenAPI - Système unifié pour la gestion des types partagés entre frontend et backend
  • Statut : ✅ Complété (2025-12-11)
  • Priorité : Haute
  • Implémenté :
    • ✅ Audit complet des types utilisés dans frontend et backend
    • ✅ Migration de tous les types partagés vers OpenAPI
    • ✅ Types scope-specific (frontend-only ou backend-only) dans fichiers types.ts appropriés
    • ✅ Suppression des définitions de types dupliquées
    • ✅ Mise à jour de tous les imports pour utiliser les types générés depuis _generated/types.gen.ts (ou .js pour backend)
    • ✅ Vérification que tous les types OpenAPI sont correctement exportés dans openapi/components/schemas.yaml
    • ✅ Documentation complète des règles de gestion des types dans docs/AGENTS_OPENAPI.md
    • ✅ Mise à jour de la documentation dans docs/AGENTS.md, docs/AGENTS_BACKEND.md, et docs/AGENTS_FRONTEND.md
    • ✅ Ajout d'exemples de migration et d'arbre de décision pour déterminer où placer les types
    • ✅ Correction des erreurs de validation OpenAPI (problèmes d'indentation YAML)
  • Fichiers modifiés :
    • openapi/components/search.yaml - Correction des erreurs YAML et structure des types AI
    • openapi/components/schemas.yaml - Export de tous les types partagés
    • docs/AGENTS_OPENAPI.md - Documentation complète des règles de gestion des types
    • docs/AGENTS.md - Mise à jour de la checklist de pré-commit
    • docs/AGENTS_BACKEND.md - Ajout des règles sur les types partagés
    • docs/AGENTS_FRONTEND.md - Ajout des règles sur les types partagés
  • Règles établies :
    • Types utilisés par frontend ET backend → MUST be in OpenAPI
    • Types utilisés uniquement dans un scope → MUST be in scope-specific types.ts files
    • Processus de migration documenté avec exemples
    • Checklist de pré-commit mise à jour pour vérifier la conformité
  • Bénéfices :
    • Single source of truth pour les types partagés
    • Type safety garantie entre frontend et backend
    • Génération automatique des types depuis OpenAPI
    • Cohérence entre API et validation
    • Réduction des erreurs de type et des incohérences
  • Documentation : docs/AGENTS_OPENAPI.md (section "Type Management Rules")

Suggestions basées sur l'analyse

• ⚠️ Couverture de tests - Augmenter la couverture de tests (backend et frontend)
  • Statut actuel : Couverture variable selon les modules (certains modules >80%, d'autres <50%)
  • Objectif : >80% de couverture pour les modules critiques
  • Priorité : Moyenne
  • Outils : Vitest pour backend et frontend
• ❌ Tests E2E - Ajouter des tests end-to-end avec Playwright ou Cypress
  • Non implémenté : Pas de tests E2E
  • Priorité : Moyenne
  • Effort : Élevé
  • Description : Tests E2E pour les flux critiques (création session, réservation, paiement)
• ❌ Tests de performance - Tests de charge et de performance
  • Non implémenté : Pas de tests de performance
  • Priorité : Moyenne
  • Outils : k6, Artillery, ou JMeter
  • Scénarios : Charge normale, pics de trafic, stress tests
• ✅ Monitoring d'erreurs - Intégration avec Sentry pour le monitoring d'erreurs
  • Priorité : Haute
  • Effort : 1-2 jours
  • Statut : ✅ Implémenté (janvier 2026)
  • Description : Intégration Sentry pour tracking automatique des erreurs frontend et backend
  • Bénéfices : Détection proactive des problèmes, stack traces, contexte utilisateur
  • Implémenté :
    • ✅ Backend NestJS : Module Sentry avec exception filter global, capture des erreurs 5xx
    • ✅ Frontend React : Initialisation Sentry, user context, session replay
    • ✅ Worker BullMQ : Erreurs des jobs capturées
    • ✅ CI/CD : Variables SENTRY_DSN et VITE_SENTRY_DSN configurées
  • Documentation : docs/SENTRY_SETUP.md
• ❌ Analytics d'usage - Analytics pour comprendre comment les utilisateurs utilisent l'application
  • Non implémenté : Pas d'analytics d'usage utilisateur
  • Priorité : Basse
  • Description : Tracking anonymisé des interactions utilisateur pour améliorer l'UX
  • Outils : Plausible, PostHog, ou solution custom
• ❌ Tests de régression automatisés - Suite de tests de régression pour éviter les régressions
  • Non implémenté : Pas de suite de tests de régression automatisés
  • Priorité : Moyenne
  • Description : Tests automatisés exécutés avant chaque déploiement
  • Intégration : CI/CD pipeline
• ⚠️ Tests de sécurité - Tests automatisés pour détecter les vulnérabilités
  • Partiellement implémenté : npm audit dans le pipeline CI, vérification des dépendances
  • Manquant : Scans automatisés OWASP ZAP, Snyk intégration complète, tests de sécurité automatisés dans CI/CD
  • Priorité : Haute
  • Outils : OWASP ZAP, Snyk, npm audit

🔧 Infrastructure & Robustesse

Améliorations récentes

• ✅ Gestion des erreurs de connexion DB - Retry automatique pour les erreurs de connexion PostgreSQL
  • Implémenté : Fonction retryQuery avec détection intelligente des erreurs de connexion
  • Configuration : Pool PostgreSQL optimisé avec timeouts et gestion d'erreurs
  • Impact : Réduction significative des erreurs dans les jobs cron
  • Fichiers : backend/src/db/db.service.ts, backend/src/scheduled-emails/scheduled-emails.service.ts

Suggestions d'amélioration

1. Monitoring et observabilité

• ⚠️ Système complet de monitoring - Tracking d'erreurs, métriques de performance et logs centralisés
  • Statut : 🚧 En cours (MVP observabilité complété)
  • Priorité : Haute
  • Effort : 3-5 jours
  • Implémenté :
    • ✅ Logging structuré avec ExtendedLoggerService (scopes, emojis, niveaux)
    • ✅ Logs de performance pour certaines opérations (timing, latence)
    • ✅ Rate limiting avec monitoring (compteurs Redis)
    • ✅ Health check basique (/api/health)
    • ✅ Système d'audit complet avec logging automatique
    • ✅ Prometheus + Grafana (MVP dashboards)
    • ✅ Alerting applicatif Slack/email (scheduler observabilité)
    • ✅ Ops status admin + test d'alerte synthétique
    • ✅ Intégration Sentry pour le tracking d'erreurs automatique (frontend + backend + workers)
  • Manquant :
    • ❌ Logs centralisés (ELK Stack ou CloudWatch)
    • ❌ Alerting on-call (Alertmanager/PagerDuty/Opsgenie)
    • ❌ Dashboard avancé SLO/SLI
    • ❌ Tracing distribué (OpenTelemetry) pour suivre les requêtes à travers les services
  • Déjà en place :
    • ✅ Métriques de performance centralisées (Prometheus + Grafana MVP)
  • Métriques clés à surveiller :
    • Latence API (P50, P95, P99) par endpoint
    • Taux d'erreur par endpoint (4xx, 5xx)
    • Utilisation DB (connexions actives, requêtes lentes >1s, pool saturation)
    • Utilisation Redis (mémoire, hit rate, connexions)
    • Performance des jobs cron (durée d'exécution, taux d'échec)
    • Utilisation CPU/mémoire du serveur
    • Taux de cache hit/miss pour les requêtes IA
  • Recommandation : Compléter le MVP par logs centralisés + alerting on-call + tracing
  • Fichiers concernés : backend/src/common/logger.service.ts, backend/src/app.service.ts, backend/src/app.controller.ts, backend/src/common/sentry/ (Sentry implémenté)

2. Health checks améliorés

• ⚠️ Endpoints de santé détaillés - Vérification complète de tous les services
  • Statut : ⚠️ Partiellement implémenté
  • Priorité : Moyenne
  • Effort : 1-2 jours
  • Implémenté :
    • ✅ Endpoint /api/health basique qui vérifie la connexion PostgreSQL
    • ✅ Retour du timestamp DB pour vérifier la synchronisation
    • ✅ Statut OK/NOK simple
    • ✅ Endpoint /api/database-info pour informations détaillées DB
    • ✅ Vérification de Redis (connexion, ping) via /api/health/ready
    • ✅ Endpoint /api/health/ready pour readiness probe (Kubernetes)
    • ✅ Endpoint /api/health/live pour liveness probe (Kubernetes)
    • ✅ Health check dégradé (ok|degraded|down) selon dépendances
    • ✅ Endpoint /api/ops/status pour vérifier la joignabilité interne queues/grafana/prometheus
  • Manquant :
    • ❌ Vérification des services externes (Google Calendar API, Gmail API, OpenAI API)
    • ❌ Métriques détaillées par service (latence, statut, dernière vérification)
    • ❌ Vérification mémoire Redis disponible
  • Structure proposée :

    {
      "status": "ok",
      "timestamp": "2025-01-01T00:00:00.000Z",
      "services": {
        "database": {
          "status": "ok",
          "latency": "12ms"
        },
        "redis": {
          "status": "ok",
          "latency": "3ms"
        },
        "googleCalendar": {
          "status": "ok",
          "latency": "150ms"
        }
      }
    }

  • Bénéfices : Détection rapide des problèmes, intégration avec load balancers, monitoring proactif
  • Fichiers : backend/src/app.service.ts (méthode health()), backend/src/app.controller.ts
  • Recommandation : Étendre /api/health pour vérifier Redis et services externes avec timeout (5s max par service)

3. Gestion des timeouts

• ✅ Timeouts configurables pour toutes les opérations - Protection contre les opérations bloquantes

  • Statut : ✅ Complété (2025-01-XX)

  • Priorité : Moyenne

  • Effort : 2-3 jours

  • Implémenté :

    • ✅ Configuration centralisée - Module TimeoutConfig avec toutes les valeurs configurables via variables d'environnement
    • ✅ Timeouts pour le pool PostgreSQL (DB_CONNECTION_TIMEOUT, DB_IDLE_TIMEOUT configurables) - ✅ Appliqué
    • ✅ Timeouts configurables pour les requêtes DB individuelles (DB_QUERY_TIMEOUT) - ✅ Appliqué
    • ✅ Variables d'environnement pour chaque timeout (plus de valeurs hardcodées)
    • ✅ Timeout global pour les requêtes HTTP (middleware TimeoutMiddleware) - ✅ Appliqué
    • ✅ Timeouts pour migrations et backups dans les scripts shell - ✅ Appliqué
    • ✅ Utilitaires de timeout (withTimeout, executeWithTimeoutAndRetry) - ✅ Disponibles
    • ✅ Retry automatique pour les erreurs de connexion DB dans les schedulers
    • ✅ Application des timeouts dans les services OpenAI - ✅ Appliqué (tous les appels API OpenAI wrappés avec withTimeout)
    • ✅ Application des timeouts dans les services Google Calendar/Gmail - ✅ Appliqué (tous les appels API wrappés avec withCalendarTimeout helper)
    • ✅ Application des timeouts dans les schedulers cron - ✅ Appliqué (tous les schedulers wrappés avec executeWithTimeoutAndRetry)

  • Configuration disponible :

    # Database timeouts (milliseconds)
    DB_QUERY_TIMEOUT=30000
    DB_CONNECTION_TIMEOUT=10000
    DB_IDLE_TIMEOUT=30000
    
    # External API timeouts (milliseconds)
    GOOGLE_CALENDAR_TIMEOUT=10000
    GMAIL_API_TIMEOUT=10000
    GOOGLE_OAUTH_TIMEOUT=10000
    OPENAI_API_TIMEOUT=30000
    
    # Job timeouts (milliseconds)
    CRON_JOB_TIMEOUT=300000  # 5 minutes max
    
    # HTTP timeouts (milliseconds)
    HTTP_REQUEST_TIMEOUT=30000
    
    # Infrastructure timeouts (seconds for shell scripts)
    MIGRATION_TIMEOUT=600
    BACKUP_TIMEOUT=1800
    
    # Other timeouts (milliseconds)
    EMAIL_TIMEOUT=30000
    WEBSOCKET_TIMEOUT=60000

  • Fichiers :

    • backend/src/common/timeout.config.ts (configuration centralisée) - ✅ Créé
    • backend/src/common/timeout.utils.ts (utilitaires) - ✅ Créé
    • backend/src/common/timeout.middleware.ts (middleware HTTP) - ✅ Créé et appliqué
    • backend/src/common/timeout.module.ts (module NestJS) - ✅ Créé
    • backend/src/db/db.service.ts (timeouts pool et requêtes) - ✅ Appliqué
    • infra/migrate-improved.sh (timeout pour migrations) - ✅ Appliqué
    • infra/backup-db.sh (timeout pour backups) - ✅ Appliqué
    • backend/src/agent/*.ts (timeouts OpenAI appliqués) - ✅ Appliqué
    • backend/src/search/*.ts (timeouts OpenAI appliqués) - ✅ Appliqué
    • backend/src/extraction/services/llm.service.ts (timeouts OpenAI appliqués) - ✅ Appliqué
    • backend/src/openai/openai.service.ts (timeouts OpenAI appliqués) - ✅ Appliqué
    • backend/src/google-calendar/google-calendar.service.ts (timeouts Google Calendar appliqués) - ✅ Appliqué
    • backend/src/quotes-invoices/gmail.service.ts (timeouts Gmail appliqués) - ✅ Appliqué
    • backend/src/*/*.scheduler.ts (timeouts cron appliqués) - ✅ Appliqué

  • Documentation :

    • docs/TIMEOUT_MANAGEMENT.md (guide complet avec statut d'application)
    • docs/ENV_VARIABLES_TIMEOUT.md (liste complète des variables d'environnement)
    • docs/ENV_TIMEOUT_EXAMPLE.txt (exemple à copier dans .env.example)

  • Recommandation : ✅ Complété - Tous les timeouts sont maintenant appliqués dans tous les services et schedulers

4. Circuit breaker pattern

• ✅ Protection contre les cascades d'erreurs - Circuit breaker pour services externes
  • Statut : ✅ Implémenté (janvier 2026)
  • Implémenté :
    • ✅ CircuitBreakerService avec opossum library
    • ✅ États CLOSED/OPEN/HALF_OPEN avec logging
    • ✅ MetricsService avec prom-client pour Prometheus
    • ✅ Endpoint /api/metrics pour scraping
    • ✅ ResilienceService combinant circuit breaker + métriques
    • ✅ MetricsInterceptor pour métriques HTTP automatiques
  • Documentation : docs/RESILIENCE_METRICS.md
  • Statut : ❌ Non implémenté
  • Priorité : Moyenne
  • Effort : 3-4 jours
  • Description : Implémenter circuit breaker pour services externes avec états (open/closed/half-open)
  • Services concernés : Google Calendar API, Gmail API, OpenAI API
  • Implémenté :
    • ✅ Gestion d'erreurs basique avec retry dans certains services
    • ✅ Rate limiting pour protéger contre la surcharge
    • ✅ Cache pour réduire les appels API externes
  • Manquant :
    • ❌ Circuit breaker pattern (open/closed/half-open states)
    • ❌ Fallback automatique en cas d'échec répété
    • ❌ Dégradation gracieuse des fonctionnalités non critiques
    • ❌ Monitoring de l'état des circuits
    • ❌ Configuration des seuils (nombre d'échecs, timeout avant retry)
  • Comportement proposé :
    • Closed : Service fonctionne normalement
    • Open : Service en panne, rejette immédiatement les requêtes (fallback)
    • Half-open : Test périodique pour voir si le service est revenu
  • Recommandation : Implémenter circuit breaker avec bibliothèque comme @nestjs/terminus ou opossum pour NestJS
  • Bénéfices : Évite la surcharge en cas de panne d'un service externe, améliore la résilience, dégradation gracieuse
  • Fichiers : Créer backend/src/common/circuit-breaker.service.ts et l'intégrer dans les services externes

5. Queue system pour jobs lourds

• ✅ Système de queue pour découpler les opérations longues - Traitement asynchrone avec retry automatique
  • Statut : ✅ Complété (2025-01-XX)
  • Priorité : Moyenne
  • Effort : 5-7 jours
  • Description : Utiliser BullMQ pour les jobs lourds avec Redis comme backend
  • Implémenté :
    • ✅ Module QueueModule avec configuration BullMQ
    • ✅ Service QueueService pour gérer les queues et jobs
    • ✅ 6 queues configurées : exports, google-calendar-sync, scheduled-emails, workflow-tasks, recurring-sessions, audit-cleanup
    • ✅ 6 processors implémentés pour chaque type de job
    • ✅ Migration complète des schedulers vers la queue
    • ✅ Migration du ExportController vers la queue
    • ✅ Intégration WebSocket pour les mises à jour de statut en temps réel
    • ✅ Endpoint /export/status/:jobId pour vérifier le statut des jobs
    • ✅ Documentation : QUEUE_SYSTEM.md (résumé), AGENTS_BACKEND.md (documentation interne) § BullMQ (routage)
  • Schedulers migrés :
    • ✅ GoogleCalendarSyncScheduler → Queue google-calendar-sync
    • ✅ ScheduledEmailsScheduler → Queue scheduled-emails
    • ✅ WorkflowTasksScheduler → Queue workflow-tasks
    • ✅ RecurringSessionsScheduler → Queue recurring-sessions
    • ✅ AuditScheduler → Queue audit-cleanup
  • Bénéfices obtenus :
    • ✅ Traitement asynchrone (non-bloquant)
    • ✅ Retry automatique avec backoff exponentiel
    • ✅ Meilleure scalabilité horizontale (workers multiples)
    • ✅ Monitoring des jobs (en cours, en attente, échoués)
    • ✅ Mises à jour en temps réel via WebSocket
  • Architecture implémentée :

    Scheduler → QueueService → Queue (Redis/BullMQ) → Processor → Service
                      ↓
                 WebSocket Updates

  • Outils utilisés : @nestjs/bullmq + bullmq
  • Fichiers créés :
    • backend/src/queue/queue.module.ts
    • backend/src/queue/queue.service.ts
    • backend/src/queue/queue.config.ts
    • backend/src/queue/types/job-data.types.ts
    • backend/src/queue/types/queue-names.types.ts
    • backend/src/workers/worker-export/exports-queue-router.processor.ts (routeur file exports; handlers export:build / doc:* — voir AGENTS_BACKEND.md § BullMQ)
    • backend/src/queue/processors/google-calendar-sync.processor.ts
    • backend/src/queue/processors/scheduled-emails.processor.ts
    • backend/src/queue/processors/workflow-tasks.processor.ts
    • backend/src/queue/processors/recurring-sessions.processor.ts
    • backend/src/queue/processors/audit-cleanup.processor.ts
    • backend/src/queue/queue-board.module.ts - Dashboard Bull Board
    • docs/QUEUE_SYSTEM.md
    • backend/src/queue/README.md
  • Documentation :
    • QUEUE_SYSTEM.md — résumé files, env, processors (routage détaillé : AGENTS_BACKEND.md § BullMQ)
    • backend/src/queue/README.md (documentation technique backend) — README module queue
  • Monitoring :
    • ✅ Bull Board intégré - Dashboard accessible à /ops/queues (ou queues.aaperture.com en production)
    • Visualisation en temps réel de toutes les queues
    • Gestion des jobs (retry, purge, filtrage)

5.1. Architecture Workers BullMQ - Déportement OCR PDF, Relances, IA, Exports 🚀 EN PLANIFICATION

• Blueprint : Déporter les actions longues/lourdes (CPU/IO/externe) dans des workers BullMQ tout en conservant la logique métier transactionnelle dans l'API NestJS.
• Statut : 🚀 En planification - Architecture et plan d'implémentation détaillés disponibles
• Priorité : Haute
• Effort : 4-6 semaines
• Description : Refactorisation de l'architecture pour séparer clairement l'API synchrone (validation + persistance + enqueue) des workers asynchrones (exécution + retries + observabilité).

Principes architecturaux :

• API synchrone = valider (Zod) + persister (Postgres) + enqueue job (BullMQ) + retourner rapidement
• Workers = exécuter + retries/backoff + idempotence + DLQ + observabilité (job_runs)
• Outbox recommandé dès qu'il faut garantir "DB commit → job/event"
• Contrats de jobs stables : payloads versionnés { v: 1, ... } + validation Zod côté worker
• Artefacts (exports, OCR results) stockés en Cloudflare R2 (ou équivalent) via un port StoragePort

Découpage cible (process) :

1. api (NestJS) : REST + auth + règles métier + outbox/enqueue
2. worker-email (NestJS) : emails planifiés, tracking, webhooks
3. worker-ai (NestJS) : appels OpenAI, post-processing, quotas/rate limiting, coûts
4. worker-export (NestJS) : génération CSV/PDF/ZIP, upload R2, presigned
5. worker-doc (NestJS) : orchestration pipeline documents (split pages, enqueue OCR/extraction)
6. ocr-service (Python) optionnel : OCR réel + extraction layout (si besoin libs Python)

Catalogue standard des jobs (BullMQ) :

• email:send - Envoi d'email individuel
• ai:run - Exécution de tâche IA
• export:build - Génération d'export
• doc:ingest - Ingestion de document
• doc:ocr - OCR de document/page
• doc:extract_structured (optionnel) - Extraction structurée
• doc:index_search (optionnel) - Indexation pour recherche

Standard job payload :

• Payload = { v: 1, orgId, userId?, entityId, ... }
• Validation Zod côté worker
• jobId stable pour idempotence : ${orgId}:${jobName}:${entityId}:${hash(stablePayloadPart)}
• Config retries/backoff standardisée : attempts: 5, backoff: { type: "exponential", delay: 3000 }

Tables transversales (recommandées) :

• outbox_events : Garantit transaction DB → publication job/event
• job_runs : Suivi d'exécution et corrélation logs
• file_objects : Référentiel d'artefacts (R2)

Modules détaillés :

• Module A — Document Processing / OCR PDF : Import contrats PDF, questionnaires scannés → OCR + indexation + extraction structurée
• Module B — IA (AI Orchestration) : Assistant IA pour rédaction, résumés, extraction, classification avec quotas/coûts
• Module D — Exports : Exports comptables, contacts, sessions, GDPR export avec stockage R2

Sécurité / Multi-tenant / Permissions :

• Toutes les tables et payloads ont orgId
• Guards API pour droits (exports, docs, outreach)
• Workers valident orgId + existence entité avant exécution
• Audit trail sur opérations sensibles

Observabilité & Ops :

• Corrélation : requestId → jobId → job_runs.id
• Logs structurés start/end + duration + attempts + errors
• Métriques : queue depth, success/fail rate, p95 duration, coûts IA
• DLQ + UI admin "replay job" (optionnel)

Documentation :

• docs/WORKERS_ARCHITECTURE.md : principes, process, queues, conventions jobs
• docs/DOCUMENT_PROCESSING_OCR.md : DDD + DB + endpoints + jobs + UI
• docs/AI_ORCHESTRATION.md : tasks, quotas, coûts, endpoints, worker
• docs/EXPORTS.md : types, statuts, R2, endpoints
• docs/OBSERVABILITY.md : job_runs, corrélation, métriques, DLQ

Checklist d'implémentation :

• Standardiser jobName/jobId + payload versionné { v: 1 }
• Zod validation des payloads côté worker
• Ajouter job_runs + outbox_events si manquants
• Isoler 4 workers : email / ai / export / doc (process séparés)
• Centraliser StoragePort (R2) et mapping file_objects
• Mettre en place polling status sur frontend pour jobs longs
• Ajouter DLQ + replay (optionnel)
• Mettre à jour la documentation (fichiers listés ci-dessus)

Estimation : 4-6 semaines de développement (MVP)

6. Backup et disaster recovery

• ✅ Stratégie de sauvegarde et récupération - Sauvegardes automatiques avec plan de récupération
  • Statut : ✅ Complété (2025-01-XX)
  • Priorité : Haute
  • Effort : 3-5 jours
  • Implémenté :
    • ✅ Script de backup manuel (infra/backup-db.sh)
    • ✅ Service de backup avec endpoint API (BackupService)
    • ✅ Logging des backups dans la DB (backup_logs table)
    • ✅ Compression gzip des backups
    • ✅ Nettoyage automatique des anciens backups (rétention configurable via RETENTION_DAYS)
    • ✅ Sauvegardes automatiques planifiées - Scheduler NestJS quotidien à 2h du matin (BackupScheduler)
    • ✅ Vérification de l'intégrité des backups - Calcul de checksum SHA-256 pour chaque backup
    • ✅ Monitoring des sauvegardes - Statut (completed/failed/in_progress), durée, erreurs enregistrées
    • ✅ Alertes en cas d'échec - Notifications email automatiques si backup échoue
    • ✅ Plan de disaster recovery documenté - Documentation complète dans docs/DISASTER_RECOVERY.md
    • ✅ Statistiques de backup - Méthode getBackupStatistics() pour monitoring
  • Manquant :
    • ❌ Sauvegardes incrémentielles (WAL archiving pour point-in-time recovery)
    • ❌ Tests de restauration réguliers (automatisés)
    • ❌ Sauvegarde des fichiers (R2/Cloudflare) en plus de la DB
    • ❌ Sauvegarde vers un emplacement distant (S3, autre serveur)
  • Stratégie actuelle :
    • Sauvegardes complètes : Quotidiennes à 2h du matin (gardées 30 jours par défaut, configurable via RETENTION_DAYS)
    • Intégrité : Checksum SHA-256 calculé pour chaque backup
    • Monitoring : Tous les backups enregistrés avec statut, durée, erreurs
    • Alertes : Notifications email en cas de succès/échec (si BACKUP_NOTIFICATION_EMAIL configuré)
  • Stratégie future proposée :
    • Sauvegardes incrémentielles : Toutes les 6 heures (gardées 7 jours)
    • Sauvegardes hebdomadaires : Gardées 90 jours
    • Sauvegardes mensuelles : Gardées 1 an
  • Outils : pg_dump pour backups complets, pgBackRest ou WAL-E pour backups incrémentiels (futur), ou solution cloud (RDS snapshots)
  • Fichiers :
    • backend/src/backup/backup.service.ts (service amélioré avec checksum, statut, durée)
    • backend/src/backup/backup.scheduler.ts (scheduler automatique)
    • backend/src/backup/backup.module.ts (module avec scheduler)
    • infra/backup-db.sh (script manuel)
    • infra/liquibase/changes/0111_improve_backup_logs/ (migration pour nouveaux champs)
    • docs/DISASTER_RECOVERY.md (plan de disaster recovery complet)
  • Documentation : docs/DISASTER_RECOVERY.md - Plan complet avec procédures de restauration, scénarios de sinistre, tests de restauration, monitoring

7. Gestion des migrations DB

• ✅ Amélioration du processus de migration - Validation et rollback automatiques
  • Statut : ✅ Complété (2025-01-XX)
  • Priorité : Basse
  • Effort : 1-2 jours
  • Implémenté :
    • ✅ Système de migrations Liquibase avec changelog maître
    • ✅ Scripts de migration (infra/migrate-improved.sh)
    • ✅ Support des rollbacks (down.sql pour chaque migration)
    • ✅ Scripts de rollback dans Makefile (make rollback)
    • ✅ Validation automatique des migrations - Validation de syntaxe SQL avant exécution (migrate-improved.sh)
    • ✅ Rollback automatique en cas d'échec - Tentative automatique de rollback si migration échoue
    • ✅ Vérification de l'ordre des migrations - Validation basique de l'ordre des migrations
    • ✅ Backup automatique avant migration en production - Création automatique de backup avant migration (production uniquement)
    • ✅ Monitoring des migrations - Table migration_logs pour logger statut, durée, erreurs
    • ✅ Script amélioré - migrate-improved.sh avec toutes les fonctionnalités intégrées
  • Implémenté (suite) :
    • ✅ Tests automatisés de migration dans CI/CD - Job test:migrations dans .gitlab-ci.yml qui valide les migrations avant déploiement (infra/test-migrations.sh)
    • ✅ Interface admin pour visualiser les migrations - Onglet "Migrations" dans le panneau admin avec statistiques, liste des migrations, détection des migrations manquantes
    • ✅ Alertes automatiques en cas d'échec de migration - Scheduler NestJS (MigrationsScheduler) qui vérifie quotidiennement les migrations échouées et envoie des emails d'alerte
    • ✅ Validation avancée - Détection des migrations manquantes via comparaison DB/changelog (parsing du changelog-master.yaml et comparaison avec migration_logs)
  • Manquant :
    • ❌ Tests automatisés de migration dans CI/CD avec base de données de test (actuellement SKIP_DB_TEST=true)
    • ❌ Interface pour déclencher manuellement une migration depuis l'admin
    • ❌ Rollback manuel depuis l'interface admin
  • Processus implémenté :
    1. ✅ Validation de la syntaxe SQL via Liquibase validate
    2. ✅ Vérification de l'ordre des migrations
    3. ✅ Backup automatique avant migration en production
    4. ✅ Exécution de la migration avec logging dans migration_logs
    5. ✅ Rollback automatique en cas d'échec
    6. ✅ Mise à jour du statut dans migration_logs
  • Outils : Liquibase avec validation automatique, script amélioré migrate-improved.sh
  • Fichiers :
    • infra/liquibase/changelog-master.yaml (changelog maître)
    • infra/migrate-improved.sh (script principal avec validation, backup, logging, rollback)
    • infra/test-migrations.sh (script de test pour CI/CD)
    • infra/migrate.sh (script basique, déprécié - utiliser migrate-improved.sh)
    • infra/liquibase/changes/0112_create_migration_logs/ (migration pour table de logging)
    • backend/src/migrations/ (service, scheduler, module pour migrations)
    • frontend/src/pages/admin/AdminPanelPage/components/MigrationsTab.tsx (interface admin)
    • frontend/src/client/status/useMigrations.ts (hooks React Query)
    • .gitlab-ci.yml (intégration CI/CD avec job test:migrations)
    • docs/MIGRATION_PROCESS.md (documentation complète)
  • Documentation : docs/MIGRATION_PROCESS.md - Guide complet avec processus, monitoring, gestion des erreurs, bonnes pratiques

8. Gestion des erreurs et retry logic

• ⚠️ Stratégie de retry améliorée - Retry intelligent avec backoff exponentiel
  • Statut : ⚠️ Partiellement implémenté
  • Priorité : Moyenne
  • Effort : 2-3 jours
  • Implémenté :
    • ✅ Retry pour erreurs de connexion DB dans les schedulers (retryQuery)
    • ✅ Gestion d'erreurs basique dans certains services
  • Manquant :
    • ❌ Retry avec backoff exponentiel pour tous les appels API externes
    • ❌ Configuration des stratégies de retry (nombre de tentatives, délai initial, max délai)
    • ❌ Retry sélectif (ne pas retry sur erreurs 4xx, seulement 5xx et timeouts)
    • ❌ Logging des retries pour debugging
    • ❌ Circuit breaker intégré avec retry logic
  • Stratégie proposée :
    • Erreurs réseau/timeout : Retry avec backoff exponentiel (3 tentatives max)
    • Erreurs 5xx : Retry avec backoff exponentiel (2 tentatives max)
    • Erreurs 4xx : Pas de retry (erreur client)
    • Erreurs DB : Retry avec backoff exponentiel (3 tentatives max)
  • Fichiers : Créer backend/src/common/retry.service.ts et l'utiliser dans tous les services externes
  • Recommandation : Utiliser une bibliothèque comme p-retry ou implémenter un helper custom

9. Rate limiting amélioré

• ⚠️ Rate limiting granulaire - Limites par utilisateur, endpoint et type d'opération
  • Statut : ⚠️ Partiellement implémenté
  • Priorité : Moyenne
  • Effort : 2-3 jours
  • Implémenté :
    • ✅ Rate limiting global avec RateLimitingGuard et Redis
    • ✅ Configuration par endpoint avec @RateLimit() decorator
    • ✅ Compteurs Redis pour tracking
  • Manquant :
    • ❌ Rate limiting par utilisateur (limites individuelles)
    • ❌ Rate limiting par type d'opération (ex: limites différentes pour IA vs API normale)
    • ❌ Rate limiting adaptatif (augmenter les limites pour utilisateurs premium)
    • ❌ Headers de rate limiting dans les réponses (X-RateLimit-*)
    • ❌ Monitoring des rate limits (nombre de requêtes bloquées)
  • Améliorations proposées :
    • Headers X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
    • Limites différentes pour les plans d'abonnement (FREE, BASIC, PRO)
    • Limites spécifiques pour les endpoints IA (plus restrictives)
  • Fichiers : backend/src/rate-limiting/rate-limiting.guard.ts
  • Recommandation : Étendre le système actuel avec des limites granulaires et des headers de réponse

10. Gestion de la charge et autoscaling

• ❌ Autoscaling et gestion de la charge - Scalabilité horizontale automatique
  • Statut : ❌ Non implémenté
  • Priorité : Basse (pour l'instant, mais importante pour la croissance)
  • Effort : 5-7 jours
  • Description : Mise en place d'un système d'autoscaling basé sur la charge
  • Composants :
    • Monitoring de la charge (CPU, mémoire, nombre de requêtes)
    • Décision d'autoscaling (règles de scaling up/down)
    • Provisionnement automatique de nouvelles instances
    • Load balancing entre instances
  • Recommandation : Utiliser Kubernetes avec HPA (Horizontal Pod Autoscaler) ou solution cloud (AWS Auto Scaling, Google Cloud Autoscaler)
  • Prérequis : Application doit être stateless (sessions dans Redis, pas de state local)
  • Bénéfices : Scalabilité automatique selon la charge, réduction des coûts en période creuse

11. Sécurité infrastructure

• ⚠️ Renforcement de la sécurité infrastructure - Protection contre les attaques et vulnérabilités
  • Statut : ⚠️ Partiellement implémenté
  • Priorité : Haute
  • Effort : 3-5 jours
  • Implémenté :
    • ✅ Rate limiting pour protection contre DDoS
    • ✅ Validation des entrées (Zod schemas)
    • ✅ Sanitization HTML pour prévenir XSS
    • ✅ Authentification JWT avec expiration
  • Manquant :
    • ❌ WAF (Web Application Firewall) pour protection contre les attaques courantes
    • ❌ Détection d'intrusion (IDS) et prévention (IPS)
    • ❌ Scans de sécurité automatisés (OWASP ZAP, Snyk)
    • ❌ Rotation automatique des secrets (tokens, clés API)
    • ❌ Chiffrement des données au repos (DB, fichiers)
    • ❌ Audit de sécurité régulier
  • Recommandation : Intégrer WAF (Cloudflare, AWS WAF), activer le chiffrement au repos pour la DB, mettre en place la rotation des secrets
  • Fichiers : Configuration infrastructure (infra/docker-compose.*.yml), CI/CD (.gitlab-ci.yml)

12. Documentation infrastructure

• ⚠️ Documentation complète de l'infrastructure - Runbooks et guides opérationnels
  • Statut : ⚠️ Partiellement implémenté
  • Priorité : Moyenne
  • Effort : 2-3 jours
  • Implémenté :
    • ✅ Documentation technique développeur (docs/BACKEND.md, docs/ARCHITECTURE.md)
    • ✅ README avec instructions de setup
  • Manquant :
    • ❌ Runbooks pour incidents courants (DB down, Redis down, service externe down)
    • ❌ Guide de disaster recovery (étapes de restauration)
    • ❌ Documentation des procédures de déploiement
    • ❌ Diagrammes d'architecture infrastructure (diagrammes de déploiement)
    • ❌ Documentation des variables d'environnement (description de chaque variable)
  • Recommandation : Créer docs/INFRASTRUCTURE.md et docs/RUNBOOKS.md avec les procédures opérationnelles

📚 Documentation & Support

Suggestions basées sur l'analyse

• ⚠️ Documentation utilisateur - Documentation complète pour les utilisateurs finaux
  • Partiellement implémenté : Documentation technique développeur (docs/), README avec setup
  • Manquant : Documentation utilisateur final, guides d'utilisation, tutoriels
• ❌ Tutoriels interactifs - Tutoriels interactifs pour guider les nouveaux utilisateurs
  • Non implémenté : Pas de tutoriels interactifs (onboarding basique existe mais pas de tutoriels)
• ❌ Centre d'aide intégré - Centre d'aide accessible depuis l'application
  • Non implémenté : Pas de centre d'aide intégré
• ❌ Chat support - Chat support intégré pour l'assistance utilisateur
  • Non implémenté : Pas de chat support intégré
• ❌ Base de connaissances - Base de connaissances avec articles et FAQ
  • Non implémenté : Pas de base de connaissances

🌐 Élargissement multi-métier (événementiel)

Objectif : Planifier l’évolution du produit pour d’autres métiers de l’événementiel (traiteurs, DJ, wedding planners, etc.) sans tout réécrire.

• Terminologie : Stratégie "métier configurable" : libellés (session vs événement vs prestation), types par défaut (mariage, portrait, etc.) extensibles par métier.
• Données : Champs communs (contact, date, lieu, montants) vs champs spécifiques métier (ex. type de session, checklist type "photo" vs "traiteur").
• Portail client : Positionnement pour un "client événementiel" (plusieurs prestataires) plutôt que "client photographe" uniquement.
• Thèmes de travail : i18n, types de session, rôles, onboarding par métier. Pas d’engagement de délais ; voir ROADMAP.md pour la section "Élargissement événementiel".

🗺️ Roadmap par horizon (révision 2026)

Court terme

1. Billing / export comptable CSV ✅
   • export-first — ACCOUNTING_EXPORT_GUIDE.md.
2. Storage abstraction ✅ + migration Scaleway ⏸️
   • abstraction livrée sur R2 ; migration Scaleway en pause (2026-10-23).
3. Relances automatiques
   • relances devis/factures et rappels session réellement fiables via workflows et jobs dédiés.
4. Cleanup Vague D
   • tables orphelines + Galleries F002 — APP_CLEANUP_MAP.md / DB_CLEANUP_AUDIT.md.

Soldé : Proposal commercial (/proposal, upsells) — DELETED FE/BE/DB (0277). Day-planner proposals KEEP.

Moyen terme

• Sync avancé Pennylane
  • webhooks, statuts, paiements, avoirs, paiements partiels, réconciliation métier.
• Portail client V2 enrichi
  • documents, factures externes, historiques d’action, meilleure lisibilité des états financiers.
• Analytics business
  • vues revenus, conversion devis -> facture -> paiement, performance commerciale par type de séance.
• Iris proactive V1
  • suggestions et relances contextuelles réellement pilotées par données CRM et signaux business.

Long terme

• Relais des statuts de facturation électronique
  • exposition des états réglementaires venant du provider sans reconstruire la logique fiscale complète.
• Iris avancée
  • orchestration proactive multi-surface, priorisation métier, recommandations plus prédictives.
• Marketplace de templates
  • templates documents, workflows, pages publiques et blocs de communication.
• Élargissement multi-métiers
  • ouverture structurée à d’autres métiers de l’événementiel.

🔁 Priorités actives requalifiées

• La conformité n’est pas supprimée :
  • elle reste un sujet de confiance, de documentation, d’archivage et d’intégration,
  • mais elle n’est plus portée comme un chantier principal de certification interne complète.
• La priorité facturation active devient :
  • provider externe de facturation,
  • mapping métier robuste,
  • sync des documents et statuts,
  • exposition homogène dans l’app et le portail.
• Le stockage souverain devient :
  • un axe infra officiel,
  • transversal à documents, portal files, galleries, slideshow/video,
  • encapsulé derrière une interface compatible S3 et transparente pour les modules NestJS/React/BullMQ.

📊 Résumé de l'état d'avancement

Pour les priorités de développement et les prochaines étapes, consultez PRIORITES.md

Fonctionnalités majeures complétées récemment

1. ✅ Socle de facturation interne robuste (100% complété) - 2024-12-19

   • Numérotation séquentielle atomique, immutabilité vérifiable, conformité France/UE de base
   • Calculs précis, avoirs, paiements unifiés, export comptable, audit trail complet
   • Endpoints admin, préparation E-invoicing, tests complets
   • Requalification 2026 : ce socle devient la base métier d’un BillingProvider externe, avec Pennylane comme cible prioritaire
   • Documentation : BILLING.md

2. ✅ Système de réservation publique (100% complété)

   • Interface publique, calendrier interactif, gestion des bookings
   • ✅ Mise en avant sur la landing page - Section dédiée ajoutée avec présentation des avantages (2026-01-17)
   • Documentation : BOOKING_SYSTEM.md et BOOKING_IMPROVEMENTS.md

3. ✅ Global Search & IA - Phase 1 (100% complété)

   • Assistant conversationnel, vues personnalisées, actions complexes
   • Documentation : AI_SEARCH_ARCHITECTURE.md

4. ✅ Synchronisation Google Calendar (100% complété)

   • Sync bidirectionnelle, gestion de disponibilité, résolution de conflits
   • Documentation : CALENDAR_SYNC_ARCHITECTURE.md

5. ✅ Notifications Push (100% complété)

   • Notifications navigateur, in-app, intégration avec actions IA
   • Documentation : TESTING_WEB_PUSH.md

6. ✅ Dark / Light Mode (100% complété)

   • Thème sombre, détection automatique, persistance des préférences

7. ✅ Gestion centralisée des types via OpenAPI (100% complété)

   • Audit complet et migration de tous les types partagés vers OpenAPI
   • Types scope-specific dans fichiers types.ts appropriés
   • Documentation complète des règles de gestion des types
   • Correction des erreurs de validation OpenAPI
   • Documentation : docs/AGENTS_OPENAPI.md

8. ✅ Calendrier visuel amélioré (100% complété)

   • Vues timeline semaine et jour, visualisation des chevauchements, légende interactive, filtres visuels, vue agenda/liste, drag & drop dans toutes les vues
   • Documentation : CALENDAR_SYNC_ARCHITECTURE.md, APP_OVERVIEW.md

9. ✅ GDPR / RGPD - Portail de gestion des données (100% complété)

   • Portail complet avec tous les droits RGPD
   • Gestion des consentements avec traçabilité
   • Export de données (JSON, CSV, XML)
   • Suppression sécurisée (FULL, PARTIAL, ANONYMIZATION)
   • Protection contre les race conditions et vulnérabilités
   • Documentation : backend/src/gdpr/README.md

10. ✅ Intégration Stripe complète (100% complété)

    • Gestion des abonnements (FREE, BASIC, PRO) avec cycles mensuels/annuels
    • Paiement des factures via Stripe Payment Intents
    • Collecte de méthodes de paiement via SetupIntent
    • Attachement de méthodes de paiement au client Stripe
    • Webhooks pour synchronisation automatique des statuts
    • Historique des paiements
    • Interface utilisateur complète avec Stripe Elements
    • Documentation : backend/src/stripe/README.md

11. ✅ Backup et disaster recovery (100% complété)

    • Sauvegardes automatiques quotidiennes (scheduler NestJS à 2h du matin)
    • Vérification d'intégrité avec checksum SHA-256
    • Monitoring complet (statut, durée, erreurs)
    • Alertes email en cas d'échec
    • Plan de disaster recovery documenté
    • Statistiques de backup pour monitoring
    • Documentation : docs/DISASTER_RECOVERY.md

12. ✅ Amélioration du processus de migration (100% complété)

• Validation automatique des migrations avant exécution
• Backup automatique avant migration en production
• Logging complet dans table migration_logs (statut, durée, erreurs)
• Rollback automatique en cas d'échec
• Vérification de l'ordre des migrations
• Script amélioré migrate-improved.sh avec toutes les fonctionnalités
• Documentation : docs/MIGRATION_PROCESS.md

13. ❌ Système de progression — DELETED (Vague A, 2026-07)

• Code removed; progression_* tables → later DB drop. See APP_CLEANUP_MAP.md.

14. ✅ Système d'organisations (100% complété - Backend + Frontend) - 2026-01-16

    Backend :

• Création et gestion d'organisations : Les utilisateurs peuvent créer des organisations et inviter d'autres utilisateurs
• Gestion des membres : Rôles (OWNER, ADMIN, MEMBER, VIEWER) avec permissions granulaires
• Partage de ressources : Partage de sessions, devis, factures, contrats, contacts avec permissions (read, write, delete)
• Système d'invitations : Invitations par email avec tokens sécurisés
• Vérification d'accès : Service helper pour vérifier l'accès aux ressources via organisations
• Intégration dans les services existants : Support du partage via OrganizationAccessService

Frontend :

• Hooks React Query complets pour toutes les opérations (list, get, create, update, delete, members, resources)

• Pages complètes : Liste, création, édition, vue détaillée avec onglets (Overview, Members, Resources)

• Composants : CreateOrganizationDialog, MembersTab, ResourcesTab avec gestion complète

• Routes intégrées dans le router TanStack React Router

• Formulaires avec react-hook-form et validation Zod

• Traductions i18n complètes

• Optimistic updates et invalidation du cache

• Documentation : backend/src/organizations/README.md

Notes

• Ce plan est évolutif et doit être mis à jour régulièrement
• Les priorités peuvent changer en fonction des retours utilisateurs
• Certaines améliorations peuvent être combinées pour optimiser le développement
• Il est important de valider les besoins avec les utilisateurs avant de développer
• Voir les documentations spécifiques pour plus de détails sur chaque fonctionnalité