Deux ans au sein du support d'un intégrateur cybersécurité européen — entre qualification de tickets, surveillance d'alertes et relation client.
Nomios a été fondée en 2004 par Sébastien Kher. Au départ, l'entreprise répondait à un besoin simple : sécuriser les infrastructures informatiques des organisations, à un moment où la cybersécurité commençait à devenir un sujet stratégique pour les entreprises.
Vingt ans plus tard, le groupe compte plus de 600 collaborateurs en Europe, avec des agences en France, aux Pays-Bas, au Royaume-Uni, en Belgique, en Allemagne et en Pologne. Nomios accompagne ses clients sur tout le cycle de vie de la cybersécurité : conseil, intégration de solutions, supervision et gestion des incidents.
Les clients viennent de secteurs très variés — énergie, santé, BTP, gestion du patrimoine, secteur public — ce qui montre à quel point la sécurité des systèmes d'information est devenue un enjeu transversal.
Le rôle principal du support est de prendre en charge et de résoudre les tickets ouverts par les clients. Un ticket peut être créé de deux manières : directement par le client via la plateforme dédiée, ou par téléphone, quand il appelle pour signaler un incident.
En complément, le support gère une activité qu'on appelle l'alerting : on surveille en continu les équipements des clients, et dès qu'une anomalie est détectée et confirmée, un ticket s'ouvre automatiquement. Ça permet de réagir avant même que le client ne s'en rende compte.
Qualification des tickets et résolution des incidents simples. Premier point de contact technique : on cadre la demande, on vérifie les informations, on évalue la priorité.
Ingénieurs spécialisés par technologie. Prennent le relais sur les incidents complexes nécessitant des investigations plus approfondies.
Équipe dédiée à l'alerting : surveillance des équipements, qualification des alertes, suivi avec le client et gestion des appels entrants.
Le support travaille aussi en étroite collaboration avec les services managés, qui administrent les outils de supervision et font le lien lors des changements de configuration. Ils peuvent suspendre temporairement la supervision pour éviter la remontée d'alertes inutiles pendant une maintenance planifiée.
Quand je suis arrivé chez Nomios en novembre 2024, je découvrais un environnement où plusieurs équipes — support, services managés, SOC — cohabitaient dans le même open space. Cette proximité physique facilite énormément l'entraide au quotidien : quand on a une question technique, on peut se tourner vers un ingénieur expérimenté en deux pas.
Mes premières semaines ont été consacrées à la prise en main des outils essentiels (Salesforce, Shinken) et à la compréhension des processus propres à chaque client. J'ai d'abord observé mes collègues pour identifier les bons réflexes, puis j'ai progressivement traité mes premières alertes en autonomie.
Au début, je manquais de repères pour identifier rapidement les bonnes informations ou savoir où les chercher. Mais l'équipe est restée disponible et bienveillante, avec des retours constructifs sur mes erreurs. C'est ce qui m'a permis de gagner en confiance et en autonomie au fil des mois.
Le travail au support repose sur un ensemble d'outils interconnectés qui couvrent toute la chaîne : centralisation des demandes, supervision des équipements, accès sécurisé et consoles techniques pour investiguer.
| Outil | Usage |
|---|---|
| Salesforce | Plateforme de centralisation des tickets et des alertes. Trace tous les échanges avec le client, lie les tickets entre eux, et garde l'historique des contacts. Interconnecté avec Shinken pour la remontée automatique des alertes. |
| Shinken | Outil de supervision (administré par les services managés). Génère les alertes et donne un historique daté du comportement des équipements, ce qui permet de savoir si une anomalie est récurrente ou inhabituelle. |
| LockPass | Coffre-fort de mots de passe. Permet d'accéder de façon sécurisée aux équipements clients et aux comptes utilisés pour ouvrir des tickets auprès d'opérateurs externes. |
| Panorama | Console de gestion centralisée pour les pare-feux Palo Alto. |
| Cisco Meraki | Plateforme cloud pour gérer les équipements réseau et le Wi-Fi de plusieurs clients. |
| FortiManager | Console centralisée pour administrer les solutions Fortinet. |
Quand un ticket arrive, la première étape c'est de relire la demande et vérifier que les informations sont complètes : technologies concernées, équipements, gravité réelle de l'incident. Les clients ont parfois tendance à mettre une priorité élevée pour accélérer le traitement, donc on doit réévaluer objectivement.
Une info clé à récupérer rapidement, c'est le numéro de série de l'équipement. Ça permet de vérifier auprès du service avant-vente si le client est éligible à notre support, ou s'il doit se tourner vers le constructeur. Disposer de cette information dès le début évite de mobiliser des ressources inutilement.
Vient ensuite l'investigation : comprendre la portée de l'incident, depuis quand il dure, combien de personnes sont touchées, si le client peut continuer son activité. Pour les tickets critiques (P1/P2), on appelle souvent directement le client par téléphone pour gagner du temps et évaluer l'impact réel.
| Statut | Signification |
|---|---|
| New | Ticket vient d'être créé sur le portail. |
| Work in progress | Le support travaille dessus. |
| Waiting Customer | En attente d'une action du client. |
| Waiting Vendor | En attente d'une action du fabricant. |
| Maintenance window | Fenêtre de maintenance planifiée. |
| Frozen | Ticket gelé temporairement (par exemple, en attente de reproduction d'un problème). |
| Solved | Solution proposée, en attente de validation client. |
| Closed | Ticket clos après confirmation client. |
L'alerting, c'est une offre complémentaire au support classique. Un client qui souscrit à ce service bénéficie d'une supervision continue de ses équipements : sur des plages horaires classiques (8h–19h) ou en continu 24h/24 et 7j/7 grâce à un système d'astreinte.
Quand une anomalie est détectée, le client est automatiquement informé et un ticket incident est ouvert de manière proactive, accompagné d'une première analyse du support. Ce service est particulièrement utilisé par les entreprises de secteurs sensibles, comme la santé ou le BTP, où une indisponibilité réseau peut avoir un impact direct sur l'activité.
Le traitement d'une alerte suit une méthodologie précise. Délai de 15 minutes pour les alertes critiques (P1), 30 minutes pour les P3. Première étape : assigner l'alerte pour éviter les doublons. Ensuite, vérification dans Shinken pour confirmer que l'alerte est toujours active. Si elle persiste, on la confirme auprès du client via Salesforce.
L'investigation commence par une tentative de connexion à l'équipement concerné via LockPass. Pour les clients sensibles, l'accès est restreint et nécessite des habilitations renouvelées régulièrement. Selon la technologie, on bascule sur Panorama (Palo Alto), Cisco Meraki ou FortiManager pour analyser les logs, vérifier les redémarrages, identifier l'origine du problème.
Toutes les alertes ne correspondent pas à un vrai incident. Certaines sont liées à des maintenances non signalées, des coupures électriques ou des arrêts planifiés. C'est pour ça qu'avant de remonter quelque chose au client, on prend toujours le temps de vérifier le contexte.
Avant de commencer cette alternance, je n'avais pas pleinement conscience de l'importance de la communication dans la gestion des incidents. Pourtant, c'est un élément central du travail au support.
Il faut être clair, précis et structuré dans les échanges avec le client, surtout dans le premier message. Celui-ci doit contenir toutes les informations nécessaires pour que le client identifie rapidement l'équipement concerné. Pour les alertes critiques, on appelle directement le site, et là, la qualité de la communication compte autant que la technique : se présenter clairement, expliquer pourquoi on appelle, rassurer un interlocuteur parfois méfiant.
Les personnes sur site n'ont pas toujours de compétences techniques. Il faut donc adapter son discours, reformuler, guider précisément quand on demande une vérification physique. Cette capacité d'adaptation est essentielle pour maintenir la confiance, et elle se développe avec la pratique.
Le support a pour mission d'assurer une continuité de service auprès des clients, donc je ne suis pas sur des horaires classiques 9h–17h. Une fois autonome, j'ai été intégré au roulement d'équipe : mes horaires varient entre 8h–16h, 10h–18h ou 11h–19h, avec une pause généralement entre 13h30 et 15h.
L'organisation du travail repose fortement sur la coordination. Plusieurs membres doivent être présents simultanément sur la vue pour respecter les délais de traitement. Cette entraide est essentielle : quand un collègue est bloqué sur un appel client, les autres prennent le relais sur les alertes en attente.
| Domaine | Compétences acquises |
|---|---|
| Organisation | Gestion de plusieurs tâches simultanément, priorisation sous contrainte de SLA, autonomie dans la recherche d'informations. |
| Technique | Maîtrise des outils de supervision (Shinken), des plateformes de gestion (Panorama, Meraki, FortiManager), analyse de logs, diagnostic d'incidents réseau. |
| Relationnel | Communication écrite et orale avec les clients, gestion d'appels entrants, adaptation du discours selon l'interlocuteur, coordination avec les ingénieurs L2. |
| Méthode | Approche pragmatique de la résolution de problèmes : recherche d'informations, formulation d'hypothèses, tests, persévérance face aux difficultés. |