🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• RÉGRESSION CALCUL totalReference : Le passage de max(sum(budgeted), sum(actual)) à max par ligne change le résultat. Exemple : 2 postes avec budgeted=[100,50] et actual=[50,80] donnent 150 (ancien) vs 100 (nouveau). Écart de 50€ pouvant fausser le budget de référence. Aucun test ne valide ce comportement.
• AUCUN TEST FINANCIER : Les champs renovationFundAnticipatedTaxes et renovationFundFees manipulent des données comptables sans couverture de test. Risque métier : erreurs de calcul silencieuses sur les budgets PPE.
• VIOLATION DRY : Les sections comptables par défaut sont dupliquées entre lifecycles.js et migration/20250219_accounting.js. Toute modification future doit être appliquée 2 fois. Dette estimée : 2h pour mutualiser.
• ÉCART TEMPS : actualTimeHours(7h) vs idealTimeHours(4h) = 3h de surcoût. Cause probable : le refactor de totalReference a nécessité des allers-retours dus au manque de spécification métier claire.

• Aucun test automatisé pour les nouveaux champs fees/anticipatedTaxes - risque élevé pour des données financières sans validation par tests
• Les corrections typographiques dans la migration ne mettent pas à jour les enregistrements existants en base - incohérence potentielle entre anciennes et nouvelles données
• Duplication de la liste de sections comptables entre migration et lifecycle - un fichier partagé éviterait le risque de désynchronisation future
• La refonte du calcul totalReference mentionnée dans l'overview n'apparaît pas dans les diffs fournis - périmètre potentiellement incomplet

• BudgetTab.tsx : Shadowing de variables dans le reduce imbriqué de totalReference - 'acc' et 'budget' du reduce interne masquent les variables du scope externe, rendant la logique opaque et le débogage difficile. Le reduce interne calcule max(actual, budgeted) par élément puis compare avec l'accumulateur interne, mais cette intention est masquée par les noms identiques.
• Duplication DRY : createDefaultAccountingSections (~90 lignes) est copié intégralement entre backend/migration/20250219_accounting.js et backend/src/api/regie/content-types/regie/lifecycles.js. La correction typographique a dû être appliquée 2 fois, démontrant le risque concret de désynchronisation.
• Absence de tests pour le calcul refondu de totalReference : le passage de 2 reduces séparés à un reduce imbriqué modifie la logique métier sans couverture de test pour valider l'équivalence des résultats, notamment pour les cas limites (budgets vides, valeurs négatives, égalité budgeted/actual).
• BudgetTab.tsx : Accumulation de 5+ useState sans migration vers useReducer, augmentant progressivement la complexité de gestion d'état du composant.
• Correction typographique positive mais impact limité : l'ajout d'espaces autour de '/' dans les noms de sections (ex: 'Frais administratifs / Débours') améliore la cohérence visuelle mais ne réduit pas la dette technique structurelle.

• Aucun test unitaire ni d'intégration pour les nouveaux champs renovationFundAnticipatedTaxes et renovationFundFees
• Absence de tests E2E pour valider l'affichage et la persistance des nouveaux champs budget
• La recherche par nom hardcoded 'Fonds de rénovation' est fragile et non testée - un changement de nom casserait la logique silencieusement
• Duplication des données de sections comptables entre la migration et le lifecycle (violation DRY) sans tests de cohérence
• Aucun test de validation pour les nouveaux champs numériques (valeurs négatives, limites, types)

• Type ppeAccounting dupliqué dans 2 contrôleurs - chaque évolution nécessite synchronisation manuelle (dette 1.5h)
• Fonction createDefaultAccountingSections copiée entre migration et lifecycles - risque de divergence (dette 1h)
• Incohérence singulier/pluriel dans RenovationFundBudget : renovationsFund vs renovationFund
• Champs optionnels sans valeur par défaut - risque de NaN dans totalReference
• Correction typographique sur noms de sections - risque de régression si utilisés comme clés de recherche

Tour 2 : Préoccupations et questions

