États du conteneur d’information ISO 19650 : guide complet sur WIP, Shared, Published et Archived

Quiconque travaille avec un CDE conforme à l’ISO 19650 se heurte tôt ou tard à une question apparemment banale : « dans quel état se trouve ce fichier ? ». La réponse n’est pas technique. Elle est normative, contractuelle, opérationnelle.

Les états du conteneur d’information sont les quatre phases du cycle de vie d’une information de projet définies par la norme ISO 19650 : 

• Travail en cours (Work in Progress (WIP)),
• Partagé (Shared),
• Publié (Published),
• Archivé (Archived).

Chaque état détermine qui peut voir, modifier et utiliser le conteneur d’information, avec des règles de transition tracées et autorisées.

Comprendre comment fonctionnent ces états est la clé pour transformer un CDE d’un simple archive en outil de gouvernance. Dans cet article, nous expliquons en détail ce que signifie chaque état, comment se déroulent les transitions et comment un CDE évolué gère opérationnellement ces étapes.

Si vous n’avez pas lu notre article introductif sur le CDE conforme à l’ISO 19650, nous vous conseillons de commencer par là : ici, nous entrons dans le détail opérationnel de l’un de ses aspects les plus techniques.

Le cycle de vie du conteneur d’information : quatre états, un processus

La norme ISO 19650-1 (§12) définit quatre états principaux que chaque conteneur d’information traverse au cours du projet. Il ne s’agit pas d’une séquence rigide : un conteneur peut revenir à des états précédents si des lacunes sont constatées, et tous les conteneurs n’arrivent pas à l’archivage en même temps.

Les états sont : 

• Work in Progress (WIP) – en cours de traitement au sein de l’équipe qui produit le contenu ;
• Shared – partagé avec d’autres équipes ou disciplines pour coordination ;
• Published (ou Published for use) – publié et approuvé pour l’utilisation contractuelle ;
• Archived – archivé comme référence historique.

Chaque état est caractérisé par quatre éléments : qui a accès au conteneur, ce que l’on peut faire, comment se déroule la transition vers l’état suivant, pourquoi le conteneur se trouve dans cette phase.

Le schéma général du cycle

La transition entre les états se fait par le processus CRA (Check, Review, Approve) – vérification, révision et approbation – réglementé par l’ISO 19650-2. Chaque transition laisse une trace dans l’audit trail du CDE.

Schéma général du cycle des états d’un CDE

État 1 — Work in Progress (WIP) : l’espace de travail de l’équipe

Le Work in Progress est l’état initial de chaque conteneur d’information. C’est l’espace dans lequel l’équipe qui produit le contenu – typiquement une Task Team dans la terminologie ISO 19650 – travaille librement sans exposer le matériel à d’autres.

Qui accède au WIP

Seuls les membres de la Task Team qui produit le conteneur d’information. D’autres disciplines, le client, le vérificateur, les autres équipes n’ont pas de visibilité sur le contenu en WIP.

Que peut-on faire

Dans le WIP, l’équipe maintient le plein contrôle opérationnel sur le conteneur d’information, avec la liberté de : 

• créer, modifier, supprimer des contenus librement ;
• tester des solutions, itérer, faire des erreurs ;
• collaborer en interne à l’équipe sans formalités ;
• associer des métadonnées préliminaires mais pas encore définitives.

Caractéristiques opérationnelles

Le WIP est le seul état dans lequel le conteneur d’information peut être supprimé (avant le partage formel). Une fois que le conteneur passe à Shared, chaque modification produit une nouvelle révision tracée.

Code de convenance typique

Le code de convenance associé est généralement S0 (État initial) ou équivalent, ce qui indique que le conteneur n’a pas encore été soumis à une vérification interne.

La transition vers Shared

Lorsque la Task Team estime que le conteneur est prêt à être partagé avec d’autres disciplines, elle lance le processus de check interne (auto-vérification technique). Ce n’est qu’après un check positif que le conteneur peut passer à Shared. Cette transition est généralement autorisée par le Task Team Manager ou par le BIM Coordinator.

