🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• Le diff ne montre pas la logique complète de soustraction des revenus - seul le renommage de variable est visible. La logique métier critique d'intégration IncomeEntryRow doit être vérifiée pour éviter un calcul incomplet.
• Le changement '> 0' vers '!== 0' révèle des catégories déficitaires auparavant masquées - les utilisateurs doivent être informés de ce changement de comportement pour éviter toute confusion sur les données historiques.
• Aucun test automatisé visible pour valider le calcul avec revenus ni le filtrage PPE - la validation manuelle mentionnée est insuffisante pour une logique financière critique exposant un risque de régression.
• Le TODO 'authorize' dans detailed_controller.ts indique un contrôle d'accès manquant sur des données financières sensibles - risque de sécurité et de conformité non négligeable.
• Les budgets calculés antérieurement étaient inexacts (dépenses sans soustraction des revenus) - faut-il envisager une recalculation rétroactive ou une communication formelle aux utilisateurs ?

• TODO d'autorisation non implémenté dans detailed_controller.ts ligne 14 - risque de sécurité : accès non vérifié aux données budgétaires PPE
• Absence totale de tests unitaires automatisés - le calcul de soustraction revenus/dépenses n'est pas testé programmatiquement, risque de régression
• Type IncomeEntryRow minimaliste (2 attributs seulement) - ne correspond pas au schéma complet income-entry-row/schema.json, nécessitera des extensions pour taxes et autres propriétés
• Aucune validation du paramètre ppeId - si absent de request.params(), le filtre $eq retournera undefined, causant potentiellement des résultats incorrects silencieusement sans erreur explicite
• Filtrage PPE ajouté uniquement sur accounting-entry-rows - income-entry-rows pourrait aussi nécessiter ce filtre pour garantir la cohérence des données entre dépenses et revenus du même projet

• VALIDATION MANQUANTE : ppeId extrait via request.params() sans guard - undefined sera propagé à getAccountingEntryRows() et stringifié dans searchParams, causant un filtrage incorrect ou une erreur silencieuse. Impact concret : appels API sans ppeId retourneraient des données non filtrées au lieu d'une erreur 400
• INCOHÉRENCE DE FILTRAGE CRITIQUE : ppeId est ajouté au searchParams pour accountingEntryRowsResponse (chunk 6) mais aucun chunk ne montre le même filtrage pour IncomeEntryRows - les revenus ne seraient pas filtrés par PPE, faussant le calcul net budget = dépenses(PPE) - revenus(tous PPE confondus)
• VIOLATION SRP : le contrôleur accumule +83 lignes avec 3+ responsabilités (fetch dépenses, fetch revenus, calcul agrégé) - un service dédié BudgetCalculationService devrait extraire la logique métier
• ABSENCE DE TESTS : aucune couverture pour le calcul de budget avec soustraction des revenus - changement fonctionnel majeur (budget peut devenir négatif) sans test unitaire ni d'intégration visible
• SÉCURITÉ : le TODO d'autorisation persiste (ligne ~11) alors que des données financières sensibles de revenus sont désormais exposées - tout utilisateur authentifié pourrait accéder aux revenus sans vérification de permissions

• 0 fichier de test sur 6 fichiers modifiés - couverture test nulle pour logique financière critique
• Soustraction revenus-dépenses non testée - risque de calcul incorrect sur données financières réelles
• Filtrage ppeId ($eq) non testé - comportement indéfini si PPE inexistant ou null
• Cas limites non couverts automatiquement : budget=0, budget<0, revenus>dépenses
• Modèle IncomeEntryRow (+7 lignes) sans infrastructure de mock pour tests unitaires

