🖥️

PR1 - Gestion du Support

The Telephone Girls


3 Sites · 100 Utilisateurs · Activité critique

SOMMAIRE

Plan de présentation

01

Organisation du Support

Organigramme, dimensionnement, planning

02

Contexte Technique

Architecture RDS, téléphonie, dépendances

03

Processus & Outil

Analyse osTicket, processus cibles, SLA

04

Exploitation & Amélioration

Analyse données, plan sur 12 mois

PARTIE 1 - ORGANISATION

Dimensionnement : 5 techniciens

2 Ă— N1

Helpdesk / Support de proximité

Ratio 1:50 users

1 Toulouse + 1 mutualisé Limoges/Brive

2 Ă— N2

Infra RDS / Téléphonie

1 spécialisé RDS

1 spécialisé Téléphonie IP

1 Ă— N3

Architecture / Référent

Responsable du service

Escalade ultime + projets

Justification : ITIL → 1 helpdesk / 70-100 users. Contexte critique (téléphonie HA) → ratio renforcé 1:50. Répartition : 1 tech sur site Toulouse (43% tickets), 1 tech itinérant Limoges/Brive, N2+N3 centralisés avec accès distant.

HORAIRES & PLANNING

Couverture 7h45–17h + Astreintes

Horaires de support


  • • Lun–Ven 7h45–17h : support plein (N1 + N2)
  • • Samedi 9h–13h : permanence N1 (1 tech)
  • • Nuit + Dim : astreinte Ă  distance N2
  • • SLA critique 24/7 pour tĂ©lĂ©phonie HA

RĂ©partition du temps

N1 - Helpdesk70%
N1 - Maintenance20%
N1 - Projets10%
N2 - Escalade50%
N2 - Projets infra50%

RĂ©partition du temps N3

Projets architecture50%
Escalade complexe30%
Management & pilotage KPIs20%

MATRICE RACI

Responsabilités par processus

Processus N1 Helpdesk N2 Infra N3 Archi Utilisateur
DĂ©tection incident R I I R
Qualification & priorisation R/A - - I
RĂ©solution N1 R/A - - I
Escalade N2 (RDS/Téléph.) R R/A - I
Escalade N3 (Architecture) I R R/A I
Gestion du changement I R A C
Demande de service R/A C I R

R=Responsable · A=Approbateur · C=Consulté · I=Informé

PARTIE 2 - CONTEXTE TECHNIQUE

Architecture RDS & Téléphonie

Ferme RDS (HA)

  • • RD Connection Broker Ă— 2 (HA + SQL)
  • • RD Web Access Ă— 2 (Load Balancer)
  • • RD Gateway Ă— 2 (Load Balancer)
  • • RD Session Hosts Ă— 3 (apps mĂ©tier)
  • • AD DC + Serveur de profils (UPD)
  • • Apps : CRM, outil de prise de RDV, softphone

Téléphonie IP (HA)

  • • IPBX en cluster actif/passif
  • • SBC (Session Border Controller) redondĂ©
  • • Trunk SIP opĂ©rateur avec bascule auto
  • • Softphones intĂ©grĂ©s aux sessions RDS
  • • QoS rĂ©seau inter-sites
  • • Monitoring temps rĂ©el (latence)

Dépendances réseau inter-sites

Liaison MPLS/SDWAN entre Limoges ↔ Toulouse ↔ Brive · Bande passante dédiée voix (128kbps/appel) · Failover 4G/5G sur chaque site · DNS/DHCP centralisés avec réplication · VPN site-to-site (Netbird)

Architecture RDS

PARTIE 3 - PROCESSUS & OUTIL

Analyse osTicket existant

Catégories de tickets

  • • TĂ©lĂ©phonie / Panne rĂ©seau
  • • RDS
  • • Demande de compte / Accès
  • • MatĂ©riel
  • • Autre (fourre-tout ⚠️)

⚠ Catégories trop vagues, pas de sous-catégories

SLA en place

  • • SLA plus Ă©levĂ© pour les tickets liĂ©s "tĂ©lĂ©phonie / rĂ©seau" que "autre" et "demande d'accès"
  • • PrioritĂ© suivant l'organigramme de l'entreprise (DG > agents)
  • • Pas d'escalade automatique

⚠ SLA non adapté à la criticité métier

Tickets les plus fréquents identifiés

0

Téléphonie IP

0

RDS / Apps

0

Matériel

0

RĂ©seau

PROCESSUS CIBLE

Flux de gestion des incidents

1. DĂ©tection

User / Monitoring

→

2. Enregistrement

osTicket (N1)

→

3. Classification

Cat + Priorité

→

4. Diagnostic

Checklist

→

5. RĂ©solution

N1/N2/N3

→

6. ClĂ´ture

Validation user

⬇ Escalade

N1→N2 si non résolu 30min (P1) / 2h (P2-P4)

⬇ Escalade

N2→N3 si non résolu 1h (P1) / 4h (P2-P4)

Grille de priorisation

P4 Basse

1 user · Demande non urgente

P3 Moyenne

Quelques users · App lente

P2 Haute

1 site impacté · RDS dégradé

P1 Critique

