Audika, c'est 650 centres auditifs en France et environ 1 500 utilisateurs qui gravitent autour de Zendesk — en agents de support ou en demandeurs.
Dans chaque centre, deux personnes en moyenne, concentrées sur leur cœur de métier : l'audition. Quand quelque chose bloque — une imprimante, un dossier mutuelle, un outil de facturation — c'est le business support interne qui prend le relais, par téléphone ou via un ticket Zendesk.
L'enjeu est simple, et l'équipe le formule sans détour : un collaborateur en centre qui n'est pas aidé, c'est un client qu'on n'aide pas. Et un client qu'on n'aide pas, c'est un client qu'on ne facture pas.
Le business support traite environ 70 % des tickets. Le reste se répartit entre les autres fonctions support : travaux, finance, services généraux, IT, logistique. Six services, dans un seul outil, chacun avec ses propres besoins.
Cette refonte n'était pas prévue. Pas budgétée, pas dans les plannings, il a fallu la caser en 2025. Aucun incident ne l'a déclenchée, mais trois constats se sont accumulés :
L'outil ne répondait plus aux usages. Une dizaine de thématiques aux titres à rallonge, un routing des demandes alambiqué : les tickets n'arrivaient pas toujours au bon endroit, et créer une demande prenait trop de temps pour les utilisateurs internes du réseau Audika.
La data était inexploitable. Quand le Comex demandait des chiffres — volume de tickets par centre, thématiques récurrentes — la responsable du support ne pouvait pas les sortir. Non pas parce que Zendesk ne le permettait pas, mais parce que les formulaires ne correspondaient pas à ce qu'on cherchait à mesurer. Impossible de faire des extractions solides sur cette base.
La connaissance était externalisée. Audika voulait réinternaliser la maîtrise de l'outil : être autonome sur les modifications du quotidien et sur la production de statistiques, sans dépendre d'un tiers pour chaque ajustement.
Le projet a suivi trois phases, portées côté OFFICERS par une consultante qui a tenu le fil rouge du projet.
L'audit et le recueil des besoins. Six services, six façons de travailler, six ensembles d'informations à faire transiter. Cette phase est longue, et c'est probablement la plus difficile. On part d'une page blanche et on écoute.
La proposition. Le regard externe sert précisément à ça : challenger les hypothèses. « Ce process-là, on peut le revoir autrement, voici ce qu'on vous propose. »
Quand une demande d'équipe n'est pas retenue, on explique pourquoi, arguments à l'appui. Et quand des divergences apparaissent entre équipes, c'est la vision du service qui utilisera l'outil au quotidien qui tranche.
La construction et le transfert. L'architecture est reconstruite (formulaires, arborescence, routing) puis le savoir est transmis aux équipes opérationnelles. Idéalement, on identifie en amont deux ou trois administrateurs internes, pour que la connaissance soit partagée et non concentrée sur une seule personne.
Des demandes plus rapides à créer, mieux qualifiées. L'arborescence a été refaite pour que les thématiques soient à la bonne place, visibles pour le demandeur comme pour l'agent. L'identification du centre est automatique, il n'y a plus d'informations redondantes à saisir. Résultat inattendu : le volume de demandes a augmenté. Audika y voit un signe de santé : l'outil est devenu assez simple pour qu'on l'utilise, et les demandes sont mieux organisées et donc mieux traitées.
Une data enfin pilotable. Les formulaires ayant été construits pour mesurer ce qui compte, les statistiques suivent. La responsable du business support a pu identifier précisément ce qui dysfonctionnait, centre par centre, thématique par thématique.
Deux niveaux de dashboards coexistent désormais : l'un pour le Comex et le pilotage de l'activité des centres, l'autre pour le management de l'équipe support elle-même : délais de traitement individuels, volumes, charge.
Une autonomie réelle. Le DSI et la responsable du business support modifient eux-mêmes leurs dashboards. La détection de patterns récurrents, par exemple un centre qui remonterait toujours le même problème, permet de traiter le problème à la source plutôt que le symptôme.
Ce fût finalement le challenge le plus important du projet. Il ne venait pas d'où on l'attendait, à savoir les 650 centres : la bascule s'y est faite en douceur, sans pic d'appels ni montagne de tickets. La résistance venait des fonctions support, ces équipes qui utilisaient déjà l'outil à leur manière et n'avaient pas envie d'en changer brutalement.
La réponse n'a pas été d'imposer. Elle a été de démontrer, équipe par équipe : les services qui avaient adhéré dès le début ont obtenu des bénéfices visibles, et ces bénéfices ont fait l'argumentaire pour les suivants. Certains arbitrages tranchés en début de projet ont été revus en cours de route, après discussion avec les équipes. C'est plus lent, mais cela a bien fonctionné, et fonctionne toujours.
Le signal qui ne trompe pas : des équipes qui n'étaient pas dans le périmètre initial (juridique, immobilier) ont demandé d'elles-mêmes à rejoindre l'outil avec leurs propres formulaires.
Trois chantiers sont identifiés :
l'intégration de ces nouveaux services en conservant le principe d'une porte d'entrée unique
l'optimisation du traitement des tickets répétitifs, avec des agents IA : il y a là des gains de productivité à aller chercher
l'interconnexion avec d'autres briques du système d'information, comme les outils RH, en complément d'Aircall et de l'outil de point de vente déjà connectés.
Le SAV d'une aide auditive passe par un audioprothésiste, en centre, physiquement.
Mais ces centres doivent être soutenus, sur beaucoup de sujets différents. C'est là un cas d'usage de Zendesk qui est particulièrement pertinent, quoique souvent sous-exploité : le soutien à un réseau de distribution ou de boutiques.