🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• Aucun test automatisé pour des champs métier critiques - 'processing_date_limit' et 'responsible' n'ont ni tests unitaires ni tests d'intégration, créant un risque de régression sur la validation Zod et l'affichage tableau
• Mélange de préoccupations dans un commit : l'ajout fonctionnel (2 champs métier) et la refactorisation technique (react-dropzone) devraient être séparés pour faciliter la revue, le rollback et l'évaluation de la valeur métier
• La synchronisation manuelle DataTransfer (DraftAccountingEntryForm.tsx, lignes 60-63) entre react-dropzone et l'input file natif est fragile - un bug ici bloquerait l'upload de pièces justificatives, impact opérationnel direct
• Le champ 'processing_date_limit' n'est pas marqué comme 'required' dans le schema backend - si la date limite est métier-critique pour le suivi des échéances, cette omission permet des entrées incomplètes
• Le modèle Collaborator est créé uniquement pour les options du dropdown responsable - risque de duplication si une entité Collaborator existe déjà ailleurs dans le codebase

• Absence de tests - la validation Zod et le comportement dropzone devraient être couverts. Justifié par les contraintes de livraison, mais dette de ~2h pour ajouter les tests manquants.
• Coexistence composants v1/v2 dans DraftAccountingEntryForm.tsx - compromis délibéré pour migration progressive sans régression. Dette estimée : ~2h pour finaliser la migration complète.
• Synchronisation DataTransfer API (lignes 68-76) - solution pragmatique mais fragile si le formulaire évolue vers un upload direct API. À réévaluer lors de la refactorisation complète du flux de soumission.
• Champ processing_date_limit optionnel en backend (pas de required:true) - décision métier délibérée, mais à confirmer avec le produit pour éviter des incohérences de données.
• Double ligne vide après useDropzone - style mineur indiquant un linting insuffisant, à corriger au prochain passage.

• Absence totale de tests pour les nouveaux champs, la validation Zod et les server actions
• Le champ processing_date_limit n'est pas required, risque de données incomplètes
• Croissance significative du composant formulaire (+102 lignes nettes) sans vérification de la maintenabilité
• Introduction de react-dropzone sans évaluation de l'alternative native ou de la justification de la dépendance
• Le modèle Collaborator (+58 lignes) pourrait dupliquer des types existants si un modèle User est déjà présent

• Aucun fichier de test ajouté ou modifié - dette de test critique pour des fonctionnalités métier
• Accès imbriqué non protégé dans le callback onDrop : fileRejections[0].errors[0].code risque de throw si la structure est inattendue
• Manipulation directe du DOM via inputFileRef.current.value = '' - pattern difficile à tester et fragile
• Utilisation de l'API DataTransfer comme workaround - problèmes potentiels de compatibilité navigateur et de testabilité
• Aucun test de validation Zod pour les nouveaux champs processing_date_limit et responsible

• Couplage domaine auth/comptable : La relation responsible_accounting_entries sur User (schema.json ligne 167+) transforme progressivement le modèle d'authentification en god-object. Solution recommandée : créer un modèle Collaborator backend ou une table de liaison pour découpler les domaines.
• Incohérence de validation entre couches : processing_date_limit et responsible sont optionnels dans schema.json mais requis dans le schéma Zod frontend. L'API Strapi directe permet de créer des entrées sans responsable, contournant la validation métier. Impact : données incohérentes en production.
• Décalage sémantique Collaborator/User : Le modèle collaborator.model.ts (58 lignes) n'a pas d'équivalent backend. Le mapping entre Collaborator et User est implicite, rendant les évolutions structurelles risquées si les modèles divergent.
• Server actions sans couche de service : action.ts mélange logique de récupération de données et orchestration de création, limitant la testabilité et la réutilisabilité. Pattern à corriger avant l'accumulation de dette.
• Absence de tests : 325 lignes ajoutées sans couverture de test sur les validations Zod, le modèle Collaborator, et les server actions. Risque de régression élevé sur le chemin critique de création d'entrée comptable.

Tour 2 : Préoccupations et questions

