Service desk · billetterie · SLA

Logiciel de service desk avec billetterie, moteur SLA et portail en libre-service.

Ordivis Service

Quatre types de tickets ITIL dans un seul processus, une priorité déduite de l'urgence et de l'impact plutôt que du ressenti, et un portail ouvert à l'ensemble de votre personnel – les utilisateurs finaux ne coûtent rien.

Utilisateurs finaux dans le portail 4 types de tickets ITIL 100 % Sur site
# La priorité se déduit, elle ne se devine pas
Urgence  élevée    (3 niveaux)
Impact     moyen  (3 niveaux)
                 ↓
Priorité      2 – Élevée

Objectif SLA  réaction  1 h   Heures ouvrées
Objectif SLA  résolution    8 h   Escalade à 80 %
Groupe    2e niveau réseau
Fondamentaux

Qu'est-ce qu'un service desk ?

Un Centre de services est le point de contact central et unique – le single point of contact – entre les utilisateurs et l'organisation informatique. Il reçoit les incidents et les demandes, les qualifie, pilote leur traitement à travers tous les groupes concernés et assume la communication jusqu'à la clôture.

L'essentiel tient dans la dernière proposition : le service desk reste responsable même lorsque la résolution a lieu ailleurs. Un ticket transmis à l'équipe réseau n'est pas « parti » – il reste un dossier dont quelqu'un répond devant l'utilisateur. C'est précisément là que la plupart des boîtes aux lettres partagées échouent.

Service desk ou helpdesk – quelle différence ?

Un helpdesk résout des incidents : l'utilisateur signale, quelqu'un corrige, dossier clos. Un Centre de services a une portée plus large et couvre l'ensemble de la relation de service – donc, outre les incidents, les demandes de service issues d'un catalogue, les changements, les informations et l'évolution des services eux-mêmes. En bref : le helpdesk réagit, le service desk pilote en plus.

Dans la pratique, une seule question révèle la différence : un utilisateur peut-il commander quelque chose chez vous – un accès, un ordinateur portable, une autorisation – ou seulement signaler quelque chose ? Si seule la seconde option existe, vous exploitez un helpdesk.

Pourquoi pas une boîte aux lettres partagée ?

Une boîte partagée fonctionne étonnamment longtemps, puis s'effondre d'un coup. Elle ne connaît ni statut, ni responsabilité, ni échéance ; personne ne sait si un message est traité ou traité deux fois, et rien ne peut être analysé. Au plus tard lorsqu'il faut prouver la rapidité de votre réaction – devant la direction, un auditeur ou une autorité de contrôle – une boîte aux lettres ne constitue pas une preuve.

Un processus, quatre types

Incident, problème, changement et demande de service

Les quatre types de tickets ITIL suivent le même cycle de vie – avec le même journal, les mêmes groupes et les mêmes règles SLA.

Incident

Une perturbation : quelque chose ne fonctionne pas comme promis. L'objectif est de rétablir le service au plus vite – au besoin par un contournement ; la cause viendra plus tard.

Problème

La cause derrière des incidents récurrents. Les incidents sont regroupés, le contournement est documenté et la correction durable est suivie.

Changement

Une modification planifiée avec classe de risque, circuit d'approbation et date de CAB. Changements standard, normaux et d'urgence, avec des approbateurs configurables.

Demande de service

Une demande standard issue du catalogue – accès, matériel, autorisation. Avec formulaire, étape d'approbation et déroulé défini plutôt qu'un mot lancé dans le couloir.

Étendue fonctionnelle

Ce que fait le service desk Ordivis

La priorité à partir de deux grandeurs

L'urgence et l'impact, à trois niveaux chacun, donnent la priorité – déduite plutôt que librement choisie. Dix agents priorisent ainsi de manière comparable, et la décision reste justifiable après coup.

Journal de ticket à trois niveaux

L'historique d'activité est structuré par indentation : ce qui s'est passé, qui l'a fait, ce qui a été communiqué. Le courriel d'origine figure également dans le journal.

Groupes de support et visibilité

Les tickets sont visibles par groupe – appartenance par utilisateur ou par rôle. Le 2e niveau voit ce qui le concerne, pas tout.

Moteur SLA & OLA

Plusieurs objectifs par ticket, délais de réaction et de résolution, heures ouvrées et calendriers pris en compte. Escalade en cas de menace de dépassement – avant, pas dans le rapport mensuel.