État 2 — Shared : le partage pour coordination

L’état Shared marque le passage de l’utilisation interne à l’utilisation interdisciplinaire. Le conteneur est maintenant visible par les autres équipes de projet et par le Lead Appointed Party (le sujet coordinateur de l’ensemble de la commande d’information).

Qui accède au conteneur Shared

Lorsque un conteneur passe à l’état Shared, sa visibilité s’étend à : 

• la Task Team qui l’a produit (avec des droits de modification limités) ;
• les autres Task Teams du projet (en lecture, pour coordination) ;
• le Lead Appointed Party (pour révision et vérification) ;
• le client (Appointing Party) selon les règles du Cahier des Charges Informatiques.

Que peut-on faire

Dans l’état Shared, le conteneur d’information devient un outil de coordination entre disciplines, il peut donc être utilisé pour : 

• consulter le conteneur pour des activités de coordination ;
• annoter, commenter, ouvrir des problèmes (typiquement via BCF) ;
• vérifier la cohérence, la détection de conflits, la coordination disciplinaire ;
• demander des modifications à la Task Team productrice via le processus formel.

Dans l’état Shared, le contenu ne peut pas être utilisé pour la construction ou pour des décisions contractuelles : c’est un matériel de coordination, pas un matériel publié.

Codes de convenance typiques

L’état Shared prévoit différents codes de convenance selon l’objectif du partage : 

• S1 – Suitable for Coordination (idoneo per coordinamento) ;
• S2 – Suitable for Information (idoneo per informazione) ;
• S3 – Suitable for Internal Review and Comment (idoneo per revisione interna e commenti) ;
• S4 – Suitable for Stage Approval (idoneo per approvazione di fase) ;
• S6/S7 – Suitable for PIM Authorization / AIM Authorization.

Chaque code a des implications contractuelles et opérationnelles différentes, et doit être cohérent avec la phase du projet.

La transition vers Published

Si le conteneur passe le processus de vérification et d’approbation (Check, Review, Approve) mené par le Lead Appointed Party et/ou par l’Appointing Party, il passe à Published. Si des non-conformités sont constatées, le conteneur retourne à WIP avec les indications de correction (rework loop).

État 3 — Published : le conteneur approuvé pour l’utilisation

L’état Published marque l’approbation officielle du conteneur d’information par l’Appointing Party (le client). À partir de ce moment, le conteneur a une valeur contractuelle et peut être utilisé pour les décisions opérationnelles du projet — conception exécutive, construction, tests, gestion.

Qui accède au Published

L’accès en lecture est généralement étendu à tous les acteurs impliqués dans le projet, selon les règles du Cahier des Charges Informatiques. Les droits de modification sont en revanche extrêmement limités : un conteneur Published ne peut pas être modifié directement. Tout changement nécessite l’ouverture d’une nouvelle révision, qui recommence le cycle depuis le WIP.

Que peut-on faire

Une fois l’état Published atteint, le conteneur d’information assume un rôle différent par rapport aux phases précédentes et il est possible de : 

• utiliser le conteneur pour des activités contractuelles, construction, gestion ;
• consulter de manière définitive et autorisée ;
• citer dans des documents contractuels et des communications formelles ;
• NE PAS modifier directement : il faut ouvrir une nouvelle révision.

Codes de conformité typiques

• A1-AN – Authorized for [scope] (autorisé pour un objectif spécifique) ;
• B1-BN – Partially signed-off (partiellement approuvé, avec réserves) ;
• CR – As Constructed Record (enregistrement du construit) ;
• PR – Published Record (publication finale d’archive).

Le code spécifie le champ d’utilisation autorisé : par exemple, A1 peut signifier « Authorized for Construction », CR « As-built record », etc.

Codes de révision

Parallèlement aux codes de conformité, les révisions du conteneur sont suivies avec des codes de révision : 

