Aller au contenu
SYS–06Étude de casScolaireProjet de session livré · ÉTS

CanTelcoX

Un BSS télécom passé de microservices synchrones à une architecture événementielle — et cinq paliers d'optimisation mesurés un par un, y compris celui qui n'a rien donné.

Type
Projet de session · équipe (ÉTS LOG430)
Domaine
Télécom · BSS (portabilité, activation, facturation, anti-fraude)
Statut
Projet de session livré · ÉTS
Période
2026
Rôle
Architecture & développement · socle événementiel et svc-subscription
Équipe
Équipe de 5 · 60 des 97 commits de la branche sont les miens
Python 3.12 · FastAPIRabbitMQMySQL · FlywayRedisKrakenD · NGINXPrometheus / GrafanaJaegerk6Docker Composefree5GC
Dépôt GitHub Mis à jour : 2026-09-09

01 Résumé

CanTelcoX est le système commercial d'un opérateur mobile : portabilité de numéro, activation de ligne, facturation, MFA, anti-fraude. Le système passe de microservices synchrones à une architecture orientée événements — 6 services hexagonaux, saga chorégraphiée sur RabbitMQ, Outbox transactionnel, file de rebut, traçage distribué. Le livrable dont je suis le plus fier n'est pas la liste de patrons : c'est la campagne de charge, conduite en cinq paliers dont chacun a une cause identifiée par la mesure — accusé P95 divisé par 2,4, convergence des sagas passée de 47 % à 100 %, zéro erreur sur 22 031 requêtes.

02 Contexte

Cours d'architecture logicielle (LOG430) à l'ÉTS. Les labos isolent chacun un patron sur la même application jouet ; le projet de session est le seul endroit où ces patrons doivent tenir ensemble, sur un domaine métier réel, avec des intégrations externes qu'on ne contrôle pas et des mesures qu'on doit concevoir soi-même.

03 Mon rôle & l'équipe

Projet d'équipe : 5 contributeurs, 97 commits sur la branche publiée. J'en signe 60, portant principalement sur le socle événementiel et sur le service le plus complexe du système. Chaque affirmation est vérifiable dans l'historique Git du dépôt public.

  • Le châssis de messagerie partagé — enveloppe d'événement, relais outbox, consommateur, DLQ, retry à backoff, propagation du traceId
  • svc-subscription de bout en bout — domaine, cycle de vie des lignes, ports, ACL, adapters free5GC, portabilité entrante et sortante
  • La saga chorégraphiée — producteurs, consommateurs, compensation, piste d'audit
  • Les cinq paliers de performance — scénario k6, campagnes, répartiteur NGINX, réplication, optimisation de l'adapter HLR

04 Cinq paliers, chacun mesuré

Campagne k6, montée 10 → 50 → 100 VU sur 3 minutes, trafic entrant par le répartiteur de charge. Deux métriques distinctes, et la distinction est tout le sujet : l'accusé de réception du POST /v1/orders, et la convergence de la saga jusqu'à COMPLETED. Un accusé rapide ne prouve rien si la chaîne derrière n'aboutit pas.

952,78 → 395,97 msMesuré
accusé P95 (référence → final)
÷ 2,4 — campagne k6 du 2026-08-06
47,05 % → 100 %Mesuré
convergence des sagas
607/607
0 % (0 / 22 031 req.)Mesuré
taux d'erreur
79,99 → 114,52 req/sMesuré
débit HTTP
+43 %
1,5 → 3,16Mesuré
sagas complètes par seconde
× 2,1
1 467 → 0Mesuré
événements dupliqués (avant → après correctif)
173Testé
tests unitaires domaine + application
60 / 97Implémenté
mes commits sur la branche publiée

05 Limites

  • Projet académique : échelle de laboratoire, pas de charge de production réelle ni d'utilisateurs.
  • Le taux de convergence atteint 100 %, mais la latence de convergence P95 reste à 26,34 s, au-dessus du seuil de 10 s fixé au scénario.
  • Le débit mesuré (114,52 req/s) demeure loin de la cible de 1 000 ops/s du cahier de charge. L'écart est mesuré et localisé, pas expliqué après coup : la topologie de démonstration — un seul broker, trois nœuds sur une machine — en est la limite structurelle.
  • Projet d'équipe de 5 : 60 des 97 commits de la branche publiée sont les miens.
  • Le dépôt est publié sous licence académique restrictive — consultable et exécutable pour évaluation, sans droits accordés sur le code des autres contributeurs.