🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• RÉGRESSION FONCTIONNELLE : Suppression des événements de ticket en vue PPE sans justification métier documentée - les utilisateurs PPE perdent potentiellement la visibilité sur les tickets en attente (status: 'pending'), ce qui pourrait impacter le suivi opérationnel si ces tickets sont utilisés pour tracer des actions requises
• ABSENCE DE TESTS AUTOMATISÉS : L'approche de test déclarée est uniquement manuelle ('tester le tableau de bord') - insuffisant pour un refactoring touchant 13+ requêtes indépendantes et 2 vues distinctes, risque élevé de régression silencieuse
• RISQUE DE DISPONIBILITÉ : Promise.all échoue entièrement si une seule requête échoue - aucune gestion d'erreur partielle (Promise.allSettled) visible, ce qui signifie qu'une erreur sur une requête secondaire (ex: convocations) pourrait empêcher l'affichage de tout le tableau de bord
• MANQUE DE MÉTRIQUES : Aucune mesure de performance avant/après documentée - impossible de quantifier le gain business réel pour justifier l'investissement de développement et le risque de régression
• COMPLEXITÉ DE MAINTENANCE : Prolifération de 13+ fonctions de requêtes exportées sans documentation des responsabilités - duplication logique probable entre requêtes utilisateur et PPE, risque de divergence future

• Types 'any' omniprésents dans defineTicketEvents, defineTaskEvents, defineConvocationEvents - aucun typage TypeScript des réponses GraphQL, rendant le code fragile
• Aucun test automatisé pour cette refonte - les tests sont uniquement manuels, insuffisant pour 6 types d'événements impactés
• Promise.all sans Promise.allSettled - une seule requête en échec fait échouer tout le chargement du tableau de bord sans fallback partiel
• Duplication entre requêtes User et PPE (ex: getTenueAgEventsByUserQuery vs getTenueAgEventsByPpeIdQuery) - une abstraction commune réduirait la maintenance
• Formatage Prettier mélangé aux changements fonctionnels - un commit séparé serait préférable pour faciliter la review

• DUPLICATION queries.tsx : 12 requêtes au pattern identique (filtre + fragments GraphQL) = ~360 lignes répétitives. Solution : créer une factory createEventQuery(type, filterFields) générant la requête gql dynamiquement, réduisant le code à ~50 lignes
• REGRESSION TYPIQUE queries.tsx : nouvelles fonctions ({ userId, endDate }) sans annotation TypeScript vs interface typée originale. Solution : définir des interfaces QueryParams partagées (UserQueryParams, PpeQueryParams) et les appliquer systématiquement
• RISQUE FONCTIONNEL dashboard.store.tsx : Promise.all rejette TOUT si UNE promesse échoue - régression par rapport au séquentiel où les données partielles s'affichaient. Solution : migrer vers Promise.allSettled, filtrer les résultats fulfilled, logger les rejected, et afficher les données disponibles avec indication visuelle des sections en échec
• ABSENCE DE TESTS : aucun test unitaire ni d'intégration pour ce refactoring critique du pattern de chargement. Solution minimale : tester le comportement avec 1 requête en échec sur N, vérifier que les données partielles s'affichent, tester les types des paramètres des nouvelles fonctions
• IMPORTS EXCESSIFS dashboard.store.tsx : 13 imports de requêtes. Solution : organiser queries.tsx en barrel exports par domaine (export * as UserQueries from './user-queries') ou sous-modules (user-queries.ts, ppe-queries.ts)

• Aucun test automatisé inclus dans le commit - refactoring à haut risque (+358/-120 lignes, 11 hunks) sans filet de sécurité
• L'approche de test déclarée est purement manuelle ('Tester le tableau de bord'), inacceptable pour un changement affectant le chargement critique du dashboard
• Changement sémantique des filtres GraphQL non testé : isTask: {eq: true} remplacé par ticketClass: {eq: 'task'} dans queries.tsx - équivalence comportementale non vérifiée
• Changement de logique de filtrage PPE non testé : ppe: {id: {eq: ppeId}} remplacé par assignedCollaborators: {id: {in: [ppeId]}} - logique métier fondamentalement différente
• Pattern Promise.all sans gestion d'erreur visible : fail-fast si une requête échoue, nécessite Promise.allSettled ou gestion d'erreur individuelle avec tests de résilience associés

