IDEF / IGOE
IDEF0 est une notation de modélisation fonctionnelle publiée par le NIST comme standard fédéral américain. Elle dessine une fonction dans une boîte, et lui attache quatre classes de flèches sur quatre côtés: ce qu'elle consomme entre par la gauche, ce qui la contraint descend sur le dessus, ce qu'elle produit sort par la droite, ce qui l'exécute monte par le bas. Elle répond ainsi à deux questions qu'une notation de séquence laisse ouvertes, qu'est-ce qui gouverne cette fonction et qu'est-ce qui l'accomplit, et elle décompose la fonction en niveaux dont la numérotation reste traçable. La variante IGOE de Roger Burlton reprend la même géométrie sous des noms adaptés aux processus de service, et se dessine en une seule boîte comme diagramme de périmètre.
Objectif
La technique sert une décision de périmètre: ce qui tombe dans la fonction, ce qui reste dehors et à quel titre. Une loi, une directive, un logiciel, un prestataire y deviennent des objets du dessin, chacun à la place qui porte son rôle.
Les flèches portent des contraintes: « les flèches ne représentent ni flux ni séquence », dit FIPS 183, et la fonction qui les reçoit est contrainte par ce qui lui est rendu disponible. Le modèle achète la gouvernance et les ressources au prix du temps, l'ordre des étapes se lisant dans le logigramme ou dans BPMN. Le livrable va du diagramme de contexte A-0, une boîte unique qui porte le but et le point de vue du modèle, à la décomposition A0 et à l'index des nœuds.
Vous trouverez plus de détails dans notre tutoriel BPMN.
Usage
Quand l'utiliser
- Cadrage d'une fonction avant une refonte: une boîte, quatre côtés, et l'équipe s'accorde sur ce qui entre et ce qui sort.
- La question porte sur ce qui gouverne le travail: lois, règlements, politiques internes et contrats deviennent des objets dessinés.
- La question porte sur les ressources: personnes, systèmes et prestataires apparaissent sous la fonction.
- Vue fonctionnelle d'entreprise à décomposer: la numérotation des nœuds tient la traçabilité d'un niveau au suivant.
Quand ne pas l'utiliser
- La question est la séquence des étapes et les remises: aucun axe du temps ici, prendre le logigramme.
- Deux organisations échangent des messages, ou le modèle doit s'exécuter dans un moteur: prendre BPMN.
- La logique interne d'un cas d'utilisation à fixer, branches gardées et concurrence réelle: prendre le diagramme d'activités UML.
Description
La boîte et ses quatre côtés
La boîte est un rectangle à angles droits, en trait plein, nommé par un verbe actif: « Établir la paie mensuelle » est une fonction, « Paie » est un sujet, et le standard le refuse. Son numéro de boîte s'écrit à l'intérieur, dans le coin inférieur droit, de 1 à 6 et 0 sur le diagramme de contexte. Les étiquettes de flèches sont des locutions nominales.
Les quatre classes se définissent par ce que la fonction leur fait, et chacune tient à un côté. L'entrée arrive par la gauche et se fait transformer ou consommer. Le contrôle descend sur le dessus et spécifie les conditions requises pour que les sorties soient correctes. La sortie part à droite. Le mécanisme monte par le bas et soutient l'exécution. Tout se joue dans une question: la flèche est-elle consommée? Les heures saisies le sont par le calcul de la paie, donc elles entrent à gauche; le taux AVS survit à la paie et décide si le résultat est juste, donc il descend sur le dessus. Même forme sur la page, rôle opposé. La question range aussi les mécanismes: la fiduciaire exécute la fonction sans être consommée par elle, et la dessiner à gauche est une erreur.
ICOM et IGOE: deux jeux de noms, une seule géométrie
Deux vocabulaires circulent. ICOM (Input, Control, Output, Mechanism) est celui de FIPS 183, donc d'IDEF0, et c'est celui du BPM CBOK. IGOE (Input, Guide, Output, Enabler) est celui de Roger Burlton, qui a rebaptisé deux classes pour les processus de service: le guide décrit quand, pourquoi ou comment une activité s'exécute, l'enabler est la ressource requise pour transformer l'entrée en sortie. C'est le vocabulaire du BABOK. La géométrie reste identique, quatre côtés sous deux étiquettes changées; l'usage diffère, l'IGOE se dessinant en une seule boîte, le processus dans le périmètre, au début d'une refonte, quand IDEF0 décompose sur plusieurs niveaux.
Les règles qui portent le modèle
La règle la plus révélatrice du standard est la plus courte: toute boîte porte au moins un contrôle et au moins une sortie, les entrées et les mécanismes restant facultatifs. Une fonction qui ne consomme rien, reste gouvernée et produit quelque chose est une boîte légale. La géométrie se vérifie: trait plein, tracé horizontal ou vertical, coudes en arcs à 90 degrés, extrémités qui touchent le périmètre et s'attachent à un côté, jamais à un coin. Hors contexte, un diagramme compte de trois à six boîtes: en dessous, la boîte parente n'avait pas à être décomposée; au-dessus, le niveau est mal choisi et le dessin prend l'aspect encombré que le BPM CBOK relève comme le défaut des implémentations d'IDEF.
La hiérarchie se lit dans les numéros de nœuds, sans point décimal. Cette adresse rend la décomposition fonctionnelle traçable, et les codes ICOM la verrouillent: près de l'extrémité libre d'une flèche de bordure, C3 dit que cette flèche est le troisième contrôle, en partant de la gauche, qui entre dans la boîte parente. Le rôle d'une flèche est relatif à la fonction qui la reçoit, un contrôle du parent pouvant être une entrée chez l'enfant. Les contrôles ainsi rendus visibles sont les règles de gestion de l'organisation, dont le modèle donne l'inventaire que l'analyse des règles métier reprend.
- A-0Gérer la paie (diagramme de contexte, une seule boîte)
- A0Gérer la paie
- A1Établir la paie mensuelle
- A11Contrôler les heures saisies
- A12Calculer les cotisations et les retenues
- A13Éditer les fiches de salaire
- A2Verser les salaires
- A3Établir les décomptes annuels
- A1Établir la paie mensuelle
Conduire le modèle
- Fixer le but, le point de vue et le contexte, avant la première boîte. Il y a un seul point de vue par modèle: deux points de vue produisent deux diagrammes irréconciliables de la même fonction.
- Dessiner le diagramme de contexte A-0, une boîte unique couvrant le périmètre entier, avec les flèches qui la relient à son environnement. C'est en substance le diagramme de périmètre de Burlton et souvent le livrable entier d'un mandat.
- Décomposer en A0, en trois à six sous-fonctions majeures. Ce diagramme A0 est le sommet du modèle.
- Détailler chaque boîte: lister tout ce qui gravite autour de la fonction, classer par les quatre côtés, vérifier que la liste couvre l'intégralité de la boîte parente.
- Coder les flèches de bordure, ce qui verrouille la correspondance entre le diagramme enfant et sa boîte parente.
En atelier, le diagramme de périmètre se construit en une séance avec l'équipe de refonte: une boîte, et l'on balaie les quatre côtés. La discussion se durcit toujours sur les guides, parce que c'est là que l'organisation découvre qu'elle ne s'accorde pas sur les règles qui la lient.
Ce que la notation exprime
Un lecteur habitué aux trois autres notations de la modélisation des processus commence par chercher la séquence, et le diagramme lui donne l'inventaire de ce qui contraint la fonction et de ce qui l'exécute: une contrainte omet le comment et le quand, dit le titre d'une annexe du standard. La circulation de la donnée dans un système relève, elle, du diagramme de flux de données.
| Notation | Séquence ou périmètre? | Messages franchissant une frontière organisationnelle? | Événements typés? | Exécutable par un moteur? | Sémantique formelle? | Couloirs possibles? |
|---|---|---|---|---|---|---|
| Logigramme | séquence | non | non | non | non | oui |
| BPMN | séquence | oui | oui | oui | oui | oui |
| Diagramme d'activités UML | séquence | non | non | non | oui | oui |
| IDEF / IGOE | périmètre | non | non | non | oui | sans objet: ni couloirs, ni temps |
Considérations IA
Deux usages tiennent. Le classement: la liste brute d'un atelier, tout ce qui gravite autour de la fonction, se range en entrées, contrôles, sorties et mécanismes, ce qui donne à la séance une version à contester. La rédaction des contrôles candidats depuis les politiques, les règlements et les contrats, car c'est le côté que les équipes peuplent le plus mal.
Le test de consommation ne se délègue pas: savoir si une chose est transformée par la fonction ou si elle la gouverne demande de connaître la manière dont l'entreprise travaille, et le modèle repose sur cette distinction. Un modèle interrogé sur « les contraintes légales de la paie suisse » rendra des numéros d'articles et des taux plausibles, périmés ou faux, et chaque contrôle d'origine légale se vérifie contre sa source. Le but et le point de vue sont des décisions de parties prenantes.
Exemples
La fonction Établir la paie mensuelle d'une PME suisse, boîte A1 du modèle de paie. Chaque flèche appartient à une seule classe, que le test de consommation décide.
- Entrée (côté gauche): consommée par la fonction
- Contrôle (côté supérieur): contraint sans être consommé
- Sortie (côté droit): produite par la fonction
- Mécanisme (côté inférieur): exécute la fonction
Le côté supérieur est celui qu'il faut lire. Six contrôles y sont nommés, issus de quatre ordres: le droit fédéral pour le Code des obligations, les taux AVS/AI/APG et la LPP, une convention de branche pour la CCT, un barème cantonal pour l'impôt à la source, l'accord individuel pour le contrat de travail. Un logigramme, un modèle BPMN ou un diagramme d'activités UML de la même fonction dessineraient une boîte « calculer la paie » et renverraient ces six sources à un commentaire, quand elles sont exactement ce que l'analyse a pour tâche d'établir. Le côté inférieur fait le même effet sur les ressources: la fonction dépend d'un prestataire externe, la fiduciaire, et cette dépendance se lit comme un fait du modèle.
Visualisations
La géométrie est le contenu. Le côté par lequel une flèche entre est son rôle, de sorte qu'un mécanisme arrivant par le haut énoncerait une chose fausse et qu'une flèche accrochée à un coin n'énoncerait rien. Les quatre côtés se distinguent donc visuellement, puisque les quatre rôles sont tout le propos de la figure. Le but et le point de vue s'écrivent sous le diagramme, comme le standard le fait lui-même, où ils tiennent lieu de mode d'emploi. L'index des nœuds se donne en texte, et porte la hiérarchie que les diagrammes ne montrent qu'un niveau à la fois.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Le but, le point de vue et le contexte se fixent avant la première boîte. Le vrai travail préparatoire est de rassembler les sources qui deviendront des contrôles, lois, règlements, politiques, contrats, et de réunir les personnes qui les connaissent. |
| Exécution | Moyen | Un diagramme de périmètre à une boîte tient dans une séance facilitée, ce qui est bon marché. Une décomposition complète sur plusieurs niveaux est une série de séances, et chaque niveau ajoute la vérification de la correspondance avec son parent. |
| Documentation | Élevé | Le modèle est fait de diagrammes, de textes et d'un glossaire, et sa valeur tient à la cohérence de l'index des nœuds, des codes ICOM et des correspondances parent-enfant à mesure qu'il change. C'est ce coût d'entretien que le modèle fait payer. |
Outils
Le tableau blanc suffit pour le diagramme de périmètre, et cette économie est une propriété de la technique: une boîte et quatre côtés tiennent sur une feuille de flipchart, ce qui est la raison pour laquelle la variante IGOE fonctionne en atelier avec des gens qui ne dessinent jamais de modèles. Les outils de dessin généralistes, Visio, diagrams.net ou Lucidchart, portent des gabarits IDEF0 et produisent des diagrammes corrects; leur apport s'arrête au dessin, et la correspondance entre la flèche de bordure d'un enfant et l'arête de sa boîte parente ne subsiste alors que dans la tête de l'auteur.
Les ateliers de modélisation d'entreprise, ARIS ou Sparx Enterprise Architect, tiennent la hiérarchie, l'index des nœuds et les codes ICOM comme des objets d'un référentiel, et absorbent sans reprise le renommage ou le déplacement d'une fonction. L'investissement se justifie dès que le modèle dépasse deux niveaux, ou qu'il doit vivre plus longtemps que le mandat. Les règles du standard étant mécaniquement vérifiables, une capacité mérite d'être exigée de l'outil: refuser une boîte sans contrôle ni sortie et signaler une flèche de bordure sans code.
Sources
- NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0), 1993: le standard primaire, qui porte la syntaxe de la boîte et des flèches, les quatre classes ICOM et les règles du modèle.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: la notation IDEF et les diagrammes IGOE parmi les notations de modélisation des processus et l'usage de la technique pour l'établissement du périmètre.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.6 IDEF: le vocabulaire ICOM, le liage des processus à travers les niveaux de détail et le défaut reconnu des implémentations.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: les couloirs sont une addition notationnelle et non une notation distincte.
- Kathy A. Long, What is an IGOE?, Business Rules Journal, janvier 2012: les définitions d'input, guide, output et enabler, adaptées aux processus du secteur des services.
- Paul Harmon, Deming, IT, and BPM IDEF0 Diagrams, BPTrends: l'attribution de l'IGOE à Roger Burlton et son usage comme diagramme de périmètre.

