Passer au contenu principal
Solya utilise la journalisation structurée et Sentry pour le suivi des erreurs, avec les PII tenus hors des rapports d’erreurs.

​
Journalisation

  • Niveaux — debug, info, warn, error (sévérité croissante). Le seuil est défini par la variable d’environnement LOG_LEVEL (défaut info) ; les messages en dessous sont ignorés.
  • Format — lisible par l’humain en développement ; lignes JSON en production (un objet par ligne) pour l’ingestion par les outils de journalisation.
  • Contexte — les logs serveur incluent automatiquement la correlationId, userId de la requête et organizationId quand disponibles, afin que vous ne les répétiez pas.
  • Serveur vs client — le code serveur utilise le logger serveur (qui transfère les erreurs à Sentry) ; le code client/isomorphe utilise un logger dont les appels debug/info sont supprimés en production.

​
Sentry

Sentry est initialisé pour les runtimes serveur, edge et client. Il est activé seulement quand un DSN est défini :
  • SENTRY_DSN (serveur) / NEXT_PUBLIC_SENTRY_DSN (client).
  • SENTRY_ENVIRONMENT / NEXT_PUBLIC_SENTRY_ENVIRONMENT — l’étiquette d’environnement.
  • SENTRY_RELEASE / NEXT_PUBLIC_SENTRY_RELEASE — l’identifiant de version.
Le traçage et la relecture de session sont désactivés (erreurs uniquement).

​
Ce qui est et n’est pas envoyé

  • Filtrage de sévérité / catégorie — les logs au niveau error vont à Sentry, sauf les erreurs de faible sévérité et de validation, qui sont traitées comme du bruit opérationnel attendu.
  • Suppression des PII — avant qu’un événement ne soit envoyé, event.user.email est supprimé. Les autres champs (messages, breadcrumbs, stack traces) sont intentionnellement préservés pour garder les diagnostics utiles ; élargir la redaction nécessiterait des tests dédiés pour éviter de silencieusement perdre le signal.
Si vous ajoutez un nouveau champ au contexte utilisateur envoyé à Sentry, décidez s’il est PII et, si c’est le cas, étendez le scrubber et ses tests. Voir la convention de sécurité pour les détails.