Où regarder

• Erreurs applicatives → Sentry (projets séparés back/front)
• Logs runtime (info/debug) → stdout du conteneur uniquement (docker logs), rien n'est persisté sur disque
• Historique métier (statuts, mails, scores, contacts binôme...) → tables log-* en base, voir entities/logging.md

Pièges

• DSN Sentry différents entre back et front : SENTRY_DSN_BACK vs SENTRY_DSN. La variable SENTRY de .env.example n'est lue nulle part — un reliquat, ne pas s'attendre à ce qu'elle fasse quoi que ce soit.
• back/src/main.ts contient un second Sentry.init(...) commenté, mort, jamais exécuté. Si Sentry semble mal configuré, la vraie init est dans back/src/app.module.ts.
• Les erreurs des consumers RabbitMQ (back/src/mvls/mvls.service.ts, back/src/events/events.service.ts) ne remontent pas dans Sentry, seulement en console — pour debug un message RabbitMQ perdu, regarder les logs Docker, pas Sentry.
• Historique métier en base = append-only : aucune ligne n'est jamais mise à jour, une correction ajoute une nouvelle entrée.
• ExternalLog (table log-external) existe mais n'est jamais alimenté en pratique — ne pas compter dessus pour tracer les appels FrontApp/Make.
• Les subscribers TypeORM (back/src/binomes/subscribers/) inspectent les colonnes modifiées comme le ferait un audit trail, mais c'est pour synchroniser le CRM FrontApp — pas un mécanisme de logging.

Recommandations

1. Définir une politique de rétention sur les tables log-* : ce sont ~12 tables append-only (+ ExternalLog, ReponseBinomeLog, AlgoMatchingTrace) qui ne sont jamais purgées ni archivées — seuls des index FK existent, pas de job de nettoyage. Sans purge/archivage, elles grossissent indéfiniment.
2. Unifier le logging runtime (aujourd'hui un mélange de Logger NestJS et de console.log bruts, sans niveaux configurés dev/prod) et couvrir le trou Sentry sur les consumers RabbitMQ.