🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• INCOHÉRENCE CRITIQUE - getDocumentInfo.ts : coproPreferenceSendByMail reste sur coproprietaires.data?.[0] alors que coproIds extrait TOUS les IDs. Conséquence métier : un copropriétaire ayant refusé les notifications email recevra quand même le document si le 1er copropriétaire a accepté. Chaque copropriétaire doit avoir sa préférence vérifiée individuellement.
• RISQUE D'ERREUR SILENCIEUSE - useShareForm.ts : forEach async ne capture pas les erreurs par copropriétaire. Si l'envoi échoue pour un copropriétaire, les autres continuent sans traçabilité. Promise.allSettled avec rapport d'erreur serait approprié.
• AUCUN TEST AUTOMATISÉ - Logique métier critique (envoi d'emails à des copropriétaires) sans couverture de test. Le développeur mentionne 'tester avec un ou plusieurs copropriétaires' mais aucun test n'est inclus dans le commit.
• CHANGEMENT D'API NON DOCUMENTÉ - createTicket reçoit maintenant undefined comme 3ème paramètre au lieu de coproId. La signature a changé mais sans documentation ni commentaire expliquant ce changement.
• RISQUE DE SURCHARGE - Pas de limitation de débit : si un document est partagé avec 50+ copropriétaires, la boucle forEach déclenchera 50+ appels API concurrents sans throttle ni retry.

• Le pattern async forEach ne garantit pas la résolution de toutes les Promises avant la fin de la fonction parente - mais c'est intentionnel pour un envoi parallèle fire-and-forget des emails
• Le paramètre undefined passé à createTicket est un hack temporaire en attendant la mise à jour de la signature de cette fonction
• Absence de tests automatisés - la logique de boucle sur plusieurs copropriétaires mériterait des tests unitaires
• Le type 'as any' sur sentDocumentToCoproDistributionList reste un problème existant non adressé dans ce PR

• BUG CRITIQUE (useShareForm.ts ligne ~100) : async dans forEach — les promesses ne sont PAS attendues, les erreurs sont avalées silencieusement. Remplacer immédiatement par Promise.all(coproIds?.map(async ...))
• Code smell (useShareForm.ts ligne ~97) : createTicket(ticketDatas, token, undefined, coproIds) — paramètre undefined explicite rend l'appel illisible et fragile, refactorer avec objet options
• Incohérence fonctionnelle (getDocumentInfo.ts lignes 20-22) : coproPreferenceSendByMail ne lit que la préférence du 1er copropriétaire alors que coproIds en mappe tous — risque d'envoi à un copropriétaire ayant refusé
• Absence de tests : aucun test unitaire visible pour 0, 1 ou N copropriétaires, ni pour le cas coproIds=undefined
• Comportement silencieux sur cas limites : coproIds undefined ou [] ne déclenche ni erreur ni log

• Zéro test automatisé ajouté: Score testCoverage 2/10 - Aucun fichier de test modifié pour un changement critique d'envoi d'emails multiples
• Anti-pattern async forEach (useShareForm.ts ligne ~97): forEach ne gère pas les Promesses, les erreurs de sentDocumentToCoproDistributionList seront silencieuses - Remplacer par Promise.all(coproIds.map(async...))
• Incohérence fonctionnelle (getDocumentInfo.ts): coproPreferenceSendByMail reste sur data[0] tandis que coproIds mappe tous les IDs - chaque copropriétaire recevra l'email sans vérification de sa préférence individuelle
• Cas limites non couverts: coproIds=[] (aucun envoi mais createTicket appelé), coproIds=undefined (crash sur forEach), coproIds avec IDs invalides
• Régression potentielle sur createTicket: Le 3ème paramètre passe de coproId à undefined - vérification nécessaire du comportement backend

• CRITIQUE - Anti-pattern async/forEach dans useShareForm.ts ligne ~97 : forEach ne propage pas les promesses retournées par le callback async. Les appels sentDocumentToCoproDistributionList s'exécutent en fire-and-forget, les erreurs sont avalées, et l'appelant ne peut pas attendre la complétion. Remplacer par Promise.all(coproIds.map(async ...)) avec gestion d'erreur par destinataire.
• MAJEUR - Incohérence logique dans getDocumentInfo.ts : coproPreferenceSendByMail récupère uniquement la préférence du premier copropriétaire (index [0]) alors que coproIds supporte N destinataires. Chaque copropriétaire doit avoir sa préférence évaluée indépendamment pour éviter les envois non désirés ou les omissions.
• MAJEUR - Paramètre undefined explicite dans createTicket(ticketDatas, token, undefined, coproIds) : signature non refactorée. Le 3ème paramètre devrait être optionnel avec valeur par défaut ou l'API devrait adopter un pattern objet de configuration.
• MODERE - Absence de gestion d'erreur granulaire : si l'envoi échoue pour un copropriétaire parmi N, aucune traçabilité ni mécanisme de retry individuel n'existe dans la boucle forEach.
• MODERE - Typage incomplet : le cast 'as any' subsistant indique que l'interface de sentDocumentToCoproDistributionList n'est pas correctement typée pour le cas multi-destinataires.

Tour 2 : Préoccupations et questions

• CRITIQUE RGPD — getDocumentInfo.ts : coproPreferenceSendByMail reste sur [0] alors que coproIds mappe tous les IDs. Un copropriétaire ayant refusé les notifications les recevra si le 1er a accepté. Violation du droit de refus et risque RGPD.
• TRAÇABILITÉ — useShareForm.ts : forEach async en fire-and-forget avale les erreurs. En cas d'échec d'envoi à un copropriétaire, aucune trace ni retry. Pour une fonctionnalité d'envoi légal de documents, c'est inacceptable.
• API FRAGILE — useShareForm.ts : createTicket(ticketDatas, token, undefined, coproIds). Le 3ème paramètre undefined est un hack qui casse la lisibilité et la maintenabilité du contrat API.
• SURCHARGE POTENTIELLE — Aucun throttle sur la boucle forEach. Pour 50+ copropriétaires, 50+ appels API concurrents sans batch ni limitation de débit.
• ZÉRO TEST — Logique critique d'envoi multi-destinataires sans test. Cas non couverts : coproIds vide, undefined, préférences divergentes, erreurs partielles.

• BUG CRITIQUE useShareForm.ts:97 - async forEach ne propage pas les Promesses. Correction : Promise.all avec try/catch par copropriétaire. Temps : 1.5h
• INCOHÉRENCE getDocumentInfo.ts:21-23 - coproPreferenceSendByMail vérifie seul le 1er copropriétaire. Correction : Map. Temps : 1h
• HACK TEMPORAIRE JUSTIFIÉ - createTicket(undefined, coproIds) sera résolu lors refonte API sprint suivant
• Cas limites non couverts : coproIds=[] (createTicket appelé sans destinataire), coproIds=undefined (crash potentiel)
• Temps réel 2.5h justifié : 0.5h investigation API, 1h implémentation, 0.5h tests manuels, 0.5h debugging

• BUG CRITIQUE : async/forEach ne propage pas les promesses — les erreurs de sentDocumentToCoproDistributionList sont avalées silencieusement. Remplacer par Promise.allSettled avec gestion d'erreur par destinataire
• INCOHÉRENCE FONCTIONNELLE : coproPreferenceSendByMail lit uniquement la préférence du 1er copropriétaire alors que coproIds en mappe tous — risque d'envoi à un copropriétaire ayant refusé les notifications
• DETTE TECHNIQUE EXPLICITE : createTicket(ticketDatas, token, undefined, coproIds) — paramètre undefined en 3ème position rend l'appel illisible et fragile, refactorer avec objet options ou paramètre optionnel
• ABSENCE DE TESTS : Zéro test unitaire pour la logique d'envoi multi-destinataires, cas limites (coproIds=[], undefined, IDs invalides) non couverts
• CAST 'as any' PERSISTANT : sentDocumentToCoproDistributionList reste typé avec 'as any' — dette préexistante non adressée dans ce PR

• AUCUN TEST AJOUTÉ - Le développeur reconnaît lui-même que des tests unitaires sont nécessaires (concern #13) mais n'en fournit aucun. Score testCoverage maintenu à 2/10.
• ARGUMENT FIRE-AND-FORGET INVALIDE - Le développeur justifie async forEach comme 'intentionnel' (concern #11) mais ce pattern ne garantit même pas le fire-and-forget : les Promesses orphelines peuvent causer des UnhandledPromiseRejection. Même un pattern fire-and-forget nécessite un minimum d'observabilité (logs d'erreur, métriques de succès/échec).
• BUG FONCTIONNEL CONFIRMÉ - coproPreferenceSendByMail reste sur data[0] (concerns #1, #16, #22) tandis que coproIds mappe TOUS les IDs. 3 reviewers indépendants confirment l'incohérence. Aucun test ne protège contre cette régression.
• CAS LIMITES NON COUVERTS ET NON TESTÉS - coproIds=[] (envoi sans destinataire), coproIds=undefined (crash), erreur réseau sur 1 envoi parmi N (perte silencieuse). Aucun de ces scénarios n'est testé.
• HACK TECHNIQUE NON RÉSOLU - createTicket(ticketDatas, token, undefined, coproIds) avec paramètre undefined explicite (concern #12). Le développeur reconnaît que c'est temporaire mais aucune issue de suivi n'est mentionnée.

• CRITIQUE (useShareForm.ts:100) : async/forEach ne propage pas les Promesses - erreurs avalées silencieusement, comportement non-déterministe. Remplacer par Promise.allSettled(coproIds.map(async ...)) pour traçabilité.
• MAJEUR (getDocumentInfo.ts:20-22) : coproPreferenceSendByMail lit uniquement data[0] alors que coproIds extrait tous les IDs - risque d'envoi à des copropriétaires ayant refusé. Retourner un mapping coproId → préférence.
• MAJEUR (useShareForm.ts:97) : createTicket(ticketDatas, token, undefined, coproIds) - paramètre undefined explicite rend la signature fragile et illisible. Refactorer vers options object.
• MODÉRÉ : Zéro test automatisé pour une logique métier critique (envoi d'emails à N destinataires avec préférences).
• MODÉRÉ : Pas de limitation de débit pour N appels API concurrents - risque de surcharge si coproIds contient 50+ éléments.

Tour 3 : Validation

• BUG CRITIQUE useShareForm.ts:97 - async forEach ne propage pas les Promesses. forEach retourne void, erreurs avalées silencieusement. Correction : Promise.allSettled(coproIds.map(async ...))
• INCOHÉRENCE FONCTIONNELLE getDocumentInfo.ts:23-25 - coproPreferenceSendByMail vérifie data[0] alors que coproIds mappe tous les IDs. Risque : envoi à copropriétaire ayant refusé si [0] a accepté
• HACK TECHNIQUE useShareForm.ts:96 - createTicket(ticketDatas, token, undefined, coproIds) avec paramètre undefined explicite. Dette tracée pour refonte API sprint suivant
• ABSENCE DE TESTS - Zéro test unitaire pour logique critique multi-destinataires. Cas non couverts : coproIds=[], undefined, erreurs partielles, préférences divergentes
• PAS DE THROTTLE - N appels API concurrents sans limitation. Risque surcharge pour 50+ copropriétaires

• ZÉRO TEST AJOUTÉ - 2 fichiers source modifiés avec logique métier critique, 0 fichier de test. 4 scénarios critiques non couverts : coproIds=[], coproIds=undefined, erreurs réseau partielles, préférences divergentes
• BUG ASYNC FOREACH (useShareForm.ts:97) - coproIds?.forEach(async ...) avale les erreurs. 4 reviewers confirment. Remplacement requis : Promise.allSettled
• BUG RGPD (getDocumentInfo.ts:18-23) - coproIds mappe tous les IDs mais coproPreferenceSendByMail lit seul data[0]. Copropriétaire refusant les notifications les recevra si data[0] a accepté
• HACK UNDEFINED (useShareForm.ts:97) - createTicket(ticketDatas, token, undefined, coproIds) rend l'API illisible. Aucun tracking pour correction promise
• AUCUN THROTTLE - 50+ copropriétaires déclenchent 50+ appels API concurrents sans limitation

• CRITIQUE : async/forEach ne propage pas les Promesses - erreurs avalées silencieusement, comportement non-déterministe. Remplacer par Promise.allSettled avec gestion d'erreur par destinataire.
• CRITIQUE RGPD : coproPreferenceSendByMail lit uniquement data[0] alors que coproIds mappe tous les IDs - risque d'envoi à des copropriétaires ayant refusé les notifications. Retourner Map.
• MAJEUR : createTicket(ticketDatas, token, undefined, coproIds) - paramètre undefined explicite viole ISP et rend le contrat API fragile. Refactorer vers options object.
• MAJEUR : Zéro test automatisé pour la logique d'envoi multi-destinataires - cas limites non couverts (coproIds=[], undefined, erreurs partielles).
• MODÉRÉ : Aucun throttling sur la boucle d'envoi - risque de surcharge API pour 50+ copropriétaires sans batch ni limitation de débit.