ISO 29481-1:2025
(Main)Building information models — Information delivery manual — Part 1: Methodology and format
Building information models — Information delivery manual — Part 1: Methodology and format
This document prescribes: — how to document a use case with an associated business context and exchange requirements; — a methodology to identify and specify the information exchanges required at identified times during the life cycle of assets. This document presents the information delivery manual (IDM) in natural language terms to facilitate interoperability between software applications used during all phases of the life cycle of assets (both buildings and infrastructure). It promotes digital collaboration between actors within the identified business context and provides a basis for accurate, reliable, repeatable and high-quality information exchange. The information delivery manual (IDM) methodology specified in this document can be applied to any information management trigger event to identify the details of the information required to be exchanged.
Modèles des informations de la construction — Protocole d’échange d’informations — Partie 1: Méthodologie et format
Le présent document prescrit les éléments suivants: — la marche à suivre pour documenter un cas d’usage auquel sont associés un contexte métier et des exigences d’échange; — une méthodologie pour identifier et spécifier les échanges d’informations requis à des moments déterminés du cycle de vie des actifs. Le présent document présente le protocole d’échange d’informations (IDM) en langage naturel afin de faciliter l’interopérabilité entre les applications logicielles durant toutes les phases du cycle de vie des actifs (aussi bien les bâtiments que les infrastructures). Il favorise la collaboration numérique entre les acteurs du contexte métier identifié et fournit une base pour un échange d’informations précis, fiable, reproductible et de haute qualité. Cette méthodologie de protocole d’échange d’informations (IDM) spécifiée dans le présent document peut être appliquée à tout événement déclencheur de la gestion de l’information afin d’identifier les détails des informations requises pour l’échange.
General Information
Relations
Standards Content (Sample)
International
Standard
ISO 29481-1
Third edition
Building information models —
2025-11
Information delivery manual —
Part 1:
Methodology and format
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 1: Méthodologie et format
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 General .1
3.2 Information organization and management .2
3.3 Information delivery .3
3.4 Interaction within organizations .4
4 Information delivery manual . 4
4.1 General .4
4.2 General requirements of an IDM .4
4.3 Users of this document .5
4.4 Use case .5
4.5 Business context .6
4.5.1 General .6
4.5.2 Process maps .7
4.5.3 Interaction maps .7
4.6 Exchange requirements .8
4.7 Information delivery .8
5 IDM framework. 8
5.1 General .8
5.2 Common metadata for all IDM components .9
5.3 Use case specification.10
5.3.1 General .10
5.3.2 Standard project phases .10
5.3.3 Local project phases .11
5.4 Business context .11
5.5 Exchange requirement . 12
5.5.1 General . 12
5.5.2 Information units . 12
5.5.3 Information constraints . 12
6 Aspects of technical implementation .13
6.1 General . 13
6.2 Interaction framework . 13
6.3 Exchange view definition . 13
Annex A (informative) IDM development guidelines .15
Annex B (informative) A simplified example of an IDM document .20
Annex C (informative) IDM use of BPMN methods .21
Annex D (informative) IDM use of interaction map symbols .25
Bibliography .31
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization and digitization of information about buildings and civil engineering
works, including building information modelling (BIM), in collaboration with the European Committee
for Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This third edition cancels and replaces the second edition (ISO 29481-1:2016), which has been technically
revised.
The main changes are as follows:
— updated the text to cover infrastructure assets as well as buildings;
— aligned terminology with other related standards;
— significantly revised the text and annexes to improve readability and clarity.
A list of all parts in the ISO 29481 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
This document specifies the format used to present the exchange requirements for a use case and its
associated business processes. This is referred to as an information delivery manual (IDM) since it precisely
defines the “information delivery” requirements of the use case, recording those using natural language in
a “manual” that can be understood by all stakeholders. An IDM consists of three components: the use case
description, the business context and specified exchange requirements.
IDMs can be used to solve commonplace problems associated with communication between different parties
in project teams or asset management teams by ensuring the clarity of and responsibility for information.
An IDM helps all parties get the full benefits from any information model by understanding how the
information will be used. If the required information is delivered in a reliable format to support different
purposes across the life of an asset and the quality of the information is satisfactory, then the use cases and
associated business processes will be greatly improved.
This document provides a methodology that begins by identifying a use case, then defines the business
context and its associated business processes using recommended mapping techniques to finally arrive at a
detailed specification of the required exchange requirements between parties at specific times during those
business processes.
This IDM methodology has been developed specifically for the built environment sector concerned with all
aspects of the delivery and management of assets. These activities can be both contractual (associated with
any aspect of asset delivery) and non-contractual (such as regulatory compliance) between all stakeholders
within the built environment sector and across the whole asset life cycle.
IDM development can be streamlined in various ways as described in Annex A.
This document also includes a brief overview of technical implementations of IDMs to support solutions
provided by software developers, and how an IDM can be configured to meet national, local and project needs.
It is often assumed that information delivery would be achieved using an information model – represented
using industry foundation classes (IFC) – and conforming to an information delivery specification to
satisfy the exchange requirements. This document significantly broadens that assumption to include any
information formats that can satisfy (in whole or in part) the exchange requirements for a given business
process.
Additional standards have been published in support of information management and building information
modelling. Figure 1 shows the position of this document within the context of those other standards.
The ISO 19650 series set out general concepts and principles for information management throughout
the whole asset life cycle, as well as specific requirements to manage information during project delivery
or asset management. It also specifies an approach for achieving information security in a collaborative
working environment and sets out criteria to be used to assess the quality of information deliverables.
The ISO 19650 series and the ISO 29481 series use the same terminology wherever possible. The IDM
specification in this document is the appropriate way to record the relationships between types of actors
that fulfil the party roles named in the ISO 19650 series and sets out the detailed information that one type
of organization requires from another.
The exchange requirements defined in an IDM specify in detail the information that is required but does this
in terms of generic actor types (e.g. what a client requires from a designer for a given business process). This
is different to the exchange information requirement described in the ISO 19650 series: it is specific to a
given appointment (e.g. what the client for project XYZ requires from their designer on that project) and the
information may be defined in whatever level of detail is deemed appropriate. This means it is possible for
one exchange information requirement to correlate to multiple exchange requirements.
The business context established as part of an IDM can also help define the information management
resources used in the ISO 19650 series, such as the information standard and the information production
methods and procedures. An IDM can be considered as a toolkit for information managers to identify what
v
information should be received or sent, the actors involved, how that information flows, for what purpose
and the milestones for pre-defined use cases.
Figure 1 — Relationships between ISO 29481-1 and other relevant standards
Working anticlockwise from the top-left in Figure 1, ISO 12911 defines a systematic approach for developing
information management documents as structured specifications to support the automated checking of
expected outcomes. The IDM specification in this document can be used to provide content for ISO 12911.
The ISO 21597 series specify the use of linked data techniques to create a collection of structured
information models and associated datasets with explicit relationship links between elements in the
separate documents, all contained in a single archive format. It provides a way of packaging information
deliverables in a consolidated container to support information exchange.
ISO 7817-1 provides an overview of the level of information need. This concept is introduced in the ISO 19650
series as the way for a project client or asset owner to indicate the quantity and nature of information
expected in response to any given information requirement. Level of information need provides a more
comprehensive way of defining information units that form part of an exchange requirement that is specified
in an IDM.
ISO 16739-1 provides a way to create a semantically precise representation of real-world assets, resulting in
a very effective way of delivering information that satisfies the exchange requirements as specified in this
document.
ISO 12006-3 provides a specification for a taxonomy in any domain of interest, allowing terms used to
denote information units in an IDM to be structured and mapped to other terms.
ISO 29481-3 defines a specification to store, exchange and read IDM specifications that conform to this
document in a standardized machine-readable way. ISO 29481-2 and ISO 19510, shown in the top-right
corner of Figure 1, specify the two alternative modelling techniques used to represent a business context
map that conforms to this document.
In summary, this document provides a basis for reliable information exchange and sharing so that users
can be confident that the information they are receiving is accurate and sufficient for the tasks they must
perform. The development of this document has been driven by the need for reliability in information
exchange between parties in any business context.
vi
International Standard ISO 29481-1:2025(en)
Building information models — Information delivery
manual —
Part 1:
Methodology and format
1 Scope
This document prescribes:
— how to document a use case with an associated business context and exchange requirements;
— a methodology to identify and specify the information exchanges required at identified times during the
life cycle of assets.
This document presents the information delivery manual (IDM) in natural language terms to facilitate
interoperability between software applications used during all phases of the life cycle of assets (both
buildings and infrastructure). It promotes digital collaboration between actors within the identified business
context and provides a basis for accurate, reliable, repeatable and high-quality information exchange.
The information delivery manual (IDM) methodology specified in this document can be applied to any
information management trigger event to identify the details of the information required to be exchanged.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 6707-1, Buildings and civil engineering works — Vocabulary — Part 1: General terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 6707-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp.
— IEC Electropedia: available at https:// www .electropedia .org/ .
3.1 General
3.1.1
actor
person, organization or organizational unit involved in a business process (3.3.4)
Note 1 to entry: Organizational units include, but are not limited to, departments, teams.
3.1.2
role
functions being performed by an actor (3.1.1) at a point in time
Note 1 to entry: The role of an actor is determined by action and outcome and not necessarily by the profession or
trade followed by the actor.
3.1.3
asset
item, thing or entity that has potential or actual value to an organization
[SOURCE: ISO 55000:2024, 3.1.1, modified — Notes to entry have been removed.]
3.1.4
metadata
data about data or data elements
[SOURCE: ISO/IEC 2382:2015, 2121505, modified — "possibly including their data descriptions, and data
about data ownership, access paths, access rights and data volatility" has been removed; notes to entry have
been removed.]
3.1.5
schema
formal description of a data model (3.1.6)
Note 1 to entry: A schema is specified with properties, structure and interrelationships.
[SOURCE: ISO 19101-1:2014, 4.1.34, modified — The word "data" has been added; note 1 to entry has been added.]
3.1.6
data model
graphical, lexical or combined representation of data
Note 1 to entry: Data model is described with schema (3.1.5).
[SOURCE: ISO/IEC 11179-1:2023, 3.2.24, modified — The words "specifying their properties, structure, and
interrelationships" have been removed; note 1 to entry has been added.]
3.2 Information organization and management
3.2.1
information model
set of structured and unstructured information containers (3.2.2)
[SOURCE: ISO 19650-1:2018, 3.3.8]
3.2.2
information container
named persistent set of information retrievable from within a file, system or application storage hierarchy
[SOURCE: ISO 19650-1:2018, 3.3.12, modified — EXAMPLE and notes to entry have been removed.]
3.2.3
exchange view definition
EVD
computer-interpretable representation of one or more data models (3.1.6) or their parts, required to fulfil
the exchange requirement (3.3.10)
Note 1 to entry: This term is adopted in this document to avoid confusion. For example, with the concept of a model
view definition (MVD) that is currently used specifically in the construction industry to define a view of all or part of
a building information model (3.2.1) held in IFC as specified in ISO 16739-1.
3.3 Information delivery
3.3.1
information delivery manual
IDM
specification of a use case (3.3.2) using business context (3.3.3) maps and exchange requirements (3.3.10)
Note 1 to entry: Use case, context maps, and exchange requirements can be collectively referred to as IDM components.
3.3.2
use case
UC
description of a business context (3.3.3) by defining a sequence of actions performed by one or more roles
(3.1.2) to realize a purpose.
Note 1 to entry: A use case specifies the scope of the context.
[SOURCE: ISO 24014-1:2021, 3.36, modified - the word "process" has been changed to "business context",
because a use case can encompass several business processes; the word "actor" has been replaced with
"role"; the phrase "and by the system itself" has been replaced with "to realize a purpose"; note 1 to entry
has been added.]
3.3.3
business context
environment in which actors (3.1.1) undertake business processes (3.3.4)
Note 1 to entry: Such an environment includes all the roles (3.1.2), activities, and interactions (3.4.2), products and
services under the actor's control.
3.3.4
business process
set of interrelated or interacting activities that use inputs to deliver an intended result
EXAMPLE Agreements, systems, services, or products.
Note 1 to entry: A business process always contains one or more transactions (3.4.3).
[SOURCE: ISO 9000:2015, 3.4.1, modified — EXAMPLE has been added; notes to entry have been replaced
with a new note to entry.]
3.3.5
business context map
graphical representation of the information flows related to a context
EXAMPLE Interaction maps (3.3.7) and process maps (3.3.6).
3.3.6
process map
PM
context map of the activities related to a use case (3.3.2)
3.3.7
interaction map
context map of the interactions (3.4.2) related to a use case (3.3.2)
3.3.8
information exchange
act of satisfying an information requirement (3.3.9) or part thereof
[SOURCE: ISO 7817-1:2024, 3.3, modified — The part of speech "verb" has been removed.]
3.3.9
information requirement
specification for what, when and for whom information is to be produced
Note 1 to entry: The specification of "how information is to be produced" is part of level of information need.
[SOURCE: ISO 19650-1:2018, 3.3.2, modified — The word "how" has been removed; note 1 to entry has
been added.]
3.3.10
exchange requirement
ER
defined collection of information units (3.3.11) required to fulfil a use case (3.3.2)
3.3.11
information unit
description of a piece of information
EXAMPLE Inspection report, window identifier, room depth.
Note 1 to entry: Information units can refer to anything used as part fulfilment of an exchange requirement (3.3.10),
ranging from entire information containers (3.2.2) such as an "invitation to bid" or an asset (3.1.3) model, to specific
information items such as the properties of objects or the components that make up an object.
3.4 Interaction within organizations
3.4.1
interaction framework
XML file for the elements of an interaction (3.4.2)
Note 1 to entry: Elements of an interaction include roles (3.1.2), transactions (3.4.3), messages, and information units
(3.3.11).
3.4.2
interaction
communicative action between two roles (3.1.2)
3.4.3
transaction
sequence of interactions (3.4.2) involving the exchange of information using messages
EXAMPLE Processing of a request by one role (3.1.2) on behalf of another.
Note 1 to entry: A transaction is a message between the initiator and the executor.
4 Information delivery manual
4.1 General
This clause specifies the general requirements of an IDM as well as the concepts and principles that inform
the development of its three main components: a defined use case, a description of the business context
and the specification of the exchange requirements. The IDM methodology presented in this document may
be followed to develop an IDM from first principles, but that work may also be streamlined as described in
the Annex A if the prescribed components of the IDM are provided as described in this document and the
information specifications are able to be made relevant to local working practices.
4.2 General requirements of an IDM
An IDM shall deliver the following as a minimum:
— a description of the use case addressed by the IDM;
— a description of the need for information exchange within the business context;
— the identity of the actors involved in any information exchange;
— a definition and description of the activities or interactions where information is created, used or
exchanged between actors to deliver a service or produce an end product;
— definitions, specifications and descriptions that can be understood;
— detailed specifications of exchange requirements including the identification of relevant objects within
structured information containers.
Further details for specifying an IDM are given in Clause 5. Guidance for development of content and the
approach to follow is given in Annex A.
4.3 Users of this document
The main users are expected to be IDM developers who consider a specific use case, employ a discovery
process or other means to define the corresponding business context, and specify exchange requirements
using knowledge elicited from end users.
More broadly, users of this document may include the following:
— software solution providers wishing to specify the requirements for information and communication
support in software applications;
— information users, i.e. executive users and end users, concerned with producing information in accordance
with the IDM to support their business processes.
It follows that a wider group of users are those who take note of the detailed specifications of the information
that an actor fulfilling a particular role are required to provide at a particular point within a business
process. Such users include the following:
— project manager, responsible for organizing the business process and ensuring that the information
exchange is appropriately managed;
— information model manager, making the necessary arrangements to support an exchange requirement;
— client, who initiates the development of an IDM and includes it as a whole or in part in a contract;
— contractor or consultant, using the IDM to make the necessary arrangements to comply with the
expectations of the business process and associated information delivery;
— business manager, using an IDM as a template or standard to be applied in many projects within its
organization;
— construction organization, using an IDM for a specific project type as a template or standard to be applied
in the sector;
— asset manager, using an IDM to define exchange requirements associated with routine or reactive
maintenance of assets;
— asset operator, using an IDM to define exchange requirements associated with operational activities.
4.4 Use case
An IDM addresses a use case that shall be specified in accordance with Clause 5.
4.5 Business context
4.5.1 General
Figure 2 shows an example of a business context (represented here as an interaction map) that requires
an IDM: a client (role R1) engages (in a contractual transaction T1) a consultant (role R2) to deliver some
service. In such a use case, the following shall be documented:
— the collaborative and contractual aspects of their relationship;
— how information will be delivered within that business context.
The IDM describes that context as well as the required information associated with any transactions (both
ways) in that relationship. That information is held within an information model made up of information
containers.
If the service required of the consultant in that example is a complex one, then it may be necessary to initiate
further business processes to fulfil the requirement, leading to a more complex business context involving
several business processes, each having specific information delivery requirements.
Figure 2 — Example of a simple business context requiring an IDM
When developing an IDM from first principles for a given use case, the nature and context of the information
exchange shall be considered through a discovery process. There are two recommended ways of looking at
that, each with an associated business context mapping methodology.
— Process maps should be used where the focus is on the business processes (defined by activities executed
by actors with roles) that must be followed to deliver a service or produce an end product (such as a
design). In this case, the information that is the focus of the IDM is associated with a specific activity
within that business process.
— Interaction maps should be used where the focus is on the interactions (made up of a series of transactions)
between actors (with roles) who are to deliver a service or product, and the concern is to ensure that
agreed communication protocols are in place to ensure that the business goals are achieved. In this case,
the information that is the focus of the IDM is associated with a transaction.
These are complementary approaches, so within any given business context, it may be appropriate to
use both methodologies: a process map can be used to clarify the details of a transaction identified in an
interaction mapping exercise, while an interaction map can be used to rigorously understand an information
exchange defined in a process map.
4.5.2 and 4.5.3 describe these types of business context maps in greater detail.
4.5.2 Process maps
The process map considers the actor roles involved in the business processes associated with the business
context with a focus on the sequence of activities to be undertaken by those actors to support the use
case. Information exchanges are identified (giving rise to exchange requirements) where an activity to be
performed by one actor requires input from another actor.
A simple example of a process map is provided in the sample IDM referenced in Annex B.
The purpose of a process map is to describe the flow of activities within the boundary of a particular
business process, the roles played by the actors involved, together with the information required, consumed
and produced.
The approach recommended for representing process maps is the business process modelling notation
(BPMN, see the ISO 19510 series). Further guidance on using BPMN is given in Annex C.
Within an IDM, a process map:
— sets the boundary for the extent of the information contained within the business process;
— identifies all the actors involved, assigning each to a swim lane in the diagrammatic representation;
— establishes the activities within the business process;
— shows the logical sequence of the activities;
— supports the expansion of activities with more detailed process maps where appropriate.
The required information associated with a business context is determined by the contents of the exchange
requirements specified in the IDM.
4.5.3 Interaction maps
An interaction map is a visual representation of the scope, key roles (actors) and the essential moments of
interaction between roles in a business context. Instead of detailing the activities necessary for production
or service provision, the interaction map highlights the fundamental transactions – structured interactions
– in which actors exchange commitments and coordinate their work.
Each interaction involves a structured conversation between two roles, where a request or delivery of
a product or service is agreed. This structured interaction is referred to as a transaction. Each business
process is a chain of transactions, each with a defined initiator (the actor responsible for starting the
interaction) and an executor (the actor tasked with completing it).
In each transaction, any information exchanges for a specific purpose (e.g. a request for a change or
information delivery and the subsequent approval) are identified, governed by specific rules that dictate the
sequence of actions. For digital purposes these communicative information exchanges are translated into
messages with data forms and attachments that provide the required information to coordinate production
or service delivery.
Interaction maps, associated transactions and their message sequence are typically represented as unified
modelling language (UML) sequence diagrams. A simple example of an interaction map is provided in the
sample IDM referenced in Annex B.
The interaction map and associated transactions form the key components of an interaction framework.
ISO 29481-2 specifies a schema for a computer-interpretable interaction framework enabling digital IDM
communication for any defined business context. This facilitates (through available software) effective
management of the business context to ensure the integrity of any information exchanges and improve the
coordination of production and services.
Further guidance on using interaction maps is given in Annex D.
Within an IDM, an interaction map:
— sets the boundary for the extent of the information contained within the business context;
— identifies the actors, either initiators or executors, for each transaction;
— establishes the required interactions within the business process;
— defines the business cooperation and communication requirements allowing the contributions of
relevant roles to the information exchanges to be managed;
— supports the detailed expansion of the steps within a transaction to ensure reliable completion.
4.6 Exchange requirements
An exchange requirement represents the connection between process and data. It describes a set of
information that shall be developed and delivered by an actor to enable a downstream activity to be
performed by another actor. It shall be defined with a clear understanding of the information requirements
of the downstream actor.
4.7 Information delivery
The information delivered in response to defined information requirements is referred to as an information
model. This includes both structured information containers (including digital representations of physical
assets in the built environment) and unstructured ones such as digital images, drawings and text documents.
These may be exchanged as attachments to a digital message or, more commonly, shared as a URL link to one
or more information containers held in a shared repository. A set of related information containers may
be bundled together into a single file referred to as an information container for linked document delivery
(ICDD) as specified in the ISO 21597 series. In addition, information delivery may be facilitated by defining
queries against shared databases, whether held within an information model associated with the asset or
any accessible private or public database resource relevant to the identified information requirements.
Where an information model that relates to a specific asset is held in a shared repository, it is frequently set
up to include information that satisfies many use cases across the full life cycle of that asset. In that case, a
specific information exchange may only require a subset of the entire information model, typically specified
as an exchange view definition (EVD). The implementation of an EVD is further explained in 6.3.
5 IDM framework
5.1 General
An information delivery manual shall comprise the following as shown in Figure 3:
— a description of the addressed use case;
— an analysis of the business context associated with that use case;
— the required information to support the use case defined as one or more exchange requirements.
The business context may be represented in an IDM by any combination of interaction maps and process
maps as well as supporting descriptive text and tables. When working from first principles, the analysis of
the business context can be thought of as a discovery process using those two mapping approaches since
their purpose is to clearly show how the exchange requirements for the use case have been derived. Business
context maps shall be used as specified in 5.4.
The required information to support the use case shall be defined in one or more exchange requirements as
specified in 5.5.
Key
association
inheritance
aggregation
composition
Figure 3 — IDM basic framework
5.2 Common metadata for all IDM components
Each IDM component (use case, business context maps and exchange requirements) shall include common
metadata within a header as specified in this subclause. This is illustrated in Figure 4 for the use case
component.
The header shall provide at least the following administrative information:
— identifiers including a full title, a short title, and a globally unique identifier;
— authoring information, including authors, a change log that identifies both creation and any change made
together with the responsible author and date.
Examples of IDM components are provided in the sample IDM referenced in Annex B.
5.3 Use case specification
5.3.1 General
The use case description shall include the header information specified in 5.2 as well as a short overview in
the form of a descriptive summary of the contents and purpose of the IDM. In addition, each use case shall
state the aim, scope, uses, regional context of the IDM and the relevant standard project phases.
Figure 4 lists the information typically associated with a use case, including optional items that may be
included where appropriate.
NOTE Optional items are indicated by dashed boxes.
Figure 4 — Typical components of a use case
5.3.2 Standard project phases
Although some exchange requirements are applicable to the entire life cycle of a project, they are often
identified as relevant to particular phases within a project. This document adopts ISO 22263 – one of the
simplest project life cycle classification systems – as the basis for providing users of the IDM documents
with a common framework for easily searching for, using, and repurposing existing IDM documents related
to their projects. The ISO 22263 project phases and their descriptions are listed in Table 1.
Table 1 — Project phases in ISO 22263
ISO 22263
Description
project phase
Inception Establish the need for a project to satisfy the clients business requirement.
Identify potential solutions to the need and plan for feasibility.
Examine the feasibility of options and decide which of these should be considered for sub-
Brief
stantive feasibility.
Gain financial approval.
Identify major design elements based on the options presented.
Conceptual design and all deliverables ready for detailed planning approval.
Design
Fix all major design elements to allow the project to proceed.
Gain full financial approval for the project.
Finalize all major deliverables and proceed to construction.
Production Produce a product that satisfies all client requirements.
Handover the product as planned.
Maintenance Operate and maintain the product effectively and efficiently.
Decommission, dismantle and dispose of the components of the project and the project itself
Demolition
in accordance with environmental and health or safety rules.
5.3.3 Local project phases
The standard project phases may be mapped to project phases commonly used in the target regions. This
document refers to the regionally used project phases as local project phrases. Examples of local project
phase classification systems include the Royal Institute of British Architects (RIBA) Plan of Work in the UK
(s
...
Norme
internationale
ISO 29481-1
Troisième édition
Modèles des informations de la
2025-11
construction — Protocole d’échange
d’informations —
Partie 1:
Méthodologie et format
Building information models — Information delivery manual —
Part 1: Methodology and format
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2025
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
3.1 Généralités .2
3.2 Gestion et organisation des informations .2
3.3 Livraison d’informations .3
3.4 Interaction au sein des organisations .4
4 Protocole d’échange d’informations . 5
4.1 Généralités .5
4.2 Exigences générales d’un IDM .5
4.3 Utilisateurs du présent document .5
4.4 Cas d’usage .6
4.5 Contexte métier .6
4.5.1 Généralités .6
4.5.2 Cartes de processus .7
4.5.3 Cartes d’interaction .8
4.6 Exigences d’échange .9
4.7 Livraison d’informations .9
5 Cadre de l’IDM . 9
5.1 Généralités .9
5.2 Métadonnées communes à tous les composants IDM .10
5.3 Spécification du cas d’usage .11
5.3.1 Généralités .11
5.3.2 Phases de projet normalisées .11
5.3.3 Phases de projets locales . 12
5.4 Contexte métier . 12
5.5 Exigence d’échange . 13
5.5.1 Généralités . 13
5.5.2 Unités d’informations . 13
5.5.3 Contraintes d’information . 13
6 Aspects de l’implémentation technique . . 14
6.1 Généralités .14
6.2 Cadre d’interaction .14
6.3 Définition de vue d’échange .14
Annexe A (informative) Lignes directrices pour le développement de l’IDM .16
Annexe B (informative) Exemple simplifié de document IDM .21
Annexe C (informative) Utilisation par l’IDM des méthodes BPMN .22
Annexe D (informative) Utilisation par l’IDM des symboles de carte d’interaction.27
Bibliographie .33
iii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes nationaux
de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l’ISO participent également aux travaux. L’ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité
de tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait
pas reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application.
Toutefois, il y a lieu d’avertir les responsables de la mise en application du présent document que des
informations plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à
l’adresse www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels
droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l’ISO liés à l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de
l’ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 59, Bâtiments et ouvrages de génie
civil, sous-comité SC 13, Organisation et numérisation des informations relatives aux bâtiments et ouvrages
de génie civil, y compris modélisation des informations de la construction (BIM), en collaboration avec le
comité technique CEN/TC 442, Modélisation des informations de la construction (BIM) du Comité européen
de normalisation (CEN), conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord de
Vienne).
Cette troisième édition annule et remplace la deuxième édition (ISO 29481-1:2016), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— mise à jour du texte pour couvrir les actifs d’infrastructure ainsi que les bâtiments;
— alignement de la terminologie avec les normes collatérales;
— révision significative du texte et des annexes afin d’améliorer la lisibilité et la clarté.
Une liste de toutes les parties de la série ISO 29481 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/fr/members.html.
iv
Introduction
Le présent document spécifie le format utilisé pour présenter les exigences d’échange pour un cas d’usage
donné ainsi que les processus métier qui y sont associés. Cette démarche est appelée «protocole d’échange
d’informations» (IDM), car elle définit précisément les exigences en matière de «livraison d’informations» du
cas d’usage, en consignant celles-ci en langage naturel dans un «protocole» pouvant être compris par toutes
les parties prenantes. Un IDM est constitué de trois composants: la description du cas d’usage, le contexte
métier et les exigences d’échange spécifiées.
Les IDM peuvent être utilisés pour résoudre des problèmes courants liés à la communication entre les
différentes parties au sein des équipes de projet ou des équipes de gestion d’actifs en garantissant la clarté
des informations et la responsabilité à leur égard. Un IDM permet à toutes les parties de tirer pleinement
profit de tout modèle d’information en comprenant comment les informations sont utilisées. Si les
informations requises sont livrées dans un format fiable pour permettre la réalisation de différents objectifs
tout au long de la vie d’un actif et si leur qualité est satisfaisante, cela permet d’améliorer considérablement
les cas d’usage et les processus métier qui y sont associés.
Le présent document fournit une méthodologie qui commence en identifiant un cas d’usage, puis définit
le contexte métier et ses processus métier associés à l’aide de techniques recommandées de mise en
correspondance pour finalement aboutir à une spécification détaillée des exigences d’échange requises
entre les parties à des moments spécifiques de ces processus métier.
La méthodologie IDM été élaborée spécifiquement pour le secteur de l’environnement bâti concerné par tous
les aspects de la réalisation et de la gestion des actifs. Ces activités peuvent être à la fois contractuelles
(associé à tout aspect de la réalisation d’actifs) et non contractuelles (comme la conformité réglementaire)
entre toutes les parties prenantes du secteur de l’environnement bâti et tout au long du cycle de vie de l’actif.
Le développement d’un IDM peut être rationalisé de différentes manières, comme décrit dans l’Annexe A.
Le présent document inclut également un aperçu des implémentations techniques des IDM pour prendre
en charge les solutions fournies par les développeurs de logiciels et de la manière dont un IDM peut être
configuré pour répondre à des besoins nationaux, locaux et par projet.
Il est souvent supposé que la livraison d’informations est réalisée en utilisant un modèle d’informations,
représenté à l’aide de classes de fondation d’industrie (IFC), et de façon conforme à une spécification de
transmission d’informations afin de satisfaire aux exigences d’échange. Le présent document élargit
considérablement cette hypothèse pour inclure tous les formats d’information qui peuvent satisfaire (en tout
ou partie) aux exigences d’échange d’un processus métier donné.
Des normes complémentaires ont été publiées afin de faciliter la gestion des informations et la modélisation
des informations de construction. La Figure 1 indique la position du présent document dans le contexte de
ces autres normes.
La série de normes ISO 19650 définit des concepts et des principes généraux pour la gestion de l’information
tout au long du cycle de vie des actifs, ainsi que des exigences spécifiques en matière de processus métier
pour gérer les informations dans le cadre de la réalisation d’un projet ou de la gestion d’actifs. Elle spécifie
également une approche pour assurer la sécurité de l’information dans un environnement de travail
collaboratif et définit les critères à utiliser pour évaluer la qualité des livrables d’informations.
Les normes des séries ISO 19650 et ISO 29481 utilisent la même terminologie dans la mesure du possible.
La spécification IDM décrite dans le présent document représente le moyen approprié de consigner les
relations entre les types d’acteurs qui assument les rôles des parties citées dans la série de normes ISO 19650
et de définir les informations détaillées qu’un type d’organisation exige d’un autre.
Les exigences d’échange définies dans un IDM spécifient en détail les informations requises, mais en se
référant à des types d’acteurs génériques (par exemple, ce qu’un maître d’ouvrage exige d’un architecte pour
un processus métier donné). Celles-ci diffèrent de l’exigence d’échange d’informations décrite dans la série
de normes ISO 19650, qui est spécifique à une désignation donnée (par exemple, ce que le maître d’ouvrage
d’un projet XYZ exige de son architecte pour ce projet), où les informations peuvent être définies à tout
v
niveau de détail jugé approprié. Cela signifie qu’il est possible qu’une exigence d’échange d’informations soit
en corrélation avec plusieurs autres exigences d’échange.
Le contexte métier établi dans le cadre d’un IDM peut également aider à définir les ressources de gestion de
l’information utilisées dans la série ISO 19650, telles que la norme d’information et les méthodes et modes
opératoires de production d’informations. Il est possible de considérer un IDM comme un ensemble d’outils
permettant aux gestionnaires de l’information d’identifier les informations qu’il convient de recevoir ou
d’envoyer, les acteurs impliqués, la manière dont ces informations circulent, le but recherché et les étapes
importantes pour les cas d’usage prédéfinis.
Figure 1 — Relations entre l’ISO 29481-1 et les autres normes pertinentes
En partant du coin supérieur gauche de la Figure 1 et en procédant dans le sens inverse des aiguilles
d’une montre, l’ISO 12911 définit une approche systématique pour élaborer des documents de gestion
de l’information sous forme de spécifications structurées afin de faciliter la vérification automatisée des
résultats attendus. La spécification IDM dans le présent document peut être utilisée pour fournir des
contenus pour l’ISO 12911.
La série ISO 21597 spécifie l’utilisation de techniques de données liées pour créer une collection de modèles
d’information structurés et d’ensembles de données associés avec des liens de relation explicites entre des
éléments dans des documents séparés, le tout contenu dans un format unique d’archive. Elle permet de
regrouper les livrables d’informations dans un conteneur consolidé afin de faciliter l’échange d’informations.
L’ISO 7817-1 fournit une vue d’ensemble du niveau du besoin d’information. Ce concept a été introduit dans la
série de normes ISO 19650 comme le moyen pour un maître d’ouvrage d’un projet ou un propriétaire d’actifs
d’indiquer la quantité et la nature des informations attendues en réponse à des exigences d’informations
données. Le niveau du besoin d’information fournit une manière plus compréhensible pour définir les unités
d’informations qui composent une partie de l’exigence d’échange définie dans l’IDM.
L’ISO 16739-1 permet de créer une représentation sémantiquement précise des actifs du monde réel,
offrant ainsi un moyen très efficace d’assurer la livraison d’informations qui satisfont aux exigences
d’échange spécifiées dans le présent document.
L’ISO 12006-3 fournit la spécification d’une taxinomie dans n’importe quel domaine d’intérêt, permettant
de structurer les termes utilisés pour désigner les unités d’informations dans un IDM et de les mettre en
correspondance avec d’autres termes.
vi
L’ISO 29481-3 définit une spécification ayant pour objectif d’échanger et de lire des spécifications IDM
conformes au présent document d’une manière normalisée et lisible par un ordinateur. L’ISO 29481-2 et
l’ISO 19510, indiquées dans le coin supérieur droit de la Figure 1, spécifient les deux autres techniques de
modélisation utilisées pour représenter une carte de contexte métier conforme au présent document.
En bref, le présent document fournit une base pour un échange et un partage d’informations fiable afin que
les utilisateurs puissent être sûrs que les informations qu’ils reçoivent sont exactes et suffisantes pour les
tâches qu’ils doivent réaliser. L’élaboration du présent document a été motivée par le besoin de fiabilité dans
l’échange d’informations entre les parties, quel que soit le contexte métier.
vii
Norme internationale ISO 29481-1:2025(fr)
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 1:
Méthodologie et format
1 Domaine d’application
Le présent document prescrit les éléments suivants:
— la marche à suivre pour documenter un cas d’usage auquel sont associés un contexte métier et des
exigences d’échange;
— une méthodologie pour identifier et spécifier les échanges d’informations requis à des moments
déterminés du cycle de vie des actifs.
Le présent document présente le protocole d’échange d’informations (IDM) en langage naturel afin de
faciliter l’interopérabilité entre les applications logicielles durant toutes les phases du cycle de vie des actifs
(aussi bien les bâtiments que les infrastructures). Il favorise la collaboration numérique entre les acteurs du
contexte métier identifié et fournit une base pour un échange d’informations précis, fiable, reproductible et
de haute qualité.
Cette méthodologie de protocole d’échange d’informations (IDM) spécifiée dans le présent document peut
être appliquée à tout événement déclencheur de la gestion de l’information afin d’identifier les détails des
informations requises pour l’échange.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour
les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 6707-1, Bâtiments et ouvrages de génie civil — Vocabulaire — Partie 1: Termes généraux
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l’ISO 6707-1 ainsi que les suivants
s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1 Généralités
3.1.1
acteur
personne, organisation ou unité d’organisation impliquée dans un processus métier (3.3.4)
Note 1 à l'article: Les unités d’organisation comprennent, sans toutefois s’y limiter, les services et les équipes.
3.1.2
rôle
fonctions exécutées par un acteur (3.1.1) à un moment
Note 1 à l'article: Le rôle d’un acteur est déterminé par l’action et le résultat et pas nécessairement par la profession ou
le métier exercé par l’acteur.
3.1.3
actif
bien, chose ou entité qui a une valeur potentielle ou réelle pour une organisation
[SOURCE: ISO 55000:2024, 3.1.1, modifié — Les notes à l’article ont été supprimées et, dans la version
française, «un organisme» a été remplacé par «une organisation» par souci de cohérence avec la
série ISO 19650 et les autres parties de la série ISO 29481.]
3.1.4
métadonnées
donnée relative à des données ou à des éléments de données
[SOURCE: ISO/IEC 2382:2015, 2121505, modifié — «y compris éventuellement leurs descriptions, ainsi que
les données relatives à la propriété des données, aux chemins d’accès, aux droits d’accès et à la volatilité des
données.» a été supprimé; les Notes à l’article ont été supprimées.]
3.1.5
schéma
description formelle d’un modèle de données (3.1.6)
Note 1 à l'article: Un schéma est spécifié avec des propriétés, une structure et des interrelations.
[SOURCE: ISO 19101-1:2014, 4.1.34, modifié — Le terme «données» a été ajouté; la Note 1 à l’article a été
ajoutée.]
3.1.6
modèle de données
représentation graphique, lexicale ou combinée de données
Note 1 à l'article: Le modèle de données est décrit par un schéma (3.1.5)
[SOURCE: ISO/IEC 11179-1:2023, 3.2.24, modifié — L’expression «spécifiant leurs propriétés, structures et
interrelations» a été supprimée; la Note 1 à l’article a été ajoutée.]
3.2 Gestion et organisation des informations
3.2.1
modèle d’informations
ensemble de conteneurs d’informations structurés et non structurés (3.2.2)
[SOURCE: ISO 19650-1:2018, 3.3.8]
3.2.2
conteneur d’informations
ensemble nommé persistant d’informations récupérables au sein d’une hiérarchie de stockage de fichier,
de système ou d’application
[SOURCE: ISO 19650-1:2018, 3.3.12, modifié — L’EXEMPLE et les notes à l’article ont été supprimés.]
3.2.3
définition de vue d’échange
EVD
représentation interprétable par ordinateur d’un ou plusieurs modèles de données (3.1.6) ou de leurs parties,
qui doit satisfaire à l’exigence d’échange (3.3.10)
Note 1 à l'article: Ce terme est adopté dans le présent document pour éviter toute confusion. Par exemple, avec le
concept d’une définition de vue de modèle (MVD) qui est actuellement utilisée spécifiquement dans le secteur de la
construction pour définir une vue de l’ensemble ou d’une partie d’un modèle d’informations sur le bâtiment (3.2.1)
contenu dans l’IFC, comme spécifié dans l’ISO 16739-1.
3.3 Livraison d’informations
3.3.1
protocole d’échange d’informations
IDM
spécification d’un cas d’usage (3.3.2) à l’aide de cartes de contexte métier (3.3.3) et d’exigences d’échange
(3.3.10)
Note 1 à l'article: Le cas d’usage, les cartes de contexte et les exigences d’échange peuvent être collectivement appelés
«composants IDM».
3.3.2
cas d’usage
UC
description d’un contexte métier (3.3.3) en définissant une séquence d’actions effectuées par un ou plusieurs
rôles (3.1.2) dans le but de réaliser un objectif
Note 1 à l'article: Un cas d’usage spécifie le domaine d’application du contexte.
[SOURCE: ISO 24014-1:2021, 3.36, modifié — Le terme «processus» a été remplacé par «contexte métier»,
car un cas d’usage peut englober plusieurs processus métier; le terme «acteur» a été remplacé par «rôle»;
l’expression «et par le système lui-même» a été remplacée par «dans le but de réaliser un objectif»; la Note 1
à l’article a été ajoutée.]
3.3.3
contexte métier
environnement dans lequel des acteurs (3.1.1) mettent en œuvre des processus métier (3.3.4)
Note 1 à l'article: Ce type d’environnement comprend tous les rôles (3.1.2), activités, interactions (3.4.2), produits et
services sous le contrôle de l’acteur.
3.3.4
processus métier
ensemble d’activités corrélées ou en interaction qui utilise des éléments d’entrée pour produire un résultat
escompté
EXEMPLE Accords, systèmes, services ou produits.
Note 1 à l'article: Un processus métier contient toujours une ou plusieurs transactions (3.4.3).
[SOURCE: ISO 9000:2015, 3.4.1, modifié — L’EXEMPLE a été ajouté; les notes à l’article ont été remplacées
par une autre note à l’article.
3.3.5
carte de contexte métier
représentation graphique des flux d’informations liés à un contexte
EXEMPLE Cartes d’interaction (3.3.7) et cartes de processus (3.3.6).
3.3.6
carte de processus
PM
carte de contexte des activités associées à un cas d’usage (3.3.2)
3.3.7
carte d’interaction
carte de contexte des interactions (3.4.2) associées à un cas d’usage (3.3.2)
3.3.8
échange d’informations
action consistant à satisfaire une exigence d’information (3.3.9) ou l’une de ses parties
[SOURCE: ISO 7817-1:2024, 3.3, modifié — La forme verbale du terme a été supprimée.]
3.3.9
exigence d’information
spécification établissant l’information à produire, l’instant où elle doit l’être et son destinataire
Note 1 à l'article: La spécification de la «méthode de production des informations» est un élément du niveau du besoin
d’information.
[SOURCE: ISO 19650-1:2018, 3.3.2, modifié — Le terme «méthode» a été supprimé; la Note 1 à l’article a été
ajoutée.]
3.3.10
exigence d’échange
de la spécification
ensemble défini d’unités d’informations (3.3.11) nécessaires à la réalisation d’un cas d’usage (3.3.2)
3.3.11
unité d’informations
description d’un élément d’information
EXEMPLE Rapport d’inspection, identificateur de fenêtre, profondeur d’une pièce.
Note 1 à l'article: Les unités d’informations peuvent désigner tout élément utilisé pour satisfaire à une exigence d’échange
(3.3.10), allant de conteneurs d’informations (3.2.2) complets tels qu’un «appel d’offres» ou un modèle d’actif (3.1.3), à
des éléments d’information spécifiques tels que les propriétés d’objets ou les composants qui constituent un objet.
3.4 Interaction au sein des organisations
3.4.1
cadre d’interaction
fichier XML contenant les éléments d’une interaction (3.4.2)
Note 1 à l'article: Les éléments d’une interaction comprennent les rôles (3.1.2), les transactions (3.4.3), les messages et
les unités d’informations (3.3.11).
3.4.2
interaction
action de communication entre deux rôles (3.1.2)
3.4.3
transaction
séquence d’interactions (3.4.2) impliquant l’échange d’informations à l’aide de messages
EXEMPLE Traitement d’une demande par un rôle (3.1.2) pour le compte d’un autre.
Note 1 à l'article: Une transaction est un message entre l’initiateur et l’exécutant.
4 Protocole d’échange d’informations
4.1 Généralités
Le présent article spécifie les exigences générales d’un IDM ainsi que les concepts et principes qui guident
le développement de ses trois composants principaux: un cas d’usage défini, une description du contexte
métier et la spécification des exigences d’échange. La méthodologie IDM présentée dans le présent document
peut être suivie pour développer un IDM à partir de principes de base, mais ce travail peut également être
simplifié comme décrit dans l’Annexe A si les composants prescrits de l’IDM sont fournis comme décrits
dans le présent document et que les spécifications d’informations peuvent être adaptées aux pratiques de
travail locales.
4.2 Exigences générales d’un IDM
Un IDM doit au minimum fournir les éléments suivants:
— une description du cas d’usage traité par l’IDM;
— une description du besoin d’échange d’informations dans le contexte métier;
— l’identité des acteurs impliqués dans tout échange d’informations;
— une définition et une description des activités ou interactions au cours desquelles des informations sont
créées, utilisées ou échangées entre les acteurs pour fournir un service ou produire un produit fini;
— les définitions, spécifications et descriptions compréhensibles;
— les spécifications détaillées des exigences d’échange, y compris l’identification des objets pertinents
dans les conteneurs d’informations structurés.
De plus amples détails pour spécifier un IDM sont donnés à l’Article 5. Des recommandations pour le
développement de contenu ainsi que l’approche à suivre sont données à l’Annexe A.
4.3 Utilisateurs du présent document
Il est prévu que les principaux utilisateurs de ce document soient des développeurs d’IDM qui considèrent
un cas d’usage spécifique, emploient un processus de découverte ou d’autres moyens pour définir le contexte
métier correspondant et spécifient les exigences d’échange à l’aide des connaissances obtenues auprès des
utilisateurs finaux.
Plus généralement, les utilisateurs du présent document peuvent inclure:
— les fournisseurs de solutions logicielles souhaitant spécifier les exigences relatives aux supports
d’information et de communication dans les applications logicielles;
— les utilisateurs des informations, c’est-à-dire les utilisateurs exécutants et les utilisateurs finaux
concernés par la production d’informations conformément à l’IDM pour faciliter leurs processus métier.
S’ensuit un plus large groupe d’utilisateurs, composé des personnes qui prennent connaissance des
spécifications détaillées des informations qu’un acteur assumant un rôle particulier est amené à fournir à
un moment donné dans le cadre d’un processus métier. Ces utilisateurs comprennent:
— le responsable de projet, chargé d’organiser le processus métier et de garantir que l’échange d’informations
est géré correctement;
— le responsable des modèles d’informations, qui prend les mesures nécessaires pour supporter une
exigence d’échange;
— le client, qui initie le développement d’un IDM et l’inclut en tout ou partie dans un contrat;
— le sous-traitant ou le consultant, qui utilise l’IDM pour prendre les mesures nécessaires afin de se
conformer aux attentes du processus métier et de la livraison d’informations associée;
— le responsable métier, qui utilise un IDM comme modèle ou norme à appliquer à de nombreux projets au
sein de son organisation;
— l’organisation de construction, qui utilise un IDM pour un type de projet spécifique comme modèle ou
norme à appliquer au secteur;
— le gestionnaire d’actifs, qui utilise un IDM pour définir les exigences d’échange associées à la maintenance
régulière ou réactive des actifs;
— l’exploitant d’actifs, qui utilise un IDM pour définir les exigences d’échange associées aux activités
opérationnelles.
4.4 Cas d’usage
Un IDM traite un cas d’usage qui doit être spécifié conformément à l’Article 5.
4.5 Contexte métier
4.5.1 Généralités
La Figure 2 montre un exemple de contexte métier (représenté ici par une carte d’interaction) qui nécessite
un IDM: un client (rôle R1) engage (dans une transaction contractuelle T1) un consultant (rôle R2)
pour fournir un certain service. Dans ce cas d’usage, les éléments suivants doivent être documentés:
— les aspects collaboratifs et contractuels de leur relation;
— la manière dont les informations sont fournies dans ce contexte métier.
L’IDM décrit ce contexte ainsi que les informations requises associées à toute transaction (dans les deux
sens) dans le cadre de cette relation. Ces informations sont consignées dans un modèle d’informations
composé de conteneurs d’informations.
Si le service demandé au consultant dans cet exemple est complexe, il peut alors être nécessaire d’initier
d’autres processus métier pour satisfaire à l’exigence, aboutissant à un contexte métier plus complexe
qui implique plusieurs processus métier, chacun ayant des exigences spécifiques en matière de livraison
d’informations.
Figure 2 — Exemple de contexte métier simple nécessitant un IDM
Lors du développement d’un IDM à partir des principes de base pour un cas d’usage donné, la nature et le
contexte de l’échange d’informations doivent être pris en compte par le biais d’un processus de découverte.
Il existe deux moyens recommandés pour aborder cet aspect, chacun étant associé à une méthodologie de
mise en correspondance du contexte métier.
— Il convient d’utiliser les cartes de processus lorsque la priorité est accordée aux processus métier (définis
par des activités exécutées par des acteurs avec des rôles) qui doivent être suivis pour fournir un service
ou produire un produit final (par exemple, une conception). Dans ce cas, les informations qui font l’objet
de l’IDM sont associées à une activité spécifique au sein de ce processus métier.
— Il convient d’utiliser les cartes d’interaction lorsque la priorité est accordée aux interactions
(composées d’une série de transactions) entre les acteurs (avec des rôles) qui doivent fournir un service
ou un produit, et que l’enjeu est de s’assurer que les protocoles de communication convenus ont été mis
en place pour garantir que les objectifs métier sont atteints. Dans ce cas, les informations qui font l’objet
de l’IDM sont associées à une transaction.
Il s’agit d’approches complémentaires, c’est pourquoi il peut être approprié, dans un contexte métier donné,
d’utiliser les deux méthodologies: la carte de processus peut être utilisée pour clarifier les détails d’une
transaction identifiée lors d’un exercice de mise en correspondance d’interactions, tandis qu’une carte
d’interaction peut être utilisée pour comprendre avec rigueur un échange d’informations défini dans une
carte de processus.
Les paragraphes 4.5.2 et 4.5.3 décrivent plus en détail ces types de cartes de contexte métier.
4.5.2 Cartes de processus
La carte de processus prend en compte les rôles des acteurs impliqués dans les processus métier associés au
contexte métier en se concentrant sur la séquence d’activités que doivent effectuer ces acteurs à l’appui du
cas d’usage. Les échanges d’informations sont identifiés (donnant lieu à des exigences d’échange) lorsqu’une
activité devant être réalisée par un acteur nécessite la contribution d’un autre acteur.
Un exemple simple de carte de processus est fourni dans l’exemple d’IDM à l’Annexe B.
L’objet d’une carte de processus est de décrire le flux d’activités dans les limites d’un processus métier
particulier, les rôles joués par les acteurs impliqués ainsi que les informations requises, consommées et
produites.
L’approche recommandée pour représenter les cartes de processus est la notation de modélisation
des processus métier (Business Process Modelling Notation [BPMN], voir la série de normes ISO 19510).
Des recommandations supplémentaires relatives à l’utilisation de la BPMN sont données dans l’Annexe C.
Dans un IDM, une carte de processus:
— définit les limites de l’étendue des informations contenues dans le processus métier;
— identifie tous les acteurs impliqués, en attribuant à chacun un diagramme à couloirs;
— établit les activités liées au processus métier;
— représente la séquence logique des activités;
— soutient le développement des activités avec des cartes de processus plus détaillées, le cas échéant.
Les informations requises associées à un contexte métier sont déterminées par le contenu des exigences
d’échange spécifiées dans l’IDM.
4.5.3 Cartes d’interaction
Une carte d’interaction est une représentation visuelle du domaine d’application, des rôles clés (acteurs)
et des moments essentiels d’interaction entre ceux-ci dans un contexte métier. Plutôt que de détailler les
activités nécessaires à la production ou à la prestation de services, la carte d’interaction met en évidence les
transactions fondamentales (les interactions structurées) dans le cadre desquelles les acteurs échangent
des engagements et coordonnent leur travail.
Chaque interaction implique une conversation structurée entre deux rôles, au cours de laquelle une
demande ou la réalisation d’un produit ou d’un service est convenue. Cette interaction structurée est
appelée transaction. Chaque processus métier est une chaîne de transactions, chacune avec un initiateur
défini (l’acteur chargé d’initier l’interaction) et un exécutant (l’acteur chargé de l’exécuter).
Dans chaque transaction, tous les échanges d’informations pour un objectif spécifique (par exemple,
une demande de changement ou la livraison d’informations et l’approbation ultérieure) sont identifiés
et régis par des règles spécifiques qui dictent la séquence d’actions. À des fins numériques, ces échanges
d’informations de communication sont traduits en messages avec des formulaires de données et des pièces
jointes qui fournissent les informations requises pour coordonner la production ou la prestation de services.
Les cartes d’interaction, les transactions associées et leur séquence de messages sont généralement
représentées sous forme de diagrammes de séquences de langage de modélisation unifié (UML). Un exemple
simple de carte d’interaction est fourni dans l’exemple d’IDM à l’Annexe B.
La carte d’interaction et les transactions associées constituent les composants clés d’un cadre d’interaction.
L’ISO 29481-2 spécifie un schéma pour un cadre d’interaction interprétable par ordinateur permettant
une communication numérique de l’IDM pour tout contexte métier défini. Cela facilite (grâce aux logiciels
disponibles) une gestion efficace du contexte métier afin de garantir l’intégrité des échanges d’informations
et d’améliorer la coordination de la production et des services.
Des recommandations supplémentaires relatives à l’utilisation des cartes d’interaction sont données dans
l’Annexe D.
Dans un IDM, une carte d’interaction:
— définit les limites de l’étendue des informations contenues dans le contexte métier;
— identifie les acteurs, qu’ils soient initiateurs ou exécutants, pour chaque transaction;
— établit les interactions requises au sein du processus métier;
— définit les exigences de coopération et de communication métier, ce qui permet de gérer les contributions
des rôles pertinents aux échanges d’informations;
— soutient le développement détaillé des étapes d’une transaction afin d’en garantir la fiabilité.
4.6 Exigences d’échange
Une exigence d’échange représente la connexion entre le processus et les données. Elle décrit un ensemble
d’informations qui doivent être établies et fournies par un acteur pour permettre à un autre acteur de réaliser
une activité en aval. Elle doit être définie en ayant une bonne compréhension des exigences d’informations
de l’acteur en aval.
4.7 Livraison d’informations
Les informations livrées en réponse aux exigences d’information définies sont appelées modèle
d’informations. Cela inclut à la fois les conteneurs d’information structurés (y compris les représentations
numériques d’actifs physiques dans l’environnement bâti) et les conteneurs non structurés (tels que les
images numériques, les plans et les documents textuels). Ceux-ci peuvent être échangés sous forme de pièces
jointes à un message numérique ou, plus couramment, partagés sous la forme d’un lien URL renvoyant à
un ou plusieurs conteneurs d’informations stockés dans un référentiel partagé. Un ensemble de conteneurs
d’information associés peut être regroupé dans un seul fichier appelé «conteneur d’information pour la
livraison de documents liés» (ICDD), comme spécifié dans la série de normes ISO 21597. En outre, la livraison
des informations peut être facilitée par la définition de requêtes dans des bases de données partagées,
qu’elles soient stockées dans un modèle d’informations associé à l’actif ou dans toute ressource de base de
données privée ou publique accessible et pertinente pour les exigences d’information identifiées.
Lorsqu’un modèle d’informations lié à un actif spécifique est stocké dans un référentiel partagé, il est
généralement structuré de sorte à inclure des informations qui répondent à de nombreux cas d’usage tout au
long du cycle de vie de l’actif concerné. Dans ce cas
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.