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.
# 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
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.
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.
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.
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.
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.
La cause derrière des incidents récurrents. Les incidents sont regroupés, le contournement est documenté et la correction durable est suivie.
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.
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.
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.
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.
Les tickets sont visibles par groupe – appartenance par utilisateur ou par rôle. Le 2e niveau voit ce qui le concerne, pas tout.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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ôle | Ce qu'il peut faire | Soumis à licence |
|---|---|---|
| Administrateur | Ensemble des fonctions, y compris service desk, configuration, tous les modules | Oui, nommé |
| Agent de service desk | Traitement des tickets – rôle moins cher pour le seul traitement | Oui, nommé |
| Utilisateurs finaux dans le portail | Signaler et suivre des tickets, lire des articles de connaissance, commander des services | Non – illimité |
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.
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.
À 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.
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.
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.
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.
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é.
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.
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.
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.
Toutes les pratiques ITIL dans une suite – de l'incident au changement, sans supplément par module.
Le rattachement au CI sur le ticket : priorisation selon les dépendances réelles plutôt qu'au ressenti.
Les mesures de sécurité sont traitées comme des tickets dans le même système – pas d'Excel à côté.
Du courriel à l'enquête CSAT en passant par l'horloge SLA – dans une démonstration en visioconférence.