Intégration de la messagerie

Les tickets naissent d'une boîte de réception surveillée. Les expéditeurs inconnus sont créés automatiquement dans l'annuaire de contacts local, les réponses reviennent dans le ticket via l'adresse de réponse.

Portail libre-service

Un portail Blazor pour les utilisateurs finaux : signaler un ticket, suivre son statut, lire des articles de connaissance, commander des demandes standard. Nombre d'utilisateurs illimité, sans frais.

Base de connaissances

Les solutions sont consultables et rattachables directement depuis le ticket. Les articles publiés apparaissent dans le portail – cela réduit le volume de tickets au lieu de se contenter de le gérer.

Rattachement au CI depuis la CMDB

Les tickets sont rattachés à des configuration items. Grâce à la CMDB , on voit immédiatement quels services sont touchés – la base d'une évaluation d'impact solide.

Mesure de la satisfaction (CSAT)

Enquête de satisfaction après la clôture du ticket. Les catégories et sous-catégories sont librement modifiables, afin que les analyses correspondent à votre organisation.

Intégration de la supervision

Les incidents provenant de CheckMK, PRTG, Zabbix ou de Nagios/Icinga deviennent automatiquement des tickets. Les répétitions arrivent en commentaire sur le ticket existant, la levée d'alerte le referme – et une fenêtre de maintenance active empêche entièrement la création.

Pas de déluge d'alertes

Un frein anti-tempête regroupe les événements de masse en un ticket collectif, et les services instables sont reconnus comme tels. L'agent qui a déjà travaillé sur le ticket garde la priorité sur l'automatisme.

Authentification unique (SSO)

Connexion auprès de votre propre fournisseur d'identité – Entra ID, Keycloak ou tout autre fournisseur OIDC, ainsi que l'authentification Windows intégrée via Kerberos. Les groupes et les claims sont mis en correspondance avec les rôles Ordivis.

Depuis l'application en fonctionnement

Comment travaille le service desk

Tickets
Logiciel de service desk : liste des tickets avec priorité, SLA et intervenant
Liste des ticketsPriorité, SLA, intervenant et client par ticket – quatre types ITIL, un processus.
Détail du ticket
Vue détaillée du ticket avec journal, horloge SLA et connaissances rattachées
Détail du ticket & journalHistorique d'activité à trois niveaux, horloge SLA, charge et connaissances rattachées.
Coûts

Pourquoi les utilisateurs finaux ne coûtent rien chez nous

Beaucoup de systèmes de billetterie facturent à l'utilisateur – et entendent par là tout le monde. Cela mène à une situation absurde : on restreint l'accès au portail en libre-service pour économiser des licences, et l'on reçoit les tickets par courriel et par téléphone à la place. Le logiciel devient moins cher, l'exploitation plus onéreuse.

Ordivis Platform facture à l'utilisateur nommé, dans deux rôles : les administrateurs avec l'ensemble des fonctions, et les agents de service desk pour le seul traitement des tickets. Les utilisateurs finaux du portail sont illimités et gratuits – tout comme les actifs, les CI et les adresses IP.

RôleCe qu'il peut faireSoumis à licence
AdministrateurEnsemble des fonctions, y compris service desk, configuration, tous les modulesOui, nommé
Agent de service deskTraitement des tickets – rôle moins cher pour le seul traitementOui, nommé
Utilisateurs finaux dans le portailSignaler et suivre des tickets, lire des articles de connaissance, commander des servicesNon – illimité
Questions fréquentes sur le service desk

Réponses brèves et honnêtes

Qu'est-ce qu'un service desk ?

Un service desk est le point de contact central et unique (single point of contact) entre les utilisateurs et l'organisation informatique. Il reçoit les incidents et les demandes, les qualifie, pilote leur traitement à travers tous les groupes concernés et assume la communication jusqu'à la clôture – y compris lorsque la résolution a lieu ailleurs.

Quelle est la différence entre un service desk et un helpdesk ?

Un helpdesk résout des incidents : l'utilisateur signale, quelqu'un corrige, dossier clos. Un service desk a une portée plus large et couvre l'ensemble de la relation de service – donc, outre les incidents, les demandes de service issues d'un catalogue, les changements, les informations et l'évolution des services. Le helpdesk réagit, le service desk pilote en plus.

