ExpertiseExpertise · communications d'entreprise
Support de niveau 3 et exploitation
d'infrastructures de téléphonie critiques.
Cette page s'adresse aux directions techniques, aux équipes d'exploitation et aux partenaires qui cherchent une expertise Mitel de niveau 3 immédiatement opérationnelle. Elle décrit un métier, pas une offre logicielle.
- Intervenant
- Régis Jocet Tchygnoumba
- Fonction
- Architecte des communications d'entreprise
- Niveau de support
- N3 · référent technique incidents complexes
- Périmètre
- Île-de-France · interventions et visites sur sites
- Expérience
- 27 années en environnements critiques
- Disponibilité
- Immédiate
Parcours
- 2026
Fondateur, ARCA CX Solutions
Audit, architecture et modernisation d'infrastructures de téléphonie et de centres de contacts.
- 2012 – 2025
Architecte Télécom Senior, Expert UC/CC
Support N3 et MCO d'un parc multi-sites de 4 500 utilisateurs au sein d'un grand groupe multi-entités. Rationalisation des infrastructures, mutualisation des plateformes, convergence des centres de contacts.
- 1998 – 2012
Responsable Téléphonie & Support Technique
Exploitation, supervision et évolution des infrastructures de téléphonie d'entreprise.
- 4 500utilisateurs exploités
- 1 200+agents de centres de contacts
- 2 000+sessions SIP
- 99,99 %disponibilité cible
Volumétries exploitées en environnement de production. Les organisations concernées ne sont pas nommées.
Domaines d'intervention
Support de niveau 3
Prise en charge des incidents que le N1 et le N2 ne referment pas : qualification, diagnostic, correction, puis retour d'expérience écrit.
Maintien en conditions opérationnelles
Supervision, maintenance préventive, gestion des versions et des correctifs, pilotage des évolutions techniques sans rupture de service.
Analyse de causes racines
Reconstitution des incidents majeurs, identification de la cause réelle, plan d'actions correctives et suivi jusqu'à disparition des récurrences.
Architecture voix et interconnexions
Trunks SIP, SBC, Microsoft Teams Direct Routing, réseaux LAN/WAN, qualité et sécurisation des flux voix.
Centres de contacts
Exploitation et convergence de plateformes multi-sites, jusqu'à 1 200 agents, avec les contraintes de continuité que cela impose.
Documentation et transfert
Procédures d'exploitation, runbooks, dossiers d'architecture, montée en compétence des équipes internes.
Ma démarche
Lorsque je rejoins une équipe d'exploitation, mon premier objectif n'est pas de proposer des changements. Mon rôle consiste d'abord à comprendre l'architecture existante, à sécuriser l'exploitation, à documenter les connaissances critiques et à gagner la confiance des équipes. Les évolutions ne viennent qu'une fois l'environnement maîtrisé et les risques correctement évalués.
Ce que je regarde en priorité
- Documentation d'architectureCe qui existe, ce qui est à jour, ce qui n'a jamais été écrit.
- Supervision et alertesCe qui est réellement remonté, et ce que personne ne voit passer.
- Sauvegardes et restaurationsUne sauvegarde jamais restaurée n'est pas une sauvegarde.
- Plan de reprise et basculesLes procédures existent-elles, et à quand remonte le dernier test ?
- Incidents des douze derniers moisLes récurrences racontent l'infrastructure mieux qu'un schéma.
- Inventaire et plan de numérotationLe socle de toute intervention fiable, souvent le plus négligé.
- Certificats des liens opérateursÉchéances, autorités intermédiaires de la chaîne, et un propriétaire par entrée. Un inventaire limité aux certificats serveurs est incomplet.
- Identification des lignes critiquesSavoir, quand un poste tombe, quel service il porte : accueil, permanence, urgence, débordement d'appels.
- Gestion des changementsQui décide, qui valide, qui trace, et comment on revient en arrière.
Architecture de référence
Principes d'une infrastructure de communications à haute disponibilité
La question que pose une direction technique n'est pas quel autocommutateur retenir. Elle est : que se passe-t-il quand le lien WAN tombe, quand un opérateur cesse d'acheminer, quand un serveur redémarre, quand le centre de contacts doit rester joignable pendant l'incident. Voici une infrastructure multi-sites construite pour répondre à ces questions, de la bordure opérateur jusqu'aux terminaux.
Le synoptique présenté ci-dessus illustre les principes généraux d'une architecture de communications d'entreprise à haute disponibilité. Il s'agit d'un schéma pédagogique conçu pour présenter une démarche d'architecture. Il ne représente aucune infrastructure réelle ni aucun environnement client.
Les points de rupture, et ce qui leur répond
- Un serveur d'appel tombe
- Le cluster bascule sur le second nœud. Plan de numérotation, annuaire et droits sont communs : rien à reconstruire, rien à ressaisir. La bascule est testée, pas supposée.
- Le lien WAN d'un site est coupé
- La passerelle média locale prend le relais. Les appels internes au site et les appels d'urgence continuent de passer par l'accès de secours, le temps que le lien revienne.
- Un opérateur cesse d'acheminer
- Plusieurs trunks SIP chez des opérateurs distincts, arrivant par des points d'entrée physiquement séparés. Le débordement est automatique et la capacité résiduelle est dimensionnée pour absorber le trafic, pas seulement pour exister.
- Le centre de contacts doit rester joignable
- Serveurs en haute disponibilité avec bascule automatique, et un portail de pilotage qui permet aux superviseurs de basculer en mode dégradé, de diffuser un message exceptionnel ou d'activer un scénario d'urgence sans intervention technique.
- Personne ne voit venir la panne
- Le serveur de management centralise les alarmes des nœuds et des passerelles, et les remonte à la supervision d'entreprise. Une infrastructure qui n'alerte pas se découvre par l'utilisateur, toujours trop tard.
- Le pont de conférence d'une salle ne répond plus
- Le terminal de conférence de la salle, raccordé au système téléphonique et non à la plateforme collaborative, offre un pont audio de repli immédiat. La réunion continue par la voix pendant que l'incident est traité. Peu d'organisations savent que ce chemin de secours existe déjà chez elles.
- Un flux doit sortir vers l'extérieur
- Les SBC en zone démilitarisée terminent la signalisation, chiffrent les médias et isolent le cœur. La médiation vers Teams passe par des nœuds dédiés, dimensionnés pour la redondance et non pour le strict nécessaire.
Ce qui rend une telle architecture robuste n'est pas la redondance elle-même : c'est qu'elle ait été éprouvée, documentée et comprise par l'équipe qui l'exploite. Une bascule jamais testée est une hypothèse. Un schéma que personne ne tient à jour devient faux en six mois. C'est la part la moins visible du métier d'architecte, et celle qui décide de la disponibilité réelle.
Motifs récurrents
Ce qui dégrade réellement la qualité des appels en production
Une dégradation audio ne vient pas nécessairement du serveur d'appel. Elle provient souvent d'un équipement ou d'un service situé sur le chemin de la signalisation ou des flux média. Le diagnostic commence donc par une séparation : la signalisation, qui établit l'appel, et le flux média, qui transporte la voix. Les deux empruntent le même réseau mais n'obéissent pas aux mêmes contraintes, et une session correctement établie ne prouve en rien que la voix circule. Voici trois causes que l'on retrouve d'une infrastructure à l'autre. Ces motifs sont génériques : ils ne décrivent aucun incident particulier et aucune organisation.
Une mise à jour d'équipement de proximité
- Symptômes
- Voix hachée ou robotisée, coupures intermittentes, remontées éparses sans corrélation évidente avec un utilisateur ou un horaire.
- Situation
- Le défaut apparaît dans les jours qui suivent une intervention réseau planifiée, considérée comme sans impact sur la voix.
- Diagnostic
- Capture de trafic aux deux extrémités, comparaison de la signalisation et des flux média, contrôle du marquage de priorité et de la taille des paquets.
- Cause
- Un paramètre revenu à sa valeur par défaut pendant la mise à jour : marquage de qualité de service perdu, VLAN voix reclassé, taille de MTU modifiée. Les flux voix repassent dans la file générique et subissent le trafic de données.
- Traitement
- Rétablir le paramétrage, puis inscrire le contrôle des marquages voix dans la procédure de mise à jour de l'équipement. La vérification ne doit pas dépendre de la mémoire de l'intervenant.
Un équipement de sécurité qui inspecte les appels
- Symptômes
- Signalisation correcte mais média absent, audio dans un seul sens, appels interrompus après une durée constante, comportement différent selon le sens de l'appel.
- Situation
- Le défaut concerne les flux qui traversent une zone de sécurité, postes distants ou raccordement opérateur. Les appels strictement internes ne le présentent pas.
- Diagnostic
- La signalisation reçue ne correspond pas à la signalisation émise : adresses réécrites dans la description de session, ports média incohérents avec ce qui a été négocié.
- Cause
- Une fonction d'inspection applicative de type SIP ALG restée active sur l'équipement de sécurité. Elle réécrit la signalisation et ouvre des ports au mauvais endroit, alors que le SBC assure déjà ce rôle en bordure.
- Traitement
- Désactiver l'inspection applicative sur les flux concernés et laisser la terminaison au SBC. Documenter la règle pour qu'elle survive au prochain changement d'équipement ou de version.
Un volume d'appels décorrélé du dimensionnement
- Symptômes
- Qualité correcte hors pointe, dégradation aux heures chargées, appels rejetés ou mis en attente prolongée, hausse de la gigue et des pertes.
- Situation
- Le phénomène se répète sur les mêmes plages horaires, alors qu'aucune alarme ne remonte des serveurs, dont les indicateurs de disponibilité restent au vert.
- Diagnostic
- Comparaison entre la volumétrie réellement observée et les capacités déclarées, canaux simultanés, licences et ressources partagées, mesurée sur les heures chargées et non sur la moyenne de la journée.
- Cause
- Un dimensionnement établi sur une moyenne journalière alors que le trafic se concentre sur quelques plages. La plateforme est saine : c'est la capacité qui est atteinte.
- Traitement
- Redimensionner sur les heures chargées, et poser des seuils d'alerte sur le taux d'occupation des ressources, pas uniquement sur la disponibilité des serveurs.
Dans ces trois situations, la plateforme téléphonique apparaît comme la première suspecte alors que la cause se situe ailleurs. Un support de niveau 3 utile commence par localiser précisément le point de dégradation avant d'engager la correction.
Ce qu'un incident critique m'a appris
Quatre dispositifs qu'une exploitation critique devrait avoir
Un nœud qui redémarre sans que son service de traitement des appels reparte, une supervision qui reste au vert pendant ce temps : la panne se corrige en quelques minutes, mais elle révèle des manques qui, eux, se corrigent dans la conception. Voici les quatre dispositifs que ce type de situation rend indispensables, par ordre de valeur pour la continuité de service.
Repli automatique entre nœuds
Les appels doivent être redirigés vers les autres nœuds de la même direction dès qu'un service critique cesse de répondre. Tant que ce repli n'est pas configuré, une panne locale suffit à interrompre le service alors que la plateforme dispose encore des ressources pour l'assurer.
Relance automatique des services critiques
Un serveur qui redémarre ne garantit pas que ses services applicatifs repartent avec lui. Le service de traitement des appels doit être surveillé et relancé lorsqu'il ne reprend pas correctement.
Supervision applicative
La supervision ne peut pas se limiter à l'état des serveurs. Elle doit contrôler les services indispensables au traitement des appels : un serveur au vert ne doit plus être considéré comme disponible si le service voix ne répond pas.
Détection par événement
Le redémarrage d'un équipement doit être un événement de supervision à part entière, remonté avec sa cause et déclenchant les contrôles post-redémarrage. Une détection par sondage, même quotidienne, laisse une fenêtre d'exposition entre la panne et le contrôle suivant.
En téléphonie critique, un serveur disponible ne signifie pas qu'un service est disponible. La supervision doit contrôler le service rendu, pas seulement l'état technique des équipements.
Qualifications
Expérience d'exploitation et références techniques
- 27 ansen communications d'entreprise
- 21 anssur la plateforme MiVoice 5000
Installation initiale, migrations, exploitation quotidienne et support de niveau 3 sur des environnements où quelques minutes d'interruption peuvent impacter directement la continuité de service. L'objectif n'est pas uniquement de résoudre un incident, mais de rétablir rapidement un service essentiel tout en supprimant durablement sa cause.
Principes d'exploitation
Continuité
21 ans sur la même plateforme
Accompagnement de la gamme à travers ses générations successives et ses changements de marque, avec une mise à niveau continue sur les versions récentes.
Continuité de service
Rétablir rapidement, corriger durablement
Lors d'un incident critique, la première priorité est le rétablissement du service. L'analyse de la cause racine, la correction définitive et les actions préventives sont ensuite conduites afin d'éviter toute récurrence.
Continuité matérielle
Stock de rechange et matériel de secours
Stock tampon dimensionné sur les équipements critiques afin de réduire le temps de rétablissement. Après chaque remplacement, la reconstitution du stock fait partie intégrante de l'intervention.
Qualification
Campagnes de tests et de validations
Participation aux campagnes de tests et de validations de versions sur des produits de l'écosystème Mitel, puis recettes fonctionnelles et techniques en environnement de production.
Architecture
Multisite et haute disponibilité
Architectures réparties, continuité de service, raccordement SIP et interconnexion avec Microsoft Teams.
Priorisation opérationnelle
La criticité dépend du service rendu
La priorité d'un incident ne dépend pas uniquement du nombre d'utilisateurs impactés. Une ligne unique peut être plus critique qu'un plateau entier lorsqu'elle assure un accueil, une permanence, une urgence ou un débordement d'appels. Le service porté par la ligne doit être qualifié avant de définir la stratégie de rétablissement.
Certifications et référentiels
Certification constructeur
Mitel MiVoice 5000
Installation, configuration, exploitation, haute disponibilité, migrations et évolutions de version.
Certification constructeur
Mitel MiContact Center
Administration, exploitation et intégration des environnements de centre de contacts, aujourd'hui regroupés dans la gamme Mitel CX.
Référentiel de services
ITIL Foundation
Gestion des services, des incidents et des changements, amélioration continue.
Bloc de compétences · RNCP39108
Product Builder No-Code · BC03
Bloc BC03 « Concevoir, configurer et paramétrer les outils métiers dans le cadre d'un projet de solution No-Code », de la certification RNCP39108 Product Builder No-Code, niveau 6 (EU). École Cube, avril 2026.
Cette expertise est exercée au sein d'ARCA CX Solutions sur les environnements MiVoice 5000, Mitel CX, MiR et les architectures associées.
Environnements maîtrisés
Cœur téléphonie
Bordure et interconnexion
Centre de contacts et services
Exploitation
Modalités d'intervention
Renfort N3
Appui ponctuel sur incidents critiques ou pics d'activité.
Mission longue
Intégration à une équipe d'exploitation, sur site et à distance.
Prestation ou CDI
Le cadre contractuel se discute selon votre contexte.
Disponible immédiatement, mobile sur l'ensemble de l'Île-de-France.