Nous faisons une mise à jour de notre plateforme une fois par semaine, le mardi, si aucun élément de dernière minute ne nous en empêche. Dans ce cycle, nous incluons entre autres des déploiements de nouvelles fonctionnalités, des améliorations de flux promoteurs et/ou des correctifs de bugs.
Notre équipe technique met tout en œuvre pour répondre aux demandes de chacun de nos clients le plus rapidement et efficacement possible, mais dépendant du nombre de tickets et de l'impact sur l'application, la date d’intégration d'un ticket dans une mise à jour peut varier, en particulier selon son urgence.
Ce n’est pas la taille du client qui détermine l’ordre de traitement mais l’impact de l’erreur sur la plateforme et le parc client. Chez Otaree, il n’y a pas de petits clients.
Par exemple, un bug impactant l'utilisation d'un outil comme un simulateur sur la totalité du parc client, se verra alors priorisé.
Qu’est-ce qu’un bug ?
On appelle un bug tout comportement du progiciel qui n’est pas conforme à son fonctionnement standard, c’est à dire tel qu’il a été codé. Seul un développeur pourra déterminer si ce qui a été signalé par un client est un bug ou simplement un fonctionnement différent de celui attendu.
Pour pouvoir commencer une enquête technique rapidement, lorsque vous nous contactez pour nous signaler une erreur potentielle, nous avons besoin d’un maximum d’informations.
Exemple
“Je n’arrive pas à créer un contact”. Cette information n’est pas suffisante pour commencer une enquête.
Quelles sont les étapes à suivre pour reproduire l’erreur rencontrée ? (Sur quels boutons cliquez-vous ?)
Où êtes-vous sur le site lorsque vous faites cette action ? (La création de contact peut se faire depuis plusieurs endroits sur le site)
Un message d’erreur apparaît-il ? Si oui, quel est-il ?
Avez-vous une impression d’écran à nous fournir ?
Cycle de vie du traitement d’un email signalant une erreur technique potentielle
Dans un premier temps, l’email reçu dans la boite email sc@otaree.com est traité par une personne de notre équipe service client. Si celui-ci demande des vérifications techniques (contenu du flux, comportement des outils Otaree etc.), ce sera un agent du support client qui prendra la main sur la demande.
Si tous les détails nécessaires pour reproduire le problème signalé nous ont été donnés dès le départ, une enquête sera alors menée. Si nous n’arrivons pas à reproduire en suivant les étapes, plus d’informations vous seront demandées.
Une fois que le support technique a déterminé la source de l’erreur ou le besoin technique pour modifier le comportement d’un outil sur la plateforme, un ticket est alors ouvert auprès de l’équipe technique composée de développeurs web.
Qualification des urgences des bugs
Les bugs sont classifiés comme suit : Priorité 1, Priorité 2 et Priorité 3
Les délais ci-dessous s’entendent uniquement pour des signalements effectués par le client comportant toutes les informations nécessaires à la reproduction de l’anomalie et ne prennent en compte que les jours ouvrés dans les limites des horaires d’ouverture.
● Priorité 1 : Bug de très haute priorité, Reproductible par Otaree, qui rend impossible l’accès ou l’utilisation d’une ou plusieurs fonctionnalités essentielles du service et pour laquelle il ne peut exister une solution de contournement technique ou organisationnelle.
Exemples d’une fonctionnalité d’urgence de niveau 1
impossible d’accéder à la plateforme
impossible de rechercher des biens
impossible d’accéder au Back Office
impossible de créer un programme/lot
Délais de prise en charge d’un ticket P1
Les tickets de criticité P1 sont pris en charge dans l’heure de leur signalement.
Le correctif est mis à disposition dans la version de production le plus rapidement possible après validation du bug, sans attendre la prochaine mise à jour planifiée.
● Priorité 2 : Bug reproductible par Otaree, qui rend inopérante l’accès ou l’utilisation d’une ou plusieurs fonctionnalités du service et pour laquelle il peut exister une solution de contournement technique ou organisationnelle.
Exemple d’une fonctionnalité d'urgence de niveau 2
impossible de faire des Dénonciations, Options ou Réservations
impossible d’utiliser l'outil de création de présentations
impossible d’utiliser les simulateurs
Délais de prise en charge d’un ticket P2
Les tickets de criticité P2 sont pris en charge dans les 10 jours suivants leur signalement
Le correctif est mis à disposition dans la version de production lors de la prochaine mise à jour planifiée.
● Priorité 3 : Signalement ou tâche qui ne présente pas les caractéristiques d'une anomalie d'un autre niveau de criticité.
Délais de prise en charge d’un ticket de priorité 3
Les tickets de criticité P3 sont pris en charge dans un ordre de criticité défini en interne par plusieurs critères, lorsqu’il n’y a pas de tickets de priorité 1 ou 2. Le correctif est mis à disposition dans la version de production une fois testé, lors d’une mise à jour planifiée.