ESSENTIEL - Le modèle événement-résultat : représenter un processus
« Quand la commande arrive, on la saisit, et si le client est solvable on prépare la livraison. » La phrase paraît claire. Elle ne dit pourtant ni qui saisit, ni ce qui se passe quand le client n'est pas solvable, ni si la vérification précède ou suit la saisie. Un schéma, lui, ne laisse pas ces zones dans l'ombre : il oblige à trancher.
C'est tout l'intérêt du modèle événement-résultat. Il ne sert pas à faire joli dans un rapport : il sert à repérer les points où le processus est ambigu, redondant ou interrompu. Donc là où les erreurs se produisent.
Le principe
Le modèle repose sur une séquence de trois éléments. Un événement survient, il déclenche une opération, celle-ci produit un résultat. Ce résultat devient très souvent l'événement déclencheur de l'opération suivante, et c'est cet enchaînement qui constitue le processus.
Le modèle est issu de la méthode Merise, où il porte le nom de modèle conceptuel des traitements. À ce niveau, il répond à une seule question : que fait-on, et à partir de quoi ? Ni qui, ni quand, ni comment. Ces trois questions arrivent ensuite, lorsqu'on ajoute les acteurs.
Les composants
| Composant | Ce qu'il est | Comment le repérer |
| L'événement | Un fait qui déclenche une action. Il est externe s'il vient de l'extérieur, interne s'il est produit par l'organisation. | C'est presque toujours un document ou un message : commande reçue, facture, relevé bancaire, échéance atteinte. |
| L'opération | Un ensemble de tâches enchaînées sans interruption, en réaction à un ou plusieurs événements. | Elle se nomme par un verbe à l'infinitif : contrôler la commande, enregistrer la facture, préparer le règlement. |
| Le résultat | Ce que l'opération produit. | Un document, une décision, un enregistrement. Il peut être positif ou négatif : commande acceptée, commande refusée. |
| La synchronisation | La condition qui combine plusieurs événements pour déclencher l'opération. | Elle s'exprime par ET ou par OU, et se place au-dessus de l'opération. |
| La règle d'émission | La condition qui détermine lequel des résultats est produit. | Elle se place sous l'opération. En l'absence de condition, on écrit « toujours ». |
Graphiquement, l'opération se représente par un rectangle en trois parties : son intitulé en haut, les tâches au milieu, les règles d'émission en bas. Les événements arrivent par le haut, les résultats sortent par le bas. Une règle absolue : toute opération possède au moins un événement déclencheur et au moins un résultat. Une opération sans entrée ou sans sortie signale une erreur de modélisation.
Synchronisation et règles d'émission
| Notion | Ce qu'elle exprime | Exemple |
| Synchronisation ET | L'opération n'est déclenchée que si tous les événements sont survenus. | Le règlement d'un fournisseur suppose la facture reçue ET le bon de réception validé. |
| Synchronisation OU | L'un ou l'autre des événements suffit. | Une commande peut arriver par le portail en ligne OU par courrier. |
| Règle d'émission conditionnelle | Plusieurs résultats possibles selon une condition. | Après contrôle : si l'encours est disponible, commande acceptée ; sinon, commande bloquée. |
| Règle d'émission « toujours » | L'opération produit systématiquement le même résultat. | L'enregistrement d'une facture produit toujours une écriture comptable. |
Ces deux notions sont ce qui distingue un vrai schéma de processus d'un simple organigramme. La synchronisation dit ce qu'il faut réunir avant d'agir ; la règle d'émission dit ce qui se passe selon les cas. C'est précisément là que se logent les règles de gestion de l'entreprise, souvent implicites tant qu'on ne les a pas écrites.
Ajouter les acteurs
Le modèle conceptuel dit ce qui se fait. En ajoutant les acteurs, on obtient le modèle organisationnel, qui répond à trois questions supplémentaires : qui réalise l'opération, quand, et de quelle manière.
| Ce qu'on ajoute | Ce que cela apporte | Ce que cela révèle |
| Les acteurs, en colonnes | Chaque opération est placée dans la colonne du service ou du poste qui la réalise. | Les allers-retours entre services, chaque changement de colonne étant un point de rupture possible. |
| Les acteurs externes | Client, fournisseur, banque, administration figurent aux extrémités. | La frontière de l'organisation, et les événements sur lesquels elle n'a aucune prise. |
| La nature du traitement | Manuel, automatisé ou semi-automatisé. | Ce qui pourrait être automatisé, et ce qui repose encore sur une intervention humaine. |
| Le moment | Période ou délai d'exécution. | Les goulets d'étranglement et les traitements qui attendent une échéance. |
C'est cette version enrichie qui est attendue dans un rapport professionnel, parce qu'elle est la seule à rendre visible la coordination entre acteurs. Un processus qui traverse cinq colonnes n'a pas la même fragilité qu'un processus entièrement traité par un même service.
C'est aussi ce qui est attendu à l'épreuve E8 du BTS CG, le parcours de professionnalisation : l'écrit à produire s'intitule précisément « analyse de l'organisation d'un processus », en douze pages au plus hors annexes. Le schéma n'y est pas une illustration mais le support du raisonnement — il sert à montrer où le processus observé pendant le stage présente des redondances, des ruptures ou des contrôles manquants.
Construire le schéma
| Étape | Ce qu'on fait | Point de vigilance |
| 1. Décrire en mots | Rédiger le déroulement du processus tel qu'il se pratique réellement. | Décrire le réel, pas la procédure théorique : c'est l'écart entre les deux qui est intéressant. |
| 2. Repérer les événements et les résultats | Souligner les documents et les faits déclencheurs. | Un même document peut être résultat d'une opération et événement de la suivante. |
| 3. Délimiter les opérations | Regrouper les tâches réalisées sans interruption par un même acteur. | Un changement d'acteur impose une nouvelle opération. |
| 4. Poser les conditions | Écrire les synchronisations en entrée, les règles d'émission en sortie. | Toute alternative doit apparaître : ne jamais laisser un cas sans issue. |
| 5. Placer les acteurs | Répartir les opérations en colonnes. | Vérifier que chaque colonne correspond à un poste réel, pas à une abstraction. |
Cas particuliers
| Situation | Ce qu'il faut retenir | Pour aller plus loin |
| Un événement temporel | Une échéance peut déclencher une opération sans qu'aucun document n'arrive : fin de mois, date limite de déclaration. | Il se représente comme les autres événements, avec sa périodicité. |
| Un résultat négatif | Le rejet, le refus ou l'anomalie sont des résultats à part entière. | Un schéma qui ne montre que le cas nominal est incomplet, et c'est l'erreur la plus fréquente. |
| Une opération entièrement automatisée | Elle figure au même titre que les autres, avec l'application comme acteur. | C'est ce qui permet de mesurer le degré d'automatisation d'un processus. |
| Un processus qui boucle | Un résultat peut ramener à une opération antérieure : correction, relance, nouvelle validation. | La boucle doit être explicite, avec sa condition de sortie. |
| Le lien avec les données | Les événements et résultats correspondent souvent à des enregistrements en base. | C'est le point de jonction entre modélisation des traitements et modélisation des données. |
Erreurs fréquentes et bonnes pratiques
| Erreur | Conséquence | Bonne pratique |
| Ne représenter que le cas où tout se passe bien | Le schéma ne sert à rien : les incidents sont précisément ce qu'on cherche à maîtriser. | Faire figurer les rejets, refus et anomalies comme résultats à part entière. |
| Confondre tâche et opération | Schéma illisible, découpé en dizaines de rectangles. | Une opération regroupe les tâches enchaînées sans interruption par un même acteur. |
| Omettre les règles d'émission | Les règles de gestion restent implicites, donc discutables et non contrôlables. | Écrire la condition sous l'opération, ou « toujours » s'il n'y en a pas. |
| Oublier la synchronisation quand plusieurs événements sont nécessaires | Le schéma laisse croire qu'un seul événement suffit à déclencher l'opération. | Poser explicitement le ET ou le OU au-dessus de l'opération. |
| Modéliser la procédure théorique | Le schéma décrit ce qui devrait se passer, pas ce qui se passe : aucun dysfonctionnement n'apparaît. | Partir des pratiques réelles, recueillies auprès des acteurs eux-mêmes. |
| Laisser une opération sans entrée ou sans sortie | Modélisation invalide : le schéma ne peut pas être lu. | Vérifier que chaque opération a au moins un événement déclencheur et un résultat. |
© 2026 RODCO — www.rodco.fr
En résumé
| Principe | Ce qu'il impose |
| Événement, opération, résultat | Trois éléments, dans cet ordre, et un résultat qui devient souvent l'événement suivant. |
| Toute opération a une entrée et une sortie | Une opération isolée signale une erreur de modélisation. |
| La synchronisation dit ce qu'il faut réunir | ET ou OU, posé au-dessus de l'opération. |
| La règle d'émission dit ce qui en sort | Elle explicite les règles de gestion, ou porte la mention « toujours ». |
| Les acteurs révèlent la coordination | Chaque changement de colonne est un point de rupture potentiel. |
| Le schéma décrit le réel | Modéliser la procédure théorique prive l'exercice de tout intérêt. |
© 2026 RODCO — www.rodco.fr