Tous les agents bloqués · Téléphonie HS complète

CONFIGURATION PROPOSÉE

SLA & Catégories optimisés

Catégories osTicket (cibles)

  • • TĂ©lĂ©phonie IP → Panne complète / DĂ©gradation qualitĂ© / Config
  • • RDS / Apps → Connexion impossible / Lenteur / App crash
  • • Softphone → Pas de tonalitĂ© / Écho / Installation
  • • RĂ©seau → Perte connectivitĂ© / VPN / WiFi
  • • Poste de travail → PĂ©riphĂ©rique / Impression / OS
  • • Comptes et Accès → CrĂ©ation / Reset MDP / Droits
  • • Nouvel agent → CrĂ©ation complète

SLA par priorité

PrioritéRéponseRésolution
â—Ź P1 Critique15 min1h
â—Ź P2 Haute30 min2h
â—Ź P3 Moyenne1h4h
â—Ź P4 Basse2h8h

Horaires : 7h45–17h Lun-Ven · 24/7 pour P1 téléphonie

Modèles de tickets (templates)

🔴 Téléphonie HS complète 🟠 RDS inaccessible 🟡 Softphone muet 🟢 Création agent 🔵 Reset mot de passe

PROCÉDURES

Check-lists incidents courants

Téléphonie HS

  1. VĂ©rifier statut IPBX (dashboard monitoring)
  2. Tester trunk SIP (appel entrant + sortant)
  3. ContrĂ´ler SBC et bascule automatique
  4. Vérifier QoS réseau (latence, jitter, MOS)
  5. Cluster → forcer bascule sur nœud passif

Lenteur RDS

  1. VĂ©rifier charge CPU/RAM des Session Hosts
  2. ContrĂ´ler nombre de sessions actives
  3. VĂ©rifier bande passante inter-sites
  4. Redémarrer le profil UPD si corrompu
  5. Basculer users vers un RDSH moins chargé

Softphone muet / Ă©cho

  1. Vérifier périphérique audio dans session RDS
  2. Tester avec un autre casque USB
  3. ContrĂ´ler la config SIP du softphone
  4. Vérifier redirection audio RDP activée
  5. Reinstaller le client softphone si nécessaire

Perte réseau site

  1. Ping routeur local + gateway opérateur
  2. VĂ©rifier statut liaison MPLS/SDWAN
  3. ContrĂ´ler bascule 4G/5G de secours
  4. Tester résolution DNS (interne + externe)
  5. Contacter opérateur si liaison physique HS

Règle d'escalade : N1→N2 si non résolu en 30 min (P1) ou 2h (autres) · N2→N3 si non résolu en 1h (P1) ou 4h (autres) · Toute escalade = mise à jour ticket + notification user

PARTIE 4 - EXPLOITATION DONNÉES

Analyse historique : 500 tickets

0

Tickets total

0

Moy. mensuelle

0

SLA global

0

MTTR moyen

Volume par catégorie

Téléphonie IP125
RDS / Apps119
Matériel68
RĂ©seau56

RĂ©partition par site

Toulouse217 (43%)
Limoges153 (31%)
Brive130 (26%)

ALERTE SLA

Respect SLA : situation critique

SLA par priorité (objectif 90%)

P1 Critique47%
P2 Haute61%
P3 Moyenne52%
P4 Basse70%

Constats principaux

  • đź”´P1 Ă  47% - plus d'1 incident critique sur 2 dĂ©passe le SLA. Manque de procĂ©dure d'urgence.
  • đźź P3 Ă  52% - le gros volume (241 tickets) n'est pas traitĂ© assez vite. Besoin d'automatisation N1.
  • 🟡TĂ©lĂ©phonie IP - SLA le plus bas (54%). CatĂ©gorie prioritaire Ă  amĂ©liorer en premier.
  • 🟢P4 meilleur Ă  70% - marge d'amĂ©lioration via self-service et FAQ.

⚠ Aucune priorité n'atteint l'objectif de 90% de respect SLA - une réorganisation complète est nécessaire

PLAN D'AMÉLIORATION

Sur 12 mois

Actions techniques

Déployer monitoring Zabbix + alertes sur IPBX, RDS, réseau

M1-M3 · KPI : MTTR -30%

Automatiser escalade N1→N2 dans osTicket (triggers + SLA schedules)

M2-M4 · KPI : SLA P1 > 80%

Créer base de connaissances osTicket avec solutions types et check-lists

M3-M6 · KPI : FCR > 60%

Actions organisationnelles

Former les N1 aux diagnostics téléphonie + RDS (1 session/mois)

M1-M12 · KPI : taux escalade -20%

Instaurer revue hebdo des tickets + comité mensuel SLA avec direction

M1-M12 · KPI : satisfaction > 85%

Déployer portail self-service osTicket (FAQ + formulaires guidés)

M4-M8 · KPI : tickets P4 -25%

Indicateurs de suivi : Taux respect SLA (par prio) · MTTR · Taux escalade · Satisfaction utilisateur (enquête trimestrielle) · Volume tickets/mois

🕵️‍♂️

Merci

Avez-vous des questions ?

1 / 14