🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• CRITIQUE - Tests manquants : computeRepartition calcule les répartitions financières sans aucun test unitaire. Cas critiques non vérifiés : (a) ownershipEffectiveDaysInFiscalYear comme ratio 0-1 vs jours bruts 0-365, (b) totalRepartition=0 → division par zéro, (c) ownershipPart=0, (d) valeur NaN/négative. Impact : paiements copropriétaires incorrects sans détection possible.
• ÉLEVÉ - Risque surpaiement : Si ownershipEffectiveDaysInFiscalYear contient des jours bruts (ex: 180) plutôt qu'un ratio (ex: 0.493), la formule produit un résultat > 1.0, attribuant à un propriétaire plus que 100% des fonds. Exemple : 50% * 180 = 9000%. Validation et documentation du format attendu sont absentes.
• ÉLEVÉ - Incohérence typage/appel : ownershipEffectiveDaysInFiscalYear() appelé comme fonction (lignes ~892, ~924) mais paramètre typé number dans la signature. Soit le paramètre devrait être une fonction (() => number), soit les appels devraient utiliser une variable. Cette incohérence masque potentiellement un bug d'exécution.
• MOYEN - Division par zéro préexistante : totalRepartition === 0 produit Infinity * days. Ce défaut existait avant ce commit mais n'a pas été corrigé lors de cette modification financière. Impact : résultat NaN propagé silencieusement dans les écritures comptables.
• MOYEN - Documentation absente : Aucun JSDoc sur computeRepartition expliquant l'intention métier du prorata, les invariants (plage ownershipEffectiveDaysInFiscalYear, préconditions sur totalRepartition), ni les cas limites. La maintenabilité et la vérifiabilité par les équipes métier sont compromises.

• Aucun test unitaire ajouté pour computeRepartition - méthode de calcul financier critique sans couverture automatisée, risque de régression futur élevé
• Incohérence de typage potentielle : ownershipEffectiveDaysInFiscalYear() est appelé comme fonction aux lignes ~892 et ~924 mais le paramètre est typé number dans la signature - TypeScript devrait inférer le retour de fonction, mais vérifier la cohérence
• Risque de dépassement : la formule ((ownershipPart / totalRepartition) * ownershipEffectiveDaysInFiscalYear) peut produire des valeurs > 1.0 si ownershipEffectiveDaysInFiscalYear n'est pas un ratio normalisé entre 0 et 1
• Le console.log supprimé indique un débogage antérieur, suggérant un manque de rigueur dans cette zone avant cette correction

• AMBIGUÏTÉ NOMINALE CRITIQUE : ownershipEffectiveDaysInFiscalYear suggère des jours (0-365) mais la formule ligne ~994 multiplie directement. Exemple : ratio 0.5 * 180 jours = 90.0 au lieu d'un ratio pur. Soit renommer en ownershipEffectiveDaysRatio si valeur [0,1], soit corriger la formule pour diviser par le nombre total de jours.
• AUCUN TEST UNITAIRE : Méthode computeRepartition modifiée sans couverture automatisée. La nouvelle formule multiplicative augmente la surface d'erreur pour un calcul financier critique.
• VALIDATION DÉFENSIVE ABSENTE : Si ownershipEffectiveDaysInFiscalYear vaut 0, NaN ou un négatif, la formule produit des résultats financiers silencieusement incorrects sans alerte.
• DOCUMENTATION MANQUANTE : La formule ((ownershipPart ?? 0) / totalRepartition) * ownershipEffectiveDaysInFiscalYear manque de JSDoc expliquant l'intention métier de proratisation temporelle.
• FAUTE DE FRAPPE PRÉEXISTANTE : Le paramètre propertieId devrait être propertyId, dégradant la lisibilité du code financier.

• 0 test ajouté pour computeRepartition - formule financière modifiée sans validation automatisée
• Division par zéro: totalRepartition === 0 produit Infinity/NaN sans erreur
• Pas de validation: ownershipEffectiveDaysInFiscalYear accepte valeurs négatives, zéro, NaN
• Incohérence typage: fonction appelée mais paramètre number - retour non validé
• Risque dépassement: résultat peut dépasser 1.0 si ownershipEffectiveDaysInFiscalYear non normalisé

