🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• Risque de régression élevé : aucun test automatisé ne vérifie la construction du payload FormData. Si un développeur réintroduit data.append("publishedAt", JSON.stringify(null)), le bug réapparaîtra sans détection en CI/CD
• Pattern incohérent sur AGId (ligne 112) : data.append("AGId", ag || "") envoie une chaîne vide quand ag est falsy, alors que publishedAt est maintenant omis. Cette incohérence suggère soit un contrat backend différent, soit un bug similaire non corrigé
• Contrat backend non documenté : le comportement attendu quand publishedAt est absent vs présent doit être explicitement documenté côté backend, sinon la correction reste fragile
• Dette technique de 3h à planifier : tests unitaires sur DocumentShareAGModal vérifiant les données FormData soumises avec et sans publishedAt
• Anti-pattern JSON.stringify() dans FormData.append() mériterait une règle ESLint personnalisée ou une entrée dans les guidelines d'équipe pour prévenir les régressions futures

• Dette technique 1.5h : test d'intégration manquant sur la construction FormData dans DocumentShareAGModal
• Pattern AGId avec chaîne vide mérite un commentaire explicatif pour distinguer du comportement publishedAt
• Documentation backend absente sur le comportement attendu quand publishedAt est absent vs présent

• Aucun test de non-régression ajouté : si un développeur réintroduit data.append("publishedAt", ...) sans logique conditionnelle, le bug réapparaîtra sans détection automatique
• Anti-pattern adjacent ligne 112 : data.append("AGId", "") envoie une chaîne vide au lieu d'omettre le champ – le backend doit interpréter "" comme absent, ce qui est fragile et incohérent avec le fix appliqué
• Absence de typage FormData : aucune validation côté client (ex : Zod, Yup) ne garantit que seuls les champs attendus avec des valeurs correctes sont envoyés
• publishedAt pourrait être requis dans un futur cas d'usage (ex : publication programmée) – il faudra alors ajouter une condition `if (publishedAt) data.append("publishedAt", publishedAt.toISOString())` plutôt que de renvoyer null

• Aucun test de régression automatisé ajouté : le bug corrigé pourrait réapparaître sans détection en CI/CD
• Approche de test manuelle uniquement décrite dans le commit, non reproductible et non pérenne
• Absence de tests d'intégration sur DocumentShareAGModal vérifiant les données FormData soumises - ce bug aurait dû être prévenu par des tests existants
• Le pattern JSON.stringify(null) produisant la chaîne 'null' dans FormData est un piège JavaScript connu qui mériterait un test unitaire dédié sur la construction du payload
• Dette technique de test estimée à 3h pour ajouter des tests couvrant la soumission du formulaire avec et sans publishedAt

• Aucun test unitaire ni d'intégration ajouté pour ce correctif - risque de régression si un développeur réintroduit JSON.stringify(null) dans FormData (dette future estimée : 0.3h)
• Pattern similaire potentiellement problématique sur la ligne adjacente : data.append("AGId", ag || "") envoie une chaîne vide au lieu de null/undefined quand ag est falsy - même catégorie de bug possible
• Absence de règle ESLint personnalisée pour détecter l'anti-pattern JSON.stringify() dans les appels FormData.append() - ce pattern est une source récurrente de bugs dans les applications React/TypeScript
• Question architecturale non résolue : le backend doit-il explicitement documenter le comportement quand publishedAt est absent vs présent ? Sans documentation, la correction reste fragile

Tour 2 : Préoccupations et questions

• Risque de régression métier élevé : aucune garantie CI/CD contre la réintroduction de JSON.stringify(null) dans FormData - un développeur pourrait réinsérer cette ligne sans détection, recréant le bug d'affichage 'null' sur les dates de publication des documents AG
• Contrat backend non documenté pour publishedAt : le comportement attendu quand le champ est absent du FormData vs présent avec valeur 'null' doit être explicité pour éviter les régressions côté API
• Pattern incohérent ligne 112 : data.append('AGId', ag || '') envoie chaîne vide quand ag est falsy, alors que publishedAt est maintenant omis - cette incohérence suggère soit des contrats backend différents, soit un bug similaire non corrigé sur AGId
• Absence de validation FormData côté client : aucun schéma (Zod/Yup) ne garantit le format des données envoyées, permettant la réintroduction d'anti-patterns JSON.stringify() dans les futurs développements

• Aucun test de non-régression : réintroduction de JSON.stringify(null) dans FormData non détectable en CI/CD - 2h dette pour tests payload FormData
• Pattern incohérent ligne 112 : data.append('AGId', '') envoie chaîne vide au lieu d'omettre le champ - 1h dette pour homogénéiser avec le fix publishedAt
• Documentation backend absente : comportement quand publishedAt est absent non spécifié - risque de régression si le backend exige ce champ
• Absence validation FormData côté client : risque de réintroduction d'anti-pattern similaire si champs null ajoutés sans condition

• Aucun test de régression automatisé : réintroduction de data.append('publishedAt', JSON.stringify(null)) non détectée en CI/CD - test manquant : expect(formData.get('publishedAt')).toBeNull()
• Pattern adjacent non corrigé ligne 112 : data.append('AGId', ag || '') envoie chaîne vide au lieu d'omettre le champ - incohérent avec le fix publishedAt
• Absence de validation FormData (Zod/Yup) : aucun schéma ne garantit le contrat backend { userId, ppeDriveId, agCategory, AGId? }
• Dette de test 3h : test unitaire buildShareFormData + test intégration DocumentShareAGModal + test régression JSON.stringify dans FormData
• Anti-pattern JSON.stringify(null) dans FormData non détecté par ESLint - règle personnalisée nécessaire

• Anti-pattern adjacent ligne 112 : data.append('AGId', ag || '') envoie '' au lieu d'omettre le champ, incohérent avec le fix publishedAt (dette ~0.3h)
• Absence de tests de régression sur la construction FormData : risque de réintroduction silencieuse de JSON.stringify(null) (dette ~0.5h)
• Contrat API non documenté : le backend doit distinguer publishedAt absent de publishedAt présent, sans documentation ce comportement est fragile
• Construction FormData ad-hoc : 7 appels append séquentiels sans validation ni logique conditionnelle cohérente

Tour 3 : Validation

• CRITIQUE : Zéro test de régression - réintroduction de data.append('publishedAt', JSON.stringify(null)) indétectable en CI/CD. Test requis : expect(formData.get('publishedAt')).toBeNull()
• CRITIQUE : Pattern incohérent ligne 112 - data.append('AGId', ag || '') envoie chaîne vide vs publishedAt omis. Stratégies contradictoires pour valeurs absentes dans le même FormData
• ÉLEVÉ : Absence de validation FormData (Zod/Yup) - aucun schéma ne garantit le contrat backend {userId, ppeDriveId, agCategory, AGId?}
• ÉLEVÉ : Contrat backend non documenté - comportement quand publishedAt est absent vs présent non spécifié, risque de régression si le backend exige ce champ
• MOYEN : Anti-pattern JSON.stringify() dans FormData.append() non détecté par ESLint - règle personnalisée nécessaire