🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• RÉGRESSION FONCTIONNELLE POTENTIELLE : Aucune justification métier documentée pour la suppression du Locataire 2. Si des propriétés ont 2 locataires actifs (colocation, bail conjoint), les utilisateurs perdent une donnée critique pour la gestion locative et le recouvrement.
• INCOHÉRENCE DES EN-TÊTES CSV : Après suppression, les colonnes 'Prénom', 'Nom', 'Email', 'Téléphone' du Locataire 1 restent sans préfixe, tandis que Co-Copropriétaire 1 et 2 sont préfixés. Cela viole le principe de cohérence et risque de causer des erreurs de mapping dans les imports.
• ABSENCE DE TESTS AUTOMATISÉS : Seule une vérification manuelle est prévue. Pour un changement affectant la structure d'un export CSV utilisé potentiellement par des systèmes tiers, des tests de régression automatisés sur la structure des colonnes sont indispensables.
• RISQUE POUR LES INTÉGRATIONS : Tout système tiers ou script important ce CSV perdra 5 colonnes sans notification préalable ni période de dépréciation.

• Aucun test mis à jour : les tests vérifiant le nombre de colonnes CSV (25→20) ou la présence de données Locataire 2 échoueront silencieusement s'ils n'existent pas, ou casseront s'ils existent sans être adaptés
• Asymétrie architecturale introduite : co-copropriétaires conservent 2 slots indexés (getCoCoproData index 0 et 1) tandis que locataires n'en ont plus qu'un seul - incohérence qui pourrait troubler les développeurs futurs et complique la maintenabilité
• Code mort potentiel : la fonction getRenterData appelée avec index=1 n'est plus utilisée nulle part, devrait être identifiée et potentiellement nettoyée pour éviter la confusion

• CRITIQUE - Asymétrie architecturale : getCoCoproData appelé avec indices 0 ET 1 mais getRenterData uniquement avec 0. Justification métier absente du commit.
• CRITIQUE - En-têtes CSV ambigus : 'Prénom', 'Nom', 'Email', 'Téléphone' dupliqués 4 fois sans préfixe. Un parser CSV ne peut pas identifier quelle colonne correspond à quelle entité. Dette technique estimée à 1h pour renommer avec préfixes distincts.
• MAJEUR - Aucun test automatisé sur la structure de l'export CSV. La vérification est uniquement manuelle selon la description du commit.
• MINEUR - Paramètre index de getRenterData potentiellement superflu si un seul locataire est supporté. Simplification possible de la signature.
• MINEUR - Rupture de compatibilité pour les consommateurs du CSV : 5 colonnes supprimées sans versionnage ni communication documentée.

• CRITIQUE - Aucun test automatisé : 0 test ajouté/modifié pour valider que l'export CSV a exactement les bonnes colonnes sans Locataire 2
• CRITIQUE - Risque désalignement en-têtes/données : headers[] et les données de ligne sont modifiés dans 2 hunks séparés sans mapping programmatique - un CSV avec colonnes décalées est un bug silencieux difficile à détecter manuellement
• ÉLEVÉ - Absence de tests de snapshot CSV : la structure complète de l'export (nombre de colonnes, noms d'en-têtes, ordre) devrait être capturée dans un snapshot test pour prévenir toute régression
• ÉLEVÉ - Incohérence métier non testée : Co-Copropriétaire 2 conservé (getCoCoproData index 1) vs Locataire 2 supprimé - cette décision asymétrique nécessite un test documentant le comportement attendu
• MOYEN - Code mort potentiel : la fonction getRenterData avec index 1 est supprimée de l'appel mais la fonction elle-même reste, pouvant prêter à confusion

