Analyse et refactore le code suivant en respectant cette méthodologie étape par étape.

<fichiers-a-analyser>
[Indique ici les chemins des fichiers à refactorer, un par ligne]
</fichiers-a-analyser>

<objectif>
[Décris l'objectif du refactoring: améliorer la lisibilité, réduire la duplication, simplifier la logique, améliorer les performances, etc.]
</objectif>

Suis ces étapes dans l'ordre:

<etape-1-analyse>
Lis chaque fichier et identifie les code smells présents parmi cette liste:
- Fonctions trop longues (plus de 30 lignes)
- Duplication de code
- Nesting excessif (plus de 3 niveaux d'indentation)
- Nommage ambigu ou trompeur
- Couplage fort entre modules
- Responsabilités multiples dans une seule fonction/classe
- Types "any" ou assertions de type non justifiées
- Effets de bord cachés
- Magic numbers ou strings sans constantes

Produis un rapport structuré:
- Fichier: [chemin]
- Smell: [nom du smell]
- Ligne(s): [numéros]
- Sévérité: critique / majeur / mineur
- Impact: [explication courte]
</etape-1-analyse>

<etape-2-plan>
Pour chaque smell identifié, propose un plan de refactoring:
- Technique: extract function, rename, inline, move, split module, introduce parameter object, etc.
- Avant: montre le code actuel (extrait pertinent)
- Après: montre le code refactoré
- Risque: aucun / faible / moyen (justifie si moyen)

Ordonne les changements du moins risqué au plus risqué.
</etape-2-plan>

<etape-3-execution>
Applique les changements un par un dans l'ordre du plan.
Après CHAQUE changement:
1. Vérifie que le code compile (pas d'erreurs TypeScript)
2. Lance les tests existants pour vérifier qu'aucune régression n'est introduite
3. Si un test échoue, annule le changement et explique pourquoi

Ne passe au changement suivant que si le précédent est validé.
</etape-3-execution>

<etape-4-verification>
Une fois tous les changements appliqués:
1. Lance la suite de tests complète
2. Vérifie le typage TypeScript (tsc --noEmit)
3. Lance le linter
4. Produis un résumé des améliorations:
   - Nombre de lignes avant/après
   - Smells résolus
   - Changements non appliqués (et pourquoi)
</etape-4-verification>

<contraintes>
- Ne change JAMAIS le comportement observable du code (même entrées = mêmes sorties)
- Préserve les interfaces publiques (exports, signatures de fonctions)
- Un commit par changement logique avec message descriptif
- Si un fichier n'a pas de tests, crée les tests AVANT de refactorer
</contraintes>