• queries.tsx - Duplication GraphQL massive : les sélections de champs pour chaque type (AG, PV, Ticket) sont copiées intégralement dans chaque sous-requête. Exemple concret : les champs tenueAgEvents apparaissent dans getTenueAgEventsByUserQuery ET getTenueAgEventsByPpeIdQuery. Solution : fragments GraphQL partagés (fragment AgEventFields on AG) réduisant la duplication à un seul point de définition par type.
• dashboard.store.tsx - Promise.all sans tolérance aux erreurs partielles : si getTicketEventsByUserQuery échoue (timeout Strapi, erreur réseau), le dashboard entier affiche une erreur au lieu de présenter les 10 autres types d'événements. Architecture cible : Promise.allSettled + filtrage des résultats rejetés + indicateur visuel de données partielles.
• dashboard.store.tsx - Synchronisation fragile index-destructuring : le tableau eventsPromises[0..6] doit correspondre exactement à la déstructuration const [tasks, docSigs, tickets, ...] = await Promise.all(eventsPromises). Un déplacement accidentel d'un élément du tableau introduit un bug silencieux où les événements sont assignés au mauvais type. Solution : objet Map ou nommage explicite des promesses.
• queries.tsx - Typage TypeScript absent sur les fonctions de génération : getTicketEventsByUserQuery({ regieId }) ne montre aucun type pour regieId, contrairement à l'original getEventsByUserId qui définissait une interface getEventsByUserId. Régression de sécurité à la compilation.
• Absence de tests automatisés pour un refactoring critique du chemin de chargement principal. Les cas non couverts incluent : échec partiel de requête, concurrence réseau, ordre de résolution variable des promesses, régression des données concaténées.

Tour 2 : Préoccupations et questions

• RÉGRESSION DISPONIBILITÉ : Promise.all (dashboard.store.tsx) fait échouer tout le dashboard si une seule requête échoue. Un timeout sur les signatures empêche l'affichage des tâches, convocations, PV et tenues d'AG. Régression par rapport au séquentiel. Solution : Promise.allSettled + indicateur visuel de données partielles.
• RÉGRESSION PPE NON JUSTIFIÉE : filtre ppe: {id: {eq: ppeId}} remplacé par assignedCollaborators: {id: {in: [ppeId]}} dans queries.tsx. Ces filtres ciblent des relations GraphQL différentes. Les utilisateurs PPE pourraient perdre la visibilité sur des tickets en attente sans notification.
• FRAGILITÉ DÉSTRUCTURATION INDEXÉE : const [tasks, docSigs, tickets, ...] dépend d'un ordre implicite. Un déplacement accidentel introduit un bug silencieux (convocations affichées comme tâches). Solution : objet de promesses nommées.
• AUCUNE MÉTRIQUE DE PERFORMANCE : le gain de temps de chargement n'est pas mesuré. Investissement de 16h + risque de régression sans preuve de gain = décision business non étayée.
• DUPLICATION MAINTENANCE : 13+ requêtes dupliquées (~360 lignes). Tout ajout de champ futur nécessite 2-3 modifications synchronisées. Fragments GraphQL partagés réduiraient ce risque.

• Fragilité index-destructuring dashboard.store.tsx : tableau eventsPromises ordonné déstructuré positionnellement - un réordonnancement accidentel introduit bug silencieux sans erreur compilation, nécessite refactoring vers pattern nommé (Map ou objet promesses nommées)
• Changements sémantiques filtres non vérifiés automatiquement : isTask:{eq:true}→ticketClass:{eq:'task'} et ppe:{id:{eq:ppeId}}→assignedCollaborators:{id:{in:[ppeId]}} modifient logique filtrage métier - équivalence supposée pour Strapi v4 mais non prouvée par tests automatisés
• Promise.all sans tolérance partielle : une seule requête en échec fait échouer tout le dashboard - Promise.allSettled avec filtrage rejected et indicateur données partielles est amélioration prioritaire backlog
• Absence tests automatisés pour refactoring critique : 6 types événements, 2 vues, changements filtres sémantiques, 29 chunks - tests manuels insuffisants comme filet de sécurité régression
• Formatage Prettier mélangé changements fonctionnels (+281/-82 dashboard.store.tsx) : complique review git, devrait être commit séparé

