Comment créer un journal d'événements de process mining

Ce que vous allez apprendre

Dans ce guide, vous allez apprendre à créer un journal d’événements de process mining de A à Z. Nous passerons en revue les trois colonnes indispensables à tout journal d’événements, verrons un exemple concret et vous montrerons comment créer votre premier journal d’événements dans Excel et en SQL.

Qu’est-ce qu’un journal d’événements de process mining ?

À lire aussi : en savoir plus sur l’amélioration des processus et trouver des modèles de données pour votre système. Découvrez également pourquoi nous n’utilisons pas les connecteurs prêts à l’emploi au profit de modèles de données simples.

Un journal d’événements de process mining, c’est tout simplement une table qui enregistre ce qui se passe dans votre processus métier. Pensez-y comme à un journal de bord qui retrace chaque étape de chaque cas qui traverse votre système. Le logiciel de process mining lit ce journal et génère des diagrammes qui montrent comment votre processus fonctionne réellement.

Chaque journal d’événements a besoin de trois informations essentielles par ligne :

ColonneSignificationExemple
Case IDIdentifiant unique qui regroupe des événements liésCommande #12345
TimestampQuand l’événement a eu lieu2025-01-15 09:30:00
ActivityCe qui s’est passé”Commande passée”

C’est tout. Avec seulement ces trois colonnes, vous pouvez commencer le process mining. Tout le reste, comme les noms de clients, les montants de commande ou les identifiants d’employés, sont des informations facultatives appelées « attributs » qui enrichissent l’analyse.

Comprendre la différence : événements vs activités

Avant d’aller plus loin, clarifions un point qui prête souvent à confusion.

Une activité est un type d’action, comme “Order Shipped” ou “Payment Received”. Pensez-y comme à une catégorie ou à un libellé.

Un événement est l’occurrence précise de cette activité. Quand la commande n°12345 est expédiée le 15 janvier à 14:30, c’est un événement.

Votre journal d’événements contient des événements, et chaque événement a un nom d’activité. Dans la pratique, on utilise souvent ces termes de manière interchangeable, et ce n’est pas gênant. Retenez simplement : les activités décrivent le “quoi”, et les événements le “quand et pour qui”.

Notre exemple : le système de commandes de Pizza Palace

Pour rendre ce guide concret, partons d’un système fictif. Imaginez que vous gérez Pizza Palace, une pizzeria locale avec un système de commande en ligne. Les clients passent commande sur le site, l’équipe prépare les pizzas et les livreurs les apportent.

Le système Pizza Palace s’appuie sur plusieurs tables qui retracent différentes étapes du processus de commande :

  • orders - Informations de base sur la commande (ID de commande, client, date/heure de création)
  • order_items - Détail des articles commandés (pizzas, accompagnements, boissons)
  • kitchen_queue - Entrée et sortie des commandes en cuisine
  • delivery_assignments - Affectations des livreurs et suivi de livraison
  • payments - Enregistrements du traitement des paiements

Votre objectif : créer un journal d’événements qui montre le parcours complet de chaque commande, de la prise de commande à la livraison.

Types d’événements : directs et déduits

En construisant un journal d’événements, vous rencontrerez deux types d’événements :

Événements directs

Les événements directs sont enregistrés explicitement dans votre système. Quelqu’un a cliqué sur un bouton ou une action a été journalisée par le système, et un timestamp est présent directement dans la base de données.

Exemples chez Pizza Palace :

  • Order placed (timestamp dans la table orders)
  • Payment received (timestamp dans la table payments)
  • Delivery completed (timestamp dans la table delivery_assignments)

Événements déduits

Les événements déduits n’ont pas leur propre horodatage, mais on peut déterminer quand ils se sont produits à partir d’autres données.

Exemples chez Pizza Palace :

  • “Order Assigned to Driver” n’a peut-être pas son propre horodatage, mais la table delivery_assignments contient un champ created_at qui indique quand l’affectation a été créée
  • ”Pizza Ready” peut être déduit du moment où le statut de la file d’attente de la cuisine passe à “completed”

Différence essentielle : les événements directs sont enregistrés explicitement, tandis que les événements déduits demandent d’interpréter d’autres champs. Les deux sont valides et utiles en Process Mining.

Planifier votre journal d’événements

Avant d’extraire les données, décidez quels événements vous voulez capturer. Pour Pizza Palace, suivons ces activités :

  1. Commande passée - Le client valide la commande
  2. Paiement reçu - Le paiement est traité avec succès
  3. Commande envoyée en cuisine - La commande entre dans la file de préparation
  4. Commande prête - La cuisine marque la commande comme terminée
  5. Affectation à un livreur - Un livreur est désigné pour la livraison
  6. Livraison terminée - La commande est livrée au client