• SRP violation : le renommage en 'accountingEntryRowsResponse' (detailed_controller.ts:153) prépare un second appel API pour les revenus sans extraction vers un BudgetCalculationService - dette estimée 2h pour refactorisation future
• Absence de tests (2/10) : la soustraction revenus-dépenses et le filtrage PPE n'ont aucune couverture - une régression budgétaire impacterait directement les rapports financiers
• Signature 4 paramètres positionnels dans getAccountingRows() : dépasser 3 paramètres rend l'ordre difficile à mémoriser, un Parameter Object (ex: BudgetQueryParams) améliorerait la maintenabilité
• Filtre PPE 3 niveaux d'imbrication {ppe:{id:{$eq:ppeId}}} : structure difficile à tester unitairement et à composer avec d'autres filtres futurs
• TODO autorisation non résolu (detailed_controller.ts:12) : chaque ajout de endpoint sans contrôle d'accès accumule du risque de sécurité - dette +1h

Tour 2 : Préoccupations et questions

• CRITIQUE - BUG CALCUL BUDGÉTAIRE : detailed_controller.ts filtre les dépenses par PPE (ligne ~177, {ppe:{id:{$eq:ppeId}}}) mais pas les revenus. Exemple concret : PPE A avec 100k€ dépenses et 50k€ revenus propres, PPE B avec 80k€ revenus. Budget affiché PPE A = 100k - (50k + 80k) = -30k au lieu du réel 100k - 50k = +50k. ÉCART DE 80k€ sur les données présentées aux décideurs financiers.
• SÉCURITÉ - DONNÉES FINANCIÈRES SANS AUTORISATION : TODO authorize (ligne ~12) non résolu alors que le contrôleur expose désormais revenus ET dépenses. Tout utilisateur authentifié accède aux budgets PPE sans vérification de permissions. Risque conformité et audit.
• VALIDATION ppeId MANQUANTE : request.params() extrait ppeId sans guard. Si absent de l'URL, undefined sera stringifié dans searchParams du filtre $eq, retournant des données non filtrées au lieu d'une erreur 400. L'utilisateur verra des chiffres globaux sans avertissement que le filtrage PPE a échoué.
• ASYMÉTRIE FISCALE DANS LE CALCUL : accountingEntryRows incluent taxe.data.attributes.taxe_value (TVA appliquée lignes ~196-204), mais IncomeEntryRow ne contient que amount_without_taxes_cents et commercial_discount sans taxe. La soustraction dépenses-avec-TVA moins revenus-sans-TVA produit un montant net incohérent.
• COMMUNICATION UTILISATEUR OBLIGATOIRE : Changement '> 0' vers '!== 0' dans graph-view.tsx et list-view.tsx révèle des budgets déficitaires auparavant masqués. Action requise : notification aux utilisateurs financiers expliquant que les montants négatifs sont désormais visibles et représentent des dépassements budgétaires réels, pas des erreurs.

• RISQUE CRITIQUE À VÉRIFIER : chunk 7 tronqué masque logique soustraction complète - si income-entry-rows n'est PAS filtré par {ppe:{id:{$eq:ppeId}}}, calcul net sera incorrect (dépenses PPE X - revenus TOUS PPE). L'existence du modèle IncomeEntryRow confirme second appel API mais filtrage PPE doit être vérifié sur code complet
• Validation ppeId absente (detailed_controller.ts ligne 8) : request.params() peut retourner undefined - si ppeId=undefined, filtre $eq:stringified(undefined) produira résultats imprévisibles selon ORM Strapi. Impact : données non filtrées retournées silencieusement au lieu d'erreur 400. Correction : guard middleware ou validation explicite
• Null-safety incomplète (detailed_controller.ts ~ligne 200) : accountingEntryRow.attributes.taxe.data.attributes.taxe_value utilise ??0 MAIS si taxe.data est null/undefined (relation non peuplée par API), accès .attributes plantera avec TypeError. Nécessite optional chaining : taxe.data?.attributes?.taxe_value ?? 0