• RÉGRESSION TYPESCRIPT CRITIQUE : interfaces typées originales supprimées sans remplacement - getTaskEventsByUserIdQuery({ userId, endDate }) sans types vs interface d'origine avec string | null. Estimation remediation : 3h
• RÉGRESSION FONCTIONNELLE PPE CONFIRMÉE PAR LE CODE : filtre ppe: {id: {eq: ppeId}} remplacé par assignedCollaborators: {id: {in: [ppeId]}} - logiques de filtrage incompatibles sans justification documentée. Impact métier potentiel élevé
• DUPLICATION MASSIVE : 12+ requêtes au pattern identique (~360 lignes) sans fragments GraphQL partagés. Remediation via fragments : estimation 6h, réduction à ~80 lignes
• PROMISE.ALL SANS TOLÉRANCE AUX ERREURS : une seule requête en échec sur 13+ bloque l'affichage complet du dashboard. Promise.allSettled + filtrage fulfilled + indication visuelle partielle requis. Estimation : 4h
• ABSENCE TOTALE DE TESTS : refactoring critique (+358/-120 lignes, 13+ requêtes) sans aucun test automatisé. Tests minimum requis : échec partiel de requêtes, équivalence des filtres, types des paramètres. Estimation : 5h

• ZÉRO test automatisé pour +358/-120 lignes modifiées touchant le chemin de chargement principal du dashboard - aucune régression ne peut être détectée automatiquement
• Filtre GraphQL isTask:{eq:true} remplacé par ticketClass:{eq:'task'} dans queries.tsx sans test vérifiant l'équivalence - tickets avec isTask=true mais ticketClass≠'task' seraient silencieusement exclus
• Filtre PPE ppe:{id:{eq:ppeId}} remplacé par assignedCollaborators:{id:{in:[ppeId]}} dans queries.tsx sans test - ces filtres ciblent des entités différentes, les résultats peuvent diverger
• Promise.all sans test de résilience dans dashboard.store.tsx - 1 échec sur 13+ requêtes bloque l'affichage complet du dashboard sans dégradation partielle
• Destructuration index-based fragile sans test de mapping - eventsPromises[0]→tasks, [1]→docSigs : un déplacement accidentel = bug silencieux

• [CRITIQUE] [queries.tsx] Changement sémantique de filtre non équivalent : ppe:{id:{eq:ppeId}} cible l'entité PPE, assignedCollaborators:{id:{in:[ppeId]}} cible le collaborateur assigné. Relations de graphe différentes dans Strapi. Bug fonctionnel potentiel nécessitant validation backend immédiate.
• [CRITIQUE] [dashboard.store.tsx] Promise.all sans tolérance aux erreurs partielles : une seule requête en échec sur 11 bloque tout le dashboard. Régression de résilience par rapport au séquentiel. Solution : Promise.allSettled + filtrage fulfilled. Dette : 2-3h.
• [ÉLEVÉ] [queries.tsx] Duplication GraphQL massive : ~360 lignes répétitives entre variantes User/PPE pour 6 types d'événements. Violation DRY. Solution : fragments GraphQL partagés. Dette : 3-4h.
• [ÉLEVÉ] [queries.tsx] Régression typage TypeScript : interface getEventsByUserId supprimée, nouvelles fonctions sans annotation. Perte de sécurité à la compilation. Dette : 1-2h.
• [MODÉRÉ] [dashboard.store.tsx] Destructuration positionnelle fragile : eventsPromises[0..6] mappé positionnellement. Bug silencieux si réordonnancement. Solution : objet nommé de promesses. Dette : 1h.

Tour 3 : Validation

• RÉGRESSION DISPONIBILITÉ : Promise.all dans dashboard.store.tsx bloque tout le dashboard si UNE requête sur 13+ échoue. Avant : données partielles. Après : aucune donnée. Impact : utilisateurs bloqués. Remediation : Promise.allSettled (3h).
• RÉGRESSION DONNÉES PPE : queries.tsx change ppe:{id:{eq:ppeId}} vers assignedCollaborators:{id:{in:[ppeId]}}. Filtres non équivalents ciblant des entités Strapi différentes. Impact : tickets invisibles pour utilisateurs PPE. Validation backend urgente.
• ZÉRO TEST : +358/-120 lignes sur chemin critique sans test automatisé. Changements filtres (isTask→ticketClass, ppe→assignedCollaborators) non vérifiés. Aucune détection régression possible.
• DUPLICATION 360 LIGNES : 13+ requêtes GraphQL dupliquées sans fragments partagés. Coût maintenance futur élevé. Fragments réduiraient à 80 lignes (5h).
• FRAGILITÉ DESTRUCTURATION : eventsPromises[0]→tasks dépend d'ordre implicite. Bug silencieux si réordonnancement. Solution : promesses nommées (1h).