Pour chaque événement, identifiez :

  • La table qui contient les données
  • Le champ qui porte l’horodatage
  • Ce qui fait office de Case ID (ici, l’ID de commande)

Voici notre correspondance :

ActivityTable sourceChamp TimestampChamp Case ID
Commande passéeorderscreated_atid
Paiement reçupaymentspayment_timeorder_id
Commande envoyée en cuisinekitchen_queuequeue_entry_timeorder_id
Commande prêtekitchen_queuecompleted_timeorder_id
Affectation à un livreurdelivery_assignmentsassigned_atorder_id
Livraison terminéedelivery_assignmentsdelivered_atorder_id

Ajouter des attributs de cas et d’événement

Case ID, Timestamp et Activity sont obligatoires, mais les attributs rendent votre analyse bien plus puissante. Ce sont des colonnes supplémentaires qui apportent du contexte.

Attributs de cas

Les attributs de cas décrivent l’ensemble du cas (commande) et sont identiques pour tous les événements de ce cas :

  • Nom du client
  • Montant total de la commande
  • Adresse de livraison
  • Nombre d’articles commandés

Attributs d’événement

Les attributs d’événement sont spécifiques à chaque événement :

  • Nom du livreur (pertinent uniquement pour les événements de livraison)
  • Méthode de paiement (pertinente uniquement pour les événements de paiement)
  • Poste de cuisine (pertinent uniquement pour les événements de cuisine)

Astuce : Vous pouvez sans problème inclure toutes les colonnes d’attributs à chaque ligne, même si certaines ne s’appliquent pas. Par exemple, la ligne “Order Placed” peut avoir une colonne “Driver Name” vide. Cela garde votre journal d’événements sous forme de table à plat, simple, que les outils de process mining adorent.

Construire le journal d’événements : structure simple

Votre journal d’événements final doit être une seule table où chaque ligne représente un événement. Voici à quoi ressemblera le journal d’événements de Pizza Palace :

Case IDTimestampActivityClientMontant de la commandeLivreurMode de paiement
10012025-01-15 18:30:00Commande passéeJohn Smith45.99
10012025-01-15 18:30:15Paiement reçuJohn Smith45.99Carte bancaire
10012025-01-15 18:31:00Commande envoyée en cuisineJohn Smith45.99
10012025-01-15 18:45:00Commande prêteJohn Smith45.99
10012025-01-15 18:46:00Affectation à un livreurJohn Smith45.99Maria Garcia
10012025-01-15 19:05:00Livraison terminéeJohn Smith45.99Maria Garcia
10022025-01-15 18:35:00Commande passéeJane Doe28.50
10022025-01-15 18:35:20Paiement reçuJane Doe28.50PayPal

Remarquez que les attributs de cas (Client, Montant de la commande) se répètent à chaque événement dans le même cas. Cette duplication est volontaire et rend les données faciles à exploiter.

Méthode 1 : créer un journal d’événements dans Excel

Si vous pouvez exporter vos données vers un tableur, vous pouvez créer un journal d’événements manuellement. Cette méthode fonctionne très bien pour de petits jeux de données ou pour apprendre.

Étape 1 : Exporter chaque type d’événement sur une feuille distincte

Créez une feuille de calcul par type d’activité :

Feuille 1 : Order Placed

Case IDTimestampActivityCustomerOrder Value
10012025-01-15 18:30:00Order PlacedJohn Smith45.99
10022025-01-15 18:35:00Order PlacedJane Doe28.50

Feuille 2 : Payment Received

Case IDTimestampActivityCustomerOrder ValuePayment Method
10012025-01-15 18:30:15Payment ReceivedJohn Smith45.99Credit Card
10022025-01-15 18:35:20Payment ReceivedJane Doe28.50PayPal

Étape 2 : Harmoniser les colonnes

Assurez-vous que toutes les feuilles partagent les mêmes colonnes dans le même ordre. Ajoutez des colonnes vides si nécessaire :

Feuille 1 : Order Placed (mise à jour)

Case IDTimestampActivityCustomerOrder ValueDriverPayment Method
10012025-01-15 18:30:00Order PlacedJohn Smith45.99

Étape 3 : Combiner toutes les feuilles

Créez une nouvelle feuille “Event Log”. Copiez et collez toutes les lignes de chaque feuille d’activité dans cette feuille combinée, les unes à la suite des autres.

Étape 4 : Trier par Case ID puis par Timestamp

Sélectionnez toutes vos données et triez par :

  1. Case ID (ascendant)
  2. Timestamp (ascendant)

