Votre outil de ticketing doit-il être utilisé pour gérer l'on/offboarding IT ?

Le ticketing est l'outil de base des services informatiques. Une solution ITSM traite très bien une panne ou une demande de support : un ordinateur refuse de démarrer, l'utilisateur ouvre un incident, le technicien le résout et clôture le ticket.

Ce modèle convient aux événements isolés. L'onboarding IT et l'offboarding IT sont d'une tout autre nature. L'arrivée d'un collaborateur n'est pas un incident, et le départ d'un salarié n'est pas une simple demande technique. Ces événements mobilisent les RH, le manager, les services généraux et plusieurs administrateurs IT. Dans ce contexte précis, l'outil de ticketing montre vite ses limites : les échanges avec les managers s'enlisent, et personne ne voit clairement quels équipements et quels accès sont rattachés à quelle personne.

Cet article passe en revue les limites d'un outil de ticketing pour gérer le cycle de vie des collaborateurs, puis décrit une approche complémentaire pour mieux structurer la logistique IT.

‍

Outil de ticketing : un incident n'est pas un processus d'onboarding

‍

Une plateforme ITSM, ou un outil de ticketing informatique, est conçue pour la gestion des services IT au quotidien. Le flux de travail standard est simple. Un utilisateur rencontre un problème et ouvre un ticket, l'équipe informatique le résout, et l'outil enregistre le temps passé et la solution apportée.

L'intégration d'un nouveau salarié a un tout autre périmètre. Un onboarding, et avant lui le preboarding, implique plusieurs départements. Les ressources humaines créent le profil administratif dans le SIRH. Les services généraux préparent le badge. L'équipe IT s'occupe du matériel et des accès logiciels. Un ticket isolé ne sait pas coordonner tout cela.

Ces tâches pèsent lourd dans l'agenda des équipes informatiques. Selon une enquête conjointe d'InformationWeek et TeamDynamix, 58 % des organisations déclarent que leur équipe IT passe plus de 5 heures par semaine sur des requêtes manuelles répétitives. L'onboarding figure systématiquement parmi les processus les plus chronophages.

Traiter une arrivée dans un outil de ticketing oblige le technicien à découper lui-même le travail en sous-tâches : un ticket pour commander le PC, un autre pour créer l'adresse e-mail, un troisième pour ouvrir l'accès au CRM. Cette gestion fragmentée ralentit nettement le parcours d'intégration.

‍

Managers et ticketing : l'inertie des allers-retours

‍

Le manager métier connaît mieux que personne les besoins de sa future recrue, et son rôle dans l'onboarding IT est central. Pourtant, l'échange entre le manager et l'IT par l'intermédiaire d'un ticket est souvent laborieux.

Le scénario est connu. Le manager ouvre un ticket pour annoncer une arrivée, avec un message imprécis du type « Merci de préparer un poste pour le nouveau commercial ». Le technicien ne dispose pas des informations nécessaires. Il doit relancer le manager pour connaître le modèle d'ordinateur attendu, savoir si un téléphone est prévu et identifier les licences spécifiques à activer.

Ces allers-retours finissent par agacer tout le monde. Le manager a le sentiment de perdre son temps, et le support informatique se transforme en enquêteur. Un rapport de l'éditeur Ivanti souligne l'effet de ces processus manuels : selon les professionnels de l'IT interrogés, un onboarding non structuré ralentit la productivité globale et allonge les délais de mise à disposition des équipements. Au bout de la chaîne, le collaborateur risque d'arriver le premier jour sans son matériel de base.

L'outil ITSM attend une donnée d'entrée précise pour fonctionner. Or le manager n'est pas technicien. Il ne connaît pas toujours le nom exact des licences et ne maîtrise pas les options de gestion des identités et des accès. Le formulaire du ticket est alors soit trop complexe, soit trop pauvre. Il manque une étape de traduction entre le besoin métier et l'exécution technique.

‍

Ticketing ITSM : aucun lien natif entre la personne et ses ressources

‍

Autre limite du ticketing : la cartographie des ressources. Un outil de ticketing gère des flux d'actions. Il ne gère pas nativement des profils utilisateurs rattachés à un catalogue de services.

Préparer un poste de travail demande pourtant une vue d'ensemble qui croise deux univers. D'un côté, le matériel, suivi dans un logiciel de gestion de parc ou une solution d'inventaire informatique. De l'autre, les accès logiciels, gérés par une solution d'IAM, c'est-à-dire un logiciel de gestion des identités et des accès.

Le ticketing se trouve entre les deux, sans les relier. Le ticket indique qu'il faut fournir un ordinateur, mais il ne vérifie pas dans l'inventaire quel matériel est disponible en stock pour ce profil. La notion de « package collaborateur » n'existe pas.