• Absence de tests unitaires pour computeRepartition - méthode de calcul financier critique sans couverture (dette estimée : 0.5h)
• Aucune validation de ownershipEffectiveDaysInFiscalYear : valeurs négatives, zéro ou NaN produiront des résultats financiers silencieusement incorrects (dette estimée : 0.5h)
• Risque de division par zéro si totalRepartition === 0 - défaut préexistant non corrigé (dette estimée : 0.5h)
• Signature computeRepartition à 4 paramètres atteint le seuil de refactorisation vers Parameter Object - tout ajout futur dégradera la lisibilité
• Formule ((ownershipPart ?? 0) / totalRepartition) * ownershipEffectiveDaysInFiscalYear manque de documentation JSDoc sur l'intention métier et les invariants

Tour 2 : Préoccupations et questions

• SURPAIEMENT CRITIQUE : Si ownershipEffectiveDaysInFiscalYear contient des jours bruts (0-365) et non un ratio (0-1), la formule ((ownershipPart ?? 0) / totalRepartition) * ownershipEffectiveDaysInFiscalYear produit des valeurs > 1.0. Exemple : propriétaire 50% × 180 jours = résultat 90.0 au lieu de 0.5. Aucun plafonnement ni validation.
• INCOHÉRENCE TYPAGE/APPEL : ownershipEffectiveDaysInFiscalYear() appelé comme fonction (lignes ~892, ~924) mais paramètre typé number (ligne ~968). Soit le typage est incorrect (devrait être () => number), soit les appels sont erronés. Risque d'erreur d'exécution sur calcul financier.
• 0 TEST UNITAIRE : computeRepartition est une méthode financière critique avec 4 paramètres et logique de proratisation. Les 5 cas minimum identifiés par l'architecte ne sont pas couverts : ratio normal, jours partiels, totalRepartition=0, ownershipPart=null, facteur=0.
• VALIDATION DÉFENSIVE ABSENTE : NaN se propage silencieusement, valeurs négatives inversent le signe, zéro annule toute répartition, totalRepartition=0 produit Infinity × days. Aucun guard clause.
• AMBIGUÏTÉ NOMINALE : ownershipEffectiveDaysInFiscalYear suggère des jours (0-365) mais la formule l'utilise comme multiplicateur pur. L'intention métier est indéchiffrable sans JSDoc ni test.

• Absence de tests unitaires pour computeRepartition - méthode financière critique sans couverture (dette préexistante, ~0.5h)
• Validation défensive manquante sur ownershipEffectiveDaysInFiscalYear - NaN/zéro produiraient résultats silencieusement incorrects (~0.5h)
• Documentation JSDoc absente sur la formule de prorata - l'intention métier doit être explicite (~0.25h)
• Division par zéro potentielle sur totalRepartition - défaut préexistant à corriger séparément (~0.25h)

• AMBIGUÏTÉ SÉMANTIQUE CRITIQUE : ownershipEffectiveDaysInFiscalYear nomme 'Days' (plage 0-365) mais la formule multiplie directement. Si valeur en jours bruts, montants 100-365x trop élevés. Action : renommer en ownershipEffectiveDaysRatio si [0,1], ou diviser par totalDaysInFiscalYear si jours.
• AUCUN TEST UNITAIRE : computeRepartition modifiée sans couverture. 5 cas minimum requis : ratio normal, jours partiels, totalRepartition=0, ownershipPart=null, facteur=0/NaN/négatif.
• VALIDATION DÉFENSIVE ABSENTE : NaN propage silencieusement, 0 annule la répartition, négatif inverse le signe. Action : if (!isFinite(v) || v < 0) throw Error.
• SHADOWING DE NOM : ownershipEffectiveDaysInFiscalYear() (fonction, lignes ~892, ~924) et ownershipEffectiveDaysInFiscalYear (paramètre, ligne ~965) partagent le même identifiant.
• JSDoc MANQUANTE : formule de prorata temporel sans documentation d'intention, invariants ou cas limites.

• ZÉRO TEST UNITAIRE pour computeRepartition : formule financière ((ownershipPart ?? 0) / totalRepartition) * ownershipEffectiveDaysInFiscalYear modifiée ligne ~994 sans validation automatisée, 3 sites d'appel impactés (lignes ~892, ~924, ~967)
• INCOHÉRENCE TYPAGE/APPEL : ownershipEffectiveDaysInFiscalYear() appelé comme fonction (lignes ~892, ~924) mais paramètre typé number (ligne ~968) - erreur compilation potentielle ou bogue exécution latent
• PROPAGATION SILENCIEUSE NaN : ownershipEffectiveDaysInFiscalYear=NaN produit résultat NaN dans écritures comptables sans erreur ni test
• RISQUE DÉPASSEMENT FINANCIER : ownershipEffectiveDaysInFiscalYear en jours bruts (ex: 180) produit résultat=90.0 au lieu de ratio attendu, attribuant >100% des fonds à un copropriétaire
• DIVISION PAR ZÉRO : totalRepartition=0 produit Infinity*ownershipEffectiveDaysInFiscalYear sans erreur ni test