• Filtre PPE assignedCollaborators:{id:{in:[ppeId]}} (chunk [4]) remplace ppe:{id:{eq:ppeId}} - relations GraphQL différentes dans Strapi, validation backend formelle requise (2h remediation)
• Promise.all sans tolérance partielle dans dashboard.store.tsx (chunk [2]) - 1 échec sur 13+ requêtes bloque affichage complet dashboard, Promise.allSettled nécessaire (3h remediation)
• Interfaces TypeScript supprimées sans remplacement - fonctions exportées sans annotations types, perte sécurité compilation (2h remediation)
• Destructuration positionnelle fragile eventsPromises[0]→tasks (chunk [2]) - réordonnancement accidentel = bug silencieux, pattern nommé préférable (1h remediation)
• Changement filtre isTask:{eq:true} → ticketClass:{eq:'task'} (chunk [3]) sans test automatisé validant équivalence - tickets avec isTask=true mais ticketClass≠'task' seraient silencieusement exclus

• BUG FONCTIONNEL queries.tsx diff[4] : ppe:{id:{eq:ppeId}} vers assignedCollaborators:{id:{in:[ppeId]}} change relation ciblée - utilisateurs PPE perdent visibilité tickets
• RÉGRESSION TYPESCRIPT queries.tsx diff[3] : interface getEventsByUserId supprimée, paramètres sans annotation - perte sécurité compilation
• PROMISE.ALL sans allSettled dashboard.store.tsx : 1 échec sur 13 requêtes = dashboard vide
• VIOLATION DRY queries.tsx : 13 fonctions identiques (~360 lignes), fragments GraphQL réduiraient à ~80 lignes
• DESTRUCTURATION POSITIONNELLE dashboard.store.tsx : ordre implicite, bug silencieux si réordonnancement

• Zéro test automatisé pour +358/-120 lignes touchant le chemin de chargement principal du dashboard - confirmé par l'auteur aux concerns 14 et 25
• Changement filtre isTask:{eq:true} vers ticketClass:{eq:'task'} dans queries.tsx chunk 3 sans test d'équivalence - tickets avec isTask=true mais ticketClass différent seraient silencieusement exclus du dashboard
• Changement filtre ppe:{id:{eq:ppeId}} vers assignedCollaborators:{id:{in:[ppeId]}} dans queries.tsx chunk 4 sans test - relations GraphQL différentes, architecte senior qualifie de bug fonctionnel potentiel au concern 16
• Promise.all sans tolérance aux erreurs partielles dans dashboard.store.tsx - 1 échec sur 13+ requêtes bloque tout le dashboard sans dégradation partielle - auteur reconnaît au concern 13
• Destructuration positionnelle fragile eventsPromises[0..n] dans dashboard.store.tsx - réordonnancement accidentel = bug silencieux sans erreur compilation - auteur reconnaît au concern 11

• CRITIQUE queries.tsx:285 - Filtre PPE changé de ppe:{id:{eq:ppeId}} vers assignedCollaborators:{id:{in:[ppeId]}} sans justification. Relations de graphe Strapi différentes. Bug fonctionnel potentiel : tickets PPE-propriétaire non-collaborateur exclus silencieusement
• CRITIQUE dashboard.store.tsx:187 - Promise.all sans tolérance erreurs partielles. 1 échec sur 11+ requêtes = dashboard entièrement inaccessible. Régression de résilience vs séquentiel
• ÉLEVÉ queries.tsx:15-350 - Duplication GraphQL ~360 lignes sans fragments partagés. 12+ requêtes avec 90% de code identique. Violation DRY : chaque évolution de champ = 2-3 modifications synchronisées
• ÉLEVÉ queries.tsx:15 - Régression TypeScript : interface typée supprimée, paramètres non annotés sur toutes les nouvelles fonctions. Perte sécurité compilation
• MODÉRÉ dashboard.store.tsx:190 - Destructuration positionnelle fragile [tasks, docSigs, tickets, ...] dépendant d'ordre implicite. Bug silencieux si réordonnancement