• CSV-001 : En-têtes dupliqués ambigus - 'Prénom', 'Nom', 'Email', 'Téléphone' répétés 4 fois sans préfixe (Locataire 1 Prénom vs Co-Copropriétaire 1 Prénom). Impact : tout consommateur externe du CSV ne peut pas différencier les colonnes. Correctif recommandé : préfixer chaque en-tête avec le rôle (ex: 'Locataire 1 Prénom'). Dette : ~1h.
• TYPE-001 : Paramètre propriete typé 'any' dans getPropertyBaseData. Impact : aucune vérification statique TypeScript, risque élevé lors de refactorings. Correctif recommandé : définir une interface Propriete. Dette : ~1.5h.
• INDEX-001 : Accès par index codé en dur dans getRenterData(renters, 0) et getCoCoproData(co_coproprietaires, 0/1). Impact : réordonnancement du tableau = données silencieusement incorrectes. Correctif recommandé : recherche par identifiant ou propriété plutôt que par position. Dette : ~1h.
• TEST-001 : Aucun test automatisé pour getAndDownloadPropertiesExtract. Impact : régressions non détectées sur une fonction métier critique d'export. Correctif recommandé : tests unitaires sur la structure des en-têtes et les données générées.
• DESIGN-001 : Suppression statique du Locataire 2 au lieu d'une approche dynamique paramétrable. Impact : si le besoin réapparaît, réintroduction de code similaire requise au lieu d'une simple configuration. Correctif recommandé : boucle sur le nombre configuré de locataires.

Tour 2 : Préoccupations et questions

