Le point de départ
Sur mon CV, la ligne « développeur full-stack Symfony/React » attire naturellement l'œil. Mais à côté, il y a une autre ligne, tout aussi réelle : plus de 3 années d'expérience en assistance technique multilingue, aujourd'hui en tant qu'Opérateur Service Desk (grade D2) chez Horsa Digital Retail. Une expérience que je ne mets pas assez en avant, alors qu'elle a profondément façonné ma façon de travailler.
Le quotidien : diagnostiquer avant de résoudre
Le support technique, ce n'est pas répondre au téléphone en attendant que ça passe. C'est appliquer, sous pression et en temps réel, une méthode très proche de celle du débogage : écouter un symptôme flou décrit par un utilisateur non-technique, poser les bonnes questions pour isoler la cause réelle, vérifier une hypothèse, proposer une solution, puis confirmer qu'elle tient. La seule différence avec le code, c'est que le « bug » est parfois humain autant que technique.
Une contrainte supplémentaire : le multilinguisme
Ce diagnostic, je le mène en italien, en français et en anglais technique, selon l'utilisateur en face. Ça oblige à une clarté redoublée : pas de jargon superflu, des explications qui doivent être comprises du premier coup, et une reformulation constante pour s'assurer que le message est bien passé. C'est une gymnastique qui a directement amélioré ma façon de documenter, de rédiger un ticket ou d'expliquer un choix technique à un client non-développeur.
Ce que ce rôle m'a réellement appris
  • Isoler un problème à partir d'un signal incomplet, avant même de toucher au code.
  • Communiquer un sujet technique de façon simple, dans trois langues, sans perdre en précision.
  • Gérer la pression et les priorités : tickets, SLA, escalades, sans perdre son calme ni sa rigueur.
  • Garder une trace utile : un bon ticket de support se lit comme une bonne issue GitHub.
  • Se mettre à la place de l'utilisateur final — un réflexe qui infuse directement dans la façon dont je conçois une interface ou un message d'erreur en développement.
Le lien avec le développement
Je ne vois pas ces deux expériences comme parallèles, mais comme complémentaires. Le support technique m'a donné une compréhension concrète de la frustration d'un utilisateur bloqué par un bug — la même frustration que je cherche à éviter quand je code une application. Et la rigueur du diagnostic, reproduite des centaines de fois sur des cas réels, s'applique presque telle quelle à l'analyse d'un stack trace ou d'un comportement inattendu en production.
Toujours orienté développement
La programmation reste ma passion et mon objectif principal. Mais je considère ces plus de 3 ans de service desk multilingue comme un vrai atout dans mon profil, particulièrement pour des postes qui demandent de dialoguer avec des utilisateurs, de comprendre un besoin métier ou de gérer un support de niveau 2/3 en parallèle du développement. Un parcours atypique, encore une fois — mais qui construit une manière plus complète d'aborder les problèmes.
De ce besoin est née une application
C'est justement pour fiabiliser ce travail au quotidien que j'ai fini par sortir de la logique "feuille Excel partagée" qui sert habituellement à suivre les tickets, les notes de procédure et les templates de réponse en support. En tant que développeur, je ne pouvais pas me satisfaire d'un fichier qui devient illisible à mesure que les cas s'accumulent : j'ai donc conçu et développé ma propre application de gestion de service desk, avec des templates de tickets organisés par client, des notes de procédures centralisées et consultables en quelques secondes, et un suivi structuré bien plus efficace qu'un tableur. Ce projet, né d'un besoin très concret sur le terrain, est devenu un outil que j'utilise quotidiennement — et j'en détaille la genèse dans un article dédié.