NexTool Solutions

Les processus informatiques tiennent rarement en une seule étape. Le diagnostic mène à l'exécution, l'exécution mène à la validation, et chaque étape n'a de sens qu'après le résultat de la précédente. Dans un GLPI standard, chacune de ces tâches naît de la saisie manuelle du technicien, ce qui rend la standardisation impossible dès que le volume augmente. Le module SubTask Flow enchaîne ces étapes : à la clôture d'une tâche, la suivante est créée automatiquement selon la solution choisie.

Pourquoi créer la tâche suivante à la main ne passe pas à l'échelle

Beaucoup de flux de traitement sont prévisibles : analyser, exécuter, valider, communiquer. GLPI propose des modèles de tâche (TaskTemplates) pour standardiser le contenu de chaque étape, mais il ne sait pas qu'une étape doit générer la suivante. Le résultat est connu : le technicien ouvre le bon modèle, recopie le responsable et l'échéance, et crée la tâche suivante à la main. Dans un environnement avec des dizaines de techniciens, cela produit trois problèmes chroniques : étapes oubliées, données divergentes entre tickets équivalents et aucune traçabilité du "pourquoi cette tâche existe". Quand un audit demande si la validation a été faite, la réponse dépend de la discipline individuelle de chaque technicien, pas d'un processus conçu.

Comment SubTask Flow enchaîne les tâches par solution

Le module crée des relations hiérarchiques entre TaskTemplates. Un modèle parent pointe vers un ou plusieurs modèles enfants, et chaque enfant peut être conditionné à une solution spécifique. Lorsque le technicien marque la tâche parent comme "Fait" et choisit la solution, le module exécute trois étapes :

1. Il identifie les modèles enfants liés à cette solution ;
2. Il crée les TicketTasks enfants dans la chronologie du même ticket ;
3. Il recopie le contenu, la catégorie, le temps estimé et le responsable définis dans le modèle enfant.

La configuration vit dans le modèle, pas dans le ticket. Vous ajustez le flux une fois et il s'applique à tous les tickets qui utilisent ce modèle, sans toucher aux règles métier ni aux automatisations externes. C'est la différence entre documenter un processus et faire en sorte que le système l'exécute.

Configuration pas à pas

1. Standardisez la liste des solutions dans la configuration du module (par exemple : "hardware", "software", "sans défaut"). Traitez-la comme un vocabulaire fermé, pas comme du texte libre.
2. Ouvrez le TaskTemplate parent et liez les modèles enfants dans l'onglet d'enchaînement.
3. Pour chaque enfant, définissez quelle solution le déclenche.
4. Assurez-vous que chaque modèle enfant possède un groupe ou technicien responsable et un temps estimé renseignés - c'est le champ qui fait le plus mal ensuite.
5. Testez sur un ticket de recette avant la mise en production : clôturez la tâche parent, choisissez chaque solution possible et confirmez que le bon enfant naît avec les bonnes données.

Protection contre les cycles

Un enchaînement sans garde-fou devient un piège. Un modèle A qui génère B, qui génère C, qui revient à A, créerait des tâches indéfiniment et figerait la chronologie du ticket. Avant d'accepter un nouveau lien, le module exécute un parcours en profondeur (DFS) sur le graphe de modèles. Si le lien ferme un cycle, il est rejeté avec un message explicatif plutôt que de laisser le problème exploser en production. La même discipline vaut que pour toute automatisation : garder les chaînes courtes et lisibles facilite le diagnostic quand quelque chose sort du script.

Traçabilité : l'onglet des journaux

Une automatisation sans trace est une boîte noire. SubTask Flow conserve un historique d'exécutions avec le modèle parent, le modèle enfant généré, la solution choisie, le technicien responsable et les horodatages. Lors d'un audit, cela répond à la question la plus fréquente - "cette sous-tâche a-t-elle été créée par une personne ou par le flux, et à partir de quelle décision ?" - sans dépendre de la mémoire de qui que ce soit. C'est aussi le premier endroit à regarder quand un client signale que "l'étape a disparu" : le journal montre si le déclencheur s'est activé et avec quelle solution.

Diagnostic : auditer le flux en SQL

Une automatisation silencieuse exige une surveillance active. La requête ci-dessous liste les sous-tâches encore ouvertes qui sont nées sans responsable défini, le symptôme classique d'un modèle enfant incomplet. Exécutez-la sur un réplica de lecture ou pendant une fenêtre de faible activité :

-- Sous-taches ouvertes (state=1) sans technicien ni groupe responsable.
-- Signale un TaskTemplate enfant avec users_id_tech/groups_id_tech vide.
SELECT t.id                       AS ticket,
       tt.id                      AS task_id,
       tmpl.name                  AS modele,
       tt.state,
       tt.users_id_tech,
       tt.groups_id_tech,
       tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t               ON t.id  = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
  AND tt.users_id_tech  = 0
  AND tt.groups_id_tech = 0
  AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;

Dans GLPI, state = 1 correspond à "À faire" et state = 2 à "Fait". Si cette liste grossit chaque semaine, le problème n'est pas le module : c'est un modèle enfant publié sans responsable, générant des tâches que personne ne voit dans la file.

Quand l'utiliser (et quand ne pas l'utiliser)

L'erreur de champ la plus fréquente

En maintenance d'environnements comptant beaucoup de techniciens, le problème qui revient le plus n'est pas technique, il est de modélisation. Quelqu'un configure l'enfant pour se déclencher sur la solution "Hardware", mais l'option que le technicien choisit réellement à l'écran est "hardware" en minuscules - ou "HW", dans un environnement qui a hérité du vocabulaire d'un autre outil. Le déclencheur ne correspond pas, la sous-tâche ne naît pas, personne ne reçoit d'erreur, et l'étape d'exécution disparaît simplement du processus sans laisser de trace visible. La correction que nous avons standardisée : traiter les chaînes de solution comme un vocabulaire contrôlé, toutes en minuscules, documentées dans une correspondance unique, et revoir les modèles enfants chaque fois que quelqu'un ajoute une nouvelle solution. La deuxième erreur récurrente est le modèle enfant sans responsable : la tâche naît orpheline, se perd au milieu de la chronologie et ne réapparaît qu'une fois le SLA déjà dépassé. C'est pourquoi la requête SQL ci-dessus fait partie de la checklist de maintenance, pas d'un audit ponctuel.

NexTool déploie et maintient des environnements GLPI avec des automatisations comme SubTask Flow conçues pour l'exploitation réelle de chaque client. Parlez à notre équipe pour cartographier et automatiser le flux de tâches de votre équipe.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.