Concevoir une plateforme de support logiciel

Quang T
Quang T
Dec 5, 2017 · 4 min read

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.

Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Sandbox Produit

Guide pratique à la Gestion de Produit

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store