• BUG AVÉRÉ : ppeId sans validation (diff[8]) - undefined propagé dans $eq cause filtrage incorrect silencieux au lieu d'erreur 400
• INCOHÉRENCE FILTRAGE CRITIQUE : ppeId filtré sur accountingEntryRows (diff[2]) mais pas sur incomeEntryRows - calcul budget_net faux si confirmé
• ABSENCE TESTS : 0/6 fichiers testés pour logique financière de soustraction et filtrage PPE
• COMPLEXITÉ : 5 paramètres positionnels dans getAccountingEntryRows() dépasse seuil lisibilité
• SRP VIOLATION : contrôleur +83 lignes avec 3 responsabilités sans extraction service (dette 3h)

• DÉFAUT FILTRAGE PPE CRITIQUE : ppeId filtré sur accountingEntryRows (chunk 2) mais PAS sur incomeEntryRows - budget PPE = dépenses(PPE) - revenus(TOUS PPE) = calcul incorrect. Test d'intégration manquant.
• ZÉRO TEST sur detailed_controller.ts (+83/-16) : soustraction revenus-dépenses, null-coalescing taxe_value, changement '> 0' vers '!== 0' - aucun test unitaire ni d'intégration.
• CAS LIMITES NON COUVERTS : budget négatif (revenus>dépenses), ppeId undefined dans $eq, taxe_value null, commercial_discount null - aucun scénario testé.
• VALIDATION ppeId ABSENTE : undefined stringifié dans searchParams cause filtrage incorrect silencieux - test de contrat API avec ppeId manquant aurait prévenu ce défaut.
• MODÈLE IncomeEntryRow INCOMPLET : 2 attributs vs schéma JSON complet - aucun test de mapping pour vérifier cohérence modèle-données.

• BUG CRITIQUE : filtre PPE {ppe:{id:{$eq:ppeId}}} appliqué uniquement sur accountingEntryRows (detailed_controller.ts:177-181), absent d'incomeEntryRows - calcul budget = dépenses(PPE X) - revenus(TOUS PPE) produit résultats incorrects quand 2+ PPE existent
• VIOLATION SRP : pattern de calcul fiscal dupliqué (taxePercentage, commercialDiscount, amountWithTaxes, discount, finalAmount) entre accountingEntryRows et incomeEntryRows dans detailed_controller.ts:193-230 - BudgetCalculationService requis (3h dette)
• 5 paramètres positionnels dans getAccountingRows() dépassent seuil Clean Code de 3 - Parameter Object BudgetQueryParams requis pour éviter erreurs d'ordre
• VALIDATION MANQUANTE : ppeId extrait sans guard (detailed_controller.ts:12) - undefined dans $eq cause données non filtrées ou exception au lieu d'erreur 400
• TODO autorisation persistant (detailed_controller.ts:~14) avec exposition accrue de revenus financiers - risque conformité accumulé

Tour 3 : Validation

• BUG CRITIQUE FILTRAGE : detailed_controller.ts lignes 174-181 vs 193+ - filtre PPE sur accountingEntryRows mais PAS sur incomeEntryRows → budget net incorrect (dépenses 1 PPE - revenus TOUS PPE). Écart 80k€ démontré sur exemple concret
• ASYMÉTRIE FISCALE : income_entry_row.d.ts sans attribut taxe → revenus calculés HT tandis que dépenses calculées TTC (lignes 196-204) → montant net financièrement incohérent
• VALIDATION ppeId ABSENTE : detailed_controller.ts ligne 8 - request.params() sans guard → undefined dans $eq retourne données non filtrées au lieu d'erreur 400
• NULL-SAFETY INCOMPLÈTE : detailed_controller.ts ~ligne 200 - taxe.data.attributes.taxe_value sans optional chaining → risque TypeError si relation non peuplée
• TODO AUTHORIZE PERSISTANT : ~ligne 14 - exposition revenus financiers sans contrôle permissions → risque conformité audit

