Développeur Backend Node.js / NestJS

Refactoring du système de lancement de scripts de migration de données. Les scripts s'exécutaient en changeant l'environnement et en modifiant une classe chargée au démarrage de l'application NestJS — le code tournait dans son constructeur. Risques : exécution hors review, effets de bord difficiles à tracer, code peu réutilisable hors des pratiques NestJS, dette dans une classe de plusieurs centaines de lignes. Migration vers des commandes NestJS classiques et des services dédiés pour faciliter l'écriture des prochains scripts.

• Héritage fragile : scripts de migration lancés au boot via une classe monolithique, sans garde-fous de review ni réutilisation des patterns NestJS du reste de la plateforme.

• Scripts de migration standardisés en commandes NestJS avec services réutilisables — exécution plus sûre et maintenable sur une plateforme où la qualité des données fournisseurs est critique.

Service générique de fusion d'entités TypeORM par introspection. Des doublons (fournisseurs textiles, etc.) apparaissaient faute de validations sur certaines routes ou à cause d'erreurs dans les scripts ; leur fusion était complexe car les entités sont fortement liées et soumises à des règles métier. Service configurable : règles de fusion par entité liée, comportement par défaut sinon, sans modifier le cœur du service.

• Fusionner des doublons sur un graphe d'entités liées (fournisseurs, chaîne textile) sans casser les règles métier — chaque type d'entité pouvant exiger une stratégie de fusion différente.

• Outil réutilisable pour nettoyer les doublons en base et fiabiliser les données de traçabilité alimentant la plateforme.

Intégration monitoring ELK et envoi centralisé des logs. L'équipe Infrastructure déployait une stack ELK ; alignement du tracing sur l'API principale NestJS (niveaux de log, métadonnées structurées) pour l'observabilité de la plateforme SaaS.

• Coordination avec l'équipe Infra sur une stack ELK en cours de déploiement : structurer tracing et métadonnées côté API pour des logs exploitables en production.

• Logs centralisés avec niveaux et métadonnées cohérents sur l'API principale — base pour le debug et le monitoring en prod.