• P01, P02, P03… – révisions en phase de conception (Pré-construction)
• C01, C02, C03… – révisions en phase de construction (Construction)

La combinaison du code de conformité et du code de révision identifie de manière unique l’état sémantique du conteneur : « S2-P03 » signifie « apte à l’information, troisième révision pré-construction ».

La transition vers Archived

À la fin de l’utilisation opérationnelle du conteneur d’information – typiquement à la fin de la phase de projet ou à la fin du contrat – le conteneur est archivé. Cela ne signifie pas le retirer : cela signifie le geler dans un état de lecture seule permanent.

État 4 — Archived : la référence historique immuable

L’état Archived conserve le conteneur d’information comme référence historique. C’est l’état final du cycle de vie, mais cela n’implique pas l’obsolescence : au contraire, cela représente la mémoire autorisée du projet.

Qui accède à l’Archived

L’accès est généralement garanti en lecture seule à tous les acteurs qui avaient le droit de visibilité sur le conteneur Published. L’archivage n’élimine pas les droits de consultation, mais bloque toute modification.

Que peut-on faire

Dans l’état Archived, le conteneur d’information perd toute fonction opérationnelle active et est conservé comme preuve stable du parcours d’information du projet dans lequel il est possible de : 

• consulter le conteneur pour référence historique, audit, litiges ;
• exporter pour transferts vers des systèmes tiers (ex. CAFM dans le cadre de Facility Management) ;
• NE PAS modifier, NE PAS supprimer : le conteneur est gelé.

Pourquoi l’archivage est critique

Du point de vue réglementaire et contractuel, l’état Archived est la preuve objective de ce qui a été produit, approuvé et utilisé pendant le projet. C’est la base documentaire pour : 

• Audit de conformité (ISO 9001, ISO 19650-5, sécurité)
• Litiges contractuels entre le client et les parties mandatées
• Vérifications de tiers (testeurs, organismes de contrôle)
• Transfert d’information au Facility Management (passation)
• Évaluation environnementale post-construction (LCA, vérification EPD).

Comment un CDE évolué gère opérationnellement les états

La norme décrit les états, mais c’est la plateforme CDE qui les rend opérationnels. Les comportements qui différencient un CDE mature d’une solution de stockage cloud concernent précisément la gestion des états.

Visualisation claire de l’état

Chaque conteneur d’information doit afficher de manière immédiate et non ambiguë son état actuel, avec des étiquettes textuelles. Un CDE évolué offre des vues filtrables par état, permettant au CDE Manager de surveiller en temps réel la distribution des conteneurs tout au long du cycle.

Transitions régulées par des workflows

Le passage entre états ne se fait pas par action arbitraire : c’est le résultat d’un workflow structuré que le CDE active automatiquement. Le workflow identifie les acteurs impliqués (par rôle ou par utilisateur), les notifie, recueille les approbations et enregistre la transition dans l’audit trail.

Une plateforme CDE évoluée permet de configurer différents workflows pour différents types de conteneurs : un modèle IFC structurel suivra un workflow différent d’un document contractuel, et un CDE mature permet de définir ces flux de manière granulaire.

Permissions conditionnées à l’état

L’accès et les actions autorisées dépendent de l’état : un utilisateur peut avoir des droits de modification sur le conteneur en WIP mais seulement en lecture lorsqu’il passe à Shared. Le CDE doit gérer cette matrice de permissions dynamique de manière automatique, sans nécessiter d’interventions manuelles à chaque transition.

Versionnement cohérent avec les états

Chaque transition d’état peut générer une nouvelle version du conteneur. En particulier, le retour de Shared à WIP après une révision génère une nouvelle version du contenu tout en maintenant la précédente visible comme référence historique. Lorsqu’une révision est chargée, le workflow en cours sur la version précédente est interrompu dans l’état où il se trouve et reste consultable comme archive du processus. Sur la nouvelle version, un nouveau processus peut commencer en cohérence avec le contenu mis à jour.

Formulaires associés aux états