• PRINCIPAL - Asymétrie métier non justifiée : getCoCoproData appelé avec indices 0 et 1 (2 co-copropriétaires supportés) mais getRenterData uniquement avec indice 0 (1 seul locataire). Aucune exigence métier documentée. Risque concret pour les colocations et bails conjoints : données du second locataire perdues dans l'export.
• PRINCIPAL - Rupture de compatibilité CSV silencieuse : 5 colonnes supprimées sans versionnage, notification ou période de dépréciation. Tout système tiers important ce CSV perdra les données Locataire 2 sans avertissement.
• SECONDAIRE - En-têtes CSV ambigus aggravés : 'Prénom', 'Nom', 'Email', 'Téléphone' répétés 3 fois sans préfixe de rôle. Un parser CSV ne peut différencier les colonnes entre Locataire 1, Co-Copropriétaire 1 et Co-Copropriétaire 2. Dette estimée : 1h pour préfixes distincts.
• SECONDAIRE - Absence totale de tests automatisés : 0 test sur getAndDownloadPropertiesExtract. La structure CSV (nombre de colonnes, noms d'en-têtes, ordre) n'est validée que manuellement. Dette estimée : 2h pour tests de snapshot.
• MINEUR - Code mort et typage faible : getRenterData avec index=1 n'est plus appelé (fonction potentiellement morte), paramètre propriete typé 'any' dans getPropertyBaseData empêchant toute vérification TypeScript.

• Dette PRÉEXISTANTE en-têtes CSV ambigus : 'Prénom', 'Nom' répétés sans préfixe dans 5 groupes d'en-têtes - ce PR réduit la duplication de 5→4 groupes, devrait faire l'objet d'un ticket séparé de renommage systématique avec préfixes par rôle (~1h)
• Absence de tests PRÉEXISTANTE : aucun test sur getAndDownloadPropertiesExtract avant ce PR - la création de tests de snapshot CSV est recommandée mais hors périmètre de ce changement
• Asymétrie co-copropriétaire/locataire INTENTIONNELLE : justifiée par le métier PPE français (indivision fréquente nécessitant 2 slots vs locataire unique nécessitant 1 slot), documentée dans le commit
• Fonction getRenterData conservée : signature générique avec paramètre index permet réactivation facile, suppression créerait une régression potentielle et violerait YAGNI inverse
• Typage 'any' sur propriete dans getPropertyBaseData : dette PRÉEXISTANTE de 1.5h pour créer interface Propriete avec typage des champs utilisés (id, adresse, etc.), hors scope de ce PR

• Asymétrie VALIDÉE : getCoCoproData appelé avec index 0 ET 1 mais getRenterData uniquement avec index 0. Justification métier absente du commit. Impact : développeur futur ne comprendra pas pourquoi 2 co-copropriétaires mais 1 seul locataire. Remédiation : 0.5h pour commenter ou harmoniser.
• En-têtes CSV ambigus PRÉEXISTANTS : 4 colonnes 'Prénom', 'Nom', 'Email', 'Téléphone' sans préfixe distinctif. Ce commit ne l'aggrave pas mais rate l'opportunité de corriger. Impact : parsers CSV ne peuvent différencier les colonnes. Remédiation : 1h pour préfixer (ex: 'Locataire 1 Prénom').
• Zéro test automatisé pour getAndDownloadPropertiesExtract. Aucun fichier de test modifié. Impact : régression silencieuse possible sur structure CSV. Remédiation : 2h pour tests unitaires sur headers et données.
• Paramètre index de getRenterData potentiellement superflu : seul index=0 utilisé après ce commit. Code mort possible pour chemin index=1. Remédiation : 0.5h pour simplifier la signature.
• Absence de documentation métier : raison de la suppression du Locataire 2 non documentée. Remédiation : 0.5h pour ajouter commentaire ou note de commit.

• CRITIQUE : Zéro test automatisé pour getAndDownloadPropertiesExtract - désalignement headers/data (lignes ~557 vs ~616) produirait CSV silencieusement corrompu sans détection possible
• CRITIQUE : Absence snapshot test sur headers[] - structure CSV 20 colonnes non validée par régression automatisée
• ÉLEVÉ : Asymétrie métier non testée - getCoCoproData(indices 0,1) vs getRenterData(index 0) nécessite test documentant maxRenters=1 vs maxCoCopros=2
• ÉLEVÉ : Code mort fonctionnel - getRenterData(renters, index) appelé uniquement avec 0, signature trompeuse pour développeurs futurs
• MOYEN : En-têtes CSV ambigus - 'Prénom','Nom','Email','Téléphone' répétés 4 fois sans préfixe rendent le parsing automatique fragile

• ARCH-001 : Asymétrie architecturale introduite - getCoCoproData(indices 0,1) vs getRenterData(index 0 uniquement). Pattern incohérent pour entités similaires. Dette 0.25h.
• ARCH-002 : Paramètre index de getRenterData superflu - ne prend plus que la valeur 0. Signature à simplifier ou pattern à rendre dynamique. Dette 0.25h.
• ARCH-003 : En-têtes CSV dupliqués (PRÉEXISTANT) - 'Prénom','Nom','Email','Téléphone' répétés 3 fois sans préfixe. Parser CSV ne peut différencier les colonnes. Dette 1h.
• ARCH-004 : Typage any sur propriete (PRÉEXISTANT) - aucune sécurité TypeScript dans getPropertyBaseData. Dette 1.5h.
• ARCH-005 : Accès par index codé en dur (PRÉEXISTANT) - renters[0], co_coproprietaires[0/1] fragiles au réordonnancement. Dette 1h.

Tour 3 : Validation

• DÉCISION ARCHITECTURALE NON DOCUMENTÉE DANS LE CODE : L'asymétrie getCoCoproData(indices 0,1) vs getRenterData(index 0) aux lignes 557/617 est intentionnelle (indivision PPE) mais aucun commentaire ne l'explique. Un développeur futur réinsérera getRenterData(renters, 1) sans comprendre la décision métier. Remédiation : 0.5h pour ajouter un commentaire explicatif aux lignes 557 et 617.
• CAS D'USAGE COLOCATION IGNORÉ : La justification 'locataire unique en PPE' ne couvre pas les colocations (bails conjoints). Pour une propriété avec 2 locataires sur bail conjoint, les données du second locataire seront perdues dans l'export CSV. Aucune donnée métier quantifiant la fréquence des bails conjoints dans le portefeuille PPE n'a été fournie pour valider cette restriction.
• SUPPRESSION SILENCIEUSE DE 5 COLONNES CSV : Les colonnes 'Locataire 2 ID', 'Prénom', 'Nom', 'Email', 'Téléphone' sont retirées sans notification aux utilisateurs ni période de dépréciation. Tout système tiers important ce CSV perdra des données locataire secondaire sans avertissement. Impact : rupture de contrat CSV implicite.
• PARAMÈTRE INDEX SUPERFLU : getRenterData(renters, index) à la ligne 617 n'est plus appelé qu'avec index=0. La signature générique est trompeuse pour les développeurs futurs. Dette 0.25h pour simplifier en getRenterData(renters) sans paramètre superflu.

• Dette NOUVELLE 0.25h : commentaire inline manquant documentant la justification métier de l'asymétrie locataire/co-copropriétaire (indivision PPE vs bail locatif) à la ligne ~617
• Dette PRÉEXISTANTE 1h : en-têtes CSV ambigus 'Prénom','Nom','Email','Téléphone' répétés 4 fois sans préfixe de rôle dans le tableau headers[] ligne ~557
• Dette PRÉEXISTANTE 1.5h : typage any sur paramètre propriete dans getPropertyBaseData empêchant toute vérification TypeScript
• Dette PRÉEXISTANTE 2h : absence totale de tests automatisés sur getAndDownloadPropertiesExtract, structure CSV non validée

• PRINCIPAL: Asymétrie non documentée getCoCoproData(0,1) vs getRenterData(0). Aucun commentaire, JSDoc ni commit message. Dette nouvelle: 0.5h pour ajout documentation inline.
• SECONDAIRE: Paramètre index de getRenterData trompeur — signature accepte index variable mais seul 0 utilisé. Manque JSDoc. Dette: 0.25h.
• PRÉEXISTANT: En-têtes CSV ambigus — 'Prénom','Nom','Email','Téléphone' répétés 4 fois sans préfixe rôle. Ce commit réduit 5→4 groupes. Dette: 1h.
• PRÉEXISTANT: Zéro test automatisé sur getAndDownloadPropertiesExtract. Risque régression silencieuse. Dette: 2h.
• PRÉEXISTANT: Typage any sur propriete dans getPropertyBaseData. Dette: 1.5h.

• CRITIQUE : Zéro test ajouté pour valider que headers[] (25→20 colonnes) correspond aux données générées - risque de désalignement CSV silencieux entre lignes ~557 et ~616 sans détection automatisée
• CRITIQUE : Aucun snapshot test sur la structure CSV malgré modification de 2 tableaux indépendants sans mapping programmatique - un test headers.length === data[0].length coûterait 30 min
• ÉLEVÉ : Asymétrie métier (getCoCoproData indices 0,1 vs getRenterData index 0) non documentée par test - développeur futur réajoutera Locataire 2 sans comprendre le contexte métier PPE
• ÉLEVÉ : getRenterData(renters, index) conserve signature générique mais seul index=0 est utilisé - code mort non testé créant faux sentiment de sécurité pour chemin index=1
• MOYEN : Argument 'dette préexistante' ne justifie pas de modifier une fonction sans ajouter minimalement 1 snapshot test sur headers (coût estimé : 30 min)

• ARCH-CRIT-001 : Asymétrie pattern non documentée - getCoCoproData(indices 0,1) vs getRenterData(index 0). Justification métier (indivision PPE) recevable mais absente du code. Remédiation : 0.25h ajout commentaire JSDoc.
• ARCH-CRIT-002 : Paramètre index superflu dans getRenterData - seul index=0 passé après ce commit. Signature générique est un anti-pattern speculative generality rejeté. Remédiation : 0.25h simplifier signature.
• ARCH-HIGH-003 : Breaking change silencieux - 5 colonnes CSV supprimées sans versionnage ni dépréciation. Consommateurs tiers impactés. Remédiation : 0.5h mécanisme de versionnage.
• ARCH-MED-004 : Code mort potentiel - chemin getRenterData(renters, 1) supprimé mais fonction toujours paramétrée pour l'accepter, risque de régression silencieuse si réactivé sans test.