• RÉGRESSION MÉTIER CRITIQUE sur totalReference (BudgetTab.tsx lignes 37-50) : Le passage de max(sum(budgeted), sum(actual)) à max-per-line-then-max modifie le résultat. Ex : budgeted=[100,50], actual=[50,80] → 150€ (ancien) vs 100€ (nouveau), écart de 33% sur le budget de référence affiché aux copropriétaires pour décision financière.
• AUCUN TEST FINANCIER : Les champs renovationFundAnticipatedTaxes et renovationFundFees (ajoutés dans les types ppeAccounting des 2 contrôleurs et persistés dans updatePpeAccountingBudget lignes 146-147) manipulent des données comptables sans validation ni test. Enjeu : erreurs silencieuses sur bilans annuels et appels de fonds.
• DUPLICATION TYPE ppeAccounting : Le type est défini séparément dans getPpeAccountingBudgetData.controller.ts et getEditPpeAccountingBudgetData.controller.ts. Chaque ajout de champ nécessite synchronisation manuelle dans 2 fichiers. Dette estimée : 1.5h pour mutualiser.
• DUPLICATION DRY DÉMONTRÉE : createDefaultAccountingSections (~90 lignes) copié entre lifecycles.js et migration/20250219_accounting.js. La correction typographique a dû être appliquée 2 fois (lignes 43 et 52), prouvant le risque concret de désynchronisation. Dette : 2h pour mutualiser.
• ABSENCE DE SPÉCIFICATION totalReference : Le refactor modifie le comportement métier sans documenter l'intention. Question clé : le budget de référence doit-il représenter le maximum des totaux globaux (ancien) ou le maximum atteint par un poste individuel (nouveau) ? Les implications financières diffèrent significativement.

• Le type ppeAccounting est dupliqué entre 2 contrôleurs - devrait être extrait dans un fichier partagé (dette 1.5h)
• La correction typographique dans la migration ne met pas à jour les enregistrements existants en base - incohérence potentielle nécessitant un script UPDATE
• Absence de tests pour les nouveaux champs financiers et le calcul totalReference refondu - risque pour des données comptables
• Les 5+ useState dans BudgetTab.tsx commencent à rendre le composant difficile à maintenir - useReducer serait plus adapté
• Incohérence singulier/pluriel dans les noms : renovationsFund vs renovationFund - devrait être standardisé

• RÉGRESSION totalReference (BudgetTab.tsx) : max(sum(budgeted), sum(actual)) → max par ligne. Impact : budgeted=[100,50], actual=[50,80] donne 150→100 (écart 50€). Aucun test de non-régression.
• SHADOWING (BudgetTab.tsx) : reduce imbriqué réutilise (acc, budget) masquant le scope externe. Renommer en (maxSoFar, lineItem) pour lisibilité.
• DRY types : ppeAccounting dupliqué dans getEditPpeAccountingBudgetData.controller.ts et getPpeAccountingBudgetData.controller.ts. 2 champs ajoutés manuellement en synchronie.
• DRY sections : createDefaultAccountingSections copié entre migration/20250219_accounting.js et lifecycles.js. Corrections typographiques appliquées 2 fois prouvant le risque de désynchronisation.
• TESTS ABSENTS : 0 test sur 11 fichiers pour 2 champs financiers et un calcul modifié. Risque métier critique pour données comptables PPE.

• RÉGRESSION CALCUL totalReference (BudgetTab.tsx) : max(sum(budgeted), sum(actual)) → max-per-line-then-max-of-all change les résultats. Preuve : budgeted=[100,50], actual=[50,80] → 150 vs 100. Écart 50€ sur budget PPE sans test de détection
• ZÉRO test pour renovationFundAnticipatedTaxes et renovationFundFees dans 3 contrôleurs (get, getEdit, update) - inacceptable pour des données comptables persistantes
• Shadowing variables BudgetTab.tsx : acc et budget dupliqués dans reduce imbriqué masquent l'intention métier et bloquent l'écriture de tests unitaires ciblés
• Aucun test de validation dans updatePpeAccountingBudget.controller.ts pour champs numériques financiers : négatifs, NaN, undefined, limites
• Recherche hardcoded 'Fonds de rénovation' dans lifecycles.js sans test - la correction typographique prouve que les noms changent et cassent la logique silencieusement

• RÉGRESSION CRITIQUE totalReference (BudgetTab.tsx) : changement sémantique de max(sum(budgeted), sum(actual)) vers max-per-line. Exemple : budgeted=[100,50], actual=[50,80] → 150 vs 100, écart de 33%. Aucun test ne valide ce comportement financier.
• SHADOWING DE VARIABLES (BudgetTab.tsx) : reduce imbriqué avec 'acc' et 'budget' masqués dans 2 scopes, rendant la logique opaque pour un calcul financier critique nécessitant audit.
• DUPLICATION DRY CONFIRMÉE (lifecycles.js + migration/20250219_accounting.js) : createDefaultAccountingSections copié ~90 lignes, correction typographique appliquée 2 fois prouve le risque de désynchronisation future.
• TYPES DUPLIQUÉS (2 contrôleurs) : ppeAccounting défini 2 fois, l'ajout des champs renovationFundAnticipatedTaxes et renovationFundFees a nécessité synchronisation manuelle.
• CHAMPS OPTIONNELS SANS DÉFAUT : renovationFundAnticipatedTaxes et renovationFundFees (number | undefined) peuvent propager NaN dans totalReference si undefined.