Comment la priorité d'un ticket est-elle déterminée ?

À partir de deux grandeurs à trois niveaux chacune : l'urgence (à quelle vitesse faut-il résoudre) et l'impact (combien d'utilisateurs ou quels processus critiques sont touchés). La priorité en est déduite plutôt que laissée au libre choix – ce qui rend la priorisation comparable entre agents et justifiable après coup.

Chaque utilisateur final coûte-t-il une licence ?

Non. La facturation se fait à l'utilisateur nommé, dans deux rôles : administrateurs et agents de service desk. Les utilisateurs finaux qui signalent et suivent des tickets dans le portail en libre-service sont illimités et gratuits. Déployer le portail à l'ensemble du personnel n'est donc pas une question de budget.

Des tickets peuvent-ils naître d'un courriel ?

Oui. Les tickets sont créés à partir d'une boîte de réception surveillée et le message d'origine reste visible dans le journal. Les expéditeurs inconnus sont créés automatiquement dans l'annuaire de contacts local, les réponses reviennent dans le ticket via l'adresse de réponse.

Comment fonctionne la surveillance des SLA ?

Le moteur SLA tient plusieurs objectifs par ticket – en général les délais de réaction et de résolution – et prend en compte les heures ouvrées et les calendriers. Des objectifs OLA peuvent en outre être tenus au niveau des groupes de support. En cas de menace de dépassement, une escalade a lieu avant que l'échéance ne soit franchie ; l'analyse arrive dans le reporting.

Le service desk fonctionne-t-il sur site ?

Oui. Ordivis Platform fonctionne comme une infrastructure de services Windows native, avec sa propre base PostgreSQL, entièrement dans votre centre de données. Pour un système de billetterie, cela compte particulièrement, car les tickets contiennent régulièrement des données à caractère personnel et des informations sur des incidents de sécurité.

Existe-t-il une application mobile pour les agents ?

Une application Android est développée et fonctionne sur l'appareil – avec une file d'attente hors ligne, afin que les saisies effectuées sur le terrain ne soient pas perdues en l'absence de connexion. Elle n'est toutefois pas encore disponible de manière générale : la connexion durcie, les notifications push et le canal de distribution restent à faire. L'état actuel figure dans le journal des versions de l'application et dans la feuille de route.

La supervision peut-elle créer des tickets automatiquement ?

Oui. Les incidents issus de CheckMK, PRTG, Zabbix, Nagios/Icinga ou de tout autre outil deviennent des tickets via un point de terminaison par lots ; une boîte aux lettres de supervision avec un profil d'analyse suffit également. L'essentiel est ce qui ne se produit pas : une répétition ne crée pas un second ticket mais un commentaire sur le premier. La levée d'alerte referme elle-même le ticket après un délai de grâce. Une fenêtre de maintenance active empêche la création, un frein anti-tempête regroupe les événements de masse en un ticket collectif, et les services instables sont enregistrés comme instables plutôt que comme une avalanche de tickets.

Ordivis prend-il en charge l'authentification unique ?

Oui, via OpenID Connect – Entra ID, Keycloak ou tout autre fournisseur OIDC. L'échange code contre jeton se fait côté serveur (modèle de courtier), aucun secret ne se trouve dans le client, PKCE est imposé. Le domaine de messagerie détermine le client et le service d'authentification, les comptes sont créés à la première connexion, les groupes de l'IdP sont mis en correspondance avec les rôles Ordivis. Pour les postes de travail du domaine, l'authentification Windows intégrée via Kerberos est disponible en complément. Une réconciliation nocturne désactive les comptes bloqués ou supprimés au niveau du service d'authentification.

Dans le même esprit

Le service desk s'inscrit dans un ensemble

Logiciel ITSM

Toutes les pratiques ITIL dans une suite – de l'incident au changement, sans supplément par module.

Logiciel CMDB

Le rattachement au CI sur le ticket : priorisation selon les dépendances réelles plutôt qu'au ressenti.

Logiciel SMSI

Les mesures de sécurité sont traitées comme des tickets dans le même système – pas d'Excel à côté.

Voyez le cycle de vie du ticket à l'œuvre.

Du courriel à l'enquête CSAT en passant par l'horloge SLA – dans une démonstration en visioconférence.