Cela place les événements dans l’ordre chronologique au sein de chaque cas, ce qui facilite le suivi du parcours de chaque commande.

Étape 5 : Exporter en CSV

Enregistrez votre feuille combinée au format CSV. Ce format fonctionne avec la quasi-totalité des outils de Process Mining.

Conseils Excel :

  • Utilisez VLOOKUP ou XLOOKUP pour récupérer des attributs de cas (comme le nom du client) depuis votre feuille de commandes
  • Utilisez des formats de date cohérents (YYYY-MM-DD HH:MM:SS fonctionne très bien)
  • Supprimez les événements en double avant l’export

Méthode 2 : créer un journal d’événements avec SQL

Pour des volumes importants ou des extractions régulières, SQL est plus efficace et reproductible. L’astuce clé consiste à utiliser UNION ALL pour combiner plusieurs requêtes en un seul jeu de résultats.

Comprendre UNION ALL

UNION ALL empile les résultats de plusieurs instructions SELECT les unes au-dessus des autres. Chaque SELECT devient un ensemble de lignes dans le résultat final. Tous les SELECT doivent renvoyer le même nombre de colonnes avec des types compatibles.

Exemple SQL complet

Voici une requête SQL qui crée un journal d’événements pour Pizza Palace :

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS timestamp,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS timestamp,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT 
    k.order_id AS case_id,
    k.queue_entry_time AS timestamp,
    'Order Sent to Kitchen' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'

UNION ALL

-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS timestamp,            -- Different timestamp than entry
    'Order Ready' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
  AND k.completed_time IS NOT NULL            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT 
    d.order_id AS case_id,
    d.assigned_at AS timestamp,
    'Assigned to Driver' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,                  -- Event-specific attribute
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'

UNION ALL

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS timestamp,
    'Delivery Completed' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
  AND d.delivered_at IS NOT NULL              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp;

Comment étendre cette requête

Pour ajouter de nouveaux événements à votre journal :

  1. Copiez l’un des blocs SELECT comme modèle
  2. Changez le nom de la table pour votre table source
  3. Mettez à jour la colonne de timestamp avec la bonne colonne
  4. Modifiez le nom d’activité pour décrire l’événement
  5. Ajustez les attributs si nécessaire
  6. Ajoutez des conditions WHERE appropriées pour filtrer les données

Par exemple, pour ajouter un événement “Delivery Attempted” :

UNION ALL

-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT 
    d.order_id AS case_id,
    d.attempt_time AS timestamp,
    'Delivery Attempted' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'

Bonnes pratiques pour créer un journal d’événements

1. Commencez simplement, complexifiez ensuite

Démarrez avec les trois colonnes requises et quelques activités clés. Une fois un journal d’événements simple créé et chargé dans un outil de process mining, vous pourrez revenir ajouter d’autres événements et attributs.

2. Validez vos données

Avant de lancer l’analyse, passez en revue votre journal d’événements pour repérer les problèmes courants :

  • Timestamps manquants - Des événements sans timestamp empêchent l’analyse de process mining
  • Événements en double - Le même événement enregistré deux fois fausse vos résultats
  • Événements hors séquence - Un “Order Ready” avant “Order Placed” indique un problème de qualité des données
  • Événements orphelins - Des événements dont l’ID de cas n’apparaît dans aucune autre activité

3. Documentez votre extraction

Notez :

  • Quelles tables vous avez utilisées
  • Quels filtres vous avez appliqués
  • Quand l’extraction a été lancée
  • Les hypothèses retenues

Cette documentation vous sera précieuse au moment de mettre à jour ou de dépanner votre journal d’événements plus tard.

4. Harmonisez les noms

Maintenez des noms d’activités cohérents d’une extraction à l’autre :

  • Mieux vaut utiliser “Order Placed” que de varier entre “Order Created” et “New Order”
  • Définissez une convention de nommage et tenez-vous-y

5. Gérez les fuseaux horaires

Si vos données proviennent de plusieurs systèmes ou régions, assurez-vous que tous les timestamps utilisent le même fuseau horaire. UTC est souvent le choix le plus sûr pour garantir la cohérence.

Difficultés courantes et solutions

Défi : même événement provenant de plusieurs sources

Il arrive que le même événement soit enregistré dans plusieurs tables. Par exemple, votre système de commandes et votre ERP peuvent tous deux noter l’expédition d’une commande.

Solution : Choisissez une « source of truth » (source de vérité) et n’utilisez que celle-là. Documentez votre choix.

Illustration des difficultés courantes lors de la création de journaux d'événements de process mining

Défi : événements sans timestamp

Certains événements n’ont pas leur propre timestamp. Par exemple, un “Order Approved” peut n’être qu’un booléen.