Un CDE évolué permet d’associer des formulaires structurés (checklist, fiches de vérification, validations techniques) aux états du conteneur. Un formulaire peut être remplissable uniquement lorsque le conteneur est en Shared, ou devenir obligatoire avant d’autoriser le passage à Published. Cela permet de conditionner les transitions à la collecte de données structurées, et non seulement à une approbation générique.

Codes de convenance : le guide de référence

Les codes de convenance sont le complément sémantique des états. Alors que l’état indique « où » se trouve le conteneur dans le cycle, le code de convenance indique « pour quoi » il est approprié à ce moment-là.

Tableau complet des codes de convenance ISO 19650

Note sur la variabilité

Les codes de convenance ici énumérés sont ceux recommandés par les normes UK BIM Framework et largement adoptés comme référence internationale. La norme ISO 19650 n’impose pas les codes exacts : chaque organisation ou projet peut adopter sa propre convention, tant qu’elle est définie dans le Cahier des Charges Informatif.

Codes de révision : la traçabilité des versions

À côté des codes de convenance, les codes de révision tracent la version du conteneur. La convention la plus répandue : 

• P01, P02, P03… pour les révisions en phase de conception (pré-construction);
• C01, C02, C03… pour les révisions en phase de construction (construction);
• certaines organisations ajoutent D01 pour les révisions après la remise au client (déployé).

La combinaison « Convenance – Révision » (ex. « S2 – P03 », « A1 – C02 ») identifie de manière unique l’état sémantique du conteneur à un moment spécifique.

Comment ils sont gérés dans le CDE

Un CDE évolué génère automatiquement les codes de révision en les incrémentant à chaque nouvelle version, évitant ainsi les erreurs de dénomination manuelle. Le système doit également empêcher la « réutilisation » de codes déjà utilisés (ex. sauter de P01 à P03 sans passer par P02), afin de maintenir la cohérence et la traçabilité.

Erreurs courantes dans la gestion des états

Après des années d’implémentation du CDE dans les projets AEC, certains erreurs récurrentes émergent qu’il est bon de connaître pour les éviter : 

• Confondre Shared avec Published : Shared n’est pas publié. Il n’a pas de valeur contractuelle, ne peut pas être utilisé pour des décisions opérationnelles, ne justifie pas la construction. Utiliser un conteneur Shared comme s’il était Published est l’une des causes les plus fréquentes de litiges.
• Sauter la phase Shared : certaines équipes chargent directement des conteneurs en état Published sans passer par Shared. Cela contourne le processus de coordination interdisciplinaire et peut conduire à des conflits non détectés, des incohérences entre disciplines, un manque d’alignement sur les exigences d’information.
• Traiter l’archivage comme une suppression : le conteneur archivé ne doit pas être supprimé : il doit être gelé en lecture seule. La suppression définitive peut violer des obligations de conservation contractuelles et réglementaires, et compromettre la capacité de défense en cas de litige.
• Modifier directement le Published : un conteneur Published ne peut pas être modifié ; chaque changement nécessite une nouvelle révision qui reprend le cycle. Modifier « silencieusement » un conteneur Published (souvent pour de « petites corrections ») annule la traçabilité et mine la validité de l’ensemble du processus d’information.
• Permissions non cohérentes avec l’état : permettre à une Task Team de modifier librement un conteneur Shared, ou pire Published, d’une autre discipline est une grave erreur de configuration du CDE. Les permissions doivent être conditionnées à l’état et séparées par rôle.

Les 10 exigences d’une plateforme CDE conforme ISO 19650

La gestion correcte des états n’est qu’une des dix exigences fondamentales d’une plateforme CDE conforme. Si vous évaluez une plateforme ou souhaitez vérifier la conformité de celle que vous utilisez, nous avons préparé un outil gratuit : 

Essayez le simulateur interactif des états — Visualisez le cycle de vie du conteneur d’information, cliquez sur chaque état pour découvrir les permissions, acteurs, codes et transitions. Idéal pour la formation de l’équipe et l’intégration des nouveaux utilisateurs.

