Skip to main content

Dette technique connue

Dernière vérification contre le code

Vérifié le 2026-08-13, entrées OTP/SBA et mailer mises à jour le 2026-08-24 (second pull backend le même jour).

Points identifiés mais volontairement non résolus dans l'immédiat — à traiter quand l'occasion se présente, pas urgents. Pour les bugs et failles de sécurité déjà actifs (pas différables), voir Bugs & failles actives connues.

Deux fichiers mailer.js distincts et redondants​

  • src/services/mailer.js — utilisé par loan.controller.js (accusé de réception, notification de changement de statut) et account_requests.controller.js.
  • src/utils/mailer.js — utilisé par users.controller.js (email d'invitation à configurer un mot de passe).

Deux implémentations séparées de la même chose (envoi d'email via Nodemailer), avec des divergences de comportement :

  • utils/mailer.js lit correctement SMTP_SECURE depuis .env (secure: process.env.SMTP_SECURE === 'true').
  • services/mailer.js ne le lisait pas à l'origine — bug corrigé le 01/08/2026 (confirmé dans le code actuel : services/mailer.js lit désormais bien SMTP_SECURE) — c'est cette divergence qui a révélé l'existence des deux fichiers.
  • utils/mailer.js a un comportement de repli propre (log "MOCK EMAIL" en console si SMTP non configuré ou en erreur) ; services/mailer.js n'a pas d'équivalent aussi robuste.

À faire un jour : fusionner en un seul module mailer, avec le comportement de repli de utils/mailer.js (plus robuste en dev), utilisé par tous les contrôleurs. En attendant, vérifier systématiquement lequel des deux fichiers on modifie avant de toucher à la config SMTP ou d'ajouter un nouveau type d'email.

Le piège d'URL déjà corrigé une fois s'est reproduit — cette fois dans l'autre fichier

utils/mailer.js avait une URL de setup-password codée en dur, corrigée le 2026-08-13 en lisant process.env.FRONTEND_URL (déjà présente dans .env.example). Le 2026-08-20 (cdde188), une nouvelle fonction sendResetPasswordEmail a été ajoutée dans l'autre fichier, services/mailer.js, pour l'email de réinitialisation de mot de passe — et reproduit exactement le même défaut : const resetUrl = \http://localhost:5173/admin/reset-password?token=${token}\`` codé en dur, avec un commentaire qui le reconnaît lui-même ("en production, il faudra utiliser une variable d'environnement, ex : process.env.FRONTEND_URL") sans l'appliquer. Preuve concrète que la duplication entre les deux fichiers mailer n'est pas qu'une question de style — elle fait déjà répéter un bug corrigé. Voir Bugs & failles actives connues.

Intégration Sopra Banking Amplitude (SBA) — réelle via UWM depuis le 2026-08-24, mais repli mock silencieux en cas de panne​

L'OTP/SMS du portail d'authentification de Demande de prêt scolaire et de Ouverture de compte est réel depuis le 2026-08-24 (code à 6 chiffres aléatoire, SMS envoyé via une passerelle Kannel, voir OTP, SMS & vérification SBA) — ce n'est donc plus "dette technique" au sens propre. La vérification bancaire elle-même (backend/src/services/sba.service.js) est passée le même jour d'un mock intégral à un vrai appel vers un middleware "UWM" (pont vers Sopra Banking Amplitude).

Ce qui reste non finalisé : en cas d'échec de cet appel (UWM injoignable, mal configuré, en panne), le service retombe silencieusement sur deux comptes de test codés en dur, sans que rien de visible côté utilisateur ne distingue ce repli d'un vrai succès — voir le détail dans OTP, SMS & vérification SBA. Tant que ce repli n'est pas retiré (ou au minimum surveillé/alerté) avant une mise en production réelle, une panne du middleware bancaire peut passer complètement inaperçue.

Deux moteurs NLP pour le chatbot, un seul actif​

Voir Chatbot (NLP + RAG) — l'ancien moteur @nlpjs (chatbot-training.json, model.nlp) n'est plus chargé par le code actuel, remplacé par un système RAG + Ollama. Décision (2026-08-13) : ces fichiers restent en place, pas de nettoyage prévu pour l'instant.