• Risque de dépassement financier : si ownershipEffectiveDaysInFiscalYear est en jours bruts (0-365) et non un ratio normalisé (0-1), computeRepartition peut retourner des valeurs > 1.0, produisant des montants de règlement incorrects sans erreur visible
• Absence de guard clauses : NaN se propage silencieusement (NaN × nombre = NaN), les valeurs négatives inversent le signe des répartitions, zéro annule toute répartition - aucun cas validé à l'entrée
• Aucun test unitaire pour computeRepartition : méthode financière critique avec 4 paramètres et logique de proratisation nécessitant minimum 5 cas de test (ratio normal, jours partiels, totalRepartition=0, ownershipPart=null, facteur=0)
• Sémantique non documentée : la formule ne spécifie pas si ownershipEffectiveDaysInFiscalYear est un ratio [0,1] ou un compteur de jours [0,365], rendant l'intention métier ambiguë
• Signature à 4 paramètres scalaires sans Parameter Object : risque d'erreur d'argument positionnel lors des prochains ajouts

Tour 3 : Validation

• Dette préexistante : absence de tests unitaires pour computeRepartition - méthode financière critique avec 4 paramètres et logique conditionnelle sans couverture (estimé 0.5h pour 5 cas de test : ratio normal, jours partiels, totalRepartition=0, ownershipPart=null, facteur=0)
• Nom ambigu ownershipEffectiveDaysInFiscalYear : le nom suggère jours bruts (0-365) mais la fonction retourne un ratio normalisé [0,1] - renommage en ownershipEffectiveDaysRatio recommandé pour éviter confusion future (0.25h)
• Validation défensive manquante : si ownershipEffectiveDaysInFiscalYear retourne NaN/0/négatif, la formule ((ownershipPart ?? 0) / totalRepartition) * ownershipEffectiveDaysInFiscalYear produit des résultats silencieusement incorrects sans erreur (0.5h pour ajouter guards avec throw)
• Division par zéro préexistante sur totalRepartition===0 : produisait déjà Infinity avant ce commit, à corriger dans un commit séparé dédié (0.25h)
• Documentation JSDoc absente sur computeRepartition : la formule de prorata temporelle nécessite documentation explicite de l'intention métier, des invariants (plage du ratio, préconditions sur totalRepartition), et des cas limites (0.25h)

• AMBIGUÏTÉ SÉMANTIQUE CRITIQUE (ligne 965, 997) : ownershipEffectiveDaysInFiscalYear nommé comme jours [0-365] mais multiplié directement dans le ratio. Si jours bruts : 0.5 * 180 = 90.0 au lieu de ≤ 1.0 → montants de règlement incorrects. ACTION REQUISE : vérifier le type de retour de la fonction ownershipEffectiveDaysInFiscalYear(). Si ratio [0,1], renommer en ownershipEffectiveDaysRatio. Si jours [0,365], diviser par 365 dans la formule.
• COLLISION NOMINALE (lignes 892, 924 vs 965) : Paramètre ownershipEffectiveDaysInFiscalYear: number porte le même nom que la fonction ownershipEffectiveDaysInFiscalYear() appelée aux sites d'appel. Un lecteur ne peut pas distinguer valeur de fonction. ACTION : renommer le paramètre pour lever l'ambiguïté.
• VALIDATION ABSENTE (ligne 997) : NaN * nombre = NaN propagé dans les écritures comptables sans erreur. Nombre négatif * ratio = inversion de signe des répartitions. Zéro * ratio = annulation silencieuse de répartition. ACTION : ajouter guard clauses avec erreur explicite.
• TESTS UNITAIRES ABSENTS : computeRepartition (4 paramètres, logique financière de proratisation) sans aucune couverture. 5 cas minimum requis : (1) ratio normal, (2) facteur < 1, (3) totalRepartition=0, (4) ownershipPart=null, (5) facteur=0. ACTION : écrire tests avant prochaine modification.
• DIVISION PAR ZÉRO PRÉEXISTANTE (ligne 997) : totalRepartition=0 produit Infinity * factor. Hors périmètre de ce commit mais impacte le même calcul. ACTION : créer ticket séparé.