3h17 du matin. Alerte ticket #INC-20260610-0847 : "客户提供完全失去了光纤连接。客户位于里昂，8 subscribers affectés。"（Perte totale de connexion fibre pour 8 abonnés.）
Vous êtes L1. Vous voyez l'incident. Vous ne savez pas s'il s'agit de : un point de terminaison client (CPE) défaillant, un splitter en panne sur un segment partagé, un problème de backbone vers l'OLT, ou une coupure de flamme sur un câble long.
La réponse par défaut dans la plupart des NOC : escalader à L2. Parce que L1 n'a pas la visibilité pour trancher. Parce que le ticket contient "perte totale" et que le SLA dit 4h. Parce que le manager a dit de ne pas prendre de risque.
Résultat : L2 passe 45 minutes à reproduire le diagnostic L1 aurait pu faire en 5, pendant que le ticket attend. Et ça se répète 8 fois par shift.
Ce problème n'est pas un problème d'équipe. C'est un problème de visibilité. Et il se corrige en 5 étapes.
La première information à établir sur un ticket réseau, c'est la couche où se situe le problème. Pas l'adresse, pas le client, pas la ville. La couche.
Un incident FTTH vit à l'une de ces trois places :
| Couche | Symptôme typique | Métriques clés | Résolution |
|---|---|---|---|
| CPE / ONT | 1 abonné, box éteinte, signal absent côté client | ONT RxPower = -30 dBm (CPE seul), ONT offline dans ACS | Remplacement ONT ou vérification connectique client |
| Distribution / Splitter | 5–20 abonnés, coupure sectionnelle, même splitter | OLT RxPower OK mais portion d'ONTs offline, FEC errors en hausse | Intervention terrain sur splitter / drop cable |
| Backbone / OLT | 100+ abonnés, port PON ou chassis OLT | OLT port PON down, rxPower drop sur tout le port, link status down | Escalade réseau + dispatch terrain infrastructure |
La classification correcte divise votre volume d'escalades par 3 à 5. Pourquoi ? Parce qu'elle transforme la question "est-ce grave ?" en "de quel type est-ce ?" — une question à cui on peut répondre sans remonter à L2.
Les métriques à regarder dans les 90 premières secondes
Quand le OLT port RxPower est dans les clous (-8 à -25 dBm), le signal entrant sur le port PON est sain. Si des ONTs sont offline sur ce port, le problème est en aval (splitter, drop cable). Si le OLT port lui-même est down, le problème est en amont (fibre feeder, chassis OLT).
En 90 secondes sur votre supervision, vous devez pouvoir répondre à trois questions : Le port OLT est-il UP ? Quel est le nombre d'ONTs affectés ? Les FEC errors sont-elles en pic ? Si vous ne pouvez pas répondre à ces trois questions sans quitter votre outil de supervision, votre stack L1 n'est pas dimensionnée correctement.
Une fois la couche identifiée, la deuxième question : où exactement dans le chemin physique ?
Un réseau GPON n'est pas un ensemble de liens — c'est un arbre. OLT en racine, splitter au premier nœud de distribution, drop cable vers chaque abonné. Une panne sur le segment "entre splitter et abonné" se diagnostique différemment d'une panne sur le feeder "entre OLT et splitter".
La topologie OLT-GPON se représente ainsi :
OLT (rack/chassis/card/port)
→ Fibre feeder (trunk cable ID)
→ ODF (Optical Distribution Frame)
→ Splitter (1:N ratio, position physique)
→ Drop cable (fibré client unique)
→ Point de terminaison
→ ONT (Serial Number / ID client)
Pourquoi le SN de l'ONT ne suffit pas
Quand un abonné appelle et vous donne son numéro de contrat, vous avez un Serial Number ONT. Ce serial vous donne accès aux données TR-069 de ce CPE — RxPower, état, erreurs CRC. Mais il ne vous dit pas où ce CPE est branché physiquement.
Pour ça, il faut la corrélation :
- ONT Serial (depuis TR-069 / ACS) ↔ ONT-ID GPON (identifiant assigné par l'OLT à l'enregistrement)
- ONT-ID ↔ Port PON OLT (rack/card/port)
- Port PON ↔ Splitter en aval (position dans le réseau de distribution)
Cette cartographie se construit une fois et se maintient. Les équipes qui l'ont fait rapportent que le diagnostic L1 passe de "je ne sais pas" à "splitter secteur B, attente dispatch" en moins de 2 minutes.
Obstacle courant : Le mapping Serial ↔ ONT-ID ↔ Port PON est stocked dans votre OSS/BSS ou votre outil de provisionnement GPON — mais il n'est pas synchronisé avec votre supervision temps réel. Quand un ONT est remplacé, l'ancienne correspondance persiste 24–48h. Résultat : vous cherchez un ONT qui n'existe plus à cet emplacement. Un workflow de mise à jour du mapping sur changement d'équipement est indispensable.
Quick topologie — checklist terrain
Questions topologiques pour qualifier le segment
- Le port PON OLT est-il UP sur le NMS ?
- Combien d'ONTs sur ce port sont offline vs total ?
- Les ONTs offline sont-ils contigus (même splitter) ou dispersés ?
- Le splitter concerné a-t-il un historique de pannes récentes ?
- Y a-t-il eu des travaux ou interventions сигнализируют sur le segment ces 72 dernières heures ?
C'est l'étape la plus négligée et la plus rentable. La récurrence change la qualification.
Un abonné avec une coupure pour la première fois cette année → problème CPE probable (connecteur desserré, ONT en fin de vie, box abonné défaillante). Le même abonné avec 4 coupures en 3 mois → problème infrastructure sur le segment.
Le changement de paradigme :
| Pattern | Interpretation | Action L1 |
|---|---|---|
| Coupure unique, abonné isolé | CPE / connectique client | Dépannage terrain standard, pas d'escalade réseau |
| Même abonné, 3+ incidents en 60 jours | Infrastructure défectueuse sur le segment | Escalade réseau avec pattern historique — dispatch prioritaire |
| Multiple abonnés même zone, incidents espacés | Splitter ou feeder dégradé | Escalade réseau avec localisation — inspection splitter |
| Même port OLT, incidents groupés (même jour/semaine) | Port OLT ou chassis en fin de vie | Escalade N2 immédiate avec historique — remplacement port/chassis |
Un NOC L1 avec accès à l'historique des incidents par segment (splitter, zone, port OLT) peut qualifier correctement 80% des tickets qui otherwise escaladeraient par défaut. Le pattern n'est pas une intuition — c'est une métrique. Il doit être visible dans votre outil de supervision en 2 clics maximum.
Les données FiberOps sur les NOC clients montrent que les segments avec plus de 3 incidents en 90 jours ont un taux de récurrence de 78% dans les 30 jours suivants. Un segment qui casse une fois cassera à nouveau. L'historique n'est pas une formalité — c'est un outil de prédiction.
Attention au biais de sélection : les incidents qui vous arrivent sont ceux qui n'ont pas été détectés automatiquement. Un segment avec 12 microcoupures en un mois (dont 10 auto-résolues par reconnection ONT) va vous arriver avec 2 tickets "coupure abonné" — mais l'historique montre un problème infrastructure, pas 2 incidents isolés.
La différence entre un ticket escaladé et un ticket bien qualifié, c'est le contexte. Un ticket avec le serial de l'ONT et le code postal ne vous dit pas si le RxPower est à -18 dBm (normal) ou -28 dBm (dégradé). Un ticket avec le RxPower, le nombre de FEC errors, et le timestamp du dernier reboot — ça vous dit exactement où vous en êtes.
L'automatisation, c'est l'enrichissement avant la main humaine. L'idée : chaque ticket incident receives automatically (sans intervention L1) le contexte de diagnostic GPON + TR-069.
Ce qu'un ticket enrichi automatiquement contient
Ticket #INC-20260610-0847 ══════════════════════════════════════ Abonné : SARL Dupont Logistique — ID 48921 Adresse : 38 rue de la Soie, 69002 Lyon Segment : OLT-Lyon-SE-01, Port PON 3/2/7 ONT-ID : 017 | Splitter: SPL-69002-14 ══════════════════════════════════════ OLT RxPower : -6.2 dBm ✅ (port OK) ONT RxPower : -24.8 dBm ✅ (dans fenêtre GPON) FEC errors : 147/min ⚠ (au-dessus du baseline 12/min) ONT firmware : V300R016C10 (2022-09 — à mettre à jour) Dernier reboot : Il y a 14 jours (perte secteur) ══════════════════════════════════════ Historique 90j : 4 incidents sur ce segment (splitter SPL-69002-14) Dernier ticket : 23 jours — résolu par reconfiguration splitter ══════════════════════════════════════ Qualification L1 : Problème infrastructure probable (pattern récurrent) Action : Escalade réseau → inspection splitter SPL-69002-14 Ticket créés : Non — résolu en L1 (FEC revienne à la normale)
Ce niveau de contexte change la prise de décision à deux niveaux :
- L1 sait directement si le problème est CPE (ticket client seul, pas d'escalade réseau) ou infrastructure (escalade justifiée, avec localisation).
- L2 reçoit un ticket pré-qualifié avec tout le contexte nécessaire au dispatch. Pas besoin de refaire le diagnostic.
Les deux sources à corréler en temps réel
Pour l'enrichissement automatique, vous avez besoin de deux flux en même temps :
La corrélation automatique entre ces deux sources est la fonctionnalité clé qui sépare une supervision moderne d'un assemblage d'outils non coordonnés. Le problème n'est pas d'avoir les données — c'est qu'elles soient dans deux silos et que le rapprochement soit manuel.
La panne est identifiée, le dispatch est parti, l'équipe terrain a travaillé sur le splitter. Vous avez une fenêtre de 4h pour confirmer la résolution avant le SLA. Le réflexe classique : "on a envoyé quelqu'un, ça devrait être bon". Le réflexe juste : confirmer la propagation de la résolution sur tous les ONTs du segment.
Une intervention sur un splitter ne résout pas le problème instantanément pour tous les abonnés. La reconnection ONT prend 2 à 5 minutes par équipement. Si vous avez 16 ONTs sur ce splitter, le dernier peut mettre 80 minutes à se reconnecter après le fix. Vous avez donc besoin d'une surveillance active post-intervention.
Checklist de vérification post-résolution
La cause #1 de tickets rouverts après résolution déclarée : le technicien a confirmé que le splitter est réparé, mais n'a pas confirmé que tous les ONTs sont reconnectés. 2 ONTs restent offline silencieux pendant 45 minutes, l'abonné appelle, le ticket est rouvert. La résolution se confirme sur le dernier ONT, pas sur le premier.
Comment automatiser la vérification post-résolution
La vérification chronologique ci-dessus est faisable manuellement pour un incident par shift. Pour 12 incidents simultanés (coupure générale après orage), c'est impossible. Une supervision IA-native monitore automatiquement :
- Le compteur d'ONTs online sur chaque port PON — et alerte quand il n'atteint pas 100% dans les 30 minutes après l'intervention.
- Les FEC errors en temps réel post-intervention — pour détecter un fix incomplet (fibre reconnectée mais endommagée).
- Le RxPower moyen par splitter — pour confirmer que la puissance optique est revenue à la normale du segment (pas juste au-dessus du seuil d'alarme).
Voir comment FiberOps automatise le diagnostic
Enrichissement automatique des tickets, corrélation TR-069 + GPON temps réel, monitoring post-résolution. Réduction de 60% des escalades inutiles sur votre NOC.
Le framework en 5 étapes — résumé
Diagnostic panne fibre — checklist NOC L1
- Étape 1 — Classifier : Optique, CPE, ou backbone ? OLT port UP ? ONTs offline combien ? FEC errors en pic ? (90 premières secondes)
- Étape 2 — Cartographier : Mapper le segment OLT → Port PON → Splitter → ONT. Vérifier que le mapping Serial ↔ ONT-ID ↔ Port est à jour.
- Étape 3 — Patterner : Vérifier l'historique des incidents sur le segment. Récurrence = infrastructure → escalade justifiée. Unique = CPE → ticket client standard.
- Étape 4 — Enrichir : Croiser TR-069 (ONT RxPower, FEC, firmware, uptime) avec GPON SNMP (port OLT, ONTs online). Ticket pré-qualifié avant escalade L2.
- Étape 5 — Vérifier : Confirmer la propagation de la résolution sur tous les ONTs du segment. Ne pas fermer avant le dernier ONT reconnecté.