Orange : cartographie et supervision IT

Contexte

Les équipes concernées suivent de nombreux services applicatifs répartis sur différentes plateformes. Savoir quel service dépend de quel autre, quel incident touche qui et où en est une migration demandait de croiser plusieurs sources d'information.

La plateforme rassemble ces informations dans un référentiel unique, branché sur les systèmes internes existants plutôt que de les dupliquer.

Le problème à résoudre

• Un référentiel des services — criticité, indicateurs de santé, métriques de qualité de service et dépendances entre services.
• Une analyse d'impact rapide — en cas d'incident ou de maintenance, savoir immédiatement quels services et quelles équipes sont concernés.
• Des transitions traçables — piloter les migrations de services avec des étapes de validation, des preuves à fournir et des délais suivis.

Contraintes

• Intégration au SI Orange — authentification via Orange Connect (OIDC), synchronisation avec l'outil de gestion des incidents et reprise des données organisationnelles.
• Charte graphique du groupe — l'interface doit respecter Boosted, le design system d'Orange.
• Processus à valider — une transition engage plusieurs équipes : chaque étape doit être horodatée, attribuée et vérifiable a posteriori.
• Exploitation interne — déploiement sur OpenShift via GitLab CI, secrets stockés dans Vault.

Choix techniques et pourquoi

• Symfony Workflow pour les transitions — chaque transition est une machine à états : les passages autorisés sont déclarés une fois, et l'application refuse ceux qui ne le sont pas. La traçabilité du processus repose sur le modèle, pas sur la discipline des utilisateurs.
• Symfony Messenger pour l'asynchrone — synchronisations avec les systèmes externes et notifications sortent du cycle de la requête HTTP : l'interface reste réactive même quand un système tiers est lent.
• API Platform et React — une API documentée côté Symfony, une interface React et TypeScript côté navigateur, habillée avec Boosted.
• Redis pour le cache — les données issues des systèmes internes sont mises en cache pour limiter les appels et garder des temps de réponse stables.
• Le même socle que les autres projets Orange — image Docker commune, librairie PHP partagée et chaîne de déploiement identique : la maintenance reste mutualisée.

Ce qui a été livré

• Catalogue de services — référentiel avec criticité, indicateurs de santé, métriques QoS et dépendances.
• Gestion des événements — incidents, maintenances planifiées et événements impactants, avec timeline, analyse d'impact et notifications aux équipes abonnées.
• Transitions techniques — workflow multi-étapes : livraison de preuves, validation en deux phases et suivi des délais par équipe.
• Tableaux de bord — état global des services, graphiques d'évolution et calendrier des événements.
• Administration — configuration des services, des groupes et des modèles de transition.
• Connecteurs — Orange Connect, gestion des incidents, cartographie d'infrastructure et hiérarchie organisationnelle.

Résultats

La plateforme est en production depuis 2019 et toujours maintenue. Elle évolue avec l'organisation des équipes : nouveaux modèles de transition, nouveaux connecteurs et montées de version régulières des frameworks.

Stack

• Back-end — PHP, Symfony (Workflow, Messenger), API Platform
• Front-end — React, TypeScript, Boosted (Bootstrap)
• Données — MySQL, Redis
• Infrastructure — Docker, OpenShift, GitLab CI, Vault

Pour aller plus loin

Ce type de plateforme relève de mon offre scalabilité et architecture applicative. Sur l'exploitation de ce type d'application, voir aussi déployer en journée sans couper le service et sortir les secrets de GitLab CI avec Vault.