• NULL-SAFETY : detailed_controller.ts ~ligne 200, taxe.data.attributes.taxe_value sans optional chaining → TypeError si taxe.data=null. Correction : taxe.data?.attributes?.taxe_value ?? 0 (0.5h dette)
• VALIDATION ppeId : detailed_controller.ts ligne 8, request.params() sans guard → undefined dans {$eq:undefined} cause filtrage incorrect silencieux. Correction : guard middleware ou validation explicite (0.5h dette)
• FILTRAGE INCOMEENTRYROWS NON VÉRIFIABLE : chunk 7 tronqué après ligne 230 empêche confirmation {ppe:{id:{$eq:ppeId}}} sur requête revenus. Si absent : budget_net = dépenses(PPE X) - revenus(TOUS PPE) = incorrect. Risque : écart 80k€ par PPE supplémentaire. Nécessite review code complet
• DUPLICATION SRP : lignes 196-210 et 216-230, pattern fiscal identique répété. Extraction BudgetCalculationService.calculateRowAmount(row) recommandée (2h dette)
• COMMUNICATION UTILISATEUR : changement '> 0'→'!== 0' dans graph-view.tsx/list-view.tsx révèle budgets déficitaires auparavant masqués - notification aux utilisateurs financiers requise

• BUG AVÉRÉ - ppeId sans validation (detailed_controller.ts:8) : undefined dans $eq retourne données non filtrées au lieu d'erreur 400. Correction immédiate requise : guard if(!ppeId) return badRequest()
• BUG CRITIQUE PROBABLE - filtrage PPE absent d'incomeEntryRows (detailed_controller.ts:177-181) : budget_net = dépenses(PPE X) - revenus(TOUS PPE). Preuve : filtre explicitement ajouté à accountingEntryRows, absent hunks incomeEntryRows. Confirmation nécessite code complet
• BUG AVÉRÉ - null-safety incomplet (detailed_controller.ts:~200) : taxe.data.attributes.taxe_value crashera si taxe.data=null. Correction : taxe?.data?.attributes?.taxe_value ?? 0
• BUG AVÉRÉ - asymétrie fiscale : dépenses TTC vs revenus HT (IncomeEntryRow sans attribut taxe). Budget net incohérent
• SRP VIOLATION - duplication pattern calcul fiscal + 5 paramètres positionnels. BudgetCalculationService + Parameter Object requis (4h dette)

• BUG FILTRAGE PPE CONFIRMÉ : diff[2] ajoute filtre ppeId sur accountingEntryRows (ligne 177) mais PAS sur incomeEntryRows - test intégration avec 2 PPEs aurait détecté en 30min
• ZÉRO TEST : +83 lignes logique financière sans test dans detailed_controller.ts - soustraction, null-coalescing, condition modifiée non vérifiées
• VALIDATION ppeId ABSENTE : undefined dans $eq (ligne 8) retourne données non filtrées silencieusement au lieu d'erreur 400
• NULL-SAFETY INCOMPLÈTE : taxe.data.attributes sans optional chaining (ligne ~200) - TypeError si taxe.data=null
• ASYMÉTRIE FISCALE : dépenses TTC vs revenus HT (IncomeEntryRow sans taxe) - montant net incohérent

• BUG CRITIQUE : filtrage PPE asymétrique - accountingEntryRows filtré par ppeId, incomeEntryRows non filtré - calcul budget incorrect en environnement multi-PPE
• ASYMÉTRIE FISCALE : dépenses calculées avec TVA (taxe_value), revenus sans TVA (IncomeEntryRow sans champ taxe) - montant net économiquement incohérent
• VIOLATION SRP/DRY : pattern de calcul fiscal dupliqué entre accountingEntryRows et incomeEntryRows - BudgetCalculationService requis (3h dette)
• VALIDATION ppeId ABSENTE : undefined propagé dans $eq cause données non filtrées silencieusement au lieu d'erreur 400
• NULL-SAFETY INCOMPLÈTE : taxe.data?.attributes?.taxe_value requis au lieu de taxe.data.attributes.taxe_value - TypeError si relation non peuplée