Concevoir une plateforme de support logiciel
Click here for English version.
Dans cet article, j’aimerai partager certaines pratiques de conception de logiciel que nous utilisons pour améliorer l’expérience utilisateur et simplifier le développement technique.
Chez Linagora dans le cadre de notre offre OSSA (Open Source Software Assurance), nous traitons des centaines de demandes de support de nos clients chaque mois sur plus de 400 logiciels libres différents 24h sur 24, 7 jours sur 7. Nous utilisons différentes solutions internes et open source pour chacun de nos clients comme GLPI, OTRS ou Redmine. Cependant, c'est toujours compliqué pour nos ingénieurs de support de basculer entre ces outils aux périmètres différents.
Investir dans une plateforme de support logiciel est essentiel pour fournir un service-client efficace et de haute qualité. C’est pourquoi nous avons décidé de créer notre propre portail client pour fournir un support professionnel sur les logiciels Open Source. Et pendant que nous y sommes, pourquoi ne pas développer au sein de la plateforme OpenPaaS de Linagora pour bénéficier de son écosystème open source?
Gestion du flux de travail de support et des délais d'engagement
Nos clients vont des administrations publiques aux entreprises avec des besoins commerciaux et des clauses contractuelles différentes. Il était important de définir un cadre de support commun à tous sur notre nouvelle plate-forme où tous nos clients pourront s'y retrouver.
Au cœur de notre modèle de support informatique, il y a les délais d'engagement de niveau de service (Service-Level Agreement). Cela signifie que nous nous engageons à répondre à nos clients et à fournir un contournement ou un solution définitive après un laps de temps.
Cela signifie que notre plate-forme de support technique doit disposer des délais d'engagement adaptatifs. Par exemple, un problème critique sur l’infrastructure Linux aura des durées différentes d’une simple demande administrative.
Sur la base de ce qui précède, nous avons choisi de conceptualiser un modèle de requête à trois composants : un type de demande pour le contexte métier, une catégorie de logiciel pour le contexte technique du client, un niveau de sévérité pour le contexte de l'incident
Ces composants seraient sélectionnés à partir d’un dictionnaire global pour assurer la cohérence interne et l'adaptation au contexte du client.
Chaque requête a ses propres délais d'engagement : temps de réponse, temps de contournement, temp de correction. Pour faciliter la configuration, seul le type de demande est requis. Les champs laissés vides sont interprétés avec un comportement par défaut. Lorsqu’un incident est soumis, le choix du logiciel est facultatif et le niveau de sévérité peut être masqué. La durée d'engagement laissée si elle n'est pas indiquée, sera considérée comme infinie et ne sera pas enregistrée.
De plus le compteur de temps peut être interrompu par divers événements comme lorsqu'un ingénieur de support attend une information essentielle ou une validation de la part du client.
Pour gérer les délais d'engagement durant le cycle de vie de la demande, nous avons décidé de mettre en place un double mécanisme de comptage. Selon l'état de la demande, le compteur sera mise en pause ou pas. Toutefois, c'est uniquement lorsque l’ingénieur de support a coché la case "contourné" ou "corrigé" que ce temps sera formellemen enregistré. Cela permet de rendre la démarche plus transparente pour les clients et éviter les erreurs de manipulation.
Gestion de l'accès et des permissions des utilisateurs
Travailler avec différents interlocuteurs internes et externes, signifie devoir gérer plusieurs niveaux d’accès. Nous avons identifié 5 acteurs différents de notre plateforme de support logiciel.
Afin de faciliter la gestion des utilisateurs, nous choisissons de suivre un contrôle d’accès basé sur les attributs (Attribute-based Access Control) avec seulement trois rôles d’utilisateur: administrateur, support et client. Les gestionnaires du client et du support sont directement renseignés en tant qu’attribut sur chaque contrat pour simplifier.
Nous avons également implémenté l'héritage des propriétés pour les contrats sur les demandes de support. Cela signifie qu’un gestionnaire de support d’un contrat a le droit sur tous les demandes associées par défaut.
Enfin, les utilisateurs ne peuvent accéder à un contrat que s’ils appartiennent à une entité ayant accès à ce contrat. Cela permet de fournir des droits différenciés au sein d’une organisation, une exigence pour certains de nos plus gros clients.
Comme pour tous nos projets open source, vous pouvez suivre l'évolution de notre développement sur notre dépôt de code.
