SFR — DSI Front Web — Télécom
Architecture et CI/CD de l’espace client, identité et boutique
SFR, RED by SFR, RMC et BFM partageaient un périmètre front sans cible commune. Audit complet des applications du périmètre espace client, identité et boutique en ligne, recommandations d’architecture, puis conception et mise en œuvre d’une nouvelle chaîne CI/CD utilisée par les équipes de développement.
4
marques unifiées sur une seule chaîne de livraison front
Le contexte
Quatre marques — SFR, RED by SFR, RMC et BFM — partageaient un même périmètre front sans architecture cible commune. Le sujet n’est pas cosmétique : espace client, identité et boutique en ligne portent la connexion, la gestion d’abonnement et la souscription. Ces parcours doivent rester distincts côté marque tout en reposant sur les mêmes mécanismes.
Un périmètre de ce type ne diverge pas par accident, mais par accumulation de décisions locales, chacune raisonnable dans son contexte. Chaque application finit par transporter sa propre chaîne de build, ses propres tests, son propre chemin de déploiement. Le coût ne se voit pas sur une application isolée : il apparaît quand une correction de sécurité doit être appliquée quatre fois.
D’où la contrainte de méthode : une architecture cible écrite sans inventaire préalable ne s’applique jamais, parce qu’elle décrit un système que personne ne reconnaît.
Notre intervention
L’audit a donc porté sur les applications réellement en service du périmètre : dépendances, temps de build, duplications entre marques, et surtout la frontière entre ce qui est partagé et ce qui n’est que copié. Cette distinction commande tout le reste — on ne factorise pas ce qui doit diverger, et on ne duplique pas ce qui doit rester unique.
Les recommandations d’architecture ont été formulées sur cette base, autour de la stack en place (React, TypeScript, Node.js) : conserver les technologies que les équipes maîtrisent et déplacer l’effort là où il produit un effet — la structure du périmètre, pas le remplacement du framework. Une cible n’a de valeur que si les équipes peuvent la défendre sans nous.
La chaîne de livraison a ensuite été conçue puis mise en œuvre : Jenkins et GitLab CI articulés autour d’un contrat unique, l’image Docker comme unité de livraison, Kubernetes comme cible d’exécution. Même artefact, même chemin de déploiement, configuration propre à chaque marque. Ce qui varie est déclaré ; le reste est commun.
Le critère retenu n’était pas la mise en service du pipeline mais son usage réel : une chaîne que les équipes contournent est un livrable raté. Elle a donc été construite avec ceux qui allaient s’en servir, puis transférée avec les recommandations.
Résultats
- Architecture cible unifiée multi-marques
- Pipeline CI/CD modernisé et adopté
- Recommandations livrées et transférées
Technologies & outils
Les quatre marques passent par une seule chaîne de livraison front. Concrètement, une évolution du processus de build ou un correctif d’outillage s’applique désormais une fois pour tout le périmètre, et une nouvelle application démarre d’un chemin existant au lieu d’en inventer un. Le coût marginal d’une marque supplémentaire cesse d’être un projet.
Le pipeline est utilisé par les équipes de développement, et les recommandations d’architecture ont été livrées puis transférées : elles restent lisibles et discutables après notre départ. C’est l’exigence de toutes nos missions d’architecture logicielle : une décision qui ne survit pas au consultant qui l’a écrite n’a pas vraiment été prise.
06 — Contact
45 minutes.
Sans engagement.
Décrivez la décision technique devant vous. Nous vous disons ce que nous ferions, si c’est pour nous, et ce que ça coûte. Réponse sous 24 h ouvrées, par un associé.