Solution : Cherchez des timestamps liés. Il existe peut-être un champ “approved_at”, ou vous pouvez utiliser le timestamp “modified_at” au moment où l’indicateur approuvé a changé.

Défi : volume d’événements très élevé

Si vous avez plusieurs millions d’événements, vos requêtes peuvent être lentes ou planter lors de l’extraction.

Solution :

  • Ajoutez des filtres de date pour limiter la période d’extraction
  • Extrayez par lots (un mois à la fois), puis fusionnez les fichiers
  • Envisagez d’utiliser des outils ETL dédiés pour les extractions à grande échelle

Et ensuite ? Charger votre journal d’événements dans un outil de process mining

Une fois votre journal d’événements exporté en CSV ou extrait depuis la base de données, vous pouvez le charger dans un outil de process mining. La plupart des outils suivent une démarche similaire :

  1. Importez votre fichier ou connectez l’outil à vos données extraites
  2. Faites correspondre vos colonnes (Case ID, Timestamp, Activity)
  3. Configurez les attributs supplémentaires
  4. Générez votre carte de processus

Les outils modernes de process mining comme ProcessMind rendent l’opération très simple. Importez votre journal d’événements et l’outil visualise automatiquement votre processus, en révélant les goulots d’étranglement, les variantes et les opportunités d’amélioration.

Conclusion

Créer un journal d’événements de process mining ne nécessite ni outils spécialisés ni connaissances techniques poussées. Au fond, il s’agit simplement d’organiser vos données dans une table avec trois colonnes essentielles : Case ID, Timestamp et Activity.

Que vous utilisiez Excel pour de petits volumes ou SQL pour des extractions plus volumineuses et régulières, les principes restent les mêmes :

  1. Identifier les événements à suivre
  2. Trouver l’horodatage pour chaque type d’événement
  3. Tout regrouper dans une table unique
  4. Ajouter des attributs pour enrichir l’analyse

Le plus difficile n’est pas l’extraction technique : c’est de bien comprendre votre processus pour savoir quels événements comptent. Commencez par les étapes évidentes (commande créée, commande livrée) et ajoutez progressivement des détails au fil des enseignements révélés par votre outil de process mining.

Envie d’aller plus loin ? Explorez nos pages d’amélioration continue des processus, où vous trouverez des informations détaillées sur les activités et les besoins en données pour des processus populaires comme Achat à paiement (P2P), Commande à encaissement (O2C) et Comptes fournisseurs. Ces ressources incluent des modèles de données pour des systèmes bien connus comme SAP, Oracle et Microsoft Dynamics, pour accélérer la création de votre journal d’événements.

Lancez-vous dès aujourd'hui

N’attendez pas le journal d’événements parfait. Partez de l’existant, apprenez des cartes de processus que vous créez et itérez. Même un journal d’événements simple, avec des activités de base, peut révéler des enseignements surprenants sur le fonctionnement réel de vos processus.

Articles de blog associés

Recevez des insights d'experts en Process Mining et optimisation de workflow directement dans votre boîte mail
Analyser votre processus : guide pratique Process Mining

Analyser votre processus : guide pratique Process Mining

Transformez vos dashboards Process Mining en actions. Méthode pas à pas pour lire vos données et trouver des pistes d’amélioration.

Pourquoi nous évitons les connecteurs prêts à l'emploi (et ce que nous faisons à la place)

Pourquoi nous évitons les connecteurs prêts à l'emploi (et ce que nous faisons à la place)

Les connecteurs promettent une extraction facile pour le process mining, mais apportent souvent complexité, retards et lock‑in. Découvrez notre approche avec de…

Guide Stratégique pour l’Amélioration des Processus Data-Driven

Guide Stratégique pour l’Amélioration des Processus Data-Driven

Guide complet pour optimiser vos processus avec la data et transformer votre entreprise.

Alternatives Celonis Process Mining : pourquoi ProcessMind se démarque ?

Alternatives Celonis Process Mining : pourquoi ProcessMind se démarque ?

Comparez Celonis et ProcessMind pour 2025. Découvrez le logiciel de process mining le plus adapté à vos besoins et à votre budget.

Relevez le défi : améliorez vos processus en moins de 30 jours !

Accès immédiat, sans carte bancaire, sans attente. Découvrez comment mapping, mining et simulation fonctionnent ensemble pour des décisions plus rapides et plus intelligentes.

Explorez chaque fonctionnalité, découvrez des insights profonds et optimisez vos opérations dès le premier jour.

Lancez votre essai gratuit et libérez tout le potentiel de la Process Intelligence, constatez des résultats concrets en moins de 30 jours !