• Incohérence validation frontend/backend : accountingEntry.schema.ts Zod requiert processing_date_limit et responsible, mais accounting-entry/schema.json les accepte vides (pas de required:true) - les appels API directs contourneront la validation métier
• Zéro test sur 325 lignes ajoutées : validation Zod des nouveaux champs, modèle Collaborator.model.ts avec requête GraphQL filtrée par regieId et rôles, synchronisation DataTransfer lignes 60-63 DraftAccountingEntryForm.tsx
• Mélange de préoccupations : l'ajout de 2 champs métier (valeur utilisateur directe) et la refactorisation react-dropzone (dette technique) devraient être des commits séparés pour permettre rollback sélectif et évaluation indépendante de la valeur livrée
• processing_date_limit optionnel en backend contredit l'exigence métier de suivi des échéances - permet des entrées comptables sans date limite de traitement
• Collaborator.model.ts (58 lignes) sans équivalent backend : mapping implicite User vers Collaborator avec filtres par regieId et rôles Admin Régie/Collaborateur Régie risque de diverger si le modèle utilisateur évolue

• L'incohérence validation backend/frontend (processing_date_limit optionnel backend mais requis Zod) mérite une correction prioritaire - risque de données incohérentes via API directe
• La synchronisation DataTransfer est un compromis pragmatique mais fragile - à réévaluer lors de la migration vers un upload API direct
• Dette de test de ~2h pour validation Zod et comportement dropzone - à planifier sprint suivant
• Le modèle Collaborator devrait être aligné avec un éventuel modèle backend si l'entité évolue

• Incohérence validation Zod required vs backend optional pour processing_date_limit/responsible - données incohérentes possibles via API directe
• Aucun test sur 325 lignes ajoutées - validation Zod, server actions et modèle Collaborator non couverts
• DataTransfer workaround lignes 68-76 fragile et non testable pour synchroniser react-dropzone avec input natif
• Accès non protégé fileRejections[0].errors[0].code risque TypeError dans onDrop
• Modèle Collaborator (58 lignes) sans équivalent backend - risque divergence sémantique User/Collaborator

• 0 fichier de test pour 325 lignes de code comptable - risque de régression sur le chemin critique de création d'entrées
• fileRejections[0].errors[0].code sans optional chaining - TypeError garanti si tableaux vides, aucun test aux limites
• DataTransfer workaround (lignes 68-76) non testable unitairement et risque de compatibilité Safari < 15.4
• inputFileRef.current.value='' - manipulation DOM directe nécessitant mock useRef complexe pour test unitaire
• Validation Zod pour processing_date_limit/responsible sans tests malgré incohérence backend optionnel vs frontend requis

• God object sur User : responsible_accounting_entries transforme le modèle d'authentification en accumulateur de relations métier, violation du SRP et du domaine bounded context
• Incohérence de validation critique : processing_date_limit et responsible optionnels en backend mais requis en frontend Zod - l'API Strapi directe permet de créer des entrées incomplètes, contournant la validation métier
• Mapping sémantique Collaborator/User non résolu : collaborator.model.ts n'a pas d'équivalent backend, les rôles sont hardcodés en français dans la requête GraphQL, créant un couplage fragile avec la configuration des permissions
• DataTransfer API workaround : synchronisation manuelle entre react-dropzone et input file natif (lignes 60-76) est fragile, non testable unitairement, et pose des risques de compatibilité navigateur
• Absence totale de tests : 325 lignes ajoutées sans couverture sur les validations Zod, le modèle Collaborator, les server actions et le comportement dropzone

Tour 3 : Validation

