Historique des exécutions et analyse des problèmes
L'historique des exécutions répond à la principale question du contrôle de l'automatisation : la règle, le robot ou le processus métier a-t-il fonctionné, et sinon, pourquoi. Sans lui, il est impossible de savoir si l'automatisation fonctionne réellement ou reste silencieusement inactive. Cette page explique comment lire les résultats des exécutions et analyser les problèmes courants.
L'historique est accessible là où vit chaque moteur : pour les règles de tâches, sur l'onglet « Historique » ; pour les robots CRM et les processus métier, dans leurs sections respectives.
Où consulter l'historique
- règles de tâches — onglet « Historique » sur
/tasks/automation: enregistrements des déclenchements par tâche ; - robots CRM — historique des déclenchements par affaire dans l'automatisation CRM ;
- processus métier — historique des étapes dans la fiche de l'instance et récapitulatif des « étapes dues à exécuter » ;
- étapes différées — récapitulatif de l'exécution : combien ont été traitées, réussies et en échec.
Commencez l'analyse par le moteur dont le comportement vous a surpris, et ouvrez son historique pour l'objet concerné.
Ce que montre un enregistrement de l'historique
Chaque enregistrement de l'historique décrit une exécution :
- statut — comment l'exécution s'est terminée ;
- heure — quand le déclenchement a eu lieu ou a été planifié ;
- objet — la tâche ou l'affaire sur laquelle portait l'exécution ;
- motif — code ou explication si l'exécution n'a pas abouti ;
- message — texte décrivant l'erreur ou le résultat.
Le couple « statut + motif » est l'outil principal d'analyse : le statut indique ce qui s'est passé, le motif pourquoi.
Résultats d'une exécution
Une exécution se termine par l'un des résultats suivants :
- réussi — l'action a été exécutée ;
- ignoré — la condition n'a pas été remplie ou l'exécution n'était pas autorisée, donc l'action n'a pas été appliquée ;
- en échec — l'action devait s'exécuter, mais n'a pas pu ;
- bloqué — un contrôle de protection a arrêté l'opération.
Ignoré et bloqué ne sont pas des dysfonctionnements, mais un comportement normal selon les règles ; l'échec, lui, exige une analyse.
Pourquoi une règle est ignorée
« Ignoré » signifie généralement que l'exécution ne correspondait pas aux conditions ou aux autorisations :
- les conditions de la règle n'étaient pas remplies pour cet objet ;
- la portée n'inclut pas ce projet, ce pipeline ou cette étape ;
- l'exécutant ou la règle n'a pas les autorisations pour l'action requise.
C'est normal : la règle ne touche volontairement pas ce qui est en dehors de ses conditions. Si elle aurait dû se déclencher, c'est que les conditions ou la portée sont trop restreintes ou incorrectes.
Pourquoi une exécution est bloquée
« Bloqué » signifie qu'un contrôle de protection s'est déclenché : l'opération n'est pas passée parce qu'une condition obligatoire n'était pas remplie (par exemple, un champ non renseigné avant un changement d'étape). Ce n'est pas une erreur d'automatisation, mais un règlement qui s'est appliqué. Analysez d'après le message du contrôle : il explique ce qu'il faut renseigner ou finaliser.
Pourquoi une étape s'est terminée en échec
« En échec » signifie que l'action devait s'exécuter, mais n'a pas pu. Causes fréquentes : l'exécutant de l'action n'a pas les autorisations, un participant ou un objet requis est absent, l'action est mal configurée, une opération externe est indisponible (par exemple, l'envoi d'un courriel sans modèle actif). Consultez le message de l'enregistrement : il indique la cause précise.
Résultat partiel
Pour les robots et les exécutions d'« étapes dues à exécuter », un résultat partiel est possible : une partie de la chaîne ou une partie des étapes différées a été exécutée, l'autre non. Pour un robot, cela dépend de la politique d'erreur (s'arrêter ou continuer) ; pour une exécution, cela se voit au récapitulatif (traité/réussi/en échec). Un résultat partiel est plus dangereux qu'un échec complet : l'objet reste dans un état à moitié traité, c'est pourquoi ces enregistrements doivent être analysés en priorité.
Corrections typiques
- ignoré alors qu'il aurait dû se déclencher — vérifiez les conditions et la portée ;
- bloqué — remplissez l'exigence du contrôle de protection ou ajustez le contrôle lui-même ;
- erreur d'autorisations — accordez les autorisations à l'exécutant de l'action ou changez d'exécutant ;
- erreur d'envoi de courriel — vérifiez que le modèle est actif et que les variables sont correctes ;
- erreur récurrente sur une même étape — corrigez la règle, le robot ou le modèle de processus métier, et non l'objet manuellement.
Bonnes pratiques
- Consultez régulièrement l'historique, et pas seulement quand quelque chose est cassé.
- Distinguez le « ignoré/bloqué » normal de la véritable « erreur ».
- Analysez les résultats partiels en priorité.
- Corrigez la cause dans la configuration de l'automatisation, et non la conséquence manuellement.
- Notez les erreurs récurrentes comme signal de révision de la règle ou du processus métier.
Erreurs fréquentes
Considérer « ignoré » comme une panne. Le plus souvent, la règle ne touche volontairement pas un objet hors de ses conditions.
Corriger l'objet manuellement au lieu de la cause. L'erreur se reproduira à la prochaine exécution.
Ignorer un résultat partiel. L'objet reste dans un état incohérent.
Ne pas lire le message ni le motif. Ils indiquent directement ce qu'il faut corriger.
Comment vérifier que c'est réparé
- une nouvelle exécution (ou une exécution manuelle) se termine avec succès ;
- l'enregistrement de l'historique affiche le statut attendu sans erreur ;
- les exécutions bloquées ont disparu après le respect de l'exigence du contrôle ;
- les résultats partiels ont été menés à terme, l'objet est dans un état correct ;
- l'erreur récurrente n'apparaît plus dans l'historique.