Le CDE comme écosystème : la gestion des états dans les plateformes réelles

Les plateformes CDE évoluées mettent en œuvre la gestion des états de manière à aller au-delà de la simple étiquetage. Dans l’écosystème usBIM d’ACCA, par exemple, usBIM.platform — le CDE conforme ISO 19650 — gère les états du conteneur d’information comme des éléments actifs du workflow, avec des transitions régulées, une visualisation claire de l’état d’avancement et une traçabilité complète.

Autour de usBIM.platform, l’écosystème offre des outils spécifiques pour les activités qui se déroulent dans les différents états : 

• dans le WIP, l’équipe collabore avec des applications comme usBIM.editor, usBIM.writer pour la production et la modification des contenus ;
• dans le Shared, interviennent usBIM.clash pour la coordination, usBIM.bcf pour le suivi des problèmes interdisciplinaire, usBIM.compare pour la comparaison entre révisions, usBIM.federation pour la fédération des modèles disciplinaires ;
• pour la qualité informative qui conditionne le passage à l’état Shared et Published, intervient usBIM.dataquality avec la validation IDS selon les exigences du Cahier des Charges Informative ;
• dans le Published et l’Archived, la plateforme garantit un accès en lecture seule, un audit trail complet, un versionnement cohérent et un export vers des systèmes en aval (ex. usBIM.maint pour le Facility Management lors de la passation).

La valeur réside dans le fait que les états ne sont pas seulement gérés par la plateforme, mais orchestrés avec les applications spécialisées : chaque état active automatiquement les outils et les workflows appropriés, réduisant ainsi le risque d’erreurs opérationnelles.

Questions fréquentes (FAQ)

Que sont les états du conteneur d’information ?

Les états du conteneur d’information sont les quatre phases du cycle de vie d’une information de projet définies par la norme ISO 19650 : Work in Progress (WIP), Shared, Published, Archived. Chaque état détermine qui peut voir, modifier et utiliser le conteneur, avec des règles de transition tracées et autorisées.

Quels sont les quatre états ISO 19650 ?

Les quatre états sont : Work in Progress (WIP), en cours de traitement interne à l’équipe ; Shared, partagé pour la coordination interdisciplinaire ; Published, approuvé pour l’utilisation contractuelle ; Archived, archivé comme référence historique immuable.

Que signifie WIP dans le CDE ?

WIP (Work in Progress) est l’état initial du conteneur d’information, dans lequel seul l’équipe productrice (Task Team) a accès. Dans cet état, il est possible de modifier et de supprimer librement le contenu. C’est le seul état dans lequel le conteneur peut être supprimé avant le partage formel.

Quelle est la différence entre Shared et Published ?

Le conteneur Shared est partagé entre disciplines pour la coordination mais n’a pas de valeur contractuelle. Le conteneur Published est formellement approuvé par le client (Appointing Party) et peut être utilisé pour des décisions opérationnelles, la construction, la contractualisation. Shared n’est pas équivalent à Published.

Qu’est-ce que le processus CRA ?

Le CRA (Check, Review, Approve) est le processus de vérification, de révision et d’approbation qui régule les transitions entre les états du conteneur d’information. Il est normé par la norme ISO 19650-2 et est le mécanisme par lequel un conteneur passe de Shared à Published.

Un conteneur Published peut-il être modifié ?

Non, un conteneur d’information en état Published ne peut pas être modifié directement. Chaque changement nécessite l’ouverture d’une nouvelle révision qui recommence le cycle depuis l’état WIP. Cela garantit la traçabilité et l’immuabilité contractuelle des versions publiées.

Que se passe-t-il lorsque l’on charge une nouvelle version d’un fichier dans le CDE ?

Lorsqu’une nouvelle version d’un conteneur d’information est chargée, la version précédente est conservée dans l’historique. Si un workflow était en cours sur la version précédente, celui-ci est généralement interrompu à l’état où il se trouve et reste consultable comme référence historique, tandis