Un provisioning efficace raisonne par rôle. Un profil « développeur » appelle une configuration matérielle particulière et des droits d'accès avancés. Un outil ITSM standard ne génère pas de lui-même un panier de ressources préapprouvées en fonction du métier. Le technicien consulte une documentation à part ou s'en remet à son expérience. Cette approche manuelle favorise les erreurs et les attributions inadaptées : l'employé reçoit parfois des logiciels dont il n'a pas besoin.

‍

Offboarding IT par ticket : traçabilité et sécurité en danger

‍

Le départ d'un collaborateur est une phase sensible qui exige de la rigueur, parce que la conformité du SI et la sécurité des données sont en jeu. Gérer une sortie avec un simple ticket expose à plusieurs faiblesses.

Quand le manager signale un départ par ticket, l'information est déclarative. Le technicien ferme les accès qu'il a en tête ou ceux que mentionne le ticket, sans vision exhaustive de ce que détient réellement l'employé. L'historique des attributions est dispersé, et la fermeture des licences logicielles risque d'être incomplète.

Le marché du SaaS met bien ce problème en évidence. Selon le cabinet Zylo, spécialiste de l'optimisation SaaS, les entreprises gaspillent une part importante de leur budget informatique : en moyenne, 44 % des licences logicielles d'une organisation sont inutilisées ou sous-exploitées. Une grande partie de ce gaspillage vient de comptes non désactivés au départ d'un salarié, car le déprovisionnement manuel par ticket oublie souvent les abonnements secondaires. Nous détaillons ces coûts d'un offboarding IT raté (comptes fantômes, licences) dans un article dédié.

La restitution du matériel pose le même problème. Le ticket de départ est parfois clôturé avant que l'ordinateur ne soit rendu, et rien ne suit la dotation de bout en bout. La traçabilité reste approximative.

Pour respecter un cadre normatif exigeant comme la certification ISO 27001, cette approche ne suffit pas. Les auditeurs demandent des preuves concrètes que chaque accès a été révoqué et que la checklist d'offboarding IT a été suivie en entier. Un outil de ticketing classique peine à fournir une piste d'audit montrant que l'inventaire des actifs informatiques a bien été mis à jour après la restitution physique. Sur ce sujet, vous pouvez lire le témoignage de Kercia sur la gouvernance des accès et l'ISO 27001.

‍

L'orchestration, un complément à l'outil de ticketing pour l'on/offboarding

‍

Face à ces limites, les entreprises cherchent d'autres façons de gérer les arrivées et les départs. L'objectif n'est pas de remplacer la plateforme ITSM, qui reste indispensable pour le support quotidien, mais d'ajouter une couche en amont : l'orchestration IT, telle que la propose Pyla.

Concrètement, un orchestrateur comme Pyla fait le pont entre la donnée RH et l'exécution IT. Dès que le SIRH signale une arrivée ou un départ, Pyla capte l'information et soumet au manager des choix prédéfinis. Celui-ci n'a plus qu'à valider un catalogue de ressources (équipements matériels, licences logicielles) adapté au profil du collaborateur.

Pyla distribue ensuite des tâches claires et structurées aux administrateurs informatiques. Chacun peut les traiter directement dans Pyla ou les retrouver dans son outil de ticketing habituel grâce à l'intégration, s'il préfère rester dans son environnement.

Ce que Pyla ajoute à un outil de ticketing classique tient surtout à l'association entre l'individu et la ressource, que le ticket, outil généraliste, ne gère pas nativement. Dans Pyla, une personne correspond à un profil précis, avec des accès et des rôles définis, et chaque ressource est attribuée à des collaborateurs identifiés.

Autrement dit, Pyla est à la gestion des identités et des ressources ce que Jira est à la gestion des incidents. L'équipe IT ne court plus après les informations manquantes et ne jongle plus avec une série de tickets déconnectés pour gérer chaque accès séparément.

Chaque action étant documentée, la traçabilité suit. La préparation des audits s'en trouve facilitée, et il n'est plus nécessaire de fouiller l'historique des tickets pendant des heures pour retracer un événement.

‍

Ticketing ou orchestration : comment répartir les rôles ?

‍

Gardez l'outil de ticketing pour ce qu'il fait bien : résoudre des incidents et traiter des demandes ponctuelles. La gestion des arrivées et des départs pose une autre question, celle de savoir qui détient quoi, et qui doit le préparer ou le récupérer. Tant que la réponse dépend de la mémoire du technicien ou de la précision du manager, les allers-retours, les licences oubliées et les écarts d'inventaire continuent.

Pour structurer ces processus, de plus en plus de directions informatiques ajoutent à leur écosystème une solution d'orchestration dédiée. Branchée sur le SIRH en amont et sur l'ITSM en aval, elle relie la donnée RH, la validation du manager et l'exécution technique. Le ticket reste le canal d'exécution. Il arrive simplement complet, et la logistique IT devient sûre et mesurable.

‍