Skip to main content

API de suivi de dossier (/api/tracking) — changement de contrat

Dernière vérification contre le code

Vérifié le 2026-08-12 contre tracking.controller.js — exact au caractère près.

Breaking change : cette API n'est plus un simple GET. Toute intégration externe pointant vers l'ancienne route cassera silencieusement (404) sans lire ce document.

Avant​

GET /api/tracking/:ticketNumber

Le ticket seul suffisait à récupérer le statut d'un dossier (prêt ou compte).

Maintenant​

POST /api/tracking
Body: { "ticket_number": "UTB-20260801-4F2A", "phone": "+228 90000000" }

Pourquoi ce changement​

Le format du ticket (UTB-YYYYMMDD-XXXX) n'a que ~1,68 million de combinaisons possibles par jour (XXXX = 4 caractères parmi 36) — largement énumérable par un script sans protection dédiée. Or l'ancienne route, avec juste le ticket, exposait déjà : statut de la demande, type de prêt/profil, dates de dépôt et de mise à jour, et un nom partiellement masqué. Dans un contexte bancaire, "telle personne a demandé un prêt et a été rejetée" reste une donnée sensible même sans nom complet.

La correction : exiger en plus le téléphone communiqué à la soumission — même principe que "code de réservation + nom" (compagnies aériennes) ou "numéro de suivi + code postal" (transporteurs). Un attaquant doit désormais deviner à la fois le ticket et le téléphone associé.

Détails d'implémentation (tracking.controller.js)​

  • Comparaison de téléphone tolérante (phonesMatch) : les deux numéros sont normalisés (chiffres uniquement), et matchent si l'un est un suffixe de l'autre (au moins 6 chiffres) — permet à un client d'omettre l'indicatif pays sans bloquer une vérification légitime.
  • Message d'erreur volontairement identique que le ticket n'existe pas OU qu'il existe mais que le téléphone ne correspond pas (NOT_FOUND_MESSAGE unique). Sinon on recrée un oracle : un attaquant pourrait distinguer "ticket valide, mauvais téléphone" de "ticket invalide" et continuer à énumérer les tickets valides même sans connaître le téléphone associé.
  • Limiteur de débit dédié (trackingLimiter, tracking.routes.js) : 15 requêtes/15 min par IP sur cette route spécifiquement, plus strict que la limite globale de l'API.

Que faire si le client change de téléphone​

Aucun mécanisme self-service pour l'instant (volontaire — un changement libre-service sans vérification forte annulerait la protection). Le client doit contacter l'agence, prouver son identité par un autre moyen, et un gestionnaire corrige le téléphone directement depuis la fiche détail de la demande (Fiche détail prêt, champ Téléphone éditable).

Évolution prévue : une fois l'OTP (email ou SMS) en place côté suivi, le client pourra se vérifier par ce canal alternatif et déclencher lui-même la mise à jour de son numéro, sans passer par l'agence. Voir aussi le portail OTP déjà en place (mais non branché à un vrai SMS) sur le formulaire Demande de prêt scolaire — même logique, contexte différent.