Tour 3 : Validation

• RÉGRESSION totalReference CRITIQUE (BudgetTab.tsx lignes 37-50) : max(sum(budgeted), sum(actual)) → max-per-line modifie les montants de référence affichés aux copropriétaires. Preuve chiffrée : budgeted=[100,50], actual=[50,80] → 150€ ancien vs 100€ nouveau (écart 33%). Impact métier : décisions d'appels de fonds basées sur un montant sous-estimé. Aucune spécification ne justifie ce changement sémantique.
• ZÉRO test sur 11 fichiers modifiés pour 2 champs financiers et un calcul refactoré. Les contrôleurs getPpeAccountingBudgetData, getEditPpeAccountingBudgetData, et updatePpeAccountingBudget n'ont aucune validation sur les montants comptables (négatifs, NaN, undefined). Inacceptable pour des données financières PPE.
• DUPLICATION type ppeAccounting : défini dans 2 contrôleurs séparés, synchronisation manuelle obligatoire à chaque ajout de champ. Dette : 1.5h pour extraire dans un fichier partagé.
• DUPLICATION createDefaultAccountingSections (~90 lignes) : copié entre lifecycles.js et migration/20250219_accounting.js. La correction typo a dû être appliquée 2 fois, prouvant le risque concret de désynchronisation. Dette : 2h pour mutualiser.
• SHADOWING variables (BudgetTab.tsx lignes 44-50) : reduce imbriqué réutilise (acc, budget) dans 2 scopes, rendant la logique financière opaque et non-auditable pour un calcul critique.

• Absence de tests pour les nouveaux champs financiers - risque acceptable pour le moment mais à combler
• Duplication de types ppeAccounting entre les 2 contrôleurs - dette technique mineure à adresser
• Incohérence singulier/pluriel renovationsFund vs renovationFund - à standardiser
• La migration ne met pas à jour les enregistrements existants avec la correction typographique

• RÉGRESSION CRITIQUE : totalReference change de max(sum) à max-per-line, modifiant les résultats financiers sans test ni documentation d'intention
• SHADOWING : reduce imbriqué réutilise (acc, budget) dans 2 scopes, rendant la logique opaque pour un calcul financier critique
• DRY TYPES : ppeAccounting dupliqué dans 2 contrôleurs, synchronisation manuelle requise pour chaque ajout de champ
• DRY SECTIONS : createDefaultAccountingSections copié ~90 lignes entre migration et lifecycles.js, correction typo appliquée 2 fois prouve le risque
• INCOHÉRENCE NOMMAGE : renovationsFund (pluriel) vs renovationFund (singulier) + typo renovationFuncInterest

• RÉGRESSION CRITIQUE totalReference : changement sémantique validé par 5 reviewers, écart 33% sur budget PPE, ZÉRO test de détection
• ZÉRO test pour renovationFundAnticipatedTaxes et renovationFundFees dans 3 contrôleurs - données comptables persistantes sans validation
• Propagation NaN potentielle : champs number | undefined dans calcul totalReference sans guard ni test
• Shadowing de variables (acc, budget) dans reduce imbriqué rend la logique illisible et non testable unitément
• Types dupliqués ppeAccounting synchronisés manuellement - risque d'oubli de champ confirmé par l'ajout des 2 nouveaux champs

• RÉGRESSION CRITIQUE totalReference : changement sémantique de max(sum(budgeted), sum(actual)) vers max-per-line sans spécification métier documentée. Impact financier mesurable (33% d'écart possible).
• SHADOWING DE VARIABLES dans reduce imbriqué : 'acc' et 'budget' masqués dans 2 scopes rendent le calcul financier opaque et non-auditable.
• DUPLICATION DRY CONFIRMÉE : types ppeAccounting dans 2 contrôleurs + createDefaultAccountingSections (~90 lignes) copié entre lifecycles.js et migration.
• INCOHÉRENCE MIGRATION : correction typographique sans UPDATE des enregistrements existants en base de données.
• NOMMAGE INCOHÉRENT : renovationsFundBalance (pluriel) vs renovationFundAnticipatedTaxes (singulier) dans la même structure de données.