Tous ses tickets
Référence, titre, date, priorité, auteur, nombre de pièces jointes et de messages, statut en couleur.
Réalisation · API · Support
Une plateforme de support intégrée aux applications métier
Nous avons conçu une plateforme de support centrale, exposée en API, et l’avons intégrée dans les applications que nous développons pour nos clients. Leurs utilisateurs signalent un incident sans quitter leur application ni créer de compte.
Contexte
Nous développons et maintenons plusieurs applications métier pour nos clients, certaines en version web et mobile. Quand un utilisateur rencontrait un problème ou avait besoin d’une évolution, la demande arrivait par e-mail, par téléphone ou par message à un développeur. Avec plusieurs difficultés :
- Des demandes perdues ou traitées deux fois
- Aucun historique partagé entre l’équipe support et le client
- Des informations manquantes : quelle application, quel module, quel écran, quel utilisateur
- Aucune vue d’ensemble de la charge de support
- Pour le client, aucune visibilité sur l’avancement de sa demande
Un outil de ticketing du marché aurait obligé chaque utilisateur à créer un compte de plus, sur une interface sans lien avec son application. L’objectif : un seul outil de support, alimenté depuis l’intérieur de chaque application, sans compte supplémentaire.
L’intégration décrite ici est celle de l’ERP d’une entreprise de rénovation et de maintenance de logements sociaux, l’une des quatre applications clientes connectées à la plateforme.
Le parcours d’un ticket
Chaque application embarque un module Support qui dialogue avec l’API de la plateforme. Pour l’utilisateur, le support fait partie de son application. Pour notre équipe, toutes les demandes arrivent au même endroit, déjà qualifiées.
- Utilisateur vers Application métier : Ouvre le support depuis l’application
- Application métier vers Plateforme de support : S’authentifie et transmet l’utilisateur
- Plateforme de support : Identifie l’application et l’utilisateur
- Plateforme de support vers Application métier : Tickets de cette application uniquement
- Utilisateur vers Application métier : Crée un ticket : module, type, description
- Application métier vers Plateforme de support : Envoie le ticket déjà qualifié
- Équipe support vers Plateforme de support : Traite le ticket et répond
- Application métier vers Utilisateur : Affiche la réponse dans le fil du ticket
Ce que voit l’utilisateur
Toutes les données viennent de la plateforme : l’application ne stocke aucun ticket. Chaque client choisit les rôles qui ont accès au module.
Le suivi complet
Les informations du ticket, les pièces jointes avec un aperçu des images, et le fil des échanges avec le support.
Un ticket déjà qualifié
Description, référence de document facultative, type (demande, incident, support), lieu, module et plateforme concernés.
Rien à ressaisir
L’utilisateur ne saisit ni son nom ni son e-mail : l’application les transmet. Le ticket est rattaché à la bonne personne et à la bonne application.
Une API pensée pour plusieurs applications
La plateforme sert des applications différentes sans jamais les mélanger.
Un accès par application
Chaque application dispose de son propre accès, qui sert aussi à cloisonner les données : une application ne voit jamais les tickets d’une autre.
Des listes propres à chaque application
Les modules et les plateformes sont fournis par l’API. Ajouter un module côté plateforme le rend disponible dans le formulaire, sans redéployer l’application.
Des listes communes
Types, lieux, priorités et statuts sont partagés par toutes les applications.
L’API suit des standards plutôt que des conventions maison : JSON-LD et Hydra pour les ressources et les collections, identifiants sous forme d’adresses, JSON Merge Patch pour les modifications partielles. Les applications consomment un contrat prévisible, sans table de correspondance à maintenir.
Une authentification sans second compte
L’utilisateur n’a pas de compte sur la plateforme. C’est son application qui s’authentifie auprès de l’API et qui indique pour quel utilisateur elle agit.
- Aucune friction : pas de second identifiant, pas de mot de passe à retenir, pas d’invitation
- Une seule source d’identité : l’application reste maîtresse de ses utilisateurs, et un utilisateur désactivé n’accède plus au support
- Un cloisonnement strict : l’accès de l’application détermine les données visibles
- Un rattachement automatique : chaque ticket et chaque message porte l’identité réelle de son auteur
Un module léger, reproductible d’une application à l’autre
Le même découpage se réplique dans chaque application. Intégrer une nouvelle application se résume à sa configuration, à ses écrans et à son accès.
Une seule pièce connaît l’adresse de l’API, l’authentification et la gestion des erreurs.
Des méthodes métier lisibles pour lister, consulter, créer, modifier ou supprimer un ticket, qui masquent l’API.
Les écrans suivent les conventions de l’application hôte : droits, formulaires, gabarits, messages.
Les tickets ne sont pas copiés dans l’application : ils sont lus en direct sur la plateforme, toujours à jour, sans synchronisation ni conflit. Les adresses et les accès sont lus dans la configuration de chaque environnement, jamais dans le code.
Résultat
La plateforme, conçue entre fin 2023 et le printemps 2024, est utilisée par quatre de nos clients.
Il signale un problème là où il travaille, sans compte ni outil supplémentaire, et suit la réponse au même endroit.
Il voit l’avancement de chaque demande et garde un historique partagé avec notre équipe.
Toutes les demandes de toutes les applications arrivent dans un seul outil, déjà qualifiées par application, module et utilisateur.
Ce que nous en retenons : concevoir une API pour plusieurs clients dès le départ, s’appuyer sur des standards plutôt que sur des conventions maison, et confiner la complexité de l’API dans une seule couche du client.
Stack
Questions fréquentes
Les utilisateurs doivent-ils créer un compte sur la plateforme de support ?
Non. C’est leur application qui s’authentifie et transmet leur identité. Ils ouvrent et suivent leurs tickets sans quitter l’application qu’ils utilisent tous les jours.
Qui peut ouvrir un ticket ?
Chaque client choisit les rôles de son application qui ont accès au module Support.
Une application peut-elle voir les tickets d’une autre ?
Non. Chaque application a son propre accès à l’API, et cet accès détermine les tickets et les listes qu’elle peut voir.
Ajouter un module demande-t-il une mise à jour de l’application ?
Non. Les listes de modules et de plateformes sont fournies par l’API : un module ajouté sur la plateforme apparaît aussitôt dans le formulaire.
Une API à concevoir pour plusieurs applications ?
Nous concevons des API et les modules qui les consomment, avec la séparation des données et les standards qui les rendent durables. Voir notre page intégration et développement d’API, notre maintenance et support applicatif, et une autre réalisation dans le même ERP : la prise de rendez-vous d’entretien par SMS.