• INCOHÉRENCE VALIDATION CRITIQUE : schema.json backend déclare processing_date_limit et responsible optionnels (pas de required:true), tandis que accountingEntry.schema.ts Zod les exige. Les appels API directs à Strapi contourneront la validation métier, permettant des entrées comptables sans date limite ni responsable. En contexte comptable, c'est inacceptable pour le suivi des SLA.
• ZÉRO TEST SUR 325 LIGNES : Aucun test sur la validation Zod des nouveaux champs requis, le modèle Collaborator.model.ts avec filtres GraphQL par regieId et rôles, ni la synchronisation DataTransfer workaround. Impossible de vérifier que le comportement correspond aux exigences métier.
• MÉLANGE DE PRÉOCCUPATIONS : L'ajout de 2 champs métier (valeur utilisateur directe) et la refactorisation react-dropzone (dette technique) dans le même commit rendent le rollback sélectif impossible si l'upload pose problème en production.
• COLLABORATOR.MODEL.TS SANS ÉQUIVALENT BACKEND : Mapping implicite User→Collaborator avec rôles hardcodés en français dans la requête GraphQL. Couplage fragile avec la configuration des permissions Strapi. Si les rôles changent de nom, la requête échouera silencieusement.
• DATATRANSFER WORKAROUND FRAGILE (lignes 60-63) : Synchronisation manuelle entre react-dropzone et input file natif non testable unitairement. Risque compatibilité Safari < 15.4 sur le chemin critique d'upload de justificatifs comptables.

• Incohérence validation backend/frontend critique : schema.json accounting-entry attributs processing_date_limit et responsible sans required:true vs Zod schema frontend les exigeant - permet POST /api/accounting-entries direct créant entrées incomplètes, correction prioritaire (ajout required:true ou middleware validation Strapi)
• Dette de tests ~2h : 0 fichiers test pour 325 lignes ajoutées couvrant validation Zod nouveaux champs, comportement dropzone (fileRejections, maxSize 4MB), modèle Collaborator avec filtres GraphQL dynamiques, synchronisation DataTransfer lignes 68-76
• DataTransfer workaround lignes 68-76 DraftAccountingEntryForm.tsx : synchronisation manuelle entre react-dropzone et input file natif fragile, non testable unitairement, risque compatibilité Safari < 15.4 - à réévaluer lors migration upload API direct
• Template literal injecté dans requête GraphQL Collaborator.model.ts ligne 21 (eq:${regieId}) : risque injection si regieId non sanitizé, couplage fragile avec rôles hardcodés en français lignes 20-23

• Incohérence validation : Zod required vs backend optional pour processing_date_limit/responsible permet données comptables incomplètes via API directe
• 0 test sur 325 lignes : validation Zod, Collaborator.model.ts, DataTransfer sync, server actions sans couverture
• DataTransfer workaround lignes 68-76 : non testable, risque compatibilité Safari < 15.4, aucun plan de remplacement
• fileRejections[0].errors[0].code : risque TypeError si errors[0] vide malgré check fileRejections.length
• Rôles hardcodés français lignes 28-31 Collaborator.model.ts : couplage fragile avec config permissions

• Dette test sous-évaluée par l'auteur (2h vs 7h minimum réel) - 5 catégories de tests nécessaires non planifiées
• fileRejections[0].errors[0].code sans optional chaining - TypeError garanti dans edge cases, 0 test aux limites
• DataTransfer workaround non testable unitairement et risque compatibilité Safari < 15.4
• Incohérence validation backend optional vs frontend Zod required - aucun test d'intégration ne protège l'API directe
• Collaborator.model.ts avec rôles hardcodés en français dans requête GraphQL - couplage fragile non testé

• INCOHÉRENCE VALIDATION CRITIQUE : processing_date_limit et responsible requis en Zod mais optionnels en backend Strapi - permet la création d'entrées comptables incomplètes via API directe, violation du principe de validation au niveau données
• MAPPING COLLABORATOR/USER FRAGILE : rôles hardcodés en français ('Collaborateur Régie', 'Admin Régie') dans requête GraphQL - couplage fragile avec configuration permissions, risque de rupture silencieuse
• DATATRANSFER WORKAROUND NON TESTABLE : synchronisation manuelle react-dropzone/input file (lignes 60-76) fragile, incompatible Safari < 15.4, non testable unitairement
• ABSENCE TOTALE DE TESTS : 325 lignes ajoutées sans couverture sur validation Zod, modèle Collaborator, server actions et comportement dropzone
• BUG POTENTIEL : fileRejections[0].errors[0].code sans optional chaining